What is a digital twin in production?

A digital twin is the digital counterpart of a real object — a machine, a line, a plant — that is continuously supplied with data from ongoing operations. It provides information about the state, history, and performance of the original without anyone needing to check on site.

The difference from a model comes down to a single word: continuous. A model describes a state. A twin describes the current state and knows the path that led there. Without a continuous data flow from operational technology, a twin remains a drawing with a timestamp.

“Continuous” does not necessarily mean real time in the control-engineering sense. What matters is that the currency of the data fits the use case and is known: seconds for process diagnostics, minutes for maintenance decisions. Within the Industry 4.0 discussion, the digital twin is therefore less a technology than a requirement on the data landscape beneath it.

These three terms are regularly mixed up in projects. They differ mainly in how current their data is and what they are good for.

The most important and most frequently overlooked distinction is between a digital shadow and a digital twin. A digital shadow is fed from the plant in real time but does not act back on it: it shows what is happening. A twin closes the loop — insights from the representation flow back as instructions into the line and its controls. Anyone who does not draw this line is selling a dashboard as a twin.

In practice, the twin is often the bracket that holds it all together: it uses geometry from the model, computes with the methods of simulation, and lays the actual values of the plant underneath.

Four types of digital twins

The common breakdown follows the scope of observation. It is useful because it answers the question of data requirements at the same time: the larger the scope, the more sources must run in sync.

The levels build on each other: a process twin without solid asset twins beneath it is just an assumption with a surface.

A temperature reading is worthless on its own. It only becomes usable once it is clear which unit supplied it, in which plant and area that unit stands, which order it relates to, and what setpoint was intended for it. This assignment is called context — and it is the actual building block of the twin.

Context does not arise in the plant. It arises in a structure that brings together values from operational technology with master data from information technology and names both consistently. A Unified Namespace is exactly the ordering principle for this: it gives every value a place that reads the same across all systems.

The twin does not emerge from the plant alone — it emerges from values plus meaning.

The levels build on each other. The most common reason a twin project fails is jumping from level 1 to level 3.

• Representation

  State values of the plant are digitally available and mirrored. You can see what is happening — but not yet why.

• Context

  Live values are linked to master data: plant structure, setpoints, maintenance plan, order. Numbers become statements.

• Prediction

  Scenarios can be computed on the representation: parameter changes, loads, failure consequences — without risk to the real hardware.

• Feedback

  Results don’t stay in the dashboard. Instructions, recipes, and limit values flow back in a controlled way into the line and its controls.

• Fault diagnosis without a site visit. State, history, and events sit in one place. Anyone who knows the plant does not need to be near it to make a judgment.
• Test changes in advance. A changed procedure is first tested on the representation and then implemented in reality. That shortens downtime and limits the risk of damage.
• Condition-based maintenance. Maintenance follows actual wear, not the calendar.
• Comparison across sites. Two identical lines can only be compared if their values are named the same way. The twin enforces this naming.
• Knowledge survives staff turnover. What today sits in people’s heads and notes becomes a queryable structure.

The technology behind the representation is rarely the problem. The problem is the data feeding it.

• Reliable cadence. Values must arrive at a known frequency — and it must be noticeable when they stop.
• Unambiguous identity. Every source belongs to exactly one object in the structure. Duplicate or changing identifiers invalidate every evaluation.
• Time reference. Without reliable timestamps, no history and no comparison can be computed.
• Legacy plants included. Plants with twenty years of remaining service life are not replaced for a data project. They must be connected via whatever interfaces they have.
• Clear ownership. If nobody owns the data path, it doesn’t get operated — only repaired.

The term is now standardized, which considerably eases tenders and supplier discussions.
Three references carry the practice:

• ISO 23247 — Automation systems and integration — Digital twin framework for manufacturing. The series describes the fundamentals in Part 1, a reference architecture in Part 2, the digital representation of manufacturing elements in Part 3, and information exchange in Part 4; 2026 added Part 5 on the digital thread and Part 6 on composing multiple twins.
• IEC 63278-1:2023 — Asset Administration Shell for industrial applications. The Asset Administration Shell is the standardized wrapper in which the characteristics and data of an asset are described independently of manufacturer. It is the core of the debate in German-speaking discourse and the bridge between design and operational data.
• IEC 62541 (OPC UA) and IEC 62264 (the international version of ISA-95) provide the transport and structure that a twin in the plant builds on.

What matters most in practice is this: anyone who aligns the structure of their plant data with these models can later switch twin vendors without having to recollect the data.

pronubes does not deliver the twin, but the streams it is built from — in the structure and quality that an evaluation can rely on. ERP, MES, and the historian remain authoritative for their respective tasks.

• pronubes Edge runs locally in the plant, translates between OPC UA, MQTT, REST, SQL, and file formats, and buffers data if the connection is lost.
• pronubes Zones maps sites, areas, systems, and data flows hierarchically — the naming without which a twin cannot scale beyond two plants.
• pronubes Insights makes connections, data streams, and system states visible. A representation whose feed silently fails is more dangerous than none at all.

Over 100 system types can be connected — from current IoT protocols to decades-old interfaces. More about the platform