Virtual Twin vs Digital Twin: What the Difference Actually Is

TL;DR

• “Virtual twin” is Dassault Systèmes’ product term for its 3DEXPERIENCE platform. Outside that marketing, it means digital twin.
• No standards body recognises a virtual/digital twin split. ISO 23247 and the National Academies define digital twin only.
• The distinction that predicts project success is data flow direction: digital model, digital shadow, or true digital twin.
• Kritzinger’s 2018 review found true digital twins scarce in the literature; most published examples are models or shadows.
• Michael Grieves introduced the concept at the University of Michigan in 2002. NASA’s John Vickers named it around 2010.
• Scope on your telemetry, not on the vendor’s vocabulary. Sensor coverage sets your ceiling before any platform choice does.

What is a virtual twin?

A virtual twin is a digital twin. The term belongs to Dassault Systèmes, which uses “Virtual Twin Experience” as the product name for what its 3DEXPERIENCE platform does. Dassault Systèmes describes it as its own advance on the digital twin concept, and its marketing positions virtual twins as the richer, more capable option.

That framing is a vendor’s framing. It is not wrong, exactly — Dassault Systèmes is describing a real product with real capabilities. But when a CTO asks a supplier “should we build a virtual twin or a digital twin,” the question has already been shaped by one vendor’s catalogue. The rest of the industry, the standards bodies and the research literature use one term: digital twin.

Is a virtual twin different from a digital twin?

Not in any definition that exists outside Dassault Systèmes’ own materials. Search for a source that draws the virtual/digital twin line and treats it as an industry distinction, and every trail leads back to 3ds.com, a Dassault Systèmes blog, or a reseller repeating the same copy. No standards body recognises the split.

The vendor-neutral definitions cover digital twins and stop there. The National Academies’ 2024 consensus report defines a digital twin as a set of virtual constructs that mirror a physical system’s structure and behaviour, update dynamically from that system’s data, predict, and inform decisions that create value — and its committee is explicit that “the bidirectional interaction between the virtual and the physical is central.” ISO 23247, the manufacturing framework, likewise defines a digital twin and has no virtual twin category.

So the honest answer to a buyer: if a supplier tells you a virtual twin is a more advanced class of thing than a digital twin, they are quoting a competitor’s brochure at you. Ask what data flows where instead.

Which distinction actually matters when you’re scoping a project?

Data flow direction. Werner Kritzinger and colleagues at TU Wien proposed the classification that has held up: sort systems by whether data moves automatically between the physical object and its digital counterpart, and in which direction. Their 2018 review in IFAC-PapersOnLine has been cited over two thousand times, and it separates three things that get sold under one name.

Kritzinger’s team found that the literature on true digital twins was thin, while digital models and digital shadows were well represented. Most systems published as digital twins were, by their own definition, models or shadows. That gap has not closed much. It is also the single most useful thing a buyer can know, because the three levels differ by roughly an order of magnitude in cost and risk, and vendors price all three as the third.

Most enterprise buyers who ask SumatoSoft for a digital twin want a digital shadow. That is not a criticism. A shadow is often the correct thing to build: it is cheaper, it carries no control-loop safety burden, and it delivers most of the monitoring value. The failure is paying twin prices for shadow scope, or scoping a twin and discovering at integration that nothing was ever going to write back to the PLC.

Where did the digital twin concept come from?

Michael Grieves introduced it at the University of Michigan in 2002, in the first executive Product Lifecycle Management course there. His slide called “Conceptual Ideal for PLM” had three parts: real space, virtual space, and the data links running between them. Grieves renamed the idea twice — Mirrored Spaces Model, then Information Mirroring Model — before the name that stuck arrived from elsewhere.

That name came from NASA. The term “digital twin” emerged around 2010 during NASA technology roadmapping co-led by John Vickers, and was defined in NASA’s published roadmaps and in a follow-on 2012 paper by Glaessgen and Stargel. NASA’s definition was built for aerospace: a multiphysics, multi-scale, probabilistic simulation of a vehicle, fed by sensor updates and fleet history, mirroring the life of the physical aircraft it shadows.

Two details get mangled in retellings, and they matter if you are citing this history yourself. Grieves described three components of one model, not three types of twin. And “Origins of the Digital Twin Concept” is a 2016 paper he co-wrote with Vickers looking back at the 2002 work — not the 2002 work itself.

What does it take to build a digital twin?

Telemetry, a model, and a decision about the return path. In that order, and the first one is where projects die. A digital twin of a physical asset needs enough sensor coverage to constrain the model. If the asset is instrumented for alarms rather than for state estimation — which describes most brownfield plant — the sensor retrofit is the project, and the modelling is the easy part.

The build sequence is unglamorous: characterise the asset and its failure modes with the people who operate it, instrument what the model needs, ingest and clean the telemetry, build a static model, make it dynamic against real data, then validate it against events you did not train on. Only after that does the return path become a real question. Writing model output back to a physical system is a controls and safety problem, not a software problem, and it is what separates a shadow from a twin.

Where are digital twins actually delivering results?

In facility layout and workflow simulation, more reliably than in the headline use cases. The Medical University of South Carolina and Siemens Healthineers used digital twins of MUSC facilities to test and validate layouts and processes before building them, and to plan scheduling in a new neuro-interventional area through workflow simulation. Modelling a room before pouring concrete is a narrow claim, and it is the kind that survives checking.

Aerospace and heavy industry are the mature domains, which is unsurprising given NASA named the concept. Predictive maintenance is the most-cited application. But the delivered result is usually a digital shadow doing condition monitoring, described as a twin.

A note on what is not in this article. Earlier versions of this post carried figures for aircraft downtime, equipment commissioning time, and retail and logistics deployments. None of them survived a source trace: they were either unattributed, attributed to a vendor’s stated goal rather than a measured outcome, or attributed to a project that had nothing to do with digital twins. That is the condition of most published digital twin statistics. If a number in a vendor’s article has no link behind it, assume it does not have a source behind it either.

How should you scope a digital twin project?

Start from your telemetry, not from a platform. Three questions settle most of the scope before any vendor conversation:

1. What decision will this change? If the answer is “we’ll have better visibility,” you want a digital shadow and should pay shadow prices.
2. What is already instrumented? Sensor coverage sets the ceiling on model fidelity. No platform fixes a gap in the physical layer.
3. Does anything write back? If nothing writes back to the asset, it is not a digital twin under any definition, including Dassault Systèmes’. That is fine. Just scope it honestly.

SumatoSoft has built IoT systems since 2012, including sensor-to-cloud monitoring like the industrial refrigeration monitoring platform in our portfolio, and predictive maintenance work in manufacturing. If you are weighing a digital twin against a digital shadow, talk to our engineers about what your telemetry will actually support before you commit to a platform.

FAQ

Is “virtual twin” a real technical term? It is a real product term belonging to Dassault Systèmes, used for its 3DEXPERIENCE platform. It is not a technical category in ISO 23247, the National Academies’ 2024 digital twin report, or the peer-reviewed literature. Those sources define digital twins and do not recognise a separate virtual twin class.

Is a digital twin the same as a simulation? No. A simulation is a model you run. A digital twin is dynamically updated with live data from the physical system it mirrors, and its output feeds back into decisions about that system. The National Academies’ 2024 report treats that bidirectional link as the defining feature. A simulation with no live data connection is a digital model.

What is a digital shadow? A digital shadow is a model that receives automated data from a physical asset but sends nothing back. Kritzinger and colleagues defined it in 2018 as the middle of three integration levels: manual data flow both ways is a digital model, automated one way is a digital shadow, automated both ways is a digital twin. Most systems marketed as digital twins are digital shadows.

Who invented the digital twin? Michael Grieves introduced the concept at the University of Michigan in 2002 as the “Conceptual Ideal for PLM,” later the Mirrored Spaces Model. The name “digital twin” came from NASA around 2010, during roadmapping work co-led by John Vickers. Grieves and Vickers documented the history together in 2016.

Do we need IoT sensors to build a digital twin? For a digital twin of a physical asset, yes. Automated data flow from the physical object is what separates a digital twin from a digital model, and that data comes from instrumentation. Digital twins of processes or organisations can draw from transactional systems instead, but the same rule applies: no automated data flow, no twin.