We’ve already determined that the concept of digital twins is more than just hype. In this blog post, we discuss how high-fidelity multiphysics models can be combined with lightweight models and measured data to create digital twins that can be used to understand, predict, optimize, and control the real system and the model of the real system. This is exemplified with a battery pack for hybrid vehicles.
The Digital Twin Concept
Traditional model-based design involves the verification and validation of models, which can be used to optimize the design or operation of a device or process. The model is usually validated by comparing experimental results with the model results and performing parameter estimation.
Mathematical modeling and simulations are widely used for the design of devices and processes.
The concept of digital twins, also called virtual twins, encompasses the verification and validation steps described above for model-based design. The difference is that a digital twin implies that the transfer of information between the model and the device or process is much tighter and often in real time. The digital twin concept may be used during the design, manufacturing, and operational phases of a device or process. The purpose is to understand, predict, optimize, and control the real system based on the model in the virtual space. We can imagine that digital twins are applicable for relatively sophisticated and expensive systems. We would probably not construct digital twins or administrate digital twin instances for every exhaust pipe in a conventional car, as this would probably not give a return on investment. A battery pack, however, is a relatively expensive system.
In this blog post, we exemplify the use of digital twins in the design and operational phases of battery packs for hybrid or electric vehicles.
Digital Twin of a Battery Pack
The figure below shows the digital twin concept containing the physical device in the real space: a battery pack with sensors and control systems. The virtual space contains the model; in this case, the model of the battery pack. The transfer of data and information connects the real space with the virtual space (Ref. 1).
The digital twin concept exemplified on a battery pack in a hybrid car.
Multiphysics, Multiscale, and Lightweight Models
The virtual space contains a rich representation of the real process that virtually mimics the real process with very high fidelity (Ref. 2). In addition, lightweight models can be used for faster interactions when results are required on small time scales. These lightweight models may be constantly calibrated to the high-fidelity rich models.
In the case of the battery pack, the digital twin may be a multiphysics and multiscale system model of the battery pack that also contains historical data. The lightweight models may be lumped and equivalent circuit models of the battery pack. The historical data may consist of measurement data for the specific battery pack, including:
- Temperature
- State of charge
- Impedance spectroscopy
- Polarization (current versus voltage curves)
It may also contain data from other battery packs of the same model. A digital twin for a specific battery pack may be referred to as a digital twin instance of that battery pack model.
The digital twin is created by a range of different models that together mimic, with very high fidelity, the behavior of the battery pack.
Using the models, the measured and reported data can be used to produce a very accurate representation of the conditions inside the battery pack and to extract parameters in the model. The models can then be used to make predictions about the operation of the battery pack and to compute control parameters that can be used in the battery pack control.
The information process implies sending back control parameters that adapt the operation of the battery pack to the status of the battery, the driving profile of the driver, and the current operational and driving conditions. It can also send reports back to the battery pack and to the driver about projected future operation and behavior of the battery pack. For example, it may send parameters that temporarily limit the maximum current during recharge (during braking) if the temperature shows a risk for overheating or at a certain state of charge of the battery cells. It may also detect a battery cell in the pack that is not performing properly and disconnect it from the circuit.
Machine Learning, Cloud Computing, and IoT
The sophisticated models incorporated in the virtual space may require powerful computers in order to produce the results quickly enough to be useful in real time. This implies that a major part of the behavior of the digital twin may be created by processes running remotely using a powerful server (for example, using cloud computing), while some processes may be running locally in the control unit installed in the car.
For example, the lightweight models mentioned above may be used directly in the control unit in a battery pack. In order to keep these lightweight models accurate, the control parameters can be updated in real time by comparing them with the predictions and results from the richer models that are computed on a larger time scale. The richer models may produce detailed physical descriptions of the temperature profiles, state of charge, and other electrochemical and physical parameters of the battery. The digital twin may therefore be produced in a system where different components are deployed on different platforms and locations.
Multiple components and models deployed in different locations may contribute to the creation of the digital twin.
A digital twin and its real counterpart are usually not isolated systems. In most cases, they are part of a larger system that may also involve other devices and their digital twins. In addition, a real device may have several digital twins, referred to as a digital twin aggregate, in order to optimize, control, and predict different aspects of a device.
For example, if some parts of the battery pack are susceptible to fatigue, then we may want to produce a digital twin for the structural behavior of the battery pack. Since this probably only influences the operation of the battery pack on a larger time scale, such a digital twin may be more loosely coupled to the digital twin that simulates the electrical behavior of the battery pack. The digital twin for the battery pack may also interchange information with the digital twin for the generator, electric motor, and the combustion engine for the hybrid car.
A real system may interact with many digital twins that may also interact with each other.
The different parts in the larger systems and their digital twins may need to communicate with each other. In addition, a digital twin may need to get data from sensors and devices installed at different physical locations. The internet of things (IoT) and its technology can be utilized for the communication between sensors, devices, and the computer systems that produce the digital twin.
Machine learning (also sometimes referred to as artificial intelligence or AI) algorithms may be used to train the digital twin in order to decide when different devices or other digital twins should be queried for data, when different control parameters should be updated, and when reports to the digital twin and the real system should be updated. So, the terms digital twin, cloud computing, IoT, and AI are important concepts for efficient development, design, manufacturing, and operation of expensive battery systems, such as the systems installed in electric vehicles.
How Can COMSOL Multiphysics® Models Be Incorporated in Digital Twins?
Engineers and scientists can use the COMSOL Multiphysics® software to create extremely accurate multiphysics and multiscale models. In addition, the software has the ability to easily combine lightweight models and to use methods that continuously update the lightweight models according to the high-fidelity behavior predicted by the richer models. Models can be continuously validated using state-of-the-art methods for parameter estimation and optimization. Such models are critical components in digital twins.
In order to use COMSOL Multiphysics models to create digital twins, we have to allow these models to continuously receive measurement data and reports from an external system and then deliver the predictions and control parameters back to that system. The simplest way to do this is by using COMSOL API for use with Java®.
For example, a COMSOL Multiphysics model file may contain several model components representing different aspects of the digital twin. In the battery pack example, the different model components may be the three-dimensional high-fidelity model component, the detailed electrochemical model component at the microscopic scale, and the lumped model components for quick interactions. When the model is saved as a Java® model file, all of these components can be accessed from a Java® program. 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, you can also implement the virtual space as a web service (a Java®-based web service running inside Tomcat, for example) that could present, for example, a representation state transfer (REST) API for communicating with the real space.
Another alternative for the connection between the real space and the virtual space can be obtained with applications in COMSOL Server™ and with compiled applications created with COMSOL Compiler™. The limitation here is that the simulation running in COMSOL Server™ or in a compiled application cannot be updated during execution. However, it is possible to start or restart an execution in order to update the real physical device as well as the digital twin according to a change triggered by an event; for example, a change in a file, a command triggered by a sensor, or an event triggered by an operator. The data and the control parameters between the real space and the virtual space can be sent back and forth as results of commands triggered by these events.
Concluding Remarks
The concept of digital twins is just beginning to become viable and attractive outside of military and space applications. One of the problems that has been brought up by analysts is the lack of models and the lack of knowledge in modeling and simulations required to produce high-fidelity predictions (Ref. 3).
Many digital twins rely only on statistical treatment of incoming data and table look-up on historical data in order to create the digital twin. The drawback is that this generates little knowledge and understanding of what really happens in a device or a process. It also requires a very large amount of reliable data for a large number of devices or processes of that specific make. This may be an optional approach for less expensive products that are produced in large series.
In contrast, once validated, a multiphysics model can be accurate over a wide range of operation with a minimum of data. For these reasons, the digital twins that include some kind of model-based description are desirable. For expensive products such as battery packs, reliable multiphysics models are especially desired.
Partial differential equations (PDEs) are the most accurate way to present the laws of physics (Ref. 4). COMSOL Multiphysics gives us the ability to create digital twins based on the most accurate descriptions, using multiphysics models based on PDEs.
References
- M. Grieves, “Digital Twin: Manufacturing Excellence through Virtual Factory Replication,” Michael W. Grieves, LLC, 2014.
- 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.
- J. Voskuil, “Model-Based — The Digital Twin,” Jos Voskuil’s Weblog, 2 July 2018; https://virtualdutchman.com/2018/07/02/model-based-the-digital-twin/.
- R. Feynman, Differential Calculus of Vector Fields, The Feynman Lectures on Physics, 1963–1965.
Oracle and Java are registered trademarks of Oracle and/or its affiliates.
Comments (0)