Why a digital twin diverges from the real object
The divergence starts not in the mathematics of the model, but in a broken feedback loop. The twin is trained on a historical slice of telemetry, while the object continues to change: operating modes shift, components wear out, new loops appear. After a few months, the map of modes inside the model describes a different unit.
The currency of object data rests on three things — channel completeness, sampling frequency, and sensor calibration. If a single loop drops out of polling or writes a constant instead of a value, the model fills the gap with a plausible but incorrect number. Externally, such a result is indistinguishable from normal, and the error accumulates silently.
The quality of source data finishes the picture with manual records: repairs, component replacements, and changes to maintenance regulations live in the log, not in the model.
The twin continues to calculate remaining useful life based on the previous state — maintenance is planned for a component that was replaced long ago, while the actual operational bottleneck remains out of focus.
Trust in the model does not fall immediately. First, the divergence is attributed to error, then the twin's answers begin to contradict the operator's readings and measurement results.
As soon as an engineer sees two different answers to the same question, the tool stops being used — and all the work invested in it is nullified.
The root cause is that the twin is designed as a report, not as a feedback loop. Without reconciliation with the object, gap control, and update rules, it inevitably becomes outdated.
We break down how this is closed — from the data collection scheme to the retraining procedure and thresholds beyond which divergence is considered unacceptable.
What a digital twin delivers: measurable effect
The effect of implementing a digital twin is measured not by the number of models built, but by operational metrics: the share of prevented failures, response time to deviation, hours of unplanned downtime, and the number of physical tests replaced by model-based calculation. Below is how each of them moves.
Reducing downtime through early warning
Equipment condition forecasting is built on a telemetry stream: the model continuously compares actual parameters with the expected behavior of the component and catches drift hours or days before it crosses the boundary.
Response time to deviation shifts from "after shutdown" to "before shutdown", and repair moves from emergency to a planned window.
In practice, this changes the downtime structure: the share of prevented failures on critical components reaches 70-80%, and unplanned downtime hours are reduced severalfold.
The trigger threshold is configured separately for each component — otherwise there are so many warnings that the dispatcher stops responding to them.
Testing decisions on the model instead of physical tests
Scenario calculation runs on the twin what used to be tested on a live object: a mode change, load increase, new maintenance procedure, or shifting of a repair window.
A change that in the physical world costs a shift of downtime and risk is calculated on the model in minutes and without intervention in production.
Therefore, only validated settings go to real equipment, and some hypotheses are filtered out in simulation. We build the loop on industrial platforms — from Azure Digital Twins to an open stack — and bind the model to your telemetry system, not the other way around.
Model operating modes: telemetry, calculation, forecast
The twin's operating mode sets the model update frequency and requirements for the exchange loop with the object.
A one-off calculation gives a snapshot at launch time, periodic synchronization gives a state delayed by one interval, and a telemetry stream gives continuous correspondence. The choice is dictated not by fashion, but by the cost of an error on outdated data.
| Option | When it fits | Limitations |
|---|---|---|
| One-off calculation | Hypothesis testing, model tuning on history | State becomes outdated immediately after launch; there is no feedback from the object |
| Periodic synchronization | Processes whose inertia is greater than the update interval | The delay between an event on the object and the model response remains |
| Telemetry stream | Continuous processes, early detection of deviations | Requires a stable channel and filtering of sensor noise |
| Forecast and scenario run | Planning, mode selection, "what if" testing | Accuracy is limited by model reliability and history quality |
Real-time synchronization with the object
The telemetry stream enters the model, the state is recalculated, and the twin highlights divergence from the object. Such a loop is justified where a deviation must be seen before it turns into a failure — the delay here is measured in seconds and minutes, not shifts.
The price for this is constant channel load, buffering during communication outages, and a procedure for what to do if the data diverges from reality.
Forecast and scenario modes
The forecast model starts from the same synchronized state, but runs it forward: scenario modeling compares load, temperature, or flow options without stopping the object. The result is a range with boundaries, not a single number: the longer the horizon, the wider the corridor. That is why forecasting is used for mode and plan selection, not as a replacement for automation.
Next, we break down which loop is needed for your task and what it will require from the infrastructure.
Implementation stages: from data audit to handover
A digital twin starts not with the model, but with data and the object boundaries — if this step is skipped, the twin calculates beautifully but diverges from reality.
Below are the implementation stages that we go through together with the customer: from data audit to handing the loop over to its operations team.
Data audit and problem statement
- Object survey: which sensors and logs already write data, at what frequency and completeness, where the gaps are, and when the measurement channels were last calibrated.
- Definition of the objective function — what exactly we are optimizing (consumption, downtime, batch quality) and by which metric we will measure the effect at the output.
- Data preparation: gap recovery, timestamp synchronization, and cutting off periods when the object operated outside its standard mode.
Loop design and pilot operation
- Loop design: we fix where the model lives, how it receives telemetry, and what it returns — recommendations to the operator or setpoints to the control system.
- Model assembly and convergence check: we compare the twin's behavior with the object on a held-out time interval; divergence on key parameters must fall within the agreed tolerance.
- Pilot operation in advisor mode: engineers compare the forecast with actuals and record which modes the model gets wrong, after which the settings are corrected.
- Handover and team training: we provide configurations, the retraining procedure, and analysis of typical failures so that your service can run the loop going forward.
Deliverables: schemes, configurations, procedures
The documentation package is assembled so that the solution can be handed over to another team without "from memory" stories. Each artifact has an owner, version, and update date: if the model is retrained, the model card changes, not just the file on the stand.
Documentation for the model and its assumptions
We describe why the model exists, which decisions it supports, and what data it was validated on. A separate block covers assumptions and applicability boundaries — at what shift in input data the conclusions become invalid and what signal catches this.
Such a list removes the main operational risk: the model quietly runs on changed data, while decisions are made using outdated logic.
What the customer retains:
- Technical description of the model: purpose, target metrics, input features, limitations, and requirements for source data quality.
- Register of assumptions and failure scenarios — indicating which are monitored automatically and which require a human decision.
- Data flow diagrams: from sources to storage and back, with quality control points, responsibility zones, and copy storage locations.
- Configuration files: recalculation parameters, trigger thresholds, environment settings — with comments on what changes during scaling.
- Role and access matrix: who sees source data, who changes parameters, who approves the model output for production.
- Maintenance procedure: quality check frequency, degradation criteria, retraining order, and rollback to the previous version.
- Instructions for operation and incident analysis: typical failures, diagnostics, escalation.
Documentation is maintained in a repository alongside the configurations, not as a separate archive.
Changes to the model and to the description go through one approval procedure — otherwise, six months later, no one will be able to say which version of the description corresponds to the operating loop.
Case study: how model divergence was reduced severalfold
Implementation case — a continuous-cycle section where a stop at one position slows the entire flow. The goal was not to build a model for its own sake, but to reconcile it with the actual state of the object: a deviation should become visible before failure, not after.
Situation before
Readings were taken manually during a round once per shift and transferred to tables — some values were lost in the process. The section model lived separately from the object: calculation based on design data, actual mode in shift logs.
Divergence was noticed late, when the deviation had already developed, so the response followed the failure — with a stop, root cause analysis, and downtime of neighboring positions.
Result after
We reconcile the model with the object automatically: telemetry flows into a single storage (AVEVA), the expected state is recalculated on every cycle, and a deviation above tolerance becomes an early warning. The operator sees not a tripped protection, but the trend leading to it.
| Metric | Before implementation | After |
|---|---|---|
| Reading collection | round once per shift, manually | automatically, continuously |
| Deviation detection | after failure | early warning based on trend |
| Model divergence from object | not measured | reduced severalfold, reconciliation on every cycle |
| Root cause analysis | from shift logs | from state history and trends |
The project results are not reporting, but controllability: model reconciliation with the object became regular, and decisions are made based on dynamics, not consequences.
How a forecasting model differs from an operator training simulator
Both tasks are built on one base: process physics, sensor archive, and mode maps. We describe the physics once — in Modelica notation — and reuse it in both loops. After that, the requirements diverge, and they determine the loop architecture and scope of work.
The forecasting model works over a horizon. Accuracy requirements here are resistance to error accumulation over a long interval, validation on a held-out period, and interval estimates instead of a single number. Response time is not critical: recalculation can take minutes and run on a schedule or by event.
The operator training simulator is built the opposite way: evaluation is needed not over a horizon, but at every step. Accuracy shifts toward behavior during startups, deviations, failures, and operator errors, while response must fit the pace of the process.
A determinism requirement is added — rerunning a scenario must produce the same result, otherwise debriefing actions loses meaning.
Hence two different loops. The forecast has data preparation, regular recalculation, drift control, model versioning, and the ability to roll back to the previous version. The simulator has an executable loop, a workstation, a scenario library, and action evaluation.
The difference in approaches determines where approximation is allowed and where stable reproducibility is required.
Shared physics saves time, but does not cancel two different acceptance tests: the forecast is checked for falling within tolerance, the simulator for scenario repeatability.
Therefore, we fix the horizon, scenario set, and checklist at the statement of work stage, before work begins.
Technical concerns: data, access, model accuracy
Concerns about a digital twin usually relate not to the model itself, but to what surrounds it: data completeness, access boundaries, and what the team will retain after handover. We have collected the questions most often heard in technical sessions and answer them briefly.
What to do about gaps in data?
Not all gaps are equal: first we look at their nature — whether a gap is random or a consequence of sensor failure. In the second case, recovery distorts the dynamics, so each recovered point gets a quality flag, and the model relies on it less.
If gaps in an interval exceed the agreed share, the section is excluded from training rather than guessed.
Can we start with one component?
Yes, and this is the preferred start: one component provides a closed loop — sensors, model, and reconciliation of the forecast with actuals on historical data.
When divergence falls within the agreed tolerance, the model is transferred to neighboring components: usually it is enough to reconfigure input parameters rather than retrain from scratch.
How is access to the model and its data separated?
Roles are divided by purpose: the process engineer sees indicators and the forecast but does not export raw arrays; the administrator manages access but does not change the model logic. Data remains in your loop; external export only by an explicit rule and with an access log.
What about support after handover?
We hand over not only the model but everything for its maintenance: configurations, the data flow diagram, and the accuracy check procedure.
After that, we stay in touch at an agreed level — from failure analysis to reconfiguration when the sensor set or component operating mode changes.
Let's discuss your task: what is needed for an estimate
To come back with an estimate and work plan, rather than general wording, we need a minimum of inputs. A digital twin is built for a specific object, so the effort directly depends on how clearly the object boundaries, available data, and operating modes are described. Below is what is worth preparing before the conversation.
- Object boundaries: which components, units, and sections are included in the model, and what consciously remains outside the perimeter — this determines the scope of work.
- Goal and target metric: what we are optimizing (resource consumption, productivity, downtime share) and by what value we will measure the effect.
- Source data for calculation: sensor records for a representative period, mode maps, maintenance and repair logs, and equipment nameplate characteristics.
- Schemes and documentation: process diagrams, drawings, lists of equipment and connections between components — these are used to build the model structure.
- Constraints: permissible mode ranges, safety requirements, and procedures that the model must not violate.
- Project timeline: desired commissioning date, milestones, and windows when equipment can be stopped for measurements.
If some data is missing, that is not a reason to postpone the conversation. Say so directly: we will identify what can be recovered from indirect records, what will have to be collected on site, and how this will shift the timeline. Describe the task — we will come back with an estimate and a work plan broken down by stage.