Digital twin of a building: why the model diverges from the asset
A building digital twin is almost always launched during commissioning: the model matches the asset, the load forecast matches actuals, and reports inspire confidence.
After a month or two of operation, the picture changes — the calculation promises one thing, meters show another, and the operator stops opening the model. The divergence between model and asset grows not in a jump but quietly: first by a few percent, then by a quarter.
The first source is fragmented metering systems. HVAC, electrical, water, access, and elevators each write to their own loop, with their own polling interval and their own point dictionaries.
The twin receives an already merged export where gaps are filled with averages, and manual operator edits are indistinguishable from instrument readings. The model learns not the physics of the asset but the peculiarities of that export.
The second is sensor data quality: calibration drift, stuck values, a device on the sunny side or near a supply grille produce a bias that the model takes as a pattern. Gaps over weekends and gateway outages add breaks to the series.
The third is model obsolescence: repartitioning, unit replacement, a change in a tenant's operating mode, and seasonal transition change characteristics, while the twin keeps calculating using the old topology.
We examine how this is closed in practice: a unified collection loop with validity checks at the input, model versioning, and regular recalibration against actuals — instead of a one-off project that a quarter later becomes a beautiful but incorrect diagram.
What a working model delivers: effect in asset operation
The effect of the model is measured not by a metric on a holdout sample but by how the asset goes through the season.
The foundation here is point semantics: if they are described according to Brick Schema rather than internal controller names, one model reads an air handling unit, a chiller, and a metering node in the same way — and survives the next reconstruction without rewriting logic.
Early fault detection is based on deviation from the equipment's own behavior, not on setpoint thresholds. The model sees that coolant flow through a fan coil diverges from the forecast at the same load and raises a signal before protection trips.
Fault localization time is reduced from hours of calling contractors to minutes for a specific node, and downtime reduction comes not from faster dispatch — the emergency mode is resolved during a scheduled shift.
Energy consumption forecasting works as a baseline: the model accounts for weather, building load, and ventilation schedule, so deviation is visible a day earlier than in reporting.
Heat and electricity consumption for ventilation no longer depends on the unit running on the same schedule for years — setpoints are adjusted to the actual profile.
Reducing false alarms is not cosmetic: when the model assesses the state of a node as a whole rather than a single threshold exceedance, trips during starts and transient modes leave the stream. The operator receives three or four priority signals instead of dozens.
Along with this, an entire class of failures disappears — non-emergency modes that previously persisted until equipment failure.
How to build a twin: static model, online loop, hybrid
The choice of scheme is determined not by the complexity of the model but by how much the data in it diverges from the real asset.
A static model is assembled from design documentation and measurement results: geometry and composition of engineering systems are fixed at handover, and thereafter divergence grows with each repartitioning.
An online loop closes the model onto telemetry — sensors, meters, ventilation and pump group controllers — and updates state against actuals.
A hybrid takes from both what works: the load-bearing frame and systems are described statically, while operating parameters are pulled from the stream. Which one suits a specific asset is decided by the frequency of changes and completeness of documentation.
| Option | When it suits | Limitations |
|---|---|---|
| Static model based on design | Asset was commissioned recently, documentation is complete, systems have not been reconfigured | Data becomes outdated after the first repartitioning; load forecasts diverge from actuals; updates only by manual reassembly |
| Online update loop | Dense telemetry, frequent mode changes, an operations service with access to data exists | Sensor uptime is critical; if the stream is lost, the model loses state; sensitive to gaps and calibration drift |
| Hybrid scheme | Asset has been in operation for a long time, part of documentation is outdated, some systems are under constant monitoring | Setup is more expensive: static and streaming loops must be separated and their frequencies synchronized; rollback on error is more difficult |
We check the limitations of each option on your data before work begins — the scheme is chosen based on facts, not on its name.
Implementation stages: from asset survey to trial operation
Implementing a digital twin is a sequence where each step relies on the previous one. A skipped asset survey or incomplete inventory of metering points yields plausible but incorrect estimates — and trust in the model is lost at the very first incident review.
- Asset survey. We walk the building, record the composition of engineering systems, actual topology, and equipment operating modes over a day and a season.
- Inventory of metering points. We reconcile sensors and controllers with the diagram: what actually transmits data, at what frequency, where there are gaps, duplicates, and unreliable readings.
- Data schema. We describe the path of telemetry to storage, bring tags to a unified dictionary, and define rules for handling gaps and outliers.
- Model assembly. We connect the physics of loops — thermal, air, hydraulic — with data and tune parameters for the specific building, not an averaged asset.
- Mode setup. We calibrate by seasons and load scenarios: working hours and weekends, peak hours, transition periods.
- Validation on historical data. We run the model on past telemetry — the divergence from actuals must fit the tolerance not "on average" but on every characteristic interval.
- Trial operation and handover. The model runs in parallel with dispatch, engineers compare its prompts with their decisions; based on results, we adjust the loops and hand over regulations, documentation, and the procedure for retraining when changes occur at the asset.
Validation on historical data and trial operation are not formalities: they show which loops the model describes confidently and which should be simplified or supplemented with measurements.
What the customer retains: configurations, diagrams, regulations
We hand over not only a working twin but also a complete set of materials by which the operations service can maintain it independently. Each artifact covers its own layer: data provenance, access rights, model update procedure, and actions for deviations.
- Documentation set — solution architecture, model composition, purpose of services and connections between them, list of failure points with diagnostic procedure.
- Data flow diagrams — which sensors and engineering systems provide readings, at what intervals, where they are stored, and how they reach the model.
- Access policies for asset data — roles, separation of rights by zones and systems, logging of requests, procedure for granting and revoking access.
- Model update regulation — retraining triggers (reading drift, new loop, change in operating mode), checks before version release, and rollback procedure.
- Instructions for the operations service — how to read model signals, what to consider a normal deviation, which actions are permissible, and when to escalate.
- Model passport — what data and over what period it was trained, applicability boundaries, and known limitations, so as not to expect a forecast where it does not work.
- Acceptance test protocols on real asset data — including scenarios with incomplete or delayed readings.
We hand everything over in editable form and place it in your environment: configurations, diagrams, and model versions — in your versioning system.
After that, the twin lives without our involvement, and we engage on a targeted basis — to expand the set of models or add scenarios.
Case study: an office center with three ventilation loops
The operations service of the office center Severny Park managed three ventilation loops — supply, exhaust, and shaft pressurization — using paper logs and tenant complaints.
Telemetry from 480 points was written to archive, but no one compared it: divergence between setpoint and actual was noticed when a wing became stuffy or cold.
Fault localization took from 4 to 6 hours of rounds and reconciliation, and a "stuck" damper actuator could persist for weeks.
What was changed in the model
We assembled a digital twin of three loops: a model of air and thermal balances to which sensor readings are fed in real time.
The model was trained on an archive of two heating seasons and 70 labeled incidents, and the deviation threshold from the forecast was configured separately — to filter out fluctuations when gates open and during cleaning.
The service engineers received an incident card: node, loop, deviation dynamics, and a hint about what to check first.
Result in numbers
| Metric | Before | After |
|---|---|---|
| Fault localization | 4–6 hours | 15–20 minutes |
| Accuracy of failure forecast one day ahead | 61% | 89% |
| False alarms per month | 28 | 4 |
| Repeat callouts for the same node | 3 out of 10 | 1 out of 10 |
The operations service's feedback came down to one phrase: "we stopped looking for a needle in a haystack." The burden of rounds decreased, and forecast-based repairs began to be scheduled for the day shift, without night emergencies.
The twin lives together with the asset: the model is retrained on new incidents, so accuracy does not drop after loop reconstruction.
How does a telemetry-based model differ from a heat engineering calculation?
A heat engineering calculation answers the question of what the building should be: design resistances of structures, standard air exchange rates, a typical weather year.
The approach is deterministic and reproducible — the result goes into the design, expert review, and energy passport.
But the actual behavior of the building differs from the calculation: it does not know about overheating during the transition period, about inflated setpoints of air handling units, or about rooms that cool faster than others.
A model based on actual data is therefore built on hourly series from sensors — temperature and coolant flow, setpoints, valve positions — plus an archive of outdoor weather.
From these series, the relationship between control actions and the building's response is reconstructed, including things absent from the design: infiltration through junctions, thermal bridges, inertia of massive floor slabs, and actual equipment operating schedules.
The difference is not so much in accuracy as in purpose: the calculation gives an averaged picture for design decisions, while the model gives a forecast for a specific building on specific days.
The former is needed to prove compliance with requirements, the latter — to manage: reschedule schedules, cut supply during off-peak hours, and see equipment overload in advance.
The choice of method is determined by the task, but in practice the approaches are combined: the calculation sets the physical framework and boundaries of permissible values, and data refines it — the model does not produce physically impossible forecasts.
It is considered working when the error on a holdout period fits within an agreed percentage, not when the curve has beautifully matched history.
Concerns about integration, data quality, and operating modes
Concerns about a digital twin rarely concern the model itself — they arise at the interface with the asset: some passports and diagrams are lost, engineering systems have been expanded over years by different contractors, and layouts change after launch. Below are four questions asked most often, with engineering answers.
Is there enough data if the asset documentation is incomplete?
We train the model on what exists: measurements, operation logs, sensor reading history.
We mark gaps explicitly and fill them with physically justified estimates, and we deliver the result with a completeness flag — an area with little data is marked as less reliable rather than given a random number.
How does the twin integrate with systems that have been operating at the asset for a long time?
We do not change anything in the existing loop: we read data through standard exchange interfaces and documented access points, and cover disputed places with adapters. We connect legacy controllers based on what they provide — even if these are manual exports on a schedule.
What happens after repartitioning or equipment replacement?
Retraining is a planned stage, not a rebuild from scratch. A change in layout or operating modes is updated by retraining on new data; a full rebuild is needed only when the physics of the asset changes. We record in advance what we do and what falls to your operations service.
Who is responsible for model errors?
We are responsible for model correctness, reproducibility of calculations, and timely updates; the customer is responsible for completeness of data from the asset.
We fix the boundary in the contract: quality metrics, support regulations, and the procedure for analyzing discrepancies between forecast and actuals.
Let's discuss the task: what we need from you for an assessment and work plan
The assessment of a digital twin is accurate exactly to the extent that the source data is complete: without a telemetry archive, there is nothing to train the model on; without as-built survey, the geometry diverges from the asset; and without engineering system diagrams, it is unclear where to place virtual measurement points. Therefore, we start not with a calculation but with an inventory of what you already have.
- Floor plans and system diagrams in source formats (DWG, IFC, Revit) plus as-built survey, if one was performed.
- Engineering sections — ventilation, heating, electrical, elevators — with metering nodes and sensor installation locations.
- List of existing sensors and controllers with protocols (BACnet, Modbus, KNX) and a history export for several months.
- Data boundaries: what is permissible to move to an external environment, who the owner is, and what access restrictions exist.
- List of processes you want to see in the twin: indoor climate, energy consumption, room occupancy, equipment wear.
- A responsible person on your side and a window for approvals — the timeline directly depends on this.
Then the procedure is as follows: a call and clarifying questions about inconsistencies in the data, then an assessment with a staged work plan — geometry collection, telemetry connection, model training and calibration, a pilot loop on one floor or one system, handover of the solution with documentation and training for your team.
Until the plan is agreed, neither party is bound by obligations: you see the pilot boundaries, scope of work, and acceptance points.
