Digital Twins and Simulation
Building a model of a physical asset or process that is accurate enough for a specific decision — validated against what actually happens, rather than a visualisation that impresses and predicts nothing.
Most digital twin projects fail by being too ambitious. An attempt to model an entire facility produces something beautiful, expensive and unable to answer a question anyone was asking. A twin scoped to one decision, validated against real outcomes, is worth more and costs a fraction.
A digital twin is a computational model of a physical asset, process or system, connected to real data from it, used to predict behaviour, test changes or diagnose problems without intervening in the physical thing.
Scope to a decision
The question we ask first is what decision the twin will change. That determines everything about the build:
| Decision | What the twin must do | Fidelity needed |
|---|---|---|
| When to service this machine | Predict degradation from condition data | Moderate; behavioural rather than physical |
| Will this process change help? | Predict throughput and quality under new settings | High on the parameters being changed |
| Where is the bottleneck? | Represent flow and constraints | Low on physics, high on logic |
| Can we train operators safely? | Behave plausibly under fault conditions | Moderate; realism matters more than accuracy |
| Will this layout work? | Simulate movement and interference | Geometric rather than dynamic |
| Model the whole facility | Everything, unspecified | Undeliverable; the common failure |
A twin that has not been validated is a visualisation
Every twin we build is tested against what actually happened — predicted versus observed, on held-out periods, reported with error bands. Where it diverges, we say where and by how much rather than presenting a smooth animation as evidence of accuracy. Unvalidated twins get trusted for exactly one expensive decision.
How we build them
Combine physics with learning where each is stronger
Physical models generalise and respect conservation laws but need parameters you may not know. Learned models capture behaviour you cannot derive and fail outside their training range. Hybrid approaches — physics with learned corrections — are usually the practical answer, and we choose per component rather than committing to one school.
Establish what the data can actually support
Sensor coverage, sampling rate, calibration drift and the conditions your history actually contains. A twin cannot predict behaviour in a regime the asset has never operated in, and stating that boundary early prevents the twin being trusted where it should not be.
Validate on held-out reality
Predicted against observed on periods the model never saw, reported with error bands per output. This is the deliverable that determines whether anyone should act on the twin, and it is what separates this from a rendering.
Keep it synchronised, or say it is not
A twin drifts from the asset as maintenance, wear and modifications accumulate. Either it is re-calibrated on a defined cadence, or it is explicitly a snapshot model — but a twin quietly diverging while still being consulted is worse than no twin.
Put the uncertainty in front of the user
A prediction with a range and the conditions under which it is unreliable. Operators calibrate their trust correctly when they can see the model's confidence, and badly when a single number is presented with no context.
Use it to generate what you cannot observe
One of the strongest applications: simulating rare failures and edge conditions to produce training data for models that would otherwise never see them. See AIoT and synthetic data generation.
What it is worth
- Testing changes without stopping production, which is where most of the return sits for process industries.
- Predicting maintenance need from condition rather than from a calendar. See predictive analytics.
- Training operators on faults that would be dangerous or expensive to create for real.
- Diagnosing anomalies by comparing observed behaviour against what the model expected.
- Evaluating design and layout changes before committing capital.
- Generating rare-condition training data for models that cannot learn it from history.
How the engagement runs
The twin is scoped to one decision, and validated against reality before anyone acts on it.
Decision scoping and data assessment
The decision the twin will change; sensor coverage, history and the regimes the data actually contains.
Modelling approach
Physics, learned and hybrid components chosen per element; first version built.
Build and calibration
Twin developed and calibrated against historical data, with uncertainty quantified per output.
Validation
Predicted versus observed on held-out periods, with divergence documented rather than smoothed.
Interface and handover
Uncertainty surfaced to users; recalibration cadence and runbook handed over.
What you receive
A validated model that answers one question, with its error bands and boundaries stated.
Decision scope
What the twin will change, and what it deliberately does not model.
Data assessment
Sensor coverage, quality and the operating regimes the history actually covers.
The twin
Physics, learned or hybrid per component, calibrated to your asset.
Validation report
Predicted versus observed on held-out periods, with error bands and divergence named.
Uncertainty presentation
Ranges and unreliable conditions surfaced to the people using it.
Recalibration process
A defined cadence, or an explicit statement that it is a snapshot model.
Is this the right engagement?
Worth being direct. Digital Twins and Simulation is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- A specific operational decision would improve with prediction.
- Testing changes on the real asset is expensive, slow or unsafe.
- Sensor history exists across a useful range of conditions.
- Operators need training on faults you cannot safely create.
- Rare conditions need simulating to train other models.
Choose something else if
- The goal is a visualisation for stakeholders rather than a decision tool.
- Sensor coverage cannot support the question being asked.
- The scope is 'model the whole facility' with no decision attached.
- The asset changes so frequently that no twin would stay current.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
What actually is a digital twin?
A computational model of a physical asset or process, connected to real data from it, used to predict behaviour or test changes without touching the real thing. The word is used loosely — a 3D visualisation with live data on it is a dashboard, not a twin, and the distinction is whether it predicts anything.
How accurate can a twin be?
It depends on the question and on what your data supports, which is why validation against held-out reality is the central deliverable. Predicted versus observed with error bands tells you what the twin is good for. A twin that has never been validated will be trusted for one expensive decision and then abandoned.
Do we need to model the whole facility?
Almost never, and attempting it is the most common way these projects fail. A twin scoped to one decision — when to service this machine, will this process change help — is deliverable, validatable and worth more than an unfinished model of everything.
How do you stop it drifting from reality?
Either a defined recalibration cadence, or an explicit statement that it is a snapshot model for a one-off analysis. Assets change through wear, maintenance and modification, and a twin quietly diverging while people still consult it is worse than having none.
Can a twin generate training data?
Yes, and it is one of the strongest applications — simulating rare failures and edge conditions that a real asset produces once a year, so that models can learn them. The same caution applies as with any synthetic data: validate the resulting model on real observations, not on simulated ones.
Often paired with this
Most clients combine two or three engagements from the Emerging and Frontier AI pillar. These are the ones that most often run immediately before or after.
AIoT: AI and IoT Integration
Analytics at the edge on sensor data, with the labelling problem solved and alerts that lead to action.
Read more →Physical AI and Robotics Integration
Perception and decision-making added to existing robotics, with safety kept out of the learned path.
Read more →Autonomous Systems and Drones
Inspection and survey autonomy with the regulatory route established before anything is built.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.