From BIM to Digital Twin

The reason BIM is such a natural seed for a twin is that it already contains two things a twin needs and that are expensive to recreate from scratch: geometry and structured asset data. The geometry gives you rooms, floors, zones and the spatial relationships between them. The asset data - carried in the model or in a handover schedule like COBie - gives you the equipment list: this air-handling unit, that VAV box, this meter, each with a make, model, capacity and often a location.

When you seed a twin from BIM you are effectively importing a ready-made inventory and a map. Exported through an open format like IFC, that inventory becomes the backbone of the twin's data model - the set of things the live data will later attach to. A temperature reading is just a number until it is bound to Zone L3-North; a vibration alarm is noise until it is bound to Chiller 2. BIM supplies exactly those anchors. This is why teams that kept a disciplined BIM through construction have a real head start: they are not inventing the asset register, they are inheriting it.

Be realistic about what transfers cleanly, though. Geometry usually comes across well; rich parametric data often does not, and much of a design model (fire-rating notes, construction sequencing, supplier quotes) is irrelevant to operations. A good handover strips the model down to what operations actually needs - an exercise sometimes called creating an asset information model - rather than dumping the entire design database into the twin.

There is also a discipline to how the inherited assets are identified. A twin lives or dies on consistent naming: if the same air handler is called AHU-1 in the drawings, AHU_01 in the BMS and Unit 3 on the maintenance sheet, no software can join those records automatically, and a person has to untangle them by hand. The most twin-ready projects agree a single naming and classification convention early - often aligned to a standard like Uniclass or Omniclass - and carry it consistently from the BIM through the controls tags to the asset register. That convention is unglamorous and easy to skip under deadline pressure, but it is one of the highest-leverage decisions in the whole handover, because everything the twin does downstream depends on being able to match a live stream to the right thing.

Here is the uncomfortable truth every operational twin must face: the building was not built exactly as it was drawn. During construction a wall shifts to clear a beam, a VAV box is relocated, two sensors specified on the drawings are never fitted, a pump is swapped for a different model because the specified one had a lead time. None of this is failure - it is normal construction. But it means the as-designed BIM and the as-built reality diverge, and a twin that trusts the drawings blindly will quietly lie to its operators.

So a real step in standing up a twin is reconciliation: walking the building (or its as-built survey, point-cloud scan or commissioning records) and correcting the model to match what exists. Which assets are really there? Where are they? What are the real tag names the BMS uses for them? This is unglamorous, careful work, and skipping it is one of the commonest reasons twins lose credibility - an operator clicks a room, sees the wrong equipment, and never trusts the tool again.

The gap is not a one-off, either. Buildings keep changing: a tenant fit-out moves partitions, a chiller is replaced, a floor is re-zoned. A twin is only as truthful as its last reconciliation, which is why keeping it current (below) is a governance job, not a launch-day task.

With a reconciled model of what exists, the defining move is to connect it to the live building. Practically, this means mapping each live data point - a stream from the BMS over BACnet, a meter over Modbus, a wireless sensor over MQTT or LoRaWAN - onto the corresponding asset in the model. Chiller-2 supply-water temperature streams into the Chiller 2 node; the third-floor CO2 sensor streams into Zone L3-North. The readings usually land in a time-series database (a historian) and the twin reads from there.

The hard part is rarely the plumbing; it is the mapping and naming. BMS point names are notoriously cryptic - something like AHU1_SAT_2 - and matching thousands of them to the right assets is where twin projects sink or swim. This is exactly the problem that semantic data models like Brick Schema and Project Haystack exist to solve: they give every point a consistent, machine-readable meaning and relationship (this point is the supply-air temperature of AHU-1, which feeds Zone L3-North), so software can navigate the building instead of guessing from text. Seeding from BIM and tagging with Brick or Haystack are complementary: BIM gives the assets and geometry, the tags give the live points meaning.

Once points are bound, the model updates itself. Values change on the screen because they changed in the building. That living link - not the 3D view - is the thing that makes it a twin.

A twin is not a deliverable you hand over and forget; it is a living model that decays without maintenance. Sensors drift or fail and their streams go stale; equipment is replaced but the model still shows the old unit; a re-zoning changes which sensor belongs to which space. Every one of these silently erodes trust. Within a year, an unmaintained twin can be more misleading than no twin at all, because people still believe it.

Keeping it current has two halves. The data side is largely automatable: watch for points that stop reporting, values pinned flat or wildly out of range, and flag them - the same data-quality discipline the sensing modules stressed. The model side needs a human process: a rule that whenever a space is altered or a piece of plant is swapped, the twin is updated as part of the change - ideally tied back to a maintained BIM or asset register so the two never drift apart. Some mature owners run the BIM and the twin as one continuously-updated digital thread from design through operation, so as-built changes flow straight into the operational model.

It also helps to be clear about who owns this upkeep, because a twin with no owner is a twin that decays by default. Someone - a facilities team, an integrator on a maintenance contract, an in-house analyst - has to be accountable for the model staying true, just as someone is accountable for the boilers. Budgeting a twin only as a one-off capital project, with nothing set aside for the ongoing reconciliation and data-quality work, is a common and quietly fatal mistake: the twin launches impressively and is worthless within eighteen months. Treat it like any other building system that needs maintenance, and it keeps earning its keep.

The honest test at the end of all this is the same one from Lesson 0.1: is it connected to the live building, and does it serve a decision? A spinning IFC model with no live feed is a BIM viewer. Add the live link, the reconciliation and the upkeep, and you finally have a twin worth trusting.