Digital Twins and ML

A digital twin is a technology that builds a virtual copy of a real-world physical system as a simulation model and monitors/predicts its state in real-time through synchronization with sensor data. By combining CAE physics models with machine learning, it enables fast prediction and adaptive updates.

The decisive difference is that it is "alive." A regular CAE simulation is run once during the design phase and that's it, but a digital twin continuously ingests sensor data and updates itself throughout its operational life. This enables predictions that account for aging degradation, unexpected loads, and environmental changes.

It is formulated as a state-space model. The system state $\mathbf{x}_k$ follows a time evolution equation, and the observation $\mathbf{y}_k$ is its partial measurement.

Here, $f$ is the physics model (FEM, etc.), $\mathbf{u}_k$ is the input (loads, etc.), $\mathbf{w}_k$ is the model error, $h$ is the observation operator, and $\mathbf{v}_k$ is the observation noise. ML is used either as a fast approximation of $f$ (surrogate model) or for learning the model error $\mathbf{w}_k$.

Using FEM's $f$ directly would be too slow for real-time updates. Approximating $f$ with ML enables predictions on the order of seconds. Furthermore, it can learn degradation mechanisms and environmental dependencies from data that are difficult to fully capture with physics models.

There are three patterns.

1. Hybrid Type: Corrects the physics model output with ML. $\hat{y} = f_{\text{physics}}(x) + f_{\text{ML}}(x, \text{residual})$

2. Surrogate Type: Replaces the entire physics model with ML. Fast but has challenges with extrapolation.

3. Physics-Constrained Embedded Type: Uses ML models with physical laws embedded in the loss function, like PINNs.

In practice, the hybrid type is the most reliable. It captures the global behavior with the physics model and corrects residuals with ML.

Let's organize the main components.

POD (Proper Orthogonal Decomposition) is standard. Compute many full FEM solutions to form a snapshot matrix, then extract principal basis vectors via SVD. Even for a model with 1 million original degrees of freedom, 10-50 basis vectors often capture over 90% of the energy. This speeds up computation by tens of thousands of times.

A two-stage training process is common.

Offline Training: During the design phase, run many parametric FEM analyses to create a dataset of parameters and responses, and pre-train the ML model. Use Latin Hypercube Sampling (LHS) to efficiently cover the parameter space.

Online Training: After operation begins, update the model sequentially using actual sensor data. Use transfer learning or fine-tuning to adapt to small amounts of real data.

Not necessarily real-time. In many cases, models are updated in batches daily or weekly. Real-time performance is needed for the data assimilation (state estimation) part, while model parameter updates themselves run on a slower cycle.

Model lightweighting is key. Techniques include exporting to ONNX format and inferencing with ONNX Runtime, quantization (INT8) to reduce computation, and optimizing GPU inference with TensorRT. If the required computational load for inference is kept around 100 MFLOPS, millisecond-level response is possible even on edge devices like NVIDIA Jetson.

Trying to go large-scale from the start leads to failure. A phased approach is the golden rule.

Phase 1: Proof of Concept (PoC) — Verify "whether predictions match actual measurements" using a single component, a few sensors, and a simple model. Duration: 3-6 months.

Phase 2: Pilot Operation — Accumulate data in the actual operational environment and gradually improve the model. Build the online learning mechanism. Duration: 6-12 months.

Phase 3: Full-Scale Deployment — Expand to multiple components and multi-physics support. Establish operation and maintenance systems.

The most common is the "insufficient data" pattern. Sensor placement is inappropriate, sampling frequency is too low, or data quality is simply poor. It's crucial to plan the sensor strategy thoroughly before the PoC.

• First, ensure the accuracy of the physics model. Even if you correct with ML, if the base physics model is sloppy, the whole thing falls apart.
• Perform regular sensor calibration. There's a risk of mistaking sensor drift for model degradation.
• Implement a mechanism to quantitatively monitor model prediction performance. Issue alerts if metrics like RMSE deteriorate.
• Strictly manage data versions. Traceability of data used for training, model versions, and inference results is necessary for audit compliance.