Digital Twins: Maintaining a Model-Data Relationship with a Real System

A three-dimensional drawing of a machine is not automatically a digital twin.

A digital twin is a maintained relationship between a physical asset or process, a software model, and ongoing data used to estimate, simulate, or predict its condition.

Its usefulness depends on model fidelity, trustworthy synchronization, explicit uncertainty, and the decision it supports.

A concrete example: turbine maintenance

A factory twin combines:

turbine design,
operating history,
temperature and vibration sensors,
load,
maintenance records,
and a wear model.

Engineers estimate remaining life and compare maintenance schedules. They do not treat the twin as perfect; inspections and failures update the model.

The physical counterpart

The twin represents a specific asset, class of assets, process, building, network, or environment.

Define:

boundaries,
components,
state,
interfaces,
and operating conditions.

Without a clear counterpart, “twin” becomes a broad marketing label.

The model

Models can be:

physics-based,
statistical,
machine learned,
rule based,
geometric,
or hybrid.

The best choice depends on the decision, available data, required explanation, and operating range.

More visual detail does not necessarily improve prediction.

Data connection

A twin receives data from:

sensors,
control systems,
maintenance,
enterprise records,
weather,
operators,
and inspections.

Track source, units, timestamps, calibration, quality, and ownership. A wrong unit or shifted clock can corrupt state.

Synchronization

The software state must be updated at a rate suitable for the use case.

A structural-maintenance twin may update daily. A process-control twin may need subsecond data.

Define latency, stale-data behaviour, buffering, and conflict resolution. “Real time” should have a measurable deadline.

State estimation

Not every physical state is directly measured.

The twin combines observations and models to estimate hidden variables such as wear, internal temperature, or remaining capacity.

Expose uncertainty and detect when the system operates outside the model's validated range.

Calibration

Calibration adjusts model parameters to match observed behaviour.

Use known experiments, inspections, and historical outcomes. Avoid tuning so closely to one asset or period that the model loses predictive value elsewhere.

Record calibration data and version.

Simulation

A twin can test “what if” scenarios:

increased load,
component failure,
maintenance timing,
new traffic plan,
or control setting.

Simulation is conditional on assumptions. It does not prove the future.

Compare simulated outcomes with observed outcomes to learn where the model is weak.

Prediction

Predictive uses include:

failure risk,
remaining useful life,
energy consumption,
capacity,
and performance.

Evaluate by horizon and consequence. A useful one-day warning may not imply accurate six-month forecasting.

Calibration and false-alarm cost matter.

Decision support

The twin should connect to a decision:

inspect,
slow equipment,
schedule service,
reroute flow,
or compare investments.

Define who acts, required confidence, evidence, and fallback. A beautiful simulation without a decision workflow is an expensive visualization.

Closed-loop control

Some twins can send optimized settings back to the physical system.

This creates an action loop requiring:

authorization,
safe constraints,
staged changes,
monitoring,
rollback,
and independent protection.

Do not give a predictive model unrestricted actuator control.

Model fidelity

Fidelity means sufficient accuracy for the intended decision, not maximum detail.

High-fidelity models cost more to compute, calibrate, and maintain. A simplified model may be more robust and understandable.

Validate the error that matters to the decision.

Validation

Use:

held-out historical periods,
controlled tests,
independent measurements,
rare conditions,
failure events,
and expert review.

Report where the twin is reliable and where it is not. Continue validation after hardware or process changes.

Drift

Physical systems wear, environments change, sensors are replaced, and maintenance alters behaviour.

Monitor residuals between predicted and observed measurements. Investigate whether drift comes from the asset, sensor, data pipeline, or model.

Version recalibration and preserve comparison.

Identity and configuration

Connect the twin to the correct physical asset and its current configuration.

Serial numbers, component replacements, firmware, calibration, and maintenance define identity over time. Applying one turbine's state to another can create dangerous recommendations.

Security

Twins can reveal infrastructure design, operating condition, location, and vulnerabilities.

Protect access, tenant separation, data, models, update paths, and control interfaces. Simulations should not become an unmonitored path to production commands.

Lifecycle

Maintain:

model version,
data schema,
sensor inventory,
calibration,
software,
owners,
and support.

When the physical asset retires, archive necessary evidence, revoke access, and delete unneeded sensitive data.

Control changes to both sides of the twin

A physical modification and a software-model update can each invalidate the relationship.

Use a change process that asks:

Did a component, sensor, control rule, or environment change?
Does the model schema still match?
Which calibration and validation must repeat?
Can old predictions still be interpreted?
Which downstream decisions depend on the update?

Version physical configuration and digital artifacts together. Do not let an automatically updated model advise an asset whose maintenance record has not synchronized.

Require explicit approval before changed twin outputs control maintenance or physical operation.

Knowledge check

What distinguishes a digital twin from a 3D model?
Why is synchronization rate use-case specific?
What does state estimation provide?
How should simulation claims be interpreted?
Why does closed-loop use require stronger controls?

The one idea to remember

A digital twin is a maintained model-data relationship tied to a specific physical system and decision. Its value comes from trustworthy synchronization, calibrated models, explicit uncertainty, validation against reality, secure action boundaries, and lifecycle ownership.