A digital twin is not a 3D model with live labels on it. It is a simulation of an asset that is continuously corrected by measurements of that asset, and the useful output is not the state it reports but the gap between what it predicted and what the sensors said.
What makes it a twin rather than a dashboard
Three properties separate a twin from a monitoring view, and dropping any one of them leaves something that may be valuable but is a different thing.
- It has state that persists between observations. A dashboard renders the latest values. A twin holds an estimate of quantities that are not directly measured — the thermal mass of a room, the remaining wear on a bearing, the charge in a cell — and carries that estimate forward through time.
- It can be advanced without data. Because it embodies a model of how the asset evolves, it can be run forward to predict a future state. That is what turns it into an answer to “what happens if” rather than only “what is”.
- It is corrected by measurement, continuously. A simulation that runs open-loop diverges from reality within hours. The correction step is the twin.
The one-time 3D scan often called a twin has none of these. It is a geometry asset, and it is genuinely useful for spatial questions, but it does not track anything.
The synchronisation loop
The loop is predict, compare, correct, and it is the same recursion used for sensor fusion applied to a richer state.
for each tick:
x_pred = f(x, u, dt) # advance the model; u = known inputs
z = latest telemetry aligned to this tick
r = z - h(x_pred) # residual: measured minus predicted
x = x_pred + K * r # correct, weighted by relative confidence
emit(x, r)
Two design decisions dominate everything else here. The tick rate must be chosen against the asset’s dynamics rather than against the telemetry rate: a building’s thermal state changes over minutes, so ticking at 1 Hz burns compute to produce a state that has not moved, while a motor’s electrical state changes in milliseconds and a one-second tick misses the transient entirely.
And h, the observation function, has to include the sensor, not just the physics. A thermocouple in a wall cavity does not measure air temperature; it measures its own temperature, which follows air temperature with a lag and an offset. Modelling h as identity when the sensor has dynamics of its own pushes that mismatch into the residual, where it looks exactly like a fault.
The residual is the product
A twin whose state matches the measurements is telling you nothing you could not read directly from the sensors. Its value appears when the two disagree, because the model encodes what should be happening, and a persistent gap is a statement that something has changed in the asset.
Concretely, for a heat exchanger, the model predicts an outlet temperature from inlet temperature, flow rate and a heat transfer coefficient. If the measured outlet runs one degree below prediction and keeps drifting further, the coefficient has fallen, which means fouling. Neither the inlet nor the outlet reading is abnormal. The residual is, and it is directly interpretable as a physical parameter rather than as an anomaly score — which is the twin’s real advantage over a purely statistical detector.
This makes residual monitoring the natural anomaly method for a twin, and it inherits all the structure described in cross-sensor anomaly detection: a residual should be near zero-mean and stationary in health, so sustained excursions and changes in residual variance are the signals. The difference is that a physics-based residual comes with units and a named cause, and an operator can act on “heat transfer coefficient down 8 percent” in a way they cannot act on “anomaly score 0.83”.
There is a trap here worth stating plainly: a twin that corrects too aggressively hides the very signal it exists to produce. If the gain K is high, the state snaps to the measurement each tick, the residual is always small, and fouling is absorbed into the state rather than being reported. Parameters that represent asset condition should be allowed to move only slowly, which in state-space terms means giving them a very small process noise, exactly as with a bias term in calibration drift detection.
Physics, data, or both
First-principles models
Conservation of mass and energy, the thermal network, the electrical equivalent circuit. These extrapolate correctly outside the conditions you have observed, their parameters mean something, and they can be built before the asset has produced any data at all. They are laborious to construct and they are wrong in the details that were simplified away. The Modelica ecosystem and the Functional Mock-up Interface exist to make such models portable between tools, which matters when the model outlives the software that built it.
Data-driven models
A learned model of the same mapping needs no physical understanding and typically fits the observed operating envelope better than a hand-built model. It extrapolates unreliably, which is a serious problem for a twin, because the situations you most want it to predict are the ones outside normal operation.
Grey-box
The common production answer is a physical structure with learned parameters or a learned correction term: the conservation equations hold, and a regression absorbs the systematic error the simplified physics leaves behind. It keeps interpretable parameters and reasonable extrapolation while fitting the data far better than the bare physics. The cost is that fault diagnosis gets harder, because a change can now be absorbed by the correction term instead of showing in a parameter.
Where twins go wrong
- Timestamp misalignment corrupts the residual. The twin compares prediction at time
tto measurement at timet. If channels are half a second apart, the residual contains the derivative of the signal multiplied by the offset, which for fast-moving quantities swamps the fault signal entirely. See clock synchronisation. - Late data forces a choice about the past. Telemetry arriving after the tick it belongs to means either accepting a stale correction or reprocessing history and revising already-published states. Both are defensible; deciding silently is not, because downstream consumers need to know whether a twin state is final.
- An uncalibrated sensor becomes a phantom fault. A drifting sensor produces a growing residual, which is precisely the signature of a degrading asset. Drift detection is a prerequisite for trusting a twin’s diagnostics, not an optional extra.
- The asset is modified and the model is not. A replaced pump, a new filter, a changed control setpoint all invalidate parameters that were fitted to the old configuration. A twin needs a maintenance event feed as much as it needs a sensor feed, and residual jumps at maintenance events should be expected and handled rather than alarmed on.
- One twin per asset does not scale by copy-paste. A fleet of a thousand assets needs one model structure with per-asset parameters, fitted and stored per unit. Building a thousand bespoke models is how digital twin programmes stall after the pilot.
Top comments (0)