A digital twin is a working model of a physical asset, process, or system, kept current by data flowing from the asset itself, so teams can test changes and predict behavior without touching the original. We build these models at Xavor Corporation in Irvine, California, as part of our physical AI engineering services.
Digital twin and virtual twin describe the same underlying idea at different points in a product’s life. Four conditions decide which assets return the modeling effort. And a proof-of-concept twin can be complete in six to ten weeks, depending on what data already exists.
A twin without a live data connection is a simulation with a more ambitious name.
Where the term virtual twin came from
Dassault Systèmes uses “virtual twin” for its own offering, a distinction its CEO Bernard Charlès formalized in 2020, and no standards body has adopted the split since. The company’s own materials state it plainly, describing a digital twin as, in their words, a Virtual Twin at Dassault Systèmes.
The phrase spread through their ecosystem rather than through the wider industry. Their 3DEXPERIENCE platform documentation and their partner network carry it. Siemens and PTC, working on the same problems, use digital twin.
That leaves executives reading vendor material with two words for something close to one idea, and each vendor with a commercial reason to prefer its own.
Two engineering teams using different vendors will describe the same model in different terms, which is why the terms are used interchangeably.
Anyone comparing proposals is comparing vocabulary as much as capability. For the underlying mechanics, we cover what a digital twin is and how one works separately. This piece assumes the fundamentals and looks at the terminology and the build.
Virtual twin vs digital twin: What separates the two terms
Digital twin and virtual twin describe the same underlying idea at different points in a product’s life: a digital twin mirrors an existing asset, fed by sensors on it, while a virtual twin begins at the concept stage before anything physical is built. The difference lies in the lifecycle position, which determines what data feeds the model.
| Digital twin | Virtual twin | |
| When it exists | After the asset is built | From the concept stage |
| What feeds it | Sensor data from the asset | Design models and assumptions |
| Question it answers | How is this performing now | How would this behave |
| Who uses the term | The broad industry | Dassault Systèmes and partners |
A concept-stage model runs on assumptions, so it predicts. A sensor-fed model runs on measurements, so it reports and forecasts.
The sequence is the practical takeaway: a model can exist before the asset does, then become a digital twin once sensors start feeding it data.
A different pairing causes similar confusion, and we cover how a digital thread differs from a digital twin there.
Which assets justify a twin
Four conditions decide which assets return the modeling effort: existing sensor coverage, the cost of failure, how often the asset changes, and how much of its behavior is already understood. Score a candidate against all four before scoping a build.
- Existing sensor coverage: the data feed either exists or becomes its own project.
- Cost of failure: consequences determine how much modeling accuracy costs.
- Rate of change: an asset reconfigured monthly compounds the value of a model that keeps pace.
- Behavioral understanding: physics you can already describe converts into a model faster than behavior nobody has characterized.
Three cases illustrate the split. A production line with instrumentation installed makes a twin a modeling exercise. An asset whose failure halts a line justifies the cost through consequence alone. A product still in design has no sensor data, which is where a concept-stage model applies.
An asset with no instrumentation turns a modeling project into an instrumentation project, and that changes the cost by an order of magnitude.
We set out digital twin use cases across manufacturing separately. Use cases are set out there; this section covers which assets justify one. The broader operational picture sits in what digital twins change for industrial operations.
What a twin build takes
A proof-of-concept twin can be complete in six to ten weeks, and the variables that move it are sensor availability, model fidelity, and how many systems the data has to cross. Our published physical AI delivery model puts a complete twin in that range as a proof of concept, following a two-to-four-week assessment that produces the architecture, and ahead of a three-to-six-month path to a handed-over physical system.
Three variables set where a project lands in that window:
- Sensor availability: existing instrumentation shortens the build, and new instrumentation extends it well past ten weeks.
- Required model fidelity: a model answering throughput questions differs from one predicting component fatigue.
- Systems the data crosses: each additional source adds mapping work and a reconciliation question.
Proof of concept comes before commitment for a reason. A working model built around one asset surfaces the data problems a program-wide plan would meet later and more expensively, and the twin itself becomes useful before anything physical exists, since synthetic data generated inside it can train perception models ahead of deployment.
Published timelines for twin builds vary from two days for a scanned space to eighteen months for a full production line, which leaves buyers comparing proposals across a range too wide to be a reference point.
Ask any prospective partner which of the three variables their estimate assumed, and the number becomes testable.
What feeds a twin: the IoT data layer
The data layer decides what a twin can answer, since a model updated hourly answers different questions from one updated in real time. Digital twins and IoT arrive together for that reason.
Sensors on the asset, a pipeline that moves what they record, and a model that consumes it. Remove any of the three and the model drifts from the thing it represents.
Update frequency drives infrastructure cost. Predictive maintenance on a rotating machine needs high-frequency vibration data. A throughput model on a production line runs on far less.
Refresh rate is a design decision with a cost attached, and it should follow the question the twin exists to answer.
The connective work sits in the IoT engineering that supplies a twin with live data.
Start with the asset, not the terminology
The word a vendor uses for the model changes nothing about which asset earns one.
Sensor coverage, failure consequences, rate of change, and how well the behavior is understood determine that, and they decide it before any platform enters the conversation.
The question that determines whether a twin project is undertaken is which asset justifies the modeling effort, and it is answered before any platform is chosen. If you want a view of yours, our engineering team reads everything that arrives at [email protected].
FAQs
A proof-of-concept twin can be complete in six to ten weeks when sensor data already exists. Timelines extend when instrumentation must be installed, when model fidelity requirements increase, or when data spans multiple systems.
A digital twin mirrors an existing asset, fed by sensors on it. A virtual twin is Dassault Systèmes' term for a model that begins at the concept stage, before anything physical is built. The lifecycle position separates them.
Component twins model a single part or sensor. Asset twins model a complete functional unit built from several components. System twins model how assets work together. Process twins model an end-to-end operation. Each level builds on the one below.