NimrodBuilding operations, connected.
All articles

Integration standards

More contractors. One system model.

Use shared equipment definitions to keep integrations consistent through expansions, retrofits, and handoffs.

Nimrod2 min readFacility operations / Field notes

An original installation may be carefully organized. Several projects later, the same kind of air handler can appear under four naming conventions, three folder structures, and different units. Each project may make sense on its own while the portfolio becomes harder to understand.

This is design drift in systems integration: the gradual accumulation of different ways to represent the same thing. Nimrod’s ontology provides a common structure that can continue across those handoffs.

Recognize what accumulates.

A supply-air temperature might arrive as SAT, DischTmp, SA-T, or AI_17. Fan status might be a number, a string, or a boolean. A controller-centric tree and an equipment-centric folder may organize equivalent systems very differently.

These differences become operational work when a team needs a consistent dashboard, a comparison across buildings, or a reusable integration template. Someone must identify the meaning behind each source convention.

[ 08 / DESIGN DRIFT ]

More contractors.
One system model.

Years of additions, replacements, and handoffs leave the same kind of equipment represented different ways. Nimrod’s ontology gives every integration a common structure.

A building’s life, project by projectIllustrative integrations
The accumulated conventions

Every handoff leaves a mark.

Different labels, units, and organization.

Nimrod ontology

The standard every integration binds to.

The consistent representation

The meaning stays the same.

Common classes, datasets, and point roles.

AHU-01Contractor A
SAT57.2 °FSF_STS1
Equipment folders
AHU07Contractor B
DischTmp14.0 °CFanProofOn
Flat point list
BLDG2_AHU_3Contractor C
SA-T57.2 °FSF_RUNTrue
Controller / Points
AirHandler_04Contractor D
AI_1714.0 °CBI_041
Vendor / Device / IO
One common definition
Equipment / HVAC

AirHandlingUnit

AirSupply Air TemperatureKind / TemperatureDefaultStatusKind / State
Inherited structure Typed point roles Defined relationships
Bind each integration
AHU-01AirHandlingUnit
Supply Air Temperature57.2 °F
StatusRunning
AHU07AirHandlingUnit
Supply Air Temperature57.2 °F
StatusRunning
BLDG2_AHU_3AirHandlingUnit
Supply Air Temperature57.2 °F
StatusRunning
AirHandler_04AirHandlingUnit
Supply Air Temperature57.2 °F
StatusRunning
04 projects 01 shared equipment class

New contractor. Same point roles. Same equipment structure.

Common class definitions and reusable binding templates keep the model consistent as the system evolves. Source point names stay connected to their equipment.

Explore the ontology

Explore four project handoffs. Different source conventions bind to the same equipment class and point roles.

Define a common destination.

An equipment class describes the representation the rest of the application can expect. For an AirHandlingUnit, that may include shared datasets and defined roles for supply-air temperature and status.

The integration binds its source Points to that structure. Equipment templates can reuse reviewed organization and binding patterns. The source name stays connected to the equipment, while operators and downstream views can work with a consistent meaning.

Review the meaning, not just the label.

A standard is useful only if the integration actually follows it. Check the source property or register, its units, the state interpretation, and the equipment relationship. A familiar label alone cannot establish that a Point represents the right measurement.

The illustration uses equivalent temperatures and fan states to show the intended consistency. Real projects still require the engineer to verify those mappings and the behavior of the source systems.

  • Agree on the equipment class and required point roles before the next project.
  • Review units and state mappings against the source equipment.
  • Reuse approved templates and document departures from the shared model.

Carry the standard into the next project.

The next expansion should add instances to a model the operations team already understands. The contractor can use a different controller or source naming convention without making every operator learn a different organization.

A shared ontology gives the portfolio a continuity mechanism. It makes expectations explicit and reusable, so standards can remain part of the working system as vendors, equipment, and teams change.

Keep exploringFind your deployment
All articles