I recently had the good fortune to sit down with Dr. Michael Grieves and John Vickers, who shaped the current landscape of digital twins.
Grieves is executive director and chief scientist for the Digital Twin Institute. Vickers is a NASA principal technologist who has been rolling out and maintaining cutting-edge spacecraft and scientific systems for the last thirty years.
People have been building physical models of things for millennia and virtual reality simulations for decades. Dr. Grieves's insight lay in formalizing a process of connecting digital representations of things across different aspects of the engineering, manufacture, maintenance, and disposal of things across their lifecycle. This came to be known as agile product lifecycle management.
The core insight was to bring the same kind of agile development productivity pioneered in digital industries to companies that made physical things like cars and airplanes. Vickers suggested the term digital twins while Grieves was working with him at NASA on a project. The term replaced some ungainly monickers used by both Grieves and NASA, which we will get to in a moment.
Suffice it to say that digital twins have caught fire across the product development community and in other areas.
What is a digital twin?
A digital twin is a virtual replica of a product, factory, building or supply chain that may be connected to its physical twin. It is not necessarily a separate app but an architecture for bringing together data across different IT systems, IoT sensors, and other sources. The industry has settled on the term digital thread for describing the APIs, integrations, and data transformations required to aggregate data from and to various systems. Grieves previously wrote:
I’m not a fan of that term, because I have hung on by a thread too often in my career. The term ‘thread’ doesn’t give me a lot of comfort. I’d rather have digital cable or digital pipe. However, we are stuck with the ‘Digital Thread’ terminology.
In the product world, digital twins are used as prototypes for testing design ideas before they are built. Grieves finds it helpful to think of these as digital twin prototypes, which complement digital twin instances of a specific product, and digital twin aggregates that help understand the behavior of a fleet of things, like the performance of a line of cars in different environments. In these use cases, it is important to take the idea of twinning as more of a metaphor rather than too literally.
It's also important to observe that the early framework for thinking about digital twins was developed to help companies ship better products at lower cost. Some of the same concepts can be applied to improving healthcare, supply chains, and business processes, but there are important differences.
Here is one interesting example: There is some debate in the academic community about whether digital twins need to be directly connected to what they are twinning. Some argue that the physical has to come before the virtual. This makes sense if you are twinning a human body in healthcare or a working supply chain. But in the product lifecycle, some of the greatest gains come from fixing quality issues before the first model is built.
Before the conversation started, I had an interesting interchange with Grieves where I suggested that digital twins could be used as prototypes for testing design ideas that never get built. Grieves responds:
These would be models and not digital twins. For there to be a digital twin, there has to be a physical implementation at some point. The digital twin can precede the physical, but nothing physical ever, no digital twin.
But even at this stage, there is some dispute over the best way to frame this notion. Vickers fires back:
Lol, this is the thing about digital twins. I see it differently. Maybe it’s just nuance. I’m pushing some ideas for digital twins for prototype systems so we can explore hundreds of different ideas. Likely, only one will be built or none at all. They are still digital twins, in my approach. It’s also more than just building physical systems. There’s the digital twin earth climate model. A different kind of digital twin. Mike is the master, and generally, after we talk about it, we are in sync. Should be fun.
Connecting the dots
Its important to appreciate that ideas like systems engineering have been around since at least the 1950s for collaborating on deep multidisciplinary problems. NASA later published the Systems Engineering Handbook in 1995 and pioneered early research into model-based systems engineering (MBSE) that helps to collaborate on complex technical problems. MBSE tools allow teams to design things using engineering primitives that can be connected like Lego blocks.
That works out great when optimizing for a few things like physical performance across mechanical, electrical, and airflow, but then struggles with important aspects like manufacturability, supply chain availability, or cost that require direct connection to various systems. But Vickers observed that these tools as they are implemented are not a replacement for digital twins. One of the biggest issues is the cultural divide across different teams in a large organization. Although MBSE tools might help build a product or system, they lack the digital thread for connecting information across silos. Vickers says:
Siloed environments are still a big problem for us today. We use the term, model-based everything. Every discipline is using model-based tools, but they are still very much siloed and not integrated. We need to work multidisciplinary where when we are in the creation phase or the analysis phase, we are still working in a coordinated fashion so that we can synthesize what is going to lead to our product in this coherent whole across these siloed environments that exist today.
Back to the beginning
Grieves first started thinking about digital twins back in the early days of computing when he was tasked with making a better system to help the local telephone company prevent people from digging up phone lines. He started to think about how to represent the physical world in virtual worlds. But at the time, he was constrained by the limits of computers with 192 kilobytes of RAM and 10 megabytes of storage. After a successful career in business, he decided to revisit the problem when he realized that most of his time was spent dealing with lawyers and accountants. He went back to school and started formulating his vision at a time when computer infrastructure was beginning to catch up with it.
Around the same time, Vickers was at NASA trying to explain similar thoughts. For a while, they settled on ‘radical innovation and design in manufacturing.’ They started explaining the concept as a “virtual digital fleet leader.” That never got much traction outside of NASA and DARPA for obvious reasons.
Grieves's original term was “mirrored spaces model,” and he later used “information mirroring model” and “virtual doppelganger.” Those summarized the concept but struggled across many audiences.
I don’t know when I first heard the term digital twins. We were working on a NASA technology roadmap and kicking around terms to describe an approach we later called the ‘virtual digital fleet leader’ that Mike and I were working on closely at the time. We were working on the same type of problem – the integration of disciplines across the total product lifecycle, such as manufacturing, that can be encapsulated into design materials, manufacturing tests, and operations. When we were doing that, they were carefully siloed phases, and we were kind of throwing things over the wall. I came to visit Mike, and I don’t remember where we were. I said I got a new name for what we were doing, and I didn’t know if he would like it or not. I think it clicked for him. When we began to promote this terminology, it took off. But we were already working on the concepts.
Grieves's book Virtually Perfect in 2010 mentioned the new idea for digital twins in a footnote describing the Information Mirroring Model. Then, in 2014, Grieves wrote a seminal paper on manufacturing. That’s when the term took off. Grieves says:
It's been cited thousands of times, and for a white paper to be cited is highly unusual in the academic arena. But it is about the digital twin and manufacturing, and that sort of put a stake in the ground in that particular area.
Later, Grieves and Vickers collaborated on a 2017 chapter for the Aerospace Industry Association, which established the whole framework for digital twins. But the field did not really explode until Moore’s law finally caught up with the original vision. High-performance engineering workstations were playing a key role in engineering design. But it took a few more years for cheaper computers to help connect these engineering tools to the information stored in other ERP, manufacturing execution systems and IT systems for the field to take off. Grieves says:
I think that required an essence of Moore’s Law to reach the point where we could actually do this thing. We laid a lot of the foundation groundwork for it. But all of a sudden, people could start to do what we had told them they could do.
In 2015, Vickers started approaching two major engineering design companies to promote digital twins for use in additive manufacturing. Here, it was not just about testing the performance but also designing for the nuances of how additive manufacturing lays down materials. That was when the design companies started introducing and selling digital twin products in this area. Vickers says:
After that, there was a big jump in where we were in the evolution of this information sharing.
I first started thinking about a concept like digital twins while working at Biosphere II in Arizona where we built the world largest self-contained ecosystem in 1992. The actual Biosphere was about two and a half acres large complete with a mini rainforest, savannah, ocean, marsh, desert, farm and human habitat. At the time I was working on the nerve system connected to over 2,500 sensors. But the kind of information we actually collected was a bit disjointed and difficult to interpret for new projects. For starters we had two separate data management systems from different vendors that used different naming schemes and data collection formats.
At one point I spent a couple of weeks just to harmonize the names of similar types of sensors. We did try and create a digital model of how the whole thing was put together. But this was fairly static and not connected to live systems.
It feels like more and more of the pieces are coming together to create digital twins thanks to innovations in cloud data infrastructure, data management, 3D graphics, and AI. But it still feels like the early 1990s of the Internet when people saw the tremendous promise, yet struggled with figuring out how to create the massive value we are seeing today.
Grieves kindly posted the full interview on YouTube. Please note that some of the comments in this story have been edited for clarity and brevity.