What people mean by “digital twin”
The term covers very different things, and mixing them up is the main reason projects stall:
- Visual twin: a 3D or schematic model of an asset or line.
- Descriptive twin: the visual model fed with live data, showing current state.
- Predictive twin: a model that forecasts behavior, such as expected wear or throughput.
- Prescriptive or what-if twin: a model used to test changes before making them.
Pick the level your question needs. Many valuable first projects are descriptive or predictive and need no 3D model at all.
Start with one question about one asset
A pretty visualization is not a result. A decision is. Choose a single high-value question, for example “what happens to OEE if we change this parameter?” or “how long until this bearing reaches its alarm limit at the current load?”. Write down who will use the answer, what they will do with it and how you will tell whether it was right. Choose one critical machine or line; when the method works there, replicating it elsewhere is much easier.
Get the data foundations right
A twin inherits every flaw in its data. Before modeling, confirm that the tags you need exist, have documented units and sensible timestamps, and are of measurable quality (see sensor data quality before analytics). A twin built on bad counters produces confident nonsense.
Choose the simplest model that answers the question
- Physics-based models encode known behavior and need little data, but need engineering effort.
- Data-driven models learn from history, but only within the range the data covers.
- Hybrid models combine both and often fit industrial problems best.
Lightweight models are often enough. Full computational fluid dynamics or finite-element simulation is rarely needed for an operational decision.
Connect to reality, carefully
Live data flows into the twin. Whether results flow back into the control system is a separate, serious decision. Start with advisory output that an operator or engineer reviews; closed-loop control from a model needs independent safeguards and a formal change process.
Validate and keep validating
Replay past periods and compare the twin’s predictions with what actually happened. Define an acceptable error before you start, and keep measuring it, because a model drifts away from reality as equipment wears and processes change. The OEE worked example shows the kind of baseline calculation that a first twin can be checked against.
Decide who owns it
A twin needs an owner who updates the model when the real equipment is modified, versions it and retires it when it stops being useful. Without that, it becomes a snapshot of a machine that no longer exists.
Common pitfalls
- A visualization with no decision attached.
- No defined accuracy, so nobody knows whether to trust it.
- Unclear data ownership and unclear model ownership.
- Starting plant-wide instead of with one asset.
For where the model should run, see the edge versus cloud decision framework.