[Column] When Operational Data Loops Back Into Design, the Digital Twin Is Complete

A column by Yu Seong-jae, director at MathWorks Korea, published in IT Daily, titled "When Operational Data Loops Back Into Design, the Digital Twin Is Complete," explains that the meaning of a digital twin is not limited to a virtual model at the development stage. It argues that the state of actual equipment changes depending on mission, environment, operating time, and maintenance history, and that a digital twin meets the criteria for judgment only when these state changes are verified through data and linked to the model. Accordingly, it says digital twins are used as a basis for operational and maintenance decisions.

It explains that this kind of system requires PHM. PHM stands for Prognostics and Health Management, and it performs functions such as sensor-data-based anomaly detection, root-cause analysis, and prediction of future state changes. Its purpose is to support maintenance decisions. In addition, the digital thread connects the information needed for this PHM process, and the article cites requirements, models, test results, operational data, and maintenance records as the items to be connected.

It also explains that both virtual testing and physical testing during the development stage aim to verify whether equipment meets requirements. However, the actual operating environment is more complex than the development stage, and even equipment with the same configuration can show differences in condition depending on load, temperature, vibration, humidity, operating time, and maintenance history. Accordingly, it says that a digital twin in the operational stage should be based on sensors and maintenance records and should reflect condition differences across equipment.

In the end, it summarizes that the core question at the development stage is whether requirements are met, whereas the core questions at the operational stage are identifying the current condition, identifying problems in progress, and determining the timing of inspections. The article explains that a digital twin should not remain a model for the development stage, but must be connected to the real equipment state that changes during operation.

PHM is commonly thought of as a technology for predicting failure timing and remaining useful life, but in practice it is a continuous process of anomaly detection, fault diagnosis, condition assessment, and maintenance decision-making. PHM is not a single predictive AI, but a system that finds anomalies, identifies the cause, assesses condition, and leads to maintenance decisions.

For this reason, the first tasks in PHM take priority over selecting an AI type. Those prior tasks are identifying the equipment, identifying the critical problem, deciding which signals can be detected, and determining how the result will be used for maintenance decisions.

In addition, high prediction accuracy alone is not enough to deliver sufficient operational value. If it is not linked to actual action, operational value is limited.

In the defense and aerospace sectors, failures are rare, and it is difficult to collect enough real failure data. The constraints include high reproduction cost and high reproduction risk. In addition, because each piece of equipment has different missions and different environments, it is also difficult to apply data from one piece of equipment directly to another.

In this environment, the role of data-driven methods is to detect abnormal patterns in sensor signals, while the role of physics-based models is to explain the causes of signal changes according to temperature and load. When failure data are insufficient, simulation becomes a means of supplementing the conditions needed, and the important principle is to use both methods together in a way that matches the purpose and the information that can be secured.

JAXA is developing PHM technology for spacecraft propulsion systems to improve the safety and reliability of lunar, Mars, and deep-space missions. Its goal is to rapidly and accurately identify thrust anomalies caused by supply-system filter clogging and valve defects.

To that end, JAXA developed a fiber Bragg grating (FBG) sensor method to expand propulsion-system information. The FBG sensor method can measure pressure without damaging the equipment. The collected data are in time-series form.

As preprocessing tools, it used MATLAB and Signal Processing Toolbox. The processing procedure calculates the fast Fourier transform (FFT) and then applies a high-pass filter. It then used the peak detection function to synchronize surge data. It also used Predictive Maintenance Toolbox to explore and rank features for machine learning model training and comparison.

The example topic was an analysis of sensor signals and the importance of fault-diagnosis features according to flow-rate changes. In this case, JAXA used MATLAB to develop a start-to-finish fault diagnosis and predictive maintenance application. This made it possible to evaluate field measurement data immediately, confirm characteristics, and implement a standalone app.

The central element of this case was the overall flow rather than the AI model itself. That flow consisted of defining the target failure, selecting sensors, processing signals, comparing features, evaluating the model, and using it in the field. The JAXA case shows an approach in which MATLAB was used to build a diagnosis and predictive maintenance app, while emphasizing the entire process from failure definition to field use rather than a single AI model.

It was also noted that an alert from a PHM model alone is not sufficient. To secure the reliability of an alert, it is necessary to check which equipment's data were used, which configuration the data came from, which sensors were used, which processing method was applied, which model version made the judgment, and whether the result matches the actual inspection outcome. Here, the role of the digital thread is to preserve the basis for the judgment.

The importance of this linkage is also tied to the application of digital twins to domestic weapon systems. The Defense Acquisition Program Administration has the "Guidelines for Using Digital Twins for Weapon Systems," which present sensor-network-based data collection and virtual experiments based on real-time simulation. They also call for functional-area-based preparation of utilization plans, with examples of functional areas including requirements definition, design and engineering, and test and evaluation.

The guidelines also cover the assessment of model and virtual-experiment appropriateness, as well as the management of utilization results and technical data. This aligns with the condition that, to use a digital twin in actual decision-making, data, models, and test results must be linked and the basis must be verifiable. In the end, for actual decision-making, data, models, and test results must be connected and verifiable.

An example of the configuration is the connection between sensor data collection, real-time testing, and the digital twin environment. Along with this, the digital thread links requirements, design models, test results, operational data, maintenance records, and PHM judgments into a single flow.

When such linkage is established, anomalies can trigger a recheck of design assumptions and a review of past test results. Changes before and after maintenance can also be compared in the same context.

Repeated problems in operation serve as new test conditions. Unexpected degradation becomes a basis for revising the model, and if the necessary state is not observed, the sensor requirements for the next piece of equipment may change.

Operational data also serve as material for the next round of design improvements. In this way, information obtained during operation leads to later testing, models, sensor requirements, and design improvements.

However, not every piece of equipment needs the most complex digital twin. The level of the digital twin should be determined not by the technical maximum but by actual decision-making needs. Connecting every part in real time increases cost and complexity, and trying to predict even remaining useful life also increases cost and complexity.

For some equipment, condition monitoring alone is sufficient, while other equipment may need fault diagnosis or life prediction. In this case, the key criterion is not model complexity, but whether the result contributes to actual operational and maintenance decisions.

An operational PHM model requires continuous validation and does not end with a single deployment. If operating conditions change, sensors change, or software changes, the input data may change, so the initial validation conditions must be continuously checked against real-world field conditions. In addition, model alerts must be continuously compared with actual inspection results, and if false alerts recur or problems are missed, the data, the features, and the judgment criteria must all be reviewed again.

Along with this management, the model version and validation results must be managed together, and the purpose is to explain the basis for judgment. AI can narrow the scope of what needs to be checked, but it cannot replace the final maintenance decision or the final mission decision.

When starting PHM, the first step is to define in advance what you want to know. At this stage, the first items to decide are the target equipment and failure, the required lead time, and the inspection and maintenance decision based on the result.

Next, the data and models available at the start of PHM should be reviewed. The data to be checked are sensor data and maintenance records, and the model to be checked is the existing model. When failure data are insufficient, simulation serves as a supplementary means.

For the application method, it is recommended to start with one critical piece of equipment rather than expanding to all equipment from the outset. When starting PHM, the scope of application should be defined in this way.

After that, a process of continuous comparison with actual results is needed when PHM begins. The comparison targets are prediction and inspection results, and the purpose of the comparison is model improvement. Repeated problems should be reflected in new test conditions and also reflected in the next design.

In this way, lessons learned from operations need a feedback loop back into design. The starting point of the digital thread lies in connecting requirements, design, code, and test results.

Operational data, maintenance records, and PHM judgments are added here as additional elements of the digital thread. When operational data, maintenance records, and PHM judgments are connected back to testing and design, a unified development-operation flow is formed.

The criterion for judging the value of a digital twin is not how realistic the screen looks or how many models it has, but whether it can explain the current condition reliably, detect problems early, use the results for maintenance, and use them for the next design. In particular, when lessons learned in operation become inputs to the next design, operations and design are linked, and overall life-cycle improvement of the digital twin leads to the systematization of engineering.

Source: IT DAILY · Yu Seong-jae
Original: https://www.itdaily.kr/news/articleView.html?idxno=242048

References

• https://www.itdaily.kr/news/articleView.html?idxno=242048