A digital twin is a live, data-driven model of a real machine, line, or asset that continuously ingests its sensor data to mirror the current state and predict what happens next. It is not a 3D visualisation or a dashboard: the value is in the model and the decision it improves, not the picture. In production, a useful twin answers a specific question, such as when a bearing will fail or which line speed maximises yield, and it stays accurate because live data keeps correcting it.
The three levels of a digital twin
Most confusion comes from lumping three very different things under one word. It helps to think in levels of maturity.
Level 1 — a static model. A physics or data model of the asset that reflects how it behaves in general. Useful for design and what-if analysis, but it does not know the state of your specific machine right now. Most vendor demos stop here and dress it up in 3D.
Level 2 — a live-synced model. The same model, but continuously fed with real sensor, PLC, and SCADA data so it tracks the actual state of a specific asset. Now you can see drift, compare expected versus measured behaviour, and catch anomalies early. This is where a twin starts earning its keep.
Level 3 — a predictive, optimising model. The live model runs forward. It estimates remaining useful life, simulates the effect of a setpoint change before you make it, and recommends the action that improves the outcome. This is the level that changes decisions, and it is the level almost nobody reaches by starting with the 3D model.
What data a digital twin actually needs
A twin is only as good as the data feeding it. In practice that means historian data from your sensors, PLCs, and SCADA layer, with enough history to capture normal operation and, ideally, a few real failures or process upsets. The signals that matter are the ones physically tied to the behaviour you care about: vibration and temperature for rotating equipment, pressure and flow for process lines, cycle times and torque for discrete machines.
Two things quietly decide whether a twin will work. First, resolution and coverage: if a fault develops over seconds but you log once a minute, the twin is blind to it. Second, labelled events: a model learns fastest when you can point to moments where something actually went wrong. Without those, you are modelling normal operation and inferring the rest, which is possible but slower and less certain. An honest scoping conversation checks this before any model is built.
When it genuinely pays off, and when it's hype
A digital twin pays off when two conditions hold together: you have enough sensor data, and there is a real decision it makes better. A better decision means money: avoided unplanned downtime, higher yield, longer asset life, less scrap, safer operation. If you cannot name the decision and the euros behind it, you are buying a visualisation, not a twin.
It is hype when the project starts with the 3D model. A beautiful rotating render of your line impresses a boardroom and improves nothing on the floor, because the geometry was never the hard part. The hard part is the live data pipeline, the model that stays accurate, and the decision loop that acts on it. Teams that lead with the visual usually spend the budget before they reach the part that pays.
It is also premature when the sensor data simply isn't there yet. If a critical asset is barely instrumented, the honest first step is often to add sensors and collect a baseline, not to model thin air. That is not a failure; it is sequencing. A twin built on six months of good data beats one built on a wish.
How it connects to predictive maintenance and simulation
A live twin and link are two views of the same engine. Predictive maintenance is the twin pointed at one question: how much useful life is left, and when should we intervene. The twin supplies the live state and the model; predictive maintenance supplies the decision and the schedule. Built together, they share the same data pipeline instead of duplicating it.
Simulation is the twin pointed forward instead of at now. Because a Level 3 twin already encodes how the asset behaves, you can ask it what-if questions, such as run the line 8% faster, change the feedstock, or shift the maintenance window, and see the modelled effect before committing on the real line. That is the difference between a dashboard, which tells you what happened, and a twin, which tells you what to do next.
How to start without wasting the budget
Start from the decision, not the render. Pick one asset or line where downtime or yield genuinely costs money, confirm the sensor data exists at the right resolution, and build the smallest live-synced model that improves that one decision. Prove the euros on a narrow scope, then widen. This is why we scope a digital twin as a fixed-price audit first, then a proof-of-concept, before any production build: the audit tells you honestly whether your data can carry a twin at all.
If you run assets or lines in the link sector and suspect a twin could pay off, the fastest way to find out is a short data audit against a specific decision. If the data is not ready, we will tell you that too, which is cheaper to hear now than after a six-figure build.
Frequently asked questions
What is a digital twin in simple terms?
A digital twin is a live, data-driven model of a real machine or line that keeps updating from its sensor data, so it reflects the actual state and can predict what happens next. It is not a 3D drawing or a dashboard; the point is the model and the decision it improves.
Is a digital twin just a 3D model or visualisation?
No. A 3D model is at most the surface of a digital twin, and often not needed at all. The substance is a model fed by live sensor, PLC, and SCADA data that stays accurate over time and drives a decision. Projects that start with the 3D render usually run out of budget before the part that pays off.
What data do you need to build a digital twin?
You need historian data from the sensors, PLCs, and SCADA tied to the behaviour you care about, at a resolution fine enough to catch how faults develop, with enough history to cover normal operation and ideally a few real failures. Without adequate resolution and coverage, a twin cannot see the events it is supposed to predict.
When is a digital twin worth it and when is it hype?
It is worth it when two things hold together: you have enough sensor data, and there is a real decision it makes better in euros, like avoided downtime or higher yield. It is hype when the project leads with the visual, or when the sensor data to support a model simply isn't there yet.
How does a digital twin relate to predictive maintenance?
Predictive maintenance is a digital twin pointed at one question: how much useful life is left and when to intervene. The twin supplies the live state and the model; predictive maintenance supplies the decision and schedule. Built together they share one data pipeline instead of duplicating it.