Physics-based Simulation Digital Twin – what can it do for you?

I don’t think there is much debate that Physics-based Simulation digital twin (PSDT) has already proved its worth . . . especially in product design. Before you actually cast the metal (or plastic), you can assure yourself that structural properties such as stress, thermal distribution, electromagnetic properties, etc., are within safe limits; going further, you can also vary the design to optimize the structural properties. There are many methods of simulation: Physical simulation, Stochastic simulation, Discrete-event simulation, . . . using techniques such as CFD, FEA, Electromagnetic, Thermal, . . .

PSDT such as NPSS can model the “hot-path” of a jet engine and fine-tune designs to maximize thrust or optimize fuel-burn, for example. But going beyond product design, NPSS can also be used during flight to identify deviations from simulated (predicted) sensor data which can lead to the detection and prediction of faults.

In a more “operational” context, large scale agricultural simulation using DSSAT which models water diffusion, soil chemistry, weather and such can help the farmer optimize fertilizer and water use in real time and also maximize crop yields.

In practical terms, once you have a complete simulation in hand, you can investigate further. What changes to the simulation will match the field measurements? Are these changes within simulation “limits”? If not, you have a problem in the field which may require a “truck-roll” on an as-needed basis instead of on a schedule. Such a PSDT saves money and time from disrupted operations and the deployment of expert troubleshooters who are in short supply.

Physics-based Simulation digital twin (PSDT) seems to address most if not all IoT use cases . . . but is that so? Let us take a deeper look . . .

In our progression of PSDTs – Product design, NPSS, DSSAT - solves what is called the “forward” problem, i.e., given the physics and constraints, it tells you what the outcomes will look like. Forward solution is the PRIMARY use of ANY simulation!

Is the “forward” solution sufficient for extracting as much value as possible from digital twins in an IoT use case? My answer is that it is necessary but NOT sufficient. Let me explain . . .

I have classified digital twins as follows. You may appreciate that FORWARD simulation is a building block for both Display and Causal digital twins!

What more do we want out of our digital twins? I have made the case for Causality here - “Evidence-based Prescriptive Analytics, CAUSAL Digital Twin and a Learning Estimation Algorithm”, April 2021 at https://arxiv.org/abs/2104.05828.

One of the major reasons why industry customers deploy IoT is to not only detect and predict faults and avoid “breakdown” maintenance (very costly indeed) but also to find ways to IMPROVE their operations and optimize production (more quantity, higher quality, less waste). The latter is called “Prescriptive Analytics” – prescribe the changes to make in operations based on evidence that will impact productivity.

Whenever you have to “prescribe” something, you need “evidence” to back it up – such as the evidence of efficacy before approving Pfizer vaccine for Covid! You need an EXPLANATION of why something is working so that you know your prescription is grounded in reality – just seeing that it works is not in itself sufficient! BTW, this is the reason for the recent clamor for “explainable" machine learning. ML black-boxes may show high accuracy and nice generalizability but people who use ML recommendations are still hesitant – they want to know the WHY behind ML recommendations!

It turns out that even though PSDT is a "forward" solution, it can be "shoe horned" into generating answers to WHY and explanations also . . . however, it is with a “human in the loop”. In the use of DSSAT for crop field, simulation gives the “forward” results nicely. If you want to find out if over-watering will reduce Nitrogen availability to the crop, you have to run those simulations multiple times and guesstimate “what is causing what”. Admittedly, a large amount of simulation experiments with various combination of parameters may ultimately reveal the cause and effect. But that is not the engineer’s way . . .

We want algorithms to expose causes and effects in a quantitative manner with confidence intervals around them! This is what Causal digital Twin (CDT) provides. Simulation is a necessary part of CDT – simulations that are based on graphs (relationships) rather than physics. Many of the physics-based simulations need super-computers . . . indeed, there are some reduced-order model approaches to soften the blow (more in the Postscript below)!

But simulations are not sufficient – around the forward model, we need an infrastructure to find conditionally-independent nodes and estimate dependencies between other pairs of nodes while holding everything else constant; this will be the brute-force method to assessing Causality. In contrast, CDT in the reference above provides an algorithm that LEARNS the causal relationships in real-time as sensor data from the field arrive . . .

In summary, BOTH Physics-based Simulation digital twin and Causal digital twin can address cause-effect relationships leading to explanations. However, the simplicity of graph-based simulation in Causal Digital Twin makes the digital twin usage so much more tractable than CFD, FEA and such computationally heavy Physics-based simulations for productivity improvements. Here is a table with my subjective rating of which type of digital twin is how good in various cases . . .

Ultimately, it is horses for courses! If the objective is to model the dynamics of interconnected systems for operational cause-effect assessments, use CDT. If you want to optimize structural design aspects of a product, use PSDT – stretching one to do the other’s job is not a good engineering approach!

Postscript: More on Physics-based Simulation

Notice that it is not “PHYSICS” simulation! Solving a Navier-Stokes or Maxwell equation for complex geometries is an impossibility; so what is done is to solve them for teeny-tiny regions and stitch together a massive number of them (that is why it takes a “super” computer). Such an effort is warranted for a one-time product design effort. But keeping such a solution “live” as data pours in via IoT is an over-kill; to accommodate, some drastic simplification (model reduction) can be attempted and approximate solutions can be completed in reasonable time for predictive maintenance. But why? This is where the “horses for courses” thinking should come in. As the table above shows, there are appropriate solutions for each situation – be it the application, number of assets or system type. Mix and match (as circled in the table) is the right approach.

#Causality #Dynamics #DigitalTwin #Causaldigitaltwin #IoT #Causalgraph #Learning #Neuralnetwork