How do you turn a BIM model into an operational digital twin?

Attaching live readings to model objects produces something that looks like a digital twin. Whether it works as one depends on less visible work. The operating decision the twin must support has to be agreed; the model has to be checked against the installed building for that scope; asset identities have to be reliable; the operational data has to be mapped to those identities; any analysis has to be validated separately from the data connections; and a process has to exist that keeps everything current after handover. That last step is often missing from the plan, and without an owner for it the twin begins to part company with reality on the day it is delivered.

One decision, one system

Choose a single system and a single operator task, such as investigating comfort complaints in the areas served by a chilled-water system. That choice fixes which assets, spaces, relationships and data points matter, and keeps the first phase affordable.

Check the model against the building

Design and construction models are produced for delivery, not operation, so for the chosen scope they need testing against reality. Do the assets in the model match what was installed, by make, model, location and serial number? Are system relationships recorded, so that you can see which pump serves which circuit and which unit serves which space? Are identifiers unique and consistent with the labels on site? Are maintenance documents linked to the right assets?

The gaps should be recorded. A model becomes an authoritative operational reference only once they have been resolved for the scope that matters.

Decide which system is the source of truth

Not everything belongs in the twin itself. Each kind of information should have an authoritative home:

The twin links these sources by identifier. Copying every field into it would only create reconciliation work.

Map the operational data

Each BMS point and meter must be mapped to the right asset and space, with units, timestamps and quality indicators. IFC, the open BIM exchange schema (ISO 16739-1:2024), covers information for operation and maintenance, but BMS points and their links to equipment are often absent from a handover model and have to be added. An operational ontology such as Brick can hold those relationships in a documented, reusable form.

The mapping should be proved on a handful of assets with known locations and connections. Switch something, and confirm that the right object in the twin changes.

A correct reading is not a correct diagnosis

Connectivity and analysis are separate claims and need separate evidence. If the twin compares actual with expected behaviour, that logic must be tested against known events and across different operating conditions, and the limits of its validity recorded.

Plan for the building changing

Equipment is replaced, spaces are re-planned, controllers are upgraded. For each kind of change, someone must update the relevant records in a defined order and verify the result. ISO 19650-3:2020, which ISO has put under revision, sets out information management for the operational phase of assets; the practical consequence is that the asset information model has to be maintained as a living record, and the twin depends on it.

Allocate the work before tender

A connected twin crosses several appointments, and problems gather at the joins between them. Each piece of work needs an owner, written into the relevant contract:

Some decisions belong to the owner alone, and are best taken before anyone is appointed:

• the first system and operator task in scope;
• the identifier convention, and which system holds the master record;
• which semantic model, in which version, holds the point-to-asset relationships;
• that the mappings and data model are the owner's deliverable, exportable in a documented form;
• the acceptance tests the twin must pass for its first task.

What to expect at handover

The handover itself should include:

• the scope covered and the evidence that it was verified;
• the point-to-asset mapping and how it was tested;
• validation records for any analytical functions;
• named responsibilities and a procedure for updates;
• a way to show when information is stale.