Digital twins

The term has been applied loosely enough to lose meaning. It is worth being precise, because the useful version of the idea is specific and the marketing version is not.

What it is

A digital twin is a model of a specific physical asset, kept in step with that asset by a continuous flow of telemetry, used to answer questions about it that measurement alone cannot.

The distinguishing features are the word specific and the word continuous.

A simulation is not a twin

A model of a class of spacecraft is a simulation. A twin models this particular vehicle, with its as-built properties, its accumulated history and its current state.

A dashboard is not a twin

Displaying telemetry is monitoring. A twin computes quantities that are not measured, from a model driven by the ones that are.

Continuous updating is essential

A model calibrated once at delivery and never updated is a design model. It diverges from the vehicle as components age and drift.

The purpose is inference

A twin earns its cost by answering what-if questions, estimating unmeasured states, and predicting degradation.

The useful test is whether the model tells you something the telemetry does not. If it only displays what was measured, it is a monitoring system with a three-dimensional rendering.

What it is for

State estimation is the clearest value. A spacecraft has far fewer sensors than it has places worth knowing about, because every sensor costs mass, harness and a telemetry channel. A calibrated thermal model driven by the sensors that do exist estimates temperatures everywhere, which is how thermal margins are actually assessed in flight.

Fidelity and calibration

A twin is only as good as its calibration against the real vehicle, and this is where the concept most often fails in practice.

The two correlation steps are what separate a twin from a design model. Ground test correlation, described in Thermal control and Structures and mechanisms, adjusts model parameters until predictions match measurements. Uncorrelated thermal models routinely miss by tens of degrees, and structural frequencies by 10% or more.

Continuous recalibration in flight is what keeps the twin valid. Solar arrays degrade, thermal surfaces darken, batteries lose capacity, and propellant depletes. A model with beginning-of-life parameters becomes progressively wrong in exactly the direction that matters, since it will predict better performance than the vehicle can deliver.

Anomaly detection

The natural application, and the one where machine learning contributes most.

The residual approach is the one the twin enables. A battery voltage within limits but 200 mV below what the model predicts for that load, temperature and state of charge is an early indication of degradation that limit checking will not see for months.

Trend analysis deserves emphasis independently. Most spacecraft failures are preceded by observable drift, and the practice that most reliably prevents anomalies from becoming failures is watching trends rather than thresholds. See Fault tolerance and reliability.

The difficulty with learned anomaly detection is false positives. A detector tuned to catch subtle anomalies also flags benign unusual behaviour, and operators who investigate many false alarms stop investigating. The operational requirement is a low false positive rate even at the cost of sensitivity, which is the opposite of how such systems are usually benchmarked.

Operations rehearsal

Running a command sequence against the twin before uplinking it catches constraint violations that static checking misses, because the violations emerge from interactions.

A sequence that slews, images, and transmits may satisfy each constraint individually and violate the battery state of charge limit in combination. Simulating it against a calibrated model of this vehicle, in its current degraded state, catches that.

This matters most for missions where a mistake is unrecoverable. Deep-space missions validate every sequence against a simulator before uplink as standard practice, and the fidelity of that simulator is the fidelity of the check. See Simulation.

What it requires

The infrastructure cost is the reason twins are less common than the discussion suggests.

The last row is the one that erodes twins over time. Spacecraft accumulate changes: a failed unit switched out, a mode never intended for continuous use, a software patch. A twin that does not track these becomes wrong in ways nobody notices, because it still produces plausible outputs.

An honest assessment

The concept is sound and the term is oversold. What is genuinely valuable is the combination of validated physics models, a good telemetry archive, and continuous recalibration, which is what serious missions have always done under the name of flight dynamics and subsystem trending.

The contribution of the digital twin framing is integration: bringing separate subsystem models into one place, driven by one telemetry stream, so that cross-subsystem interactions are visible. That is a real improvement and a more modest claim than usual.

Where twins matter most is where the vehicle cannot be reached and the consequence of a mistake is total, which points at long-duration deep-space missions and at crewed missions operating under communication delay. See Mars habitats.

References

• Glaessgen, E. H. and Stargel, D. S. “The Digital Twin Paradigm for Future NASA and US Air Force Vehicles”, AIAA 2012-1818.
• Tao, F. et al. “Digital Twin in Industry: State-of-the-Art”, IEEE Transactions on Industrial Informatics, 15:2405, 2019.
• Martin, R. A. et al. “Model-based systems engineering and digital twin applications in NASA missions”, NASA technical reports.
• Fuertes, S. et al. “Improving spacecraft health monitoring with automatic anomaly detection techniques”, SpaceOps 2016.