Learn
Industrial digital twin
An industrial digital twin is a software model of a physical asset that is kept in step with the real thing. Three distinct kinds share the name: a visual twin holding geometry, a simulation twin holding physics, and an operational data twin holding the asset structure and the live readings bound to it.
The word covers three different products. That would be a vocabulary problem if the three cost the same to build and keep, and they do not. Picking the wrong one is how a twin program ends up as a demo nobody opens a year later. This page separates them, says what each is genuinely good at, and is direct about which one Fleetera builds.
What is an industrial digital twin?
At its simplest, a digital twin is a model of a physical thing that is kept current as the physical thing changes. The definition is uncontroversial and almost useless on its own, because it says nothing about what the model is made of. In industrial software, three very different artifacts answer to it, and they are built by different people, for different questions, at different running costs.
- Visual twin
- A geometric model of the plant: CAD, a laser scan, or a game-engine scene you can walk through. It answers questions about space and shape.
- Simulation twin
- A behavioral model: equations that predict how a machine responds to conditions. It answers questions about scenarios you have not run.
- Operational data twin
- A structural model of the fleet: sites, assets, sub-assets, and typed variables with live readings bound to them. It answers questions about what is happening and what happened.
The three are not competitors and they are not stages of maturity. A refinery may reasonably want all three. But they are bought and maintained separately, and the failure mode is buying one while imagining another. A team that wanted to know why a machine underperformed last Tuesday and was sold a walkthrough of the building got the wrong artifact, and no amount of polish on the walkthrough will fix that.
The last row of that comparison is the one to read twice. Two of the three go stale unless a person decides to refresh them. The third goes stale only if the data stops arriving, which is a problem you can detect, alert on, and fix, rather than a chore somebody has to remember.
What is a visual twin for, and what does it cost to keep?
A visual twin is geometry. It comes from CAD models, a laser scan, drone photogrammetry, or a scene built by hand, and it is rendered so a person can move through it. When the question is spatial, nothing else comes close.
- Planning access and clearances before a crew mobilizes
- Training people on a layout they have not physically visited
- Coordinating trades so two contractors do not book the same space
- Communicating a site to stakeholders who will never stand in it
The running cost is the part that is rarely quoted. Geometry is true on the day it is captured. Every physical change after that, a replaced unit, a new cable tray, a temporary structure that became permanent, moves the site away from the model, and nothing about the model notices. Keeping a visual twin current means re-surveying, which means people, equipment, and a decision that this quarter is the quarter you pay for it again.
In practice most visual twins drift. They stay useful for the questions where approximate geometry is fine, and they quietly stop being trusted for the questions where it is not. That is a reasonable outcome as long as it was the expected one. It is an expensive surprise when the twin was sold as the foundation of an operations program.
What is a simulation twin for, and what does it cost to keep?
A simulation twin is behavior expressed as mathematics. It might be a thermal model of a battery enclosure, an aerodynamic model of a rotor, or a process model of a treatment plant. You give it inputs and it tells you what the real machine would probably do, including under conditions you would not deliberately create.
- Testing a change before it is made to real equipment
- Exploring failure conditions that are unsafe or expensive to reproduce
- Sizing and designing equipment that does not exist yet
- Producing an expected value that measured behavior can be compared against
The running cost here is calibration. A simulation is only as good as its fit to the specific machine it claims to represent, and real machines age: bearings wear, modules degrade, fouling accumulates, a component gets replaced with a part from a different supplier. A model that matched on commissioning day drifts from its asset in a way that is invisible from inside the model. Keeping it true means periodically re-fitting it against measured behavior, which takes an engineer who understands both the equations and the plant.
A simulation twin needs an operational twin underneath it
Re-fitting a model means comparing it against what the machine actually did, on that asset, over a defined window, in units you trust. That is the operational layer's output. This is why the third kind tends to come first in practice: it is what the other two are calibrated and validated against.
What is an operational data twin?
An operational data twin is a structural model of the fleet, kept live by the readings flowing into it. It holds no geometry and no equations. What it holds is the answer to a duller and more frequently asked question: what exists, how is it arranged, what does each thing measure, and what have those measurements been doing.
Concretely it is four things. A hierarchy, because a site contains assets and an asset contains sub-assets, and a reading has to land on the exact piece of equipment it came from. Types, because a hundred identical machines should be described once and stamped, not configured a hundred times. Variables with units, because a number without a unit and an owner is not information. And bindings, because each of those variables has to be wired to a real address on real equipment before any of it means anything.
The reason this kind earns its keep is that it makes everything downstream fleet-wide instead of per-device. A dashboard, an alert rule, or a KPI defined against an asset type applies to every asset of that type, including the ones bought next year. Without the twin, each of those is rebuilt per site, which is how organizations end up with a hundred dashboards that disagree.
- One definition on the asset type follows every current and future asset of that type
- A raw controller address becomes a named variable with a unit and an owner
- Questions can be asked of the fleet, not of one device at a time
- New equipment inherits the model rather than starting a new integration
The other half of this kind is its memory. A structure with only the present tense in it is a status board, and a status board cannot tell you whether today is unusual. So an operational twin carries history: recent operation at full resolution for live work, and older operation rolled into hourly and daily aggregates so a long look back stays fast. In Fleetera those tiers are queried as one, and retention is a query window rather than a delete, so a question that reaches past the window narrows gracefully to the resolution you have instead of failing.
That combination, a typed structure plus a history attached to it, is what turns a question into a query. Without the structure, comparing two machines is a data-cleaning exercise. Without the history, you can only ever describe now. With both, the same question asked of one asset and of the whole fleet is the same question.
Which kind does Fleetera build?
The third one, and only the third one. Fleetera's digital twins are the asset and site model in Fabric: sites contain assets, assets contain sub-assets, asset types carry typed variables with units, and bindings connect those variables to real addresses on real equipment. We do not render 3D geometry and we do not run physics simulations. If you need a walkthrough of a building or a thermal model of an enclosure, that is a different product and we would rather you knew that before you bought anything.
What we do build around the model is the machinery that keeps it fed and honest. One runtime per site reaches equipment over OPC UA with subscriptions, Modbus TCP and RTU, MQTT, and REST, with no plugins to install. A dual hot and cold buffer keeps recording at the site through restarts and through a lost connection, and streams what it holds once the link returns. Point Fleetera at an OPC UA server and it suggests how each raw signal maps to your variables, and you review and approve: nothing binds without your yes, and you can always browse and bind by hand.
Say the kind out loud before you compare vendors
Most disagreements about digital twin products are two people using one word for two artifacts. Decide which kind your question needs, then compare only the products that build it. A comparison across kinds is not a close call, it is a category error.
The third kind, as a product
Sites, assets, sub-assets and typed variables, bound to real equipment and kept fed by what it reports.
Does a digital twin control the equipment?
This is the question that stalls twin projects inside operations teams, and it is worth answering flatly. A twin of any of the three kinds is a model. It reads. The systems that keep equipment safe are the controllers, the protection relays, and the interlocks that were commissioned with the plant, and a twin sits above them rather than instead of them.
That boundary is not a limitation to be engineered away later. Control systems are certified, tested against the failure modes of the specific machine, and owned by the people responsible when something goes wrong. A model built for analysis has none of that assurance behind it, and a company that quietly routes analysis output into an actuator has moved a safety decision into a system that was never designed to carry one.
Fleetera keeps that line explicit. Fabric reads from equipment over its own protocol and models what it reads. Command manages configuration across sites from the cloud, with a person approving what runs and an audit trail behind it. The equipment keeps doing its job, and is not asked to change, because a control system is not a place to experiment.
A twin changes who knows, not what acts
The value of an operational twin is that a question about any asset in the fleet has a fast, consistent answer. What happens next is still a decision a person makes, through the systems that were built to carry it.
Digital twin, digital thread, and simulation: three words, three different things?
Yes, and they are not even the same category of thing, which is why a conversation that uses all three interchangeably goes nowhere. One is a model of an object. One is a record that follows an object through time. One is a technique. Reading them that way makes the overlap obvious and ends the argument about which is a subset of which.
Three words that are not even the same category of thing: a model, a record over a lifetime, and a technique.
| Word | What kind of thing it is | What it answers |
|---|---|---|
| Digital twin | A model of one physical thing, kept in step with it | What the thing is and, in the operational kind, what it has been doing |
| Digital thread | A connected record of one asset across its life, and a linkage across systems rather than a system of its own | Where a fact came from and what happened before now: specification, build, commissioning, operating history, maintenance, modification, and eventually disposal |
| Simulation | A technique: equations run to predict behavior, often describing a class of machine rather than any particular one | What a machine would do under conditions it has not met. It becomes a simulation twin only once bound to a specific asset and re-fitted against what that asset actually did |
The relationships follow from those definitions. A thread needs models at several points along its length, because a record of an asset's life is a record about something. A simulation twin needs an operational twin underneath it, because calibration means comparing predictions against measured behavior on that specific asset. And an operational twin contributes one segment of a thread, the operating history, while the design, procurement and maintenance segments stay in the systems that produced them.
That segment boundary is worth being direct about. Fleetera builds the operational data twin and the history behind it. It is not an end-to-end digital thread across engineering, procurement and maintenance systems, and a product that models assets and their readings should not be sold as one. Where a thread exists in your organization, the operational twin is the part of it that stays current without anybody maintaining it by hand.
Ask which word is doing the work
If a vendor says twin and means thread, you are being sold integration across your record systems. If they say twin and mean simulation, you are being sold equations that will need calibrating. Both are real products, and neither is the structural model of the fleet that makes a dashboard apply to every asset of a type.
How do you tell which kind a vendor means?
The marketing language for all three is close to identical, so the vocabulary will not separate them. The questions below will, because each one has a different answer depending on what the product is actually made of.
Five questions whose answers differ by what the product is made of, and what each answer separates.
| Ask | What the answer tells you |
|---|---|
| 1. Where does the model come from on day one: a CAD file, a set of equations, or a description of the equipment and its signals? | CAD, equations, or the equipment's own signals: the three answers are the three kinds. |
| 2. What happens to the model when a physical change is made on site, and who has to do something about it? | A re-survey, a re-fit, or nothing beyond the next reading arriving. |
| 3. Can it tell me what this asset did last Tuesday, and at what resolution? | Separates the operational kind from the other two: it is a question about recorded history, and only a twin fed by live readings has one. |
| 4. Can it tell me what this asset would do at a temperature it has never seen? | Separates the simulation kind: predicting unseen conditions is exactly what equations are for and exactly what a data model cannot do. |
| 5. If I add ten identical machines, do I configure ten things or stamp one type? | A good check on whether an operational twin is genuinely type-based, or a hierarchy of one-off configurations wearing the word. |
There is also a standard to point at when a discussion needs common ground. ISO 23247 sets out a digital twin framework for manufacturing: the parts of a twin system, and how the digital representation relates to the physical element it observes. It is a framework rather than a product test, so it will not tell you which of the three kinds a vendor built, and we make no claim of conformance to it. What it is genuinely useful for is forcing both sides of a conversation to say what is being observed, by what, and how the model is kept in step.
How do you know a twin is still true?
Every kind of twin drifts from the thing it represents. The difference that matters in operations is whether the drift is detectable from inside the system. Geometry drift is invisible until someone visits the site and notices. Calibration drift is invisible until a prediction is checked against measurement. Data drift is different: a variable that stops updating, a binding pointing at an address that no longer exists, or a site that has gone quiet is a condition you can watch for and be told about.
That is the practical argument for making the operational twin the foundation, and it has nothing to do with which kind answers the most interesting questions. It is the only one of the three whose staleness is itself a measurable signal, which means it can be governed rather than remembered.
The test to apply
Ask what happens to each twin when nobody looks at it for a year. The one that can tell you it has gone stale is the one you can build an operation on.
Once the operational twin exists and is trusted, the other two get easier rather than less necessary. A simulation has measured behavior to be fitted against. A visual model has a live source of truth for what equipment is present. Ordering matters more than choosing.
Common questions
Terms on this page
The vocabulary this guide uses, defined plainly in the industrial data glossary. Each one opens at its own entry.