A connected model can help operators investigate faults and test changes. Its usefulness depends on knowing which decisions it can support, where its predictions hold and who keeps it aligned with the physical asset
A building operator investigating high overnight electricity use does not necessarily need a more detailed three-dimensional model. They need to know which equipment was running, whether it should have been running and what will happen if its operating schedule changes. A digital twin becomes useful when it connects those questions to evidence about the particular building.
That creates a more demanding brief than displaying sensor readings on a model. The owner must decide what the system is expected to explain or predict, how uncertainty will be communicated and how an operator will act on the result. Otherwise, an impressive interface can conceal a weak relationship between the asset on screen and the asset outside.
The same principle applies to infrastructure. A model supporting drainage maintenance has different information needs from one examining bridge deterioration or station energy demand. Sharing a platform does not make their evidence interchangeable. Each application needs a defined purpose and a defensible connection between observations, model behaviour and the decision being taken.
Define the decision before the digital twin
The government’s published digital twin definition emphasises a known physical counterpart, suitable timing, stated assumptions and a specified validation envelope. That last term describes the conditions within which the representation has been shown to behave adequately. The definition also recognises connected, semi-connected and disconnected states, provided their status is recorded.
For a facilities team, this suggests a precise starting question: can the system identify avoidable plant operation while maintaining required internal conditions? The initial scope might cover an air-handling system and its associated zones. Modelling every door handle would add little if the real uncertainty concerned occupancy schedules, ventilation demand and the relationship between controls and equipment.
A useful brief states both the action and its constraints. An operator might approve a schedule adjustment, request an inspection or reject a recommendation because a room has changed use. Specifying these decisions makes it possible to identify the data, expertise and permissions required. It also gives suppliers something concrete to demonstrate performance against.
An asset relationship is more than a live data feed
The Gemini Principles, developed through the Centre for Digital Built Britain, place purpose, trust and function at the centre of digital twins. Their description links data about a physical asset to better decisions and outcomes, with accuracy suited to the intended purpose. This remains a useful challenge to projects that measure success mainly through the number of connected sensors.
Consider a pump replaced during maintenance. Its old identifier may remain in the asset register while the new equipment has a different performance curve. A sensor may still report plausible values, and the dashboard may remain green. Yet the relationship between measured flow, electrical consumption and expected behaviour has changed. The connection is technically active while the operational interpretation is wrong.
Maintenance procedures therefore need to update the digital relationship as well as the physical equipment. Replacement, recommissioning, sensor relocation and changes to control sequences should trigger checks on identifiers, units and model parameters. This work belongs in the operating budget. Treating it as occasional software administration leaves the twin vulnerable to routine building changes.
Validation must challenge the model
Calibration adjusts a model to match observations. Validation asks whether it performs adequately on evidence not used to tune it. A heating model fitted to mild autumn conditions may reproduce those weeks closely and still behave poorly during a cold spell. Agreement alone is therefore insufficient without understanding which conditions were actually tested.
A sensible project test could reserve part of the available operating record, then compare predictions with measured outcomes for that period. It should examine errors during relevant events, such as morning start-up or changing occupancy, as well as overall averages. An average can look acceptable while hiding a recurring failure at precisely the time operators need guidance.
The acceptance threshold should reflect the decision. Small errors might be tolerable for screening buildings for further investigation but unacceptable for a decision with little operating margin. Owners should ask how uncertainty propagates from sensors and assumptions into the recommended action. The result should distinguish a strong recommendation from a request for more evidence.
NIST’s digital twins research programme identifies verification, validation and uncertainty quantification as part of the work needed for credible implementations. Its manufacturing context differs from an occupied building, but the underlying distinction is valuable: correctly running software, a suitable representation, and quantified confidence in results are separate questions.
Make missing and ageing data visible
Operational data has several clocks. A temperature reading may update frequently, an inspection annually and a component’s condition only when someone opens an enclosure. Combining them in one interface can make them appear equally current. The display should retain their dates, origins and quality flags, particularly where a recommendation depends on an old observation.
Missing measurements should not quietly become measured facts. Interpolation and estimation can keep an analysis running, but operators need to see when they are being used. A report should also distinguish a sensor reporting zero from a sensor that has stopped reporting. Those states can require entirely different responses, even if a poorly designed chart presents them similarly.
An operational twin also needs a defined response to unexpected conditions. If refurbishment changes occupancy or plant configuration, earlier validation may no longer apply. A controlled pause, restricted use or renewed validation can be more useful than continued predictions that carry an outdated appearance of confidence. The owner needs to know who can make that call.
Keep the building safe when the connection fails
Digital twins can inform controls without assuming responsibility for every protective function. In its building example, the government definition explicitly separates the twin from the control system’s ability to function safely without it. This distinction matters when an owner considers recommendations that move beyond advisory dashboards toward automatic changes to equipment settings.
The NIST report on digital twin security and trust examines cybersecurity and trust considerations associated with representing real systems electronically. For an asset owner, a practical implication is to assess the whole connection: sensors, data transfer, user access, models and the route by which an output might influence physical equipment.
Access should follow the task. An analyst testing a scenario need not have permission to change operating setpoints. A contractor maintaining one system need not see every connected building. Recording who changed a parameter, why it changed and which result followed also helps operators investigate errors. Security and operational accountability meet in the same audit record.
Buy continuing usefulness, not a handover image
The commercial comparison should include the work needed after commissioning: maintaining integrations, checking sensors, updating models, supporting users and revisiting validation. It should also identify how data and configuration can be exported if the provider changes. A twin that becomes unaffordable to maintain may lose its asset relationship long before the building reaches the end of its life.
Contractual responsibility should be equally explicit. The owner needs to know who investigates a failed data feed, who approves a model change and who answers an operator’s question about an unexpected result. A maintenance agreement that covers software availability without covering those activities can leave the system online while its practical usefulness deteriorates.
Benefits need equally careful measurement. A fall in energy use after introducing a twin could reflect milder weather, reduced occupancy or an unrelated plant upgrade. A credible evaluation records the actions the system prompted and examines outcomes against an appropriate baseline. It includes the staff time needed to investigate false alarms and maintain the information.
The first deployment can be small enough to learn from while still testing the full operating process. Select a persistent problem, connect the necessary evidence and follow the recommendation through to a documented action. Operators can then judge whether the system improved the decision, whether the result lasted and which additional assets merit the same investment.
The post Digital twins earn their place when operators can trust the next decision appeared first on Planning, Building & Construction Today.
