Digital twins: model fidelity, synchronisation and what the model is actually for

Fidelity should be set by the question, not by ambition

A model detailed enough to check that a robot can reach every fixture without collision needs accurate geometry and nothing else. A model used to predict how a heat exchanger fouls needs physics and calibration data but very little geometry. A model used to test control logic before commissioning needs machine behaviour and timing. Building all three into one thing produces something slow, expensive and hard to maintain, which usually ends up abandoned. Naming the question first also exposes the cases where a spreadsheet or a simple calculation would have been sufficient, which is more often than the enthusiasm around the term suggests.

A twin that stops matching the asset is worse than none

The distinguishing feature of a twin, as opposed to a model, is that it tracks the physical thing over time. Physical assets change constantly: a fixture is shimmed, a pipe is rerouted, a control parameter is retuned, a component is replaced with a different type. Unless those changes flow into the model, it drifts into confident inaccuracy, and people who trusted it make decisions on a picture of a plant that no longer exists. Synchronisation is therefore an ongoing operating cost with a named owner, tied into engineering change control, and it is the commitment most twin projects fail to budget.

Commissioning control logic against a model

One of the most concrete uses is testing machine logic against a simulated plant before the equipment exists or while it is still running production. Sequences, interlocks, alarm behaviour and fault recovery can be exercised, including cases that are hazardous or destructive to create physically. The payoff is a shorter commissioning window, which on a line shutdown is worth a great deal. The limits are real: a model reproduces the behaviour someone thought to model, so it finds logic errors rather than the mechanical surprises that dominate real commissioning. Treat it as removing a category of problem, not as removing the need to commission.

Where the model gets its data determines whether anyone believes it

A live model needs measurements, and the quality of those measurements bounds everything. Poorly calibrated instruments, unsynchronised clocks, and signals without context produce a twin that diverges from reality in ways nobody can diagnose, at which point engineers quietly stop consulting it. Before committing to a live model, audit the measurements it will depend on and be honest about which quantities are not measured at all and will have to be inferred. Many twin projects would be better spent first on the instrumentation and data discipline that any later modelling effort will require anyway.

Ownership after the project team disperses

Models are usually built by a project team or a consultancy, and then need somebody to run them. Without an owner they follow the same path as unmaintained documentation: correct at handover, unreliable within a year, ignored thereafter. Before starting, name who will hold the model, who validates it against the asset, what triggers a revalidation, and which software licences and skills that requires long-term. If nobody in the organisation will own it, the honest options are to buy the analysis as a service or to scope the model as a one-off study with a defined shelf life.

Frequently asked questions

What is the difference between a model and a twin?

A model represents an asset at a point in time and answers questions asked during design or study. A twin maintains correspondence with a specific physical asset as that asset operates and changes, which requires a live data connection and a process for feeding engineering changes into it. The distinction matters commercially because the second carries a continuing cost. Much of what is sold under the twin label is in practice a model, and for many purposes a model is entirely sufficient.

How do we stop a plant model drifting away from reality?

Attach it to engineering change control so that any physical or control modification includes updating the model as a step, with the same sign-off as the drawings. Add a periodic validation comparing model output against measured behaviour under known conditions, with a defined tolerance and a documented action when it fails. And name an owner with the time and the licence to do the work. Without those three elements, drift is not a risk but a certainty.

Is a digital twin worth it for a single machine?

Sometimes, if the machine is a constraint, hard to experiment on during production, or expensive to commission. Testing control logic offline before a shutdown, or trialling a parameter change without disturbing output, can justify a focused model of one asset. What rarely pays is building a general model of an ordinary machine because the capability sounded worthwhile. The test is whether you can name the specific decisions the model will inform in its first year.