Digital Twins: Not Just Hype

Is the term “digital twin” just hype, or a trick to get a new angle to sell modeling software? In this blog post, we discuss the difference between models, applications, and digital twins. We conclude that although the term has been misused to a certain extent (in relation to the original formulation), there is substance behind it.

What Is a Digital Twin?

One of the first industries to consider the use of digital twins is the aerospace industry. In a very insightful paper, Glaessgen and Stargel (Ref. 1) explain the use of digital twins for vehicle certification and fleet management. The digital twin for a vehicle would be used to “continuously forecast the health of the vehicle or system, the remaining useful life, and the probability of mission success.” The description of the digital twin is the following: “A digital twin is an integrated multiphysics, multiscale, probabilistic simulation of an as-built vehicle or system that uses the best available physical models, sensor updates, fleet history, etc., to mirror the life of its corresponding flying twin.”

The term “digital twin” was coined by Michael Grieves at the University of Michigan in 2011. (Ref. 2) The concept had already been formulated by Grieves in 2002, but was then referred to as a “mirrored spaces model.” In Grieves’s definition, the digital twin concept consists of a real space and a virtual space. The virtual space contains all of the information gathered from the real space. It also contains a high-fidelity description of the physical device or process from the microscopic level to the geometric, macroscopic level. The description provided by the digital twin should be “virtually indistinguishable from its physical counterpart.” (Ref. 3)

A Few Definitions from M. Grieves

• Digital twin prototype (DTP): This is the prototype used for the digital twin instance. A detailed high-fidelity model would typically be a part of such a prototype. However, the prototype would not include measured data and reports from a specific physical device (yet).
• Digital twin instance (DTI): A digital twin that contains parameters, control parameters, sensor data, and historical data for a specific product, device, or process. Such an instance would be able to, for example, make a life prediction of a specific engine in a specific fighter jet, as exemplified above.
• Digital twin aggregate (DTA): An aggregate of digital twins that may not have an independent unique data structure. Instead, the constituent DTIs may query each other for data.
• Digital twin environment (DTE): An integrated multidomain physics application space for operating digital twins.

An important requirement in the concept of the digital twin is that it should be a dynamic, continuously updated representation of the real physical product, device, or process. It should not be a static representation of the real space. The real and virtual spaces are connected from manufacture and operation to disposal of the product, device, or process. Information from sensors, reports from users, and other information gathered through the processes of manufacture and operation has to be continuously transferred to the digital twin. The predictions, control parameters, and other variables that may be used to design and operate the real device must continuously be transferred back from the virtual space to the real space.

In contrast to a conventional model, a digital twin has a very tight connection between the real and virtual spaces.

If we look at the case of a jet airplane in the operational stage (also including situation awareness), the airplane’s sensors and control system may continuously send data to the digital twin. Also, the pilot may send data and reports. The digital twin may send control parameters and reports back to the airplane. So, certain aspects of the digital twin may operate in real time and deployed in the airplanes different computer systems while other more demanding tasks may not be operating in real time on the real device. In any of the cases, the connection between the real space and the virtual space is strong.

Systems, Subsystems, and Virtual Subspaces

We can imagine that a jet airplane is an extremely complex system. A high-fidelity modeling and simulation environment of such an advanced machine probably requires several hundreds, maybe thousands, of multiphysics and multiscale models to be described accurately.

For example, the jet engine may be described by a combustion model in order to optimize the performance of the jet, as well as predict and control operating conditions for combustion. A CFD model may also be coupled to the combustion model, which in turn may be coupled to a pipe flow model of the fuel distribution system. Also, the cooling system may require a specific model with pipe flow models coupled to heat transfer in solids and CFD. In addition, a multibody dynamics fluid-structure interaction (FSI) model may predict and control the movement of certain parts of the jet engine, given the flow field and the forces exerted by the fluid. Structural mechanics analysis may be carried out and coupled to detailed microscopic material models of certain critical components that are sensitive to fatigue and temperature cycling. The models may continuously get data from the flow in the turbine, the composition of the gas mixture, the temperature, the revolutions of the jet engine, the vibrations, the speed, and the history of all of the operational variables for a specific turbine — and there are many more aspects of just the turbine.

A CFD and heat transfer analysis makes it possible to compute the stresses and strains on a turbine stator. The stresses allow engineers to estimate the number of cycles that the turbine stator can be subjected to before risking failure due to fatigue. The digital twin instance keeps track of the number of temperature cycles and also the maximum stresses and strains the stator has been subjected to during its lifetime.

Other parts of the jet require equally accurate descriptions. The flight control, hydraulics, landing gears, and other subsystems may have their own digital twins, each consisting of multiphysics, multiscale models, simulation data, sensor data, and historical data.

The figure above shows some of the most important subsystems in a fighter jet. A digital twin consists of many different subspaces containing models, simulation data, measured data, and reports for each of the subsystems of the airplane. Such system may be described with a digital twin aggregate.

The digital twin may therefore consist of many virtual subspaces and subsystems that talk to each other and query each other for information; for example, in a digital twin aggregate. A simulation data management system may coordinate the looser connections between different multiphysics, multiscale models; for example, by executing a simulation upon a query for updated information from another subsystem. System models with cosimulation capabilities may be used to run simulations that require a bidirectional coupling between different subsystems.

The high-fidelity model, sensor data, historical data, and user reports may be used for digital twins for different stages of a product, device, or process. The digital twin and its technology, for the case of the jet airplane above, may be used during design, certification, manufacture, operation, situation awareness, and life prediction. (Ref 1)

Lightweight Models

High-fidelity multiphysics and multiscale models may require computer power and may also take long computational time to give results. However, some systems of the physical product may need simulation data in real time; for example, for control systems and real-time diagnosis in the jet airplane above. For the purposes that require a very fast reply upon queries from the real system, the digital twin has to incorporate lightweight models that can deliver a fast reply.

The detailed CFD simulation (LES) for this simple benchmark wing profile takes hours to run on a relatively powerful desktop computer. The corresponding simulation on a real wing geometry takes hours to compute on a supercomputer. Such detailed simulations can only be run for validation of an array of simpler models, from turbulence models down to very simple lumped models that can be run in real time.

The drawback with lightweight model is that they often have a limited range of validity. The digital twin can broaden this range by continuously validating the lightweight model using high-fidelity models, sensors, and reported data for the operational range. The update of the lightweight models may be scheduled and also triggered when the operational range is close to being outside a previously verified range.

The benefit of lightweight models is obvious: They are fast. If we look at the example of the fighter jet, the lightweight models may be embedded in the subsystems and computers that control these subsystems. The continuous update and validation of these models can be done using sensors and reported data and also through high-speed communication with the supercomputers on an air force facility, where high-fidelity multiphysics and multiscale models are deployed together with historical data and sensor data.

The Hype

From the discussion above, we can conclude that a huge amount of sensor data, historical data, reports, simulation data, and control parameters must be sent between the real space and the virtual space and stored in a unified repository. For military applications, all of this will take place within a closed system where the jet fighter communicates with the supercomputers at an air force facility using military communication systems. For civilian applications, the need for communication and computations explains the hype around the internet of things (IoT), 5G network, machine learning, and cloud computing in conjunction with digital twins. The analogous requirements within a closed system are valid for military applications.

There is a real value in these technologies in conjunction with the digital twin concept. It is not only hype!

For civilian applications, it is extremely important that the IoT is able to communicate sensor data and send back validation and control data to the embedded system in a device. Machine learning, also called artificial intelligence, can be used to decide when to query or update subsystems, sensors, and different models in order to keep the digital twin and the physical device or process in close fidelity. Cloud computing may be used to solve the complex model equations, validate the models, filter and process measured data, store and process historical data, and query different system and subsystems depending on the commands from a user or an AI. So, there is real value in this concept; it is not just hype.

COMSOL Multiphysics® and Digital Twins

It is obvious that the COMSOL Multiphysics® software can provide the multiphysics and multiscale models required to build the high-fidelity descriptions for digital twins. In addition, the COMSOL® software has capabilities to control and validate these models using measured data in combination with different methods for parameter estimation, optimization, and control. COMSOL Multiphysics also provides methods for model order reduction (Ref. 4) and lumped model methods that may be used for producing and validating lightweight models.

A COMSOL Multiphysics model may also contain several model components in order to model a system with components that can be very closely coupled. A system model could, for example, be a model of the jet engine containing a pipe flow model component for the fuel distribution system, a component for the cooling system, one or several structural model components, combustion, and CFD model components for different parts of the engine.

The tight linkage between the real and virtual spaces can be achieved in COMSOL Multiphysics using COMSOL API for use with Java®. The Java® model file incorporated in such a program can communicate with the external system; for example, by using dynamic link library files (dll-files). Benefiting from the Java® ecosystem, it is also possible to implement the virtual space as a web service (such as a Java®-based web service running inside Tomcat) that could present, for example, a representation state transfer application programming interface (REST API) for communicating with the real space. This would be a central part of the digital twin environment.

Web service running Apache Tomcat presents a REST API, which can be used to get a tight linkage between the physical device and the COMSOL application to create a digital twin. Turbine photograph by Sanjay Acharya — Own work. Licensed under CC BY-SA 3.0, via Wikimedia Commons.

COMSOL Server™ can be used to administrate models and applications that can be queried for simulation data triggered by the update of an input file or an operator. Also, applications compiled using COMSOL Compiler™ can be used to receive input data and produce output data in the form of control parameters and reports. The only limitations for applications in COMSOL Server™ and compiled applications is that the input cannot be updated during execution (in contrast to the example above using COMSOL API for use with Java®, where input data can be continuously received in real time). The input is done upon execution while the output may be continuous during execution. The typical use of COMSOL Server™ and compiled applications would therefore be in high-fidelity descriptions run on relatively powerful computers. These applications may be queried within the digital twin to produce data for the validation of lightweight models that may be embedded in the product, device, or process.

Concluding Remarks

We can conclude from the discussion above that concept of digital twins is not just hype. The value of being able to understand, predict, and optimize a product, device, or process during design, manufacturing, operation, and even disposal is very large. For example, in the case of the fighter jet, the digital twin would follow its physical counterpart through its product life cycle, delivering design, control, and operational parameters, as well as safety and life prediction, at a relatively low cost.

COMSOL Multiphysics, COMSOL Server™, and COMSOL Compiler™ can all deliver the multiphysics, multiscale, and lightweight models as well as the validation and control methods for digital twins, all with the highest possible fidelity between the real and virtual spaces delivered by real multiphysics capabilities!

Next Step

Learn more about how COMSOL Multiphysics models and simulation applications can fit into the use of digital twins at your organization. Contact us to evaluate the software via the button below:

References

1. E. Glaessgen and D. Stargel, “The Digital Twin Paradigm for Future NASA and U.S. Air Force Vehicles,” 53rd Structures, Structural Dynamics and Materials Conference, 2012.
2. M. Grieves, “Origins of the Digital Twin Concept”, working paper, Florida Institute of Technology, 2016.
3. M. Grieves, “Digital Twin: Manufacturing Excellence through Virtual Factory Replication,” Michael W. Grieves, LLC, 2014.
4. D. Hartmann, M. Herz, and U. Wever, “Model Order Reduction a Key Technology for Digital Twins”, Reduced-Order Modeling (ROM) for Simulation and Optimization, pp. 167–179, Springer, 2018.

Oracle and Java are registered trademarks of Oracle and/or its affiliates.