How do BIM and IFC relate to operational building ontologies?

They describe the same building for different purposes. BIM (building information modelling) and IFC (Industry Foundation Classes, the open data schema for exchanging BIM information) describe a building as designed and constructed: its spaces, systems, components and their properties. Operational ontologies such as Brick, Project Haystack or RealEstateCore describe the context applications need to interpret live and historical data, such as which sensor belongs to which equipment and which equipment serves which space. Both know about rooms and air-handling units, but they were built for different jobs.

That overlap is both an opportunity and a trap. Connected through shared identities, the two let the effort spent on project information carry on working after handover. The trap is assuming that a design model automatically describes the building as it actually operates.

What IFC can carry

IFC, published as ISO 16739-1, covers life-cycle phases up to and including operation and maintenance, according to ISO's abstract. It can therefore carry a great deal of what operations need: equipment identity, type, location, system membership and selected properties. What a particular export actually contains depends on the modelling brief and on the model view definition, the subset of the schema, that the software implements.

The gaps operations usually have to fill

Handover models vary, but the typical picture is uneven:

An IFC export is a useful starting point, then, though it seldom maps BMS points to equipment.

Building the bridge

The single most valuable decision is to agree one identifier per asset and per space, and to use it in the model, the asset register, the BMS and the operational ontology alike. Everything else depends on it.

With that in place, whatever is reliable in the model, such as identity, type, location and system, can be reused once it has been checked against the installed condition. The operational relationships the model lacks, such as feeds, serves and has point, are then added in the operational ontology and linked to the same identifiers. Every transformation and source should be recorded, so that any fact can be traced back to the model, a survey or a commissioning record. The mapping is then tested the way an operator will use it: raise a test alarm on a handful of points from different systems and floors, and check that each leads straight to the right asset, room and manual.

Keeping the two aligned

The model and the operational ontology will fall out of step unless someone keeps them aligned. When a unit is replaced, it may need a new asset identity while keeping the same functional relationships to its system and spaces. Who updates which record, in what order, and how the change is verified all need defining while the building is new, long before the first unit is replaced.