There is much talk of using analytics as the foundation of the digital twin strategy. This approach is doomed to fail, but why? It comes down to one thing: lack of context. Advanced technologies to improve use cases for complex products need the unique history and configuration of what is being analyzed. Without it, your analysis can turn into paralysis and lead to incorrect decisions that cost time and money.
What adds to the complexity of digital twin strategies is that a digital twin of a physical product needs to portray an exact representation while providing flexibility in how people use that representation to support many use cases across the product lifecycle. At first these two characteristics may seem like oil and water to each other, but in reality, it’s possible to achieve, so let’s explore how.
What is a digital twin?
You’ve probably noticed that every vendor and analyst need to provide their own definition of the digital twin. Yes, we must do it to, but we are doing it to clarify an important, overlooked point to digital twins. If you buy into the fact that a digital twin is an exact representation to what is in the field, then you cannot let another vendor tell you it’s ok to “model” a view of a digital twin—it’s not an exact representation. And this creates the failure in proof-of-concepts when you try to scale. It’s very difficult to keep an exact representation of a complex product accurate over a long period of time – especially when you have hundreds or thousands in operation, or if they are part of a system of assets like a refinery or power station.
But we must try, right? We must work towards this goal to change our approach to future product development, quality, and maintenance to evolve from how we have been approaching these use cases and processes over the last 40 years. So, to get on track, we need to think of each product as unique.
It must be individualized, like an NFT
NFT stands for non-fungible token and most of them are part of the Ethereum blockchain. You can think of them as one-of-a-kind trading cards for digital assets, like art or music. What all NFTs have in common is the fact they are unique and cannot be replaced by something else. Every digital twin you deploy for a complex product should be thought of the same way. Every product comes out of the factory with subtle differences and these differences grow as it is operated and maintained in the field. And it is because of this uniqueness you need to capture and track its changes over time so you have a current view of the product itself to do the appropriate analysis for accurate decision-making. How do you capture and keep it current? We have an offering, called Digital Twin Core, with plenty of demos and content to review at your leisure.
Flexibility for any use case
We have seen a variety of approaches used to create and deploy a digital twin configuration to support different use cases across the lifecycle. Your approach is going to be determined by the number of products you are maintaining, and the fidelity of the configuration you require. Some companies with few assets and limited maintenance frequency are more than happy to periodically record the current state of their products’ configurations once monthly, quarterly, or yearly.
Others in more complex industries need constant upkeep of their digital twin configurations. For example, in Oil & Gas or Power Generation, changes are frequent, products are many, and there are relationships between products—creating systems of systems. These companies need their configurations to be more automated to keep up with the pace of change.
Others may provide maintenance with their products, such as Renewables or Robotics. They want to keep a product’s configuration up-to-date in order to support service level agreements—keeping their customers happy. This coupled with the related information “coming off” their products, will provide insights so they can have in-depth business opportunity discussions with their customers for upgrades and future product developments.
But what if you have millions of products like the automotive industry? In that case, it may make more sense to assemble digital twin configurations when they are required—for example, to simulate what happens if I send an over-the-air (OTA) software update to certain configurations of the product.
Example digital twin configurations by use case:
What's your use case?
If you are ready to create individual digital twin configurations flexible enough to support many uses cases, it’s important to know you have options depending on who you are and where you sit within the product lifecycle.
Manufacturers need to capture the “as-built” configuration of every product that is built by capturing all serialized electrical, mechanical, and software components. The digital twin can be further enhanced using the digital thread, to link back this configuration to information such as CAD models, simulations, requirements, change orders, and on and on. By doing this, you create an opportunity to share this information with your customers so they can leverage the configuration and associated information tied to it out in the field, where the product operates. This also allows the customer to continue to build a digital twin’s history by linking to its operations and maintenance history.
Owners and operators can build digital twin configurations for any product or system of products they have and keep them up-to-date as they change through maintenance activities. This will require a sustainable process for capturing change as it operates over time. This means utilizing your maintenance management system, and other pertinent systems, to capture the history of the product in your digital thread.
Whatever path you are on, your digital twin configuration should be created so that it is flexible to adapt to changing business requirements by different users. You will soon see this become the go-to user interface to explore and analyze each product’s story from inception to disposal.
For more information, read our Digital Twin eBook.