What a digital twin is once the marketing is removed, the four kinds that actually get built, and how to tell a useful one from an expensive demonstration.
"Digital twin" is among the most oversold phrases in the industry. There is a
genuinely useful idea underneath, and separating it from the demo footage is
worth doing carefully.
When someone proposes a digital twin programme, ask which of the four they mean
and what decision it will change. "All of them" usually means none of them well.
The kind with the fastest payback is nearly always the vehicle twin — because
it is data engineering rather than physics, and because it immediately improves
OTA targeting and diagnostics.
You are unlikely to build the physics. You will still benefit in four concrete
ways.
Realistic test data. A battery twin driving your SIL environment produces
plausible state-of-charge curves — including the awkward non-linear end of
discharge where display bugs hide. Far better than a linear ramp.
Diagnosing a customer complaint. "The range estimate jumped by 40 km" is
untestable as a bug report. With a vehicle twin holding that car's software
versions, configuration and recent signal history, it becomes reproducible on a
desk.
Deciding who gets an update. A vehicle twin knows which hardware revision and
which dependent components each car has, which is what makes a targeted rollout
possible rather than a fleet-wide gamble.
Answering questions about the past. "Did this ever happen before the March
release?" is a query against fleet history, not a testing exercise.
"Where does its state come from, and how often?" A real twin has a telemetry
path and an update rate. A demonstration has a configuration file.
"How was it validated?" Against what recorded reality, and what was the
error? An unvalidated model is a hypothesis.
"What decision does it change?" If nobody acts differently because of it, it
is a visualisation.
"What happens when the vehicle is offline for a month?" Real fleets go quiet.
A twin that assumes continuous connectivity has not met one.
"Can I query one VIN?" If the answer is only aggregate dashboards, it is
analytics, which is fine — but it is not a vehicle twin.
Gotcha
A rendered 3D vehicle rotating on a screen is a visualisation. It may sit on top
of a real twin, or on nothing at all. The graphics tell you nothing about
whether the underlying state is synchronised, validated, or used.
This sounds cynical. It is the single most useful filter to apply in this area.
If you want the benefit without a programme-scale investment:
Record real traces and replay them. This is a twin of one drive, it is
perfectly faithful by construction, and it costs nothing.
Version the vehicle configuration — software versions, hardware revisions,
options — in a queryable store keyed by VIN. This alone unlocks targeted OTA
and most diagnostics value.
Add a physics model only where a decision needs one, and validate it
against recorded data before trusting it.
Keep signal history for the fleet, at a sample rate you can afford. Most
"we cannot reproduce it" tickets die here.
