by Ryan Gelotte
The term “Digital Twin” is applied so frequently these days that there’s a lot of ambiguity around what it truly means.
Commonly, the definition of a digital twin is a virtual representation of anything physical, and it can be literally anything – for instance, software is a digital twin of itself.
The recently-formed offers this definition of “digital twin”:
A digital twin is a virtual representation of real-world entities and processes, synchronized at a specified frequency and fidelity.
• Digital twin systems transform business by accelerating holistic understanding, optimal decision-making, and effective action.Source: Digital Twin Consortium Defines Digital Twin
• Digital twins use real-time and historical data to represent the past and present and simulate predicted futures.
• Digital twins are motivated by outcomes, tailored to use cases, powered by integration, built on data, guided by domain knowledge, and implemented in IT/OT systems.
This definition is well-worded and yet still quite broad. It appropriately quantifies the digital twin’s accuracy to a physical part with the phrase “synchronized at a specified frequency and fidelity” to qualify and quantify each digital twin.
Broad language is great for ensuring you don’t limit the possibilities for the future. It sometimes makes sense to avoid specificity with broad and public definitions. However, when it comes down to the brass tacks of implementation at the scale of digital twins, specificity is a must.
In our neck of the woods, working with digital twins within the manufacturing domain, we struggle to find actionable steps with a broad definition of digital twin.
Looking at one viewpoint, realization of a design, the uncertainty of ambiguous digital twin language inhibits adoption of Model-Based Definition (MBD) and Model-Based Enterprise (MBE) efforts.
If you surveyed hundreds of people across different roles and stages in the lifecycle, from simulation engineers (CAE/FEA) to quality technicians, you would receive hundreds of different answers to a single question: “What is a digital twin?” The ambiguity is so pervasive that people make up their own definitions of what a digital twin is. A great party-game, but not good for creating strong communication plans rooted in robust strategies to pragmatically scale MBD adoption.
Our favorite digital twin is the metrology twin that is created by gathering points using CMM or any of the various metrology applications. The digital point cloud data is the only digital 3D shape data that is derived directly from the physical part. Every other “digital twin” is really just a digital poser, or at least some idealized digital representation of the actual part. Many of the buzz-word narratives dilute the value of the digital twin, because the fuzzy definitions are not actionable.
Bedir Tekinerdogan and Cor Verdouw wrote an excellent paper, Systems Architecture Design Pattern Catalog for Developing Digital Twins, that clarifies this point well. They note that “A digital twin is a digital replica of a physical entity to which it is remotely connected. A digital twin can provide a rich representation of the corresponding physical entity and enables sophisticated control for various purposes.”
Ideally, only the inspection point data and any surface/solid model that is derived from the point data would be considered the digital twin, because twin implies two in common usage when considering Merriam-Webster’s definition.
Since metrology point cloud data is derived from a physical part, it fits the most commonly used definition of “twin”. Everything else – MBD CAD model, FEA mesh, lightweight viewables, etc. – is nothing more than “digital representations” of a physical part. They do not fit the definition of a digital “twin”. If everyone believes their digital representation is a digital twin, then in reality none of them are a digital twin. The value of “digital twinning” is realized when comparing the digital twin (derived from the physical world) to the digital representations where the delta between the two can be quantified.
Those of us in the engineering and CAD communities don’t get too confused because this is the space we live and work in daily. But when this language starts propagating out to the rest of the enterprise, and the language is continuously evolving, it feeds the confusion.
The good news is – we are all talking about using digital data! We love digital data and the potential to automate many of the manual processes that occur today between design, fabrication, and inspection. And even though there is no formal definition of “digital twin” as something that is derived from the physical part, there are many companies implementing this type of “digital twinning” process. If we could agree on a standard definition of “digital twin” for 3D shape data, then we should also be able to agree on the definition for other domains, such as materials and electrical properties.
Ryan Gelotte is the Chief Technology Officer of Action Engineering. He is certified as an ASME Geometric Dimensioning and Tolerancing Professional (GDTP) at the 2009 Senior Level. He holds degrees in Plastics Engineering Technology and Mechanical Engineering Technology from Penn State Erie, The Behrend College. His career over the years has included a focus on all aspects of plastic part design and manufacturing, including mold design, as well as expertise of PTC’s various CAD and PLM systems. In fact, Ryan started his career as an Applications Engineer for PTC from 1998-1999 and, over the years, has provided training, support, and consulting services with PTC’s products for several companies. His experience in engineering systems, product design, and manufacturing have been instrumental in preparing him for the many challenges that come with implementing a Model-Based Enterprise. He enjoys the many challenges inherent to the engineering discipline and thrives off of finding new and better ways to accomplish superior results both in engineering and manufacturing operations by defining Model-Based processes.