A digital twin is not a 3D picture of your machine. It is a live model, fed by the real asset's sensors, that you can run experiments on and feed the answers back. The value is in the loop, not the render.
The term gets attached to everything from a CAD render to a dashboard. A useful definition is narrower: a digital twin is a live model of a specific asset, kept in step with reality by that asset’s own sensor data. It is not a generic simulation and not a static drawing — it tracks this machine, this line, this plant, as it actually behaves now.
That liveness is the whole point. A model you calibrate once and walk away from drifts out of agreement with the real thing within weeks. A twin is continuously corrected by telemetry, so what you ask it stays relevant to the asset in front of you.
Data flows up: the asset streams telemetry — temperatures, vibration, currents, cycle times — that keeps the model matched to reality. Insight and control flow down: you run a what-if on the twin instead of the machine, and feed the result back as a setpoint, a schedule, or a maintenance decision.
That closed loop is what separates a twin from a report. You can test a change before committing it to hardware, predict a failure before it happens, or optimise an operating point without risking the real asset. The render, if there is one, is just a window onto the model — not the model itself.
A twin earns its keep when there is a decision it improves and a cost to getting that decision wrong. Predictive maintenance on an asset whose unplanned downtime is expensive. Process optimisation where a few percent of yield or energy is real money. Commissioning a change that would be risky or slow to trial on the live line.
Where none of those is true, a twin is an expensive dashboard. The engineering discipline is deciding what the twin is for first — which decision, what accuracy it needs, which signals feed it — and building only as much model as that decision justifies.
A working twin is a stack: instrumentation and edge gateways to get trustworthy telemetry off the asset; a data path that keeps it live; a model — physics-based, data-driven, or both — of the behaviour that matters; and the integration back into control and operations that closes the loop. Each layer is where twins quietly fail if it is weak.
We build twins from that whole stack, anchored to a decision rather than a demo — the sensing and edge, the model, the simulation, and the path that turns a prediction into an action on the real asset.
No. A 3D model is a picture; a digital twin is a live model kept in step with a specific real asset by that asset's sensor data, used to simulate, predict and decide. The visualisation, if any, is a window onto the twin, not the twin itself.
A simulation is a model you run against assumed inputs. A digital twin is continuously fed by the real asset's telemetry, so it stays matched to how that specific asset behaves now, and its what-if answers remain relevant rather than drifting out of date.
When it improves a specific decision whose wrong answer is costly — predictive maintenance on expensive downtime, process optimisation where yield or energy matters, or trialling a risky change virtually. Without such a decision, a twin is an expensive dashboard.
Enough trustworthy telemetry to keep the model matched to reality for the decision it serves — typically temperatures, vibration, currents, flows and cycle times from instrumentation and edge gateways, delivered reliably enough that the model does not drift.
Either or both. Some twins are physics-based models, some are data-driven, and many combine the two. The right choice depends on the asset, the decision, the accuracy required and how much good data exists to learn from.
By closing the loop: a what-if run on the twin becomes a setpoint, a schedule change, or a maintenance action on the real asset. If nothing flows back down to change what the asset does, you have a monitoring dashboard, not a twin.
Instrumentation, a live model and the path that turns a prediction into an action — anchored to a real decision, not a demo. Tell us the asset and what getting the call wrong costs you.