Digital Twin vs Simulation
What a Validated Model Is, and Isn’t
“Digital twin” has become the default label for almost any model of a factory, which makes it hard to know what you’re buying or building. The two terms do mean different things. The difference isn’t about how realistic the graphics look. It’s about the data connection, and whether the model has been validated against the real system.
What a simulation model is
A simulation model represents how a system behaves over time, so you can run experiments on the model instead of the real thing. What happens if the filler runs faster, the accumulation table doubles or preventive maintenance moves to a different shift? A model of a production line is built from the line’s structure (machines, rates, buffers) and its behavior (how often each machine stops and for how long), and it’s only as good as both.
The model can be generic, a teaching example, or a detailed representation of one specific line built from that line’s own event data. Its inputs are refreshed when someone re-pulls the data.
What a digital twin is
A digital twin is a virtual representation of one specific physical asset, process or system that stays connected to it. The concept is usually traced to Michael Grieves’s product-lifecycle work in the early 2000s, and the name was popularized through NASA technology roadmaps around 2010. The core idea has three parts: the physical system, its virtual counterpart and the data link between them.
A widely cited research classification (Kritzinger and colleagues, 2018) separates three levels by how the data moves.
| Level | Physical → model | Model → physical | Example |
|---|---|---|---|
| Digital model | Manual | Manual | A line simulation built from exported downtime logs, where a person acts on the results |
| Digital shadow | Automatic | Manual | The same model fed on a schedule from the plant historian, where a person acts on the results |
| Digital twin | Automatic | Automatic | The model receives live state and sends settings or schedules back to the line |
By that definition, many products sold as digital twins are digital models or digital shadows. For many questions a model is exactly the right tool. It’s still a reason to ask three questions of any twin: what is connected, how often, and in which direction?
Simulation vs digital twin, side by side
| Aspect | Simulation model | Digital twin |
|---|---|---|
| Main purpose | Experiment by comparing what-if alternatives | Mirror and act on one live asset or process |
| Data connection | Loaded from historical data, refreshed as needed | Automatic, continuing connection |
| Time horizon | Weeks to years of simulated operation | Often the current state and the near future |
| Typical decisions | Buffer sizing, line design, capital projects, maintenance policy | Next-shift scheduling, live monitoring, control adjustments |
| Infrastructure | The model and its input data | Model, data pipelines, integration and upkeep |
| Must be validated? | Yes | Yes, and kept valid as the asset changes |
Validation comes first
A live data feed doesn’t make a model correct. If the model’s structure is wrong, or a machine’s failures are averaged into a single number, a connected twin reproduces the error faster and with more confidence. The discipline that matters is validation. Run the model over a period you’ve measured, and compare.
Compare at the right level, too. An overall total can match for the wrong reasons, with one failure mode overstated and another understated so the errors cancel. Comparing simulated and measured behavior for each failure mode separately can’t hide that.
Done that way, a discrete rate model can match a plant’s measured OEE closely. Each machine’s failure modes have to be kept separate, with time-to-failure and time-to-repair distributions fitted from the plant’s own event data, and the model validated against history. The published proof point is Fischel and Lange’s WSC 2020 study of a multi-line food plant, modeled in ExtendSim®. That model was rebuilt in ReliaSim® and independently validated by Tom Lange, and the ReliaSim model performed within 1% of both the plant’s measured OEE and the original model. The details are in the published OEE validation case study.
When a live connection is worth it
- Worth it: decisions made hour to hour or shift to shift, where the current state (what’s down right now, what’s in the buffers) changes the answer, and where someone or something will act on the output quickly.
- Usually not needed: design and investment decisions such as buffer sizing, adding a machine or changing a maintenance policy. These depend on months of failure and repair behavior, and a validated model refreshed from that history answers them fully.
- Either way: the model has to reproduce measured history before its predictions are worth acting on.
Why ReliaSim calls it a playing field
ReliaSim builds validated simulation models of production lines from the event data plants already record, using discrete rate simulation. They’re simulation models in the sense defined above, not live-connected twins.
We call the model a playing field. It’s the term our modelers have long used for the scope an experiment plays out on: the machines, buffers and stops that matter to the question, and nothing that doesn’t.
The name says what the model is for. A twin’s job is to mirror the line as it runs today. A playing field’s job is to let you try moves you haven’t made yet, like a faster filler, a bigger buffer or a second case packer, and see what each one is worth before you commit. That’s the question a capital decision turns on.
ExtendSim® is a registered trademark of Andritz Inc., referenced for identification only.
Frequently asked questions
What is the difference between a digital twin and a simulation?
A simulation model is a representation of how a system behaves, used to run experiments on it. A digital twin is a virtual representation of one specific physical asset or process that stays connected to it, so data flows automatically from the real system to the model, and in the strict definition back again. Many digital twins contain a simulation model, and the connection is what makes it a twin.
Is every simulation model a digital twin?
No. A model of a specific line, built from that line’s data and refreshed when someone re-pulls the data, is a simulation model, which the research literature calls a digital model. It becomes a digital shadow when data flows into it automatically, and a digital twin in the strict sense when data flows automatically in both directions. Vendors often use the term loosely, so ask what is connected, how often and in which direction.
Does a digital twin need real-time data?
It needs an automatic data connection, but how fresh the data must be depends on the decision. Operational decisions about the next shift benefit from data that is minutes old. Design decisions such as buffer sizing, line layout or capital investment depend on months of failure and repair history, and a model refreshed periodically from that history answers them just as well.
What does it mean to validate a simulation model?
It means running the model over a period for which you have measured results and comparing the two before trusting any prediction. A strong validation compares each failure mode separately, not just the overall total, because errors in individual modes can cancel out into an aggregate that looks right for the wrong reasons.
Can a simulation model become a digital twin later?
Yes, in principle. A validated model can be connected to live data feeds once the data pipeline and the business case exist. Validating the model first means the connection carries a model already known to reproduce the real system, rather than feeding live data into a model that has never been checked.
Explore a plant model in your browser
The Chocolate Processing demo runs three systems in series, with equipment failures, as a campaign schedule.
Open Chocolate Processing →Or read simulation methodologies.