“Digital twin” is a frequently used phrase added to the vernacular around digital engineering – and just like with any other new technology, there’s presently an industry-wide rush to define what they are and to create a vocabulary about them. The rush is understandable. With new technology there’s always a vacuum to fill and a market to define. Doing that before there is a universally agreed upon language around the new technology, and in the process claiming some sort of first-mover status, is how many companies carve out a leadership niche.

When it comes to digital twins, we’re seeing this exact scenario play out. Organizations are releasing various maturity models and roadmaps – all designed to put their own spin on digital twins and to convince the market that their definition of digital twin development is the correct one.

Our approach at GDIT is to take a big step back. We look at digital twins through the lens of digital engineering, and we know it can be made better with digital threads. We also know that attaching a digital thread to an authoritative source of data and injecting it into a model creates a true digital twin.

Let’s break that down.

A Digital Thread...

Digital threads create simpler, universal access to data. You use them to address questions that require pulling data out of applications and structuring it to formulate an answer.

Imagine, for a physical system – such as a piece of aircraft or a vehicle – trying to answer the question: Does the design for this vehicle component meet its weight requirement? There is data available to answer that question. The digital thread is the analytic receipt or manifest that helps answer the question, but it must be converted from something analytical into something that is human comprehensible.

For a piece of software, the digital thread would include things like requirements, interface descriptions, and component relationships.

Attached to an Authoritative Source of Data...

When a digital thread is attached to an authoritative source of data, the thread can be trusted and actioned. In the example of a physical system above (i.e., an aircraft) the thread might include data from millions of parts hosted on a server.

Our software example would rely on source code management, a hosted repository for all software required for a system, as its authoritative source to populate a thread capable of empirically answering questions. These questions might include, Are my requirements traced to a design element? or Do I have a test defined for each component of my system?

And Injected into a Digital Model...

Injecting a digital thread and its connection to an authoritative data source into a digital model of a system – this can be a cloud model, a software model or even a physical model – allows for richer, more realistic simulations. And this is what makes a model a true digital twin.

Makes a True Digital Twin.

No matter the level of maturity or how it is defined elsewhere, a true digital twin includes a digital thread attached to an authoritative source of data and used in a model. With this type of true digital twin, teams can conduct simulations and tests that begin with a foundation of real and validated data.

Moreover, with true digital twins, teams can get data out of their simulations and feed it back into the twin, creating a feedback loop and a replica of a system that aids in decision making. This type of digital twin creates better simulations, helps to reduce risks, creates less design rework which lowers costs, and promotes transparency since the data, models and feedback loops are available to everyone involved.

For all of these reasons, the growth in the development and use of digital twins is only going to continue, which is a very good thing. Digital twins can be incredibly valuable to a variety of missions and use cases. Ensuring these efforts result in true twins, and not just models or descriptions of a system, is incredibly important – and digital threads and authoritative sources of data sit at the center of it all.