Digital Twins
See the system. Test the next move.
Digital twin development is the work of linking a model of an asset or process to its observed state so people can test a change before making it. ColdAI builds twins around a specific operating decision, with three parts that must agree: a consistent state model, a behavior model calibrated against what the asset actually does, and an explicit comparison between the baseline and a proposed scenario, uncertainty included.
The opportunity
Start with a decision
worth improving.
An operator wants to know how a change in load might affect an asset. A useful twin connects observed state to a calibrated model, rather than presenting a visually impressive but unverified replica.
From possibility to a working system
Follow the flow.
Three connected decisions. One considered architecture.
Conceptual flow, not a live system or measured result.
Connect physical and digital
Map assets, identifiers and signals into a consistent state model. Track measurement time and data quality so users can distinguish fresh observations from missing or stale readings.
Model the behavior
Choose the level of physical, statistical or process modeling the decision needs. Calibrate against observed behavior and document which conditions fall outside the model's validated range.
Explore a scenario
Compare a proposed change with the baseline and make assumptions visible. Use the result to inform an operator decision, with a controlled boundary between simulation and real-world actuation.
The work, made concrete
What we can build
with your team.
We agree scope, dependencies and acceptance criteria before delivery. Your project can start with an assessment, a pilot or an integration into an existing system.
An asset and telemetry data model
Clarify the system boundary, the responsible owners and the decisions the architecture needs to support.
A calibrated scenario workflow
Turn the agreed design into reviewable work, evaluated against representative inputs and explicit success criteria.
Decision views with explicit uncertainty
Make the next step operable: document responsibilities, known limitations and the path from pilot to ongoing use.
In depth
Go deeper into digital twin design
Practical guides for scoping a first twin around a single decision and for choosing the data standards that let it integrate equipment from several vendors.
- 01ProcessScoping a minimum viable digital twinA decision-first process for scoping a first digital twin: pick one operating decision, match model fidelity, inventory data, calibrate and show uncertainty.
- 02ArchitectureDigital twin data standards: AAS, DTDL, OPC UA, ISO 23247How OPC UA, the Asset Administration Shell, DTDL, ISO 23247 and NGSI-LD fit together in a multi-vendor digital twin, and how to map identity, units and time.
Twin, simulation, dashboard or 3D model: how to tell them apart
Vendors use the word twin for all four. The differences decide what you can rely on.
| Capability | Monitoring dashboard | Standalone simulation | 3D model | Digital twin |
|---|---|---|---|---|
| Reflects current state | Yes | No, uses chosen inputs | Only if connected to data | Yes, with freshness shown |
| Predicts behavior under change | No | Yes | No | Yes |
| Checked against observed behavior | Not applicable | Sometimes, at design time | No | Continuously, by design |
| Shows uncertainty | Rarely | Sometimes | No | Yes, in decision views |
| Typical weakness | Tells you what happened, not what would happen | Drifts from the real asset after commissioning | Looks authoritative without predicting anything | Costs more to keep current than the others |
A dashboard, simulation or 3D model is often the right answer on its own. A twin is worth its upkeep only when a recurring decision needs live state and prediction together.
Terms worth agreeing before specifying a twin
- State model
- The structured description of what each asset is and its current condition, built from identifiers and signals, with the time of each last good reading.
- Behavior model
- The physics-based, statistical or process model that predicts how the asset responds to a change in inputs or operating conditions.
- Validated range
- The operating conditions over which the behavior model has been checked against measurements. Predictions outside it deserve a warning, not a confident chart.
- Data freshness
- How old the newest trustworthy value for each signal is. Stale values shown as live are among the most common ways a twin misleads.
- Scenario
- A named, documented set of changes to the baseline, such as higher load, a different schedule or an asset out of service, run through the behavior model.
- Actuation boundary
- The deliberate separation between what the twin calculates and what changes real equipment. Crossing it is a separate engineering and safety decision.
The calibration loop that keeps a twin trustworthy
- Observe state
Ingest signals and update the state model, flagging stale or missing values.
- Predict
Run the behavior model forward for current conditions.
- Compare with reality
Check predictions against later measurements and track the error.
- Recalibrate or flag
Adjust parameters when error grows, or mark the model out of range.
- Support a decision
Compare scenarios with the baseline and record what was chosen.
- Record the outcome
Log what happened after the decision as evidence for the next cycle.
Making scenario comparison honest and repeatable
Scenario comparison is where a twin earns its keep, and also where it is easiest to mislead. Start every comparison from a documented baseline: the current state, the expected inputs and the same model version used for the scenario. Change as few variables as the question allows, so the difference between baseline and scenario can be attributed to something specific.
Show results as ranges when the inputs are uncertain, for example when demand or ambient temperature could plausibly vary. Put the assumptions next to the chart rather than in a separate document, and mark any part of the result that relies on conditions outside the validated range. Finally, log which scenario informed which decision. Without that record, nobody can later check whether the twin helped.
For a first project, the process for scoping a minimum viable twin shows how to choose the decision and fidelity, and the guide to twin data standards covers integration when equipment comes from several vendors.
When a digital twin is worth building, and when something simpler will do
- If
The decision is rare and low-stakes, and an engineer can work it out from first principles.
ThenUse an engineering calculation or a one-off simulation study.
A twin's value comes from repeated use; one-off questions do not repay its upkeep.
- If
There is little or no sensor history for the asset.
ThenInstrument the asset and collect history before building a twin.
Without observed behavior there is nothing to calibrate against, so predictions cannot be trusted.
- If
The main need is to warn people when an asset starts to behave abnormally.
ThenStart with predictive monitoring rather than a twin.
Alerting needs a good baseline and escalation, not scenario simulation.
- If
The goal is to help people understand a site or train them on it.
ThenConsider a 3D or immersive model without live prediction.
Spatial understanding does not require a calibrated behavior model.
- If
A recurring decision depends on how an asset will respond to a change, and the data exists.
ThenBuild a twin scoped to that decision.
This is the case where live state and a calibrated model together change the outcome.
How a twin drifts away from the asset it represents
Physical changes are not reflected
Early signalPrediction error jumps after maintenance, a retrofit or a process change.
MitigationMake twin updates part of the management-of-change process for the asset.
Sensors are recalibrated or replaced
Early signalA step change in one signal with no matching change in related signals.
MitigationRecord calibration events in the data history and review the affected model parameters.
The model is used outside its validated range
Early signalUsers ask about conditions far from any seen in calibration.
MitigationShow the validated range in every view and warn automatically when inputs exceed it.
Nobody owns recalibration
Early signalError tracking exists but nobody reviews it.
MitigationName a model custodian with time allocated, and report prediction error alongside usage.
Frequently asked questions
How is a digital twin different from predictive maintenance?
Predictive maintenance watches telemetry for signs that an asset is degrading and raises alerts. A digital twin models how an asset or process behaves so people can compare what would happen under different choices. They share data and often support each other: monitoring can flag a change, and a twin can test the response before anyone acts.
Can a digital twin control equipment directly?
It can be connected that way, but it should not start there. A twin is designed to inform a person who acts through existing controls and procedures. Automating setpoints from a twin is a separate change that needs evidence of prediction accuracy, defined fallbacks and the safety review any control change requires.
What does a ColdAI digital twin engagement deliver?
The deliverables are an asset and telemetry data model, a calibrated scenario workflow and decision views that show uncertainty explicitly. To start, we need a specific operating decision, access to asset history and sensor data, and people who understand the physical system and can judge whether the model behaves plausibly.
Do we need a dedicated digital twin platform?
Not necessarily. Some teams use a commercial twin platform, others combine a historian, a modeling environment and a web front end. Choose based on the modeling approach the decision needs and how the data must be integrated, and keep your asset model in a neutral form so the platform can change later.
Where do digital twins tend to be most useful?
Where physical behavior is reasonably well understood, decisions recur and mistakes are costly: production lines, energy and utility networks, process plants and infrastructure assets are common settings. The common thread is not the industry but a recurring operating decision with good data behind it.
Connect the architecture
The next connection.
Explore the complementary capabilities that can turn an individual technology into a complete workflow.
Your next move
Bring us the
real problem.
A workflow that takes too long. A system that cannot connect. An idea that needs a technical path. Start there, and we can define what to investigate, build and measure.
- A specific operating decision
- Asset history and sensor access
- People who understand the physical system