A Beginner’s Guide to Digital Twin – an illustrative approach

Concept

 Digital Twin is a virtual model of a physical asset that mimics the behavior and operation of its physical counterpart. Usually, the model resides in the cloud and hence can be monitored and controlled from anywhere remotely.

Specifically, sensors on the physical asset are used to capture the operational and environmental data on a continuous basis, and this dynamic data is streamed to cloud where it is enhanced with static data, such as engineering specification data of the physical asset stored in other systems. The combined data is then used as input to a statistical or an engineering model in the cloud, and analyzed in real time to generate insights that are fed back to the physical asset to control its ongoing operation, completing the feedback loop as shown below.

Digital Twin is the core of product and system life-cycle in that it can be used starting with product design and development to monitoring to operations to maintenance and not just be limited to product design aspect as discussed in the literature. Multiple facets of the Digital Twin are shown in the diagram below. We will elaborate on each one of these aspects in the rest of the article with respect to a specific physical asset, namely an Excavator.

Wipro’s Digital Twin platform bridges the gap between design and operations as shown below. The product-specific data traditionally resides in the PDM/PLM systems while operational data is streamed to and analyzed in the so-called IoT platform, and usually, these two systems are distinct and not connected. To realize the full potential of Digital Twin, it is imperative that these two systems are integrated. There are several ways of doing this integration and most often than not, the integration is done in an unstructured manner. However, Wipro’s Digital Twin Platform uses a sophisticated asset modeling framework that glues together two apparently distinct systems in a seamless manner. The output of the Digital Twin platform is fed back to the Plant / Operation system completing the feedback loop as shown below.

Digital Twin mimics the behavior of a physical asset

Let me explain the concept in little detail with a specific example. The diagram below shows a backhoe excavator (on the left hand side of the diagram) digging in the field somewhere in the world and while it’s digging, its engine is running and the engine parameters have certain values, the battery has certain voltage and the fuel level also keeps changing as the engine is being used in a continuous manner. Thus the backhoe excavator has a certain state characterized by specific values of various operational parameters at different instants of time. A sampling of the operational parameter values in a given instant of time is shown in the middle of the diagram while a time series of external battery voltage is shown on the bottom right of the diagram. As these values are stored against the respective variables of the Digital Twin model as time series data, the state of the Logical Backhoe Excavator (the Digital Twin), at any point of time, is exactly the same as that of the Physical Backhoe Excavator. Literally a twin! 

One can potentially visualize the Digital Twin annotated by the various parameter values, changing in time exactly as they change for the backhoe excavator in the field, and at any instant of time, have a replica of the physical asset in digital form. As a result, one can diagnose a problem of the physical asset in the field (say in India) by analyzing the Digital Twin in the cloud from anywhere in the world as shown in the diagram below. An extremely powerful concept. This is powerful because the expert who can diagnose problems with the excavator could be based in UK or in Japan while the physical asset experiencing problem could be in India. There is no need to fly down the expert to India to diagnose the problem with the excavator – a huge cost saving for the company that deploys the excavators.

Modeling an Excavator

Various parts of an excavator are shown on the diagram below. 

The corresponding virtual model is shown below.

Against each one of the parameters (such as, Fuel Pump or Battery) shown in the diagram above, one can maintain the corresponding time series data from the field, thereby reflecting the exact state of the physical asset at any instant of time. Thus, the abstract model captures the static as well as the dynamic data (time series data) of the backhoe excavator plus the actual location (GPS coordinates). Time series data (both current as well as historical) can be used for developing statistical models to predict failure leading to predictive maintenance, while location data can be used to enforce geo-fencing leading to tracking and tracing of stolen vehicles, for example.

Digital Twin in Product Design

When R&D engineers design a specific model of backhoe excavator, they use several reference performance curves to do sizing of the various parameters like max Engine-capacity, max RPM, max Bucket-depth etc. For the sake of simplicity, we show two different reference curves: (1) Productivity vs. RPM and (2) Fuel Efficiency vs. RPM in the diagram below.

Both of these diagrams have “ideal” curves or the reference curves used for the design. However, when hundreds of excavators are in the field, and their performance data (productivity and fuel consumption in the example) are constantly collected in real time, their performance do not exactly match the performance predicted by the “ideal” curve. In fact, there are deviations because the “ideal” curve makes various assumptions about the environmental conditions that may not hold true in practice and variations in the environmental parameters lead to difference in the performance of the machines in the field vis-à-vis the performance of the “ideal” machine. These deviations are shown in the diagram above as Machine-1 and Machine-2 curves in both the Productivity vs. RPM graph and in Fuel Efficiency vs. RPM graph. For example, productivity of Machines 1 & 2 are worse than that of the ideal machine and the fuel efficiency of Machines 1 & 2 are higher than that of the ideal machine. Now the R&D engineers can analyze the field data (of the Digital Twin) to see if these deviations are random noise or there is an underlying pattern based on the environmental parameters like say Ambient Temperature and/or Humidity. If it’s the latter, the R&D engineers would modify the “ideal” curves Productivity = f (RPM) and Fuel Efficiency = g (RPM) to Productivity = f (RPM) - h (Temp, Humidity) and Fuel Efficiency = g (RPM) + k (Temp, Humidity) respectively for the next round of design. Furthermore, R&D engineers can simulate the behavior of the Digital Twin with various Temperature and Humidity values and see if the modified equations represent their behavior more accurately or not. If they do, the R&D engineers use the modified equations for the next round of design. If not, they keep tweaking the ideal equations with various factors until the modified equations truly reflect their field behavior. Please note that the focus of this example is not on the accuracy of the equations rather on the illustration of the concept of how the design of a Physical Asset gets improved by the field data captured in the Digital Twin.

In general, Digital Twin is used to understand the performance of a new variant of an excavator before committing to expensive changes in manufacturing process. The process is illustrated below. Here n variants of the Excavator are fed into the Digital Twin template and simulated with field data one by one until the best alternative is found. In this example, the best alternative is the model with Max Torque of 1300 RPM and Power of 79hp as shown on the right bottom corner of the diagram.

All the above examples show various facets of using Digital Twin by R&D engineers to design the next version of the asset based on the actual operational data generated by the current generation of physical assets in the field. Note that in a traditional design, unlike in Digital Twin-based design, simulations are done using synthetic data as opposed to using real-time field data and hence the design done using Digital Twin is far more accurate and reflective of real-world deployment situation.

Digital Twin in Remote Product Monitoring

 Consider two scenarios side by side. The first without digital twin. A remote operator sees a table and tries to imagine what is going on in the field as shown below. In this case, we have shown only a few of the parameters being monitored. In real life, there could be several hundred parameters monitored and staring at the black screen is rarely helpful for an operator to figure out the problem.

Now consider a situation with Digital Twin. The operator can visually experience the operation of the excavator and immediately figure out if and where is a problem.

When the Digital Twin for the excavator deployed in India is magnified, the details can be visualized as follows, immediately telling the remote operator what is wrong and where – Engine Temperature and Fuel Level are Red and should be acted upon immediately. In fact, in this example, the Engine Temperature is too high and the Fuel Level is too low. Some of the other parameters like External Battery Voltage and Fuel Filter are Green and hence do not require any attention. In addition, there are parameters like Engine Running Band2 and Internal Battery Charge that are Amber and may need attention.

An expert, sitting in say New York can instruct the operator of the excavator in India to cool down the Engine by giving it rest and by checking if the coolant level is low. If the latter is true, the operator will be instructed to add more coolant and bring the level up to the desired mark. The operator of the excavator might also be instructed to add more fuel to the tank. Please note that, in real life, the instructions from the remote expert to the operator in the field could be far more complex and non-obvious. The examples here are simple to drive the point home in an intuitive manner.

 Digital Twin in Remote Control

A physical asset in the field can be controlled remotely after testing the control functions on the digital twin. There are two ways of doing remote control: (1) Configuration Over The Air (COTA) and (2) Firmware Over The Air (FOTA). The former applies to changing the configuration parameters of a physical asset by sending the new configuration values over the air. For example, an excavator in the field may be allowed to operate only over a specified region based on business contract. If the excavator goes outside the specified region, alerts may be generated for the relevant stakeholders. This is called “Geo fencing”. The specification of the region for the excavator is a “configuration” parameter. Similarly, an excavator may be configured to operate only during certain hours of operation and if it works outside of the specified hours of operation, alerts may be generated. This is known as “Time fencing” and in this case the “configuration” parameter is the “time duration”.

Let me illustrate with an example how Geo fencing can be simulated on the digital twin before sending the corresponding configuration parameter values over the air to the physical asset to ensure Geo fencing in real life.

The diagram below shows how Geo fencing can be specified for the digital twin in the cloud and how it can be tested. In the diagram, the geo fencing area is specified by the dotted closed curve around the location of the digital twin on the map. During the test, the digital twin is moved outside the specified area to check if alerts are generated.

Note that in the following diagram, when the digital twin goes outside the specified region, alerts are generated, ensuring that Geo fencing logic is working correctly.

Once the simulation works on the digital twin as expected, the Geo fence configuration is pushed to the physical asset over the air as shown below.

Just as Configuration parameters can be tested first on the digital twin before doing COTA, firmware upgrade can be simulated and verified on the digital twin model before doing FOTA. In case of FOTA simulation, one can simulate distribution of a firmware with a specified version number and verify that the version number of firmware associated with the digital twin gets updated to the later version associated with the new firmware. Once this step is executed, FOTA can be performed on the excavator in the field.

Digital Twin in Remote Product Operation

While Remote Monitoring of an Asset is aimed at preventing breakdown or damage in the field, Remote Operation is more complex. Remote Operation is aimed at utilizing an asset in an optimal manner in order to prolong the life of the asset and also to use it in the most efficient manner. Thus, remote operation is a continuous process of tracking various parameters of the asset and comparing their values against the optimal operating values (think of doing a multi-dimensional plot of the parameters and comparing the current operating point of the physical asset with the multi-dimensional ideal operating point). If there is a deviation beyond a threshold, the operator of the physical asset in the field is instructed to take appropriate action in order to bring the operating point closer to the ideal operating point. The goal is not only to avoid outage but also to automate service assurance by automatically identifying performance issues and giving insight needed to manage problems proactively.

Let me explain the concept using an illustrative example in the context of an excavator. When an operator in the field is using an excavator, most of the times, he would not know if the excavator is operating at the optimal productivity level. This is because he is mostly interested in doing the job without the machine breaking down and is not aware of the engineering design and operating specs that are typically known to the experts. Productivity of an excavator would depend on various parameters including weather, terrain conditions etc. As the operating data from the excavator are continuously fed into the Digital Twin, the engineering model is run to compute productivity. When the Productivity of the excavator in the field goes down, the operator of the excavator in the field is prompted to improve productivity.  Alternative recommendations are flashed to the operator on the dashboard so that he can make the final choice. In the example below, two different combinations of RPM and Bucket Cut Depth (BCD) [Option-1: RPM = 1600, BCD = 100, and Option-2: RPM = 1700, BCD = 50] are provided to the operator corresponding to productivity levels P = 29.00 and 30.77 respectively. Based on the various environmental and ambient conditions, and leveraging his experience from operating an excavator for many years, the operator might choose the first option even though productivity is slightly lower. This is an example of computing multiple alternative “intelligent” decisions by the system but putting the human operator in control of making the final choice.

Digital Twin in Product Maintenance

Product maintenance can be Reactive or Proactive. Reactive product maintenance is also called breakdown maintenance meaning that the product needs to be repaired when it stops functioning. Naturally, this is an expensive proposition as the asset is down until it gets fixed and thereby there is a loss of productivity and then there is an expense involved in getting a field service agent to come and fix the problem. Proactive maintenance aims at fixing an asset before any problem occurs with the goal of eliminating unplanned downtime and avoidance of lengthy repair process.

Digital Twin facilitates both. When the physical asset is down, the digital twin is also down meaning that the breakdown state of the physical asset gets reflected in the digital twin’s dashboard in the cloud. At that time, a field agent can be informed to come fix the problem. However, the field agent is not just told to come and see what’s wrong but the field agent can be provided with a lot more information based on the most recent history of operation of the asset before the asset broke down. The entire history is available at the Digital Twin for analysis and diagnosis from a remote site and based on the diagnosis, the most appropriate field agent (based on his records of repair in the past) can be dispatched with the right equipment and right replacement parts if any. This makes the repair process far more efficient compared to the case when a field agent does a blind (uninformed) trip to the site of breakdown of the excavator and spends time figuring out what might have happened to the machine.

Digital twin facilitates Proactive maintenance as well. There are three different variations of Proactive maintenance: (1) Preventive, (2) Predictive and (3) Prescriptive. Preventive maintenance can be done on the physical asset by assigning a maintenance schedule to the digital twin based on the product specification of the asset and waiting until the maintenance time window expires showing the need for maintenance by a red mark on the dashboard.

While preventive maintenance avoids the cost associated with breakdown maintenance, it is still sub-optimal as one might end up doing the maintenance work well ahead of time. Predictive maintenance, on the other hand, calculates the optimal time window (ideally just before the asset is going to break down) and dispatches a technician to do the maintenance work proactively just in the nick of time. This is where digital twin plays a big role. In fact, the operations data collected from the physical asset over a long period of time is used to develop a statistical model for the digital twin. This statistical model gets executed in real time with the real-time data streaming from the physical asset creating a replica of the state of the physical asset at the digital twin. Therefore, when the digital twin indicates time for maintenance, it is most likely the time for maintenance of the physical asset as well. This is how digital twin facilitates predictive maintenance.

While predictive maintenance anticipates the time for maintenance, prescriptive maintenance says what can be done to the physical asset to prolong its life and hence prolong the predictive maintenance time window. Prescriptive maintenance can also be simulated on the digital twin model to verify its accuracy before practicing it on the physical asset.

Application of Virtual Reality (VR) based training on the Digital Twin

Before a field agent is sent to repair a physical asset, the problem can be shown to the field agent on the digital twin first. Then the field agent can be trained using virtual reality to fix the issue in a step-by-step manner. For example, if there is a problem with the fuel pump in the engine, an expert can show the field agent how to open the engine door, where to locate the fuel pump, how to remove the fuel pump and how to install the new fuel pump – all using virtual reality in a step-by-step manner on the digital twin’s 3D model. With this training, the field agent can fix the problem on the physical asset in a minimum amount of time, thereby dramatically reducing the cost of maintenance. This is likely to happen as the field agent is exactly prepped with the problem and the corresponding fix well ahead of time – thanks to virtual reality and digital twin.

From a Digital Twin of an Asset to a Digital Twin of a Collection of Assets

 Imagine a factory with many machines, each doing a different type of work. Just as we explained in the article above, digital twin can be created for every machine in the factory. Once digital twins are created, one needs to capture the interaction between the digital twins – what information is exchanged between a pair of digital twins and how the state of twins change on receiving specific messages. This actually creates a sophisticated model with rich visualization of a system of state machines with complex interactions between various digital twins. There are several advantages of this model, especially being able to simulate and predict problems resulting from complex series of interactions between the digital twins when say a physical asset corresponding a digital twin is expected to undergo any functional modification. Not only is it possible to predict the problem, but also it is possible to identifying the root cause well ahead of time with high probability. Hence preemptive actions can be taken in order to avoid problems from actually happening in practice. This article will be followed by an article on the topic of digital twin of a complex system.

Conclusion

Digital Twin is a virtual representation of a physical asset such that the state of the digital twin, at any point of time, exactly reflects the state of the physical asset in the field. Therefore, monitoring the behavior of the digital twin from a location thousands of miles away from the physical location of the asset, one can predict and visualize impending problems in the field and take preemptive actions. This has serious business consequences for the OEMs of the assets, the service providers as well as for the actual users of the assets. Just as there are maintenance implications, there are operational implications as well in that the operation of a physical asset can be optimized by remotely guiding the operator in the field with recommendations. In future with operator-less assets, the same ideas can be extended to operate the asset optimally in the field. R&D engineers also benefit from observing the behavior of the assets in the field under real-world situation through the digital twin and experimenting with alternative designs of the digital twin before deciding on the final design of future physical assets. Given the holistic applicability of digital twin paradigm across multiple facets of business functions and the simplicity of creating them in the cloud using the latest technologies, it is becoming mainstream in the Manufacturing world and beyond. Wipro, by virtue of its Digital Twin Platform, is able to bring two distinct worlds of PLM and IoT together and create a unique value proposition in a seamless manner.

Acknowledgments

My sincere thanks go to my colleagues Senthil Kumaresan, Gurdeep Singh, Prashanna Jha, Mohit Kalra and Prateek Chowdhry for their help in better conceptualizing some of the things mentioned in this article and making the article comprehensive.