What is 'digital twin health', and why is it becoming critical?
Read time: ~4 mins
Twins are Systems
The age of asset digital twins is upon us, and as such, many organisations are “full steam ahead” when it comes to implementing them and seeking to embed them into operations. However, as twins move beyond deployments and through the first cycles of sustaining capex and upgrades, the realities of maintaining twins, and the consequences of over specifying fidelity, are becoming apparent.
As always, it is best to think of an asset digital twin (“twin”) as a system; it contains many physical and virtual components, most of which are existing enterprise and OT systems and sensors, and of course, it mirrors the physical asset system. Like any system, the individual components (physical and virtual) are subject to degradation, change, upgrade, modification or replacement. Many of the virtual components aggregate data, of varying qualities, and the predictive tools such as ML are subject to drift. In short, the components of the system are changing. Is it any wonder that the twin itself will need to change and adapt over time?
Complexity and Rate of Change
The complexity of a system, and the rate at which it changes, have major implications for maintenance and sustainment. In the physical world, this is obvious and factored into specifications, and we seek to understand total lifecycle costs. In the virtual world, we seem to have not learned this lesson yet. Twins are seen as “cutting edge” and fidelity, the degree to which the virtual replicates the physical, has primacy over use cases and cost/benefit. This is classic capex “gold plating”, and we have all seen it many times in the physical world during our careers. Twins are no different. Maximising the bang and shininess of the new toy during project delivery and handover is good for justifying the budget approval. But what have we set ourselves up for over the long run?
Twins are seen as “cutting edge” and fidelity, the degree to which the virtual replicates the physical, has primacy over use cases and cost/benefit. This is classic capex “gold plating”
Twin Health
All systems are changed deliberately to improve operation or reduce cost. All systems are prone to degradation due to their operation. Systems, virtual and physical, begin changing from the moment they are created. The management of this change is the core of the asset lifecycle. The health of a system is a measure of its ability to continue to provide useful service; unhealthy systems provide lower service, are at greater risk of failure, or require greater intervention to return them to a healthy status.
We introduce the concept of twin health - the degree to which a twin can provide useful service. As with physical asset health, twin health degrades from 100 (perfect health) to 0 (completely unusable). Similarly to asset health, twin health can begin to degrade during the creation phase. The development of high-fidelity 3D models during the design phase provides 1 dimension of a twin - 3D model fidelity. However, many assets are not constructed in accordance with the model, and many models are not as-built to match the constructed asset. At handover then, if the twins spatial foundation is the engineering 3D model, it’s health may already be <100. Deviation has begun. In fact, at higher fidelity, greater deviations are likely to be present. At the fastener and fundamental geometry level, the twin may look substantially different to the asset which it purports to mirror. Wear happens. Replacement of components happens. New equipment is installed. Failures happen and are fixed, sometimes on the fly, and sometimes as part of planned work. All of these changes to the physical world create the potential for the physical system to deviate from the twin. If the twins fidelity was sufficiently high to include extensive details on the physical world, then we better have processes or systems in place to update all the places where that data is stored; or our twin is holding onto the past, and it’s health is degrading.
<100 and dropping
Health is <100 and dropping, but is that a problem? It depends on the use case, and it depends on when that use case is called for. If using the model as a backdrop, or spatial context, then no, it is almost certainly not a problem. But when health drops below a given use case requirement, then it becomes a problem. Use cases are the determining factor in allowable twin health. The degrading health may not be noticed while health > use case requirement, but that’s the same as saying that we’re surprised when we run a pump to failure… and then it breaks. We shouldn't be surprised, and we should have processes in place to return to service quickly, or better yet, prevent the failure in the first place.
Twin Health Management
To manage the health of our assets, and our twins, we need to allow for and include inspections, servicing and upgrades. Recall that the twin is a system, and many of the components have other duties, and the whole relies heavily on data. Data integrity is very important to twin health. Garbage in - garbage out. But perhaps more importantly, garbage in - old garbage replicated and stored many times - some fraction of garbage out.
Physical system complexity, rate of change, the fidelity of twin and use case requirements are the key factors in determining twin lifecycle costs. Proper selection of fidelity, based on use case requirements, which in turn are based on system complexity, helps to prevent twin gold plating. Proper planning of twin health management, based on the rate of change of the physical system, ensures that health stays above the use case requirements, and that return to service can be achieved quickly in the event of failure. Proper data integrity processes help to keep clean data flowing through our systems and reduce the need for data clean-up work.
Reach out and speak to our team if you’d like assistance with scoping, implementation or adoption and maintenance of your digital twins.