Digital Twins & Physics-Based Digital Models

What a useful digital twin is

A useful digital twin is a maintained digital representation of a specific physical system that uses real-world information to estimate, predict or interpret that system's state. The defining features are that it represents a specific asset — not a generic model of an asset class — and that it is connected to that asset through real-world data, so that its state reflects the asset's actual condition and history. The engineering value is in the connection: a model that is calibrated once and then left alone is a digital model, not a twin. A twin is maintained, updated and used to support decisions about its physical counterpart — fatigue usage accumulation, remaining life, current load state, deformation under a measured load, the interpretation of a sensor anomaly. The term is heavily overused, and a clear definition is the first defence against buying or building the wrong thing.

A spectrum, not a rigid taxonomy

It is helpful to think of a spectrum rather than a hard boundary. A digital model is a physics-based representation of an asset, built and validated but not necessarily connected to the live asset. A digital shadow is a model that receives data from the asset — sensor streams, operational loads — but does not automatically feed that information back to update its own state; the connection is one-way. A digital twin closes the loop: it receives data from the asset, updates its state, and uses the updated state to predict or support decisions, with the update and prediction maintained over the asset's life. This spectrum is useful for thinking about what a given system does and what it would need to do to qualify as a twin. Different authors and communities use these terms differently, and a rigid universal taxonomy is not claimed here; the engineering point is what the system actually does with asset data, not what it is called.

The components of a digital twin

A digital twin is a pipeline, not a single model. Data comes from the physical asset through sensors and operational feeds; it is processed — filtered, synchronised, checked for quality; it drives a physics model, often a reduced-order model so that the state can be estimated in real time; the state estimate supports a prediction or a decision. Each stage has its own failure modes, and the twin is only as trustworthy as its weakest stage. The ordered list below sets out the pipeline.

1. Physical asset — the specific structure or system the twin represents.
2. Sensors and operational data — strain, acceleration, temperature, load, usage counts from the asset.
3. Data processing — filtering, synchronisation, quality checks, handling of missing or bad data.
4. Physics model / reduced model — the physics-based representation, usually reduced for real-time evaluation.
5. State estimation — inferring the asset's current state (loads, stresses, temperatures, damage) from the data and the model.
6. Prediction / decision support — fatigue usage, remaining life, current deformation, load exceedance, maintenance triggers.

What a twin is used for

The uses of a digital twin are concrete and engineering-led. Fatigue usage tracking accumulates damage at critical locations from measured loads, so that inspection or retirement can be scheduled against actual usage rather than a conservative assumption. Thermal state estimation reconstructs the temperature field of a structure from a few sensors and a model, so that thermally driven stresses can be assessed. Structural load reconstruction infers the loads the asset has experienced from measured responses. Remaining-life estimation combines the current damage state with a model of future usage. Vibration-health monitoring detects changes in dynamic behaviour that indicate damage or degradation. Deformation estimation reconstructs the full-field displacement of a structure from sparse sensors and a reduced model. In each case the twin provides an estimate that is more specific to the actual asset and its actual history than a generic analysis could be — and that specificity is the value.

• Fatigue usage tracking — accumulate damage at critical locations from measured loads.
• Thermal state estimation — reconstruct temperature field from sparse sensors and a model.
• Structural load reconstruction — infer loads experienced from measured responses.
• Remaining-life estimation — combine current damage state with a model of future usage.
• Vibration-health monitoring — detect changes in dynamic behaviour indicating damage.
• Deformation estimation — reconstruct full-field displacement from sparse sensors and a reduced model.

A digital twin is not a model on a dashboard

The most common mischaracterisation is to call any finite-element model displayed alongside live sensor data a "digital twin". Visualisation is not connection, and connection is not a twin. A genuine twin uses the asset data to update its own state and to support a decision; a model that is merely shown next to the data does neither. The test is functional: does the digital representation change its state in response to the asset data, does it predict something about the asset that the raw data alone does not reveal, and is it maintained in configuration consistency with the specific asset? If the answer to any of these is no, the system is a digital model or a digital shadow, and that is a perfectly legitimate thing to be — but it is not a twin.

A DIGITAL TWIN IS NOT SIMPLY AN FE MODEL DISPLAYED ON A DASHBOARD.

A physically credible example

The diagram shows a credible digital twin for a structural application — an aerospace wing, a UAV structure, a race-car structure or a comparable advanced mechanical system. The physical system is instrumented with strain, acceleration, temperature and load sensors. The data is processed and fed into a reduced physics model whose parameters are kept current with the asset. State estimation produces a current estimate of fatigue usage, deformation or load. There are no floating holograms and no magical visualisation; the twin is a maintained pipeline from sensor data to an engineering estimate.

DIGITAL TWIN — PHYSICALLY CREDIBLE EXAMPLE

  PHYSICAL SYSTEM                     DIGITAL TWIN
  (e.g. aerospace wing /               (maintained, connected,
   UAV / race-car structure)           configuration-consistent)

  ┌───────────────────┐               ┌─────────────────────────┐
  │  physical asset   │  sensor data  │  DATA PROCESSING         │
  │  (specific unit)  │──────────────►│  filter · synchronise ·  │
  │                   │  strain,      │  quality check · handle  │
  │  ● strain gauges  │  acceleration,│  missing / bad data      │
  │  ● accelerometers │  temperature, │           │              │
  │  ● temperature    │  load         │           ▼              │
  │  ● load / usage   │               │  REDUCED PHYSICS MODEL   │
  │                   │               │  (parameters kept        │
  │                   │               │   current with asset)    │
  │                   │               │           │              │
  │                   │               │           ▼              │
  │                   │               │  STATE ESTIMATION        │
  │                   │               │  (infer current loads,   │
  │                   │               │   stresses, damage)      │
  │                   │               │           │              │
  │                   │               │           ▼              │
  │                   │               │  ESTIMATE / PREDICTION   │
  │                   │               │  fatigue usage ·         │
  │                   │               │  deformation · load      │
  │                   │               │  remaining life          │
  └───────────────────┘               └─────────────────────────┘

  No floating holograms. The twin is a maintained pipeline
  from sensor data to an engineering estimate, kept
  configuration-consistent with a specific physical asset.

Sensor uncertainty and observability

A digital twin is only as good as the data it receives and the model it uses. Sensors have calibration uncertainty, drift, noise and failure modes; data can be missing or corrupted; the model may not be observable from the available sensors — that is, the sensor set may not be sufficient to determine the state the twin is trying to estimate. Observability is a property of the combination of sensor placement and model, and it must be checked, not assumed. A twin that estimates a stress at a location with no nearby sensor and no model path that constrains that stress from the available measurements is producing a model prediction dressed up as a measurement-based estimate. The credible handling of sensor uncertainty and observability is what separates a trustworthy twin from a dashboard that happens to show numbers.

Configuration control: the twin must stay consistent with the asset

A specific physical asset changes over its life: components are replaced, repairs are made, modifications are introduced, sensors are added or removed. A digital twin that is not updated to reflect these changes drifts out of consistency with the asset it represents, and its estimates — however sophisticated the model — become estimates of a different structure. Configuration control is the discipline of keeping the twin's model, parameters and sensor definitions current with the as-maintained configuration of the asset. Without it, the twin silently becomes a model of a generic or historical asset, and the specificity that is the whole point of a twin is lost.

THE "TWIN" MUST REMAIN CONFIGURATION-CONSISTENT WITH THE PHYSICAL ASSET.

Digital twin credibility checklist

The checklist below is a practical set of questions for assessing whether a proposed or existing digital twin is credible enough to support engineering decisions. Most failures of digital-twin projects are not in the model but in the unglamorous parts: sensor handling, configuration control, validation and a clear statement of what decision the twin actually supports.

• Physical asset uniquely identified? — The twin represents a specific serialised asset, not an asset class.
• Configuration current? — Model, parameters and sensor definitions reflect as-maintained state.
• Sensor calibration known? — Calibration, drift and uncertainty are documented and current.
• Missing or bad sensor data handled? — Degraded sensor states are detected and the twin degrades gracefully.
• Model parameters current? — Updated from test or operational data with documented provenance.
• Operational domain defined? — The conditions under which the twin is valid are stated explicitly.
• Model state observable from the sensors? — Observability checked, not assumed.
• Uncertainty represented? — Estimates carry uncertainty, not just point values.
• Prediction horizon appropriate? — The twin is not used to predict further than its model and data support.
• Model update controlled? — Updates are reviewed and approved, not automatic and untraceable.
• Independent validation performed? — Validated against data not used to calibrate the model.
• Decision supported is clearly defined? — The twin exists to support a specific decision; that decision is named.

Digital model, digital shadow, digital twin

The table distinguishes the three points on the spectrum. The distinction is functional — what the system does with asset data — and the term "digital twin" is appropriate only when the full loop is closed: data flows from the asset, the model state is updated, and predictions or decisions are produced and maintained over the asset's life. Calling a lesser system a twin does not make it one, and doing so sets up the programme to rely on a capability it does not actually have.

The classic misuse: a static model with a live data overlay

The most common misuse is labelling a static finite-element model a "digital twin" because it is visualised alongside live sensor data. The model does not update its state from the data; it does not predict anything the raw data does not already show; it is not kept configuration-consistent with a specific asset; and the decision it supports is not clearly defined. It is a digital model with a dashboard, which is a useful thing, but it is not a twin. The risk is that the label creates an expectation of capability — live state estimation, remaining-life prediction, configuration-tracked decisions — that the system does not meet. The defence is to test the claim functionally: does the representation update, does it predict, is it maintained, and what decision does it support?

CALLING A STATIC FE MODEL A "DIGITAL TWIN" BECAUSE IT IS VISUALISED ALONGSIDE SENSOR DATA DOES NOT MAKE IT ONE. A digital twin must be maintained, connected and configuration-consistent with a specific physical asset.