Digital Twin and Digital Thread: Do not confuse!

The terms "digital twin" and "digital thread", which have become more common recently, both have a lot to do with systems engineering. But be careful, they are not the same thing! What the differences are and what we can do with the digital twin, or the digital thread, is the subject of the following.
I've been wanting to write an article about the "Digital Twin" for some time. The topic also came up recently at the Automotive Day where Andreas Willert pointed out that these two terms should not be confused.
Both Digital Twin and Digital Thread help to evaluate procedures, processes and product concepts in a virtual environment. The digital twin is the current representation of a product or system. The digital thread, on the other hand, is the record of all the details of a product or system over time, from its creation to its disposal. Both are useful.
The digital thread is not new
The digital thread enables traceability over the entire life cycle of a product. This has been practiced in safety-critical industries for decades. In aviation and railroad technology in particular, this is mandatory and is an important driver of Product Lifecycle Management (PLM).
For example, if a vehicle has an accident due to a system error, such as faulty acceleration, the Digital Thread can identify the problem through traceability over the entire life cycle of a vehicle.
Traditionally, PLM has had a strong focus on parts and components. The Digital Thread is now about making traceability more granular, i.e. moving away from the "document mindset". In addition, software (and its revisions) must now also be tracked.
The Digital Twin opens up new possibilities
The digital twin, on the other hand, is a model that represents the actual state of a system. The aim of the digital twin is to carry out activities on the model before they are carried out on the actual system. The range of possible activities depends heavily on the model. In the case of a vehicle, this could be moving the engine block to determine whether there is enough space for another unit. In the case of a combustion engine, it could be simulating how well it tolerates a new fuel. In the first case, a simple CAD model the basis, in the second case perhaps an elaborate Simulink model.
Working with models is nothing new. The idea behind the digital twin is about holism; the CAD model and Simulink model belong to an overall model, the digital twin.
Selective modeling is not new. Holistic modelling, on the other hand, is, as far as I know, only implemented in a few organizations, for example in aviation.
Combining Digital Twin and Digital Thread
There are of course overlaps between the two concepts. This makes it all the easier to combine the concepts in order to support even more powerful use cases. One important aspect is the reduction of redundancies: In particular MBSE an important approach that simplifies traceability, i.e. supports the digital twin.
But with MBSE-based approaches, we already have a model. And depending on the level of detail or formalism, it may be possible to interact with the (partial) model: We may already have the part of a digital twin.
Hype and reality
But we should come back down to earth: It is a long way from simulating one aspect of the system to a real Digital Twin. As far as the digital thread is concerned, we still have many gaps, often caused by tool breakages.
Digital Thread and Digital Twiin are ideas that should not be confused, but which we can definitely pursue together. However, this is a big vision that only a few teams have realized so far and can only be achieved with a strategic focus and staying power.






