bimkernel · 07

Digital
twins
on site.

A model is not a twin until data flows back on its own from the real asset.

The model is handed over and frozen.

Construction lasts a few years and the building, decades. On handover day the model stops changing, but the asset does not.

Three parts and a round trip.

A physical asset, its digital replica and the connection that keeps them in sync. That connection is what makes the model a twin.

It depends on how the data travels.

Manual both ways is a model. Automatic one way only, a shadow. Automatic both ways, a twin.

Six layers, from asset to decision.

Data is born in a sensor, travels over a network, is stored with its context, is matched with the model and ends up in an action.

From scan to autonomous building.

Six steps, from the point cloud to the building that runs itself. Each one rests on the one before.

As live as the decision it serves.

Each kind of data has its own pace: geometry changes over years, occupancy in minutes and a vibration in milliseconds.

Born in design, matures in operation.

In design it simulates, during construction it compares as-built with as-designed, and in operation it monitors and learns.

Six questions it answers.

A twin earns its place through the questions it answers better than a spreadsheet or a site visit.

From a building to a country.

The most cited examples range from an instrumented bridge to the living model of an entire city. All of them started from a specific question.

More connection, more attack surface.

A twin joins the office network to the building services network. You have to decide who sees what, who owns the data and how much it costs to keep it running.

There is no single twin standard.

There is one per layer: vocabulary, information management, model, data meaning and transport. The twin stitches them together.

From the project model to the asset model.

The standard separates the model used to design and build from the one handed over for operation. The twin is fed by the second.

The model already knows what a sensor is.

The open standard has entities for sensors, actuators and time series, and a unique identifier for every element.

Let the data say what it is and whose it is.

A point called “AI-3.07” says nothing. An ontology turns it into “air temperature of zone 104, supplied by unit 1”.

Nine principles in three groups.

The UK published them so that twins owned by different parties could one day be connected. They are still the best checklist.

Each vendor pushes from its own ground.

BIM authoring vendors stretch their model towards operation. Building services and industrial vendors climb up from the data. They meet in the middle.

From the handed-over model to the building in use.

It takes the project models, keeps the assets that matter to the operator, gives them parameters and connects them to sensor streams.

Infrastructure, with its change history.

It synchronises models from many programs into an iModel that records every change, like a code repository, and attaches sensor and inspection data to it.

Game engines are the shop window.

They provide the realistic image and real-time simulation. The data and its meaning still live in another layer.

The cloud brings the graph and the scale.

The big clouds offer a twin service: a graph of entities and relationships connected to millions of readings.

A twin is a graph, not a file.

Every room, piece of equipment or sensor is a node with properties and telemetry. The relationships are what let you ask questions.

A twin without coordinates cannot be connected.

To join a building’s twin with that of its street, its network or its city, they all have to speak the same reference system.

Three worlds that need stitching together.

The BIM model is static, the semantic graph explains relationships and the building services network speaks in readings. Each has its own format.

If the GUID changes, the twin breaks.

The sensor in the model and the one on the network are matched by an identifier. Deleting and recreating an element changes it and leaves the reading orphaned.

From the controller to the cloud.

Building services speak industrial protocols. A gateway translates them into lightweight messages that the cloud stores as time series.

The twin is specified in the contract.

If the tender documents do not require assets with code, manufacturer and link to their space, the model arrives without them and nobody adds them later.

Four questions before trusting it.

Is everything that was requested there? Can it be linked? Do the relationships make sense? Is the incoming data good?

The specification, turned into a test.

One file requires every sensor to have a tag and a room, and every piece of equipment to come with manufacturer and serial number. The IFC passes or fails.

Rules for the graph.

What IDS does with the IFC, SHACL does with the graph: it checks that each sensor hangs from what it should and measures in the right unit.

A sensor can lie too.

It freezes, drifts out of calibration, loses readings or gets the time wrong. Check the data before you believe the twin.

Four rules.