What a digital twin actually is, and is not, in industrial control
"Digital twin" has been stretched to cover everything from a 3D rendering of a factory floor to a predictive analytics service running on a cloud platform. In industrial control specifically, the term has a narrower technical meaning: a digital twin is an executable representation of a controlled system whose behavior matches the running system closely enough to be used for engineering work.
That definition rules out a few things that are commonly mislabeled. A 3D visualization is not a twin; it is a viewer. A historian dashboard is not a twin; it is a record. An anomaly-detection model trained on operational data is not a twin; it is a classifier. A twin runs behavior. It can be put into a state, it can be driven with inputs, and it produces outputs that match what the real system would produce.
The three levels of digital twin maturity
Digital twin implementations fall on a maturity ladder. The terminology is not standardized across vendors, but the substance is clear enough.
Level 1: Visualization. A 3D or 2D rendering of the system, possibly animated by live data. Useful for operator awareness and stakeholder communication. Not executable. Often called a "twin" in marketing material.
Level 2: Simulation. A behavioral simulation that approximates the system's behavior. Built independently of the live control logic. Useful for design exploration, training, and what-if analysis. Drifts away from the live system over time as both evolve separately.
Level 3: Executable behavioral twin. A simulation that runs the same model as the deployed control software. Built once, deployed twice (one runtime to hardware, one runtime to simulation). The twin and the live system are different deployments of the same model, so behavior is, by construction, the same.
Most digital twin projects in the public discourse are at Level 1 or Level 2. The strategic value of digital twins (commissioning before hardware, change validation before production, accurate operator training) requires Level 3.
Why most digital twin projects fail
The failure mode is consistent. A twin gets built as a separate artifact, often by a different team than the one maintaining the live control logic. Initially the twin matches the live system. Over the next twelve to twenty-four months, the live system gets changed: an interlock is added, a state machine is restructured, a parameter range is tightened. Each change is, individually, made for good operational reasons. Each change requires a corresponding update to the twin, which is rarely a high priority for the operations team that just made the live change.
The twin and the live system gradually diverge. The first signs are minor (a simulation result that surprises someone, a behavior in the field that the twin does not reproduce). The team continues to use the twin for some purposes and stops trusting it for others. Within three years, the twin is treated as an approximation rather than a reference, and its budget is cut. The project is judged a failure.
The failure is rarely technical. It is architectural. Two artifacts maintained by hand cannot be kept in sync at the rate that operational change requires.
Why testing earlier is dramatically cheaper
The economics of defect detection have been understood in software engineering for decades. A defect found during design costs roughly one unit to fix. The same defect found during implementation costs ten. During commissioning, it costs a hundred. Once it reaches production, the cost can be orders of magnitude higher, because the diagnosis happens under operational pressure with incomplete data, and the fix has to be made without disrupting operations.
In industrial control, the curve is steeper than in most software domains. Production systems run on physical hardware, integrated with mechanical and electrical equipment, often in regulated environments. A defect that surfaces in commissioning means a delayed delivery, missed milestones, and engineering teams diagnosing problems on-site under contractual pressure. A defect that surfaces in production can mean lost revenue per minute of downtime, safety implications, and the kind of investigation that why control software becomes harder to change over time describes in detail.
Despite this, most industrial automation projects still discover the majority of their defects late. The reasons are structural. Software work is pushed toward the end of the project, after mechanical and electrical decisions have been made. Validation effort focuses on the fair-weather scenarios where the system is supposed to work. The bad-weather cases, the rare combinations and failure modes that often matter most, are skipped because there is no time and no environment to test them in.
Digital twins, used properly, change this. Behavioral validation that would otherwise wait for hardware can begin as soon as the model exists. Bad-weather scenarios that cannot be tested on a real production line can be exercised exhaustively in simulation. Defects that would surface in commissioning surface during design instead, where they cost a fraction to fix.
The catch is that this only works at Level 3. A Level 1 or Level 2 twin cannot run the same behavior as the eventual production system, so a defect found in the twin does not reliably predict a defect in production. The economic case for early testing depends on the architectural integrity of the twin.
The architectural requirement: shared model
A Level 3 digital twin requires that the twin and the live control logic share a model. They are not two systems that have to be kept in sync; they are two deployments of the same system. A change to the model affects both, automatically.
Model-centric platforms are the natural architecture for this. The model holds the behavior; one code generator targets the production controller, another targets the simulation runtime. Both deployments execute the same logic. Drift is architecturally prevented because there is no second artifact to drift.
Cordis SUITE implements this through the Cordis Gateway, the runtime layer that connects the model to either simulation or live hardware. The same model can be deployed against a virtual representation of the controlled equipment for design-time validation, against a digital twin during commissioning for behavior verification, and against the production controllers for live operation. The Gateway makes these three deployments interchangeable from the model's perspective. The behavior that runs in production is the behavior that was validated in simulation, by construction, because both deployments execute the same generated code from the same model.
The practical consequence is that a digital twin in Cordis SUITE is not a separate project that has to be built, validated, and maintained against the live system. It is a deployment view of the model that drives production. When the model changes, both the production code and the twin behavior update together. There is no synchronization step, no drift, no second team responsible for keeping the twin current.
The Gateway also supports the inverse flow. Live behavioral data from production can be captured (every PLC cycle, structured against the model) and replayed against the twin in the engineering environment. Engineers can investigate incidents by loading the captured state into the twin and watching the live state machines play back, against the same model that defined them. Root cause analysis happens offline, with full data, without operational pressure. This is the same capability described in why control software becomes harder to change over time, applied here to twin-based investigation.
Cordis SUITE has implemented this architecture since 2000 and has been refining the Gateway as digital twin technology matured around it. The platform was Level 3 before "Level 3" was a category.
Practical use cases
Once a Level 3 twin is in place, several use cases become routine that are uneconomical at lower maturity levels.
Commissioning. This is the most economically significant. Behavior can be validated before hardware is connected, and often before hardware is purchased. The work that would otherwise happen in expensive on-site commissioning windows happens in the office, on schedule. Defects that would have cost a hundred to fix during commissioning cost one to fix in design. For projects with significant integration complexity, this single use case justifies the investment in the platform.
Change validation. A proposed change can be deployed to the twin and exercised under realistic scenarios before it goes anywhere near production. Failed changes cost a fraction of what they would cost in production, and the team can iterate on the fix without operational impact. Over an asset lifetime, the compounding effect is substantial: every change is safer, every change is faster, and the system stays changeable instead of drifting toward the frozen state.
Incident investigation. When something happens in production, the captured behavioral state can be loaded into the twin and the sequence of events replayed in the engineering environment. The investigation happens offline, with the full record, against the same model that defined the system's intended behavior. Root cause analysis becomes a process of reading rather than guessing.
Operator training. Operators train on a twin that behaves exactly like the system they will operate, including edge cases, failure modes, and recovery procedures. Training fidelity rises, time-to-competence drops, and operators arrive at production with experience that previously could only be acquired during real incidents.
Predictive analysis. The twin can be driven with hypothetical inputs to evaluate how the system would respond to scenarios that have not yet happened: capacity changes, equipment degradation, alternative operating profiles.
What to look for in a digital-twin-capable platform
The questions that separate a real Level 3 twin from a marketing claim are concrete:
- Is the twin running the same model as the live control logic, or a separate representation of it?
- What is the propagation delay between a model change and the corresponding behavioral change in the twin?
- Can runtime state from the live system be projected onto the twin for replay or debugging?
- Is the twin executable in a way that supports automated validation, or only interactive exploration?
- What share of the platform's customer base actually uses the twin in production engineering workflows?
- How early in development can engineering teams begin meaningful behavioral validation against the twin?
- When a defect is found in the twin, how reliable is the prediction that the same defect would have surfaced in production?
- Is the twin maintained as a separate project with its own budget, or as a deployment view of the same model that drives production?
A platform that answers these well typically has a model-centric architecture underneath. A platform that struggles with them is usually a Level 1 or Level 2 system marketed as Level 3.
The honest framing
The promise of digital twins in industrial control is older than the term. The promise has not been fully delivered because most twins are built as separate artifacts that drift away from the systems they are supposed to mirror. The architectural shift that makes the promise real is not a better twin, but a shared model from which both the twin and the production system are derived. When the twin is a deployment view rather than a parallel project, the economic case (early testing, cheap defect detection, change validation, incident investigation) becomes structural rather than aspirational. Everything else is a 3D rendering with a budget attached.