When I started my professional career 17 years back, my first assignment was to create a digital model of an SUV to simulate its ride and handling characteristics. I still remember my excitement when the simulation results matched within certain limits with the experimental measurements. I was able to run a virtual car on a virtual road and predict its behavior 4 years before it was manufactured!! My colleagues were working on similar projects to virtually simulate how the SUV that we were designing would behave under different operating conditions in various domains like structural durability, noise and vibrations, thermal, aerodynamics, and the manufacturing plants where it would be assembled. Today, as the term ‘Digital Twin’ is in limelight, many of my colleagues ask-
Were we not creating Digital Twins during the new product development for last 20 years under the discipline of CAD/CAM/CAE and virtual validation? How is today’s Digital Twin different from the digital prototypes that we worked on all these years?
In a way these are valid questions. The industry has been creating independent Digital Twins catering to very specific purposes during NPD process. The way Digital Twin is referred today has got a broader, and all-encompassing scope.
To understand the difference, let’s see what are the core requirements a modern Digital Twin. We can define a Digital Twin as a virtual representation of a physical asset which is-
- Valid across the entire life cycle- from product design, manufacturing, operations, repair/maintenance, and retire/replace.
- Interacts autonomously with various other assets and agents within a complex system which it is part of.
- Can be queried by a user about its status in various dimensions including engineering performance (potential failures, maintenance needs, operating parameters), financial factors, potential risks etc.
- Possesses ability to answer the queries and predict its future states using pre-built mathematical models, advanced statistical models (potentially including AI/ML algorithms) which are executed using real-time data coming from the sensors installed on the asset and its surroundings system components.
As you would appreciate, the main difference is that instead of having a digital model for a class of an asset- for example a new aircraft engine that is being designed, we can now have a separate digital model for all engines that are mounted on the aircrafts and are flying which can be simulated using operational data. This is possible because of the advancement in the sensor technology, drastic reduction in the cost of sensors, and an ability to have intelligence at the edge.
A Digital Twin working on real-time operational data would be much more accurate in predicting the performance when compared to the virtual model which uses parametric data. It is important to examine if the improved accuracy will make a valid business case to add all the complexities and cost to the overall system.
Lets assume that the business case is making sense. Are we then ready to create a Digital Twin of our asset? Probably not as straight forward as you may think. Let’s see what some of the challenges are.
Digital Twins in Silos
Throughout the asset life-cycle the industries have already started using virtual models to simulate what-if scenarios. So, the pieces of Digital Twins are already existing in the enterprise. The question is how to connect all these models to create a holistic Digital Twin. It is not just a matter of collaboration within an organization. There are multiple players (vendors and partners) who jointly create a complex system like an aero-engine or an automobile. How to resolve the issues related to intellectual property between the vendors and the OEMs while asking them to share their models to a common enterprise?
Lack of Ontology
As I mentioned at the start, one of the key requirements from a Digital Twin is to autonomously interact with its surrounding elements within the system of systems (Super-system). To be able to achieve this, we need to have a well defined and universally accepted ontology for all participating domains. Presently, there are communication protocols and standards for individual domains like 3D modelling, Simulation, IoT etc, there is no overarching standard to pass information across the domains. Creating an ad-hoc communication channel is still a possibility, but its not scalable at all.
Data ownership
The main differentiator of the Digital Twin is the accuracy gained by the use of operational data coming from the sensors installed on the assets. Once the asset is sold by an OEM to the buyer, the question of data ownership is not clearly answered in all industries. In cases where the data is not owned by the operating organization, the commercial models to share data across needs to be developed.
Where would a Digital Twin Implementation make sense?
Considering the balance of cost & complexity of implementation and potential benefits, I believe that the Digital Twin will add maximum value in large complex projects or very high value assets. Some of the candidates are-
High value assets like- Ships, Satellites, Aircrafts, Submarines, Power-plants, Railways
Large construction projects for Airports, Seaports, Mines, and Smart cities
Asset and network heavy businesses like Energy distribution, Water distribution, Rail and Road networks
For smaller, less complex products and sub-systems the full scale Digital Twin may not be compelling enough, but if these products are part of a larger complex system, there is a potential of creating a new revenue stream by supplying their components of Digital twin to the main orchestrator.
I see a full scale Digital Twin as a bit futuristic, the pieces of Digital Twin have already started getting developed and adding incremental value to the business. The next step towards realization of a holistic Digital Twin is to create a Digital Thread to tie all these pieces together, and an Ontology Schema to enable them to autonomously interact with each other.
