The term Digital Twin has become fairly common, though there is still a lot of confusion about its meaning. In fact, there isn’t a single definition of Digital Twin, and the definition has changed over time. This leads to confusion of course. The best way to reduce the confusion is to understand that people are developing digital twins for different purposes. Each purpose is valid and valuable in and of itself.
What I am describing in this blog, the first in a three-part series, is the origins of the term Digital Twin. In the second blog, I will describe the evolution of Digital Twins so you can better understand what capabilities are required in a Digital Twin to fit your needs. In the third blog, I will focus on the use of a Digital Supply Chain Twin for supply chain planning.
The Origins of the term Digital Twin
The term was originally used in the equipment design space, usually for very large military construction projects. You can imagine how many documents are required to capture the design of an aircraft carrier. Obviously, the maintenance of these documents, in paper form, was a colossal effort, leading to errors, which in turn lead to huge costs and periods of inoperability of the assets.
The Mysterious History of Digital Twin Technology and Who Created It (challenge.org)
From the diagram above you can see that in fact, the twinning concept predates the term digital. The physical twin is still used very extensively in the design space. An example is the crash tests for cars. I feel much more secure buying a new car knowing that a physical crash test was performed. I would feel far less secure if the crash test were entirely digital.
This is also a good transition to the value of digital twins. It wasn’t until 1934 that car manufacturers even started performing the crash test, and these were performed to improve the sturdiness of cars. They had very little to do with driver safety. A car would be rolled down a hill into a concrete obstruction, and then inspected manually. Of course, this took a lot of time and very little could be determined about how the car behaved during the crash.
Today there is a huge amount of telemetry that captures how the car performs during the crash, and, more importantly, the stresses on human dummies placed in the cars. I want to point out that these tests are still physical.
From Design Capture to Performance Capture
We see many examples in our lives of the difference between intent and reality. This is of course also true for manufacturing and supply chain design.
This shift from capturing the design in digital format to capturing performance is very important in the shift of the use of Digital Twins. Even the original physical inspections of the car crashes were a step in this direction, but the digital capture of the dynamic performance characteristics was a huge leap forward because this telemetry could be analyzed in detail after the fact.
From As-Designed to As-Built
The crash tests are still part of the design process. Once the cars are produced in volume, each car gets a unique VIN, essentially the car’s fingerprint, which captures not only the materials used but can also be used to trace back to the batch and supplier of those materials, as well as which factory, which production line, which shift was used to produce the car.
This is extremely useful information to analyze systemic problems in the supply chain of quality, cost, and time. A large earth-moving equipment manufacturer noticed an increase in warrantee claims and could trace nearly all the claims back to equipment manufactured during the night shift. Seniority rules at the plant meant that most of the workers on the night shift were recent recruits.
Now that we have established the origins and initial expansion of the term ‘Digital Twin’, we will explore how the digital twin capabilities have expanded into the analysis.