Seeing Double: What Is a Digital Twin and How Do We Get There?

If you work in manufacturing or supply chain, you have probably heard the term “digital twin” more than once. There are many explanations. You will often hear that they are a digital representation of a part. Yes, that is true. However, writing down a part number in an Excel sheet is also a digital representation of a part. So where is the difference? What makes digital twins special and why are they built the way they are?

In this article you will not be confronted with technical buzzwords (I only counted a handful). For now, let's dive into a real-world situation.

Just Another Manic Monday in Supply Chain Management

It is Monday morning and Andrea sees several messages in her inbox, all of them about the same part, a housing for an electric motor, one of the metal parts inside an electric car. Andrea works as Head of Supply Chain Management at Wonder Metals GmbH, a family-owned aluminum die-casting company based in Germany.

The first customer reuqest is by “Bavarian Automotive”. The customer wants to know the CO₂ emissions caused during the production of the motor housing. That is an easy question. She asks her colleague and then sends the data to her customer in the form of an Excel file. The data had been calculated at the beginning of the year.

Figure 1: The first request answered manually – one file, sent by email.

Andrea opens her second email. It is from “Swabian Luxury Automotive” and they are asking for simple production data: Where and when was the part produced, and with which serial number? Andrea proceeds to look up that information in her manufacturing systems and sends a copy to her customer.

Figure 2: Two customers, two files, still sent manually.

Andrea reads through the emails again and realizes that both carmakers want weekly updates. While peeking into her mailbox and seeing two other requests, she sees herself and her colleagues busy with updating and sending files to her customers all week. There must be a better way. The data already exists in her systems, why can’t her customers just request the data automatically? Andrea remembers that a former intern had already built a tool that exports the data on a weekly basis. So, Andrea creates two servers which provide exactly these files. Each server is associated with one customer and one part. Instead of sending files to her customers, she sends them the address where they can find the data themselves.

Figure 3: One data server per customer, each with its own address.

Computer Says No - Or Rather: John from IT Does

Andrea is happy with herself, as she will not be busy with answering these requests anymore. Ping Another email arrives. It is John from IT. It reads: “Andrea, we have 2,000 customers, we cannot create a server for each one of them – declined”. Andrea starts thinking and notices a pattern. Both of her customers request data for the exact same product with some data also being the exact same. They even have the same internal part number. Perhaps she can put the two servers together, creating a single interface for both customers.

Figure 4: A single interface for both customers – but both pull the same combined file.

Andrea sips her coffee, satisfied with the result, until she notices a problem: Both customers are pulling the same file, CO2 emissions and production data together, even though each of them is only allowed to see one of the two. The interface looks fine, but the access control underneath does not.

One Part Number to Rule Them All - How a Part Identifier Links Separate Sub-Models

The fix is to stop treating “the file” as one thing. Andrea splits it into two separate data sets, one with CO2 emissions, one with production data, and shares each only with the customer who is allowed to see it. But both datasets still describe the same physical part, so she needs something to tie them together without merging them back into one file.

That “something” is a part number entry that works purely as a label, like a folder on a shelf marked “Part 123.” Open the folder and you find two separate documents inside, each shared with a different company. The folder itself holds no data; it just tells you which documents belong to the same part. Both customers still ask for the same part number, but each of them only gets their own document.

Figure 5: The part number becomes a label that points to one dataset per customer.

Never Poke the Sleeping IT Guy

Everything works fine and Andrea can spend her time on her actual work again. A week later she is greeted by further emails. Her contact person at Bavarian Automotive tells her that he urgently needs production data and data about end-of-line checks, the final quality tests every part goes through before it leaves the factory. She spends hours trying to make the data available, but she ends up with a problem. The data about the end-of-line checks updates much more often than all the other data attributes. She can hear the faint voice of John complaining to her about updating big files just to change small aspects of it. Andrea ends up splitting the dataset into its pieces and makes each department responsible for their own data.

Figure 6: Each aspect becomes its own dataset, owned by the department that produces it.

This architecture has another benefit. Whenever there are new aspects and new data structures required by her customers, Andrea can just add that data to the list without changing anything else.

While John is happy now, Andrea instantly gets a complaint from her Sustainability department, which is responsible for providing CO2 emission data. Apparently, both customers want the same data in different formats. Andrea sighs… She started this endeavor because she wanted to prevent redundant data.

There's a Standard for That!

Andrea’s life would be much easier if both customers accepted the same data format. If Andrea wants this to happen, she must find a data structure that works for both customers and (thinking into the future) also for other use cases and products. Andrea feels like this is a huge task. Luckily there already are organizations of industry experts who come up with industry-wide standardized data structures, for example the International Digital Twin Association (IDTA) an industry body that publishes ready-made data models for manufacturing. Andrea can simply pick a data model off the shelf and manages to convince her customers to use it, making life easier for everyone involved.

Figure 7: Standardized data structures plus access control decide who may read which dataset.

While she is at it, she also introduces a mechanism that controls which customer has access to which dataset. She does not really understand how that works, but as long as it is easy to set up, that is good enough for her. She is busy enough with everything else and leaves it to her trusted solution provider (sovity GmbH) for Catena-X, the automotive industry's ecosystem for data exchange between companies.

Andrea leans back in her chair and is happy with the result. Her customers can pull the data automatically; the system is as lean as can be and even John is happy when he looks at his cloud storage bill.

As Andrea drifts off in her comfortable office chair, the familiar Teams call notification sound pulls her out of her daydreams. It is the sustainability department. They sound nervous. Apparently, they do not really know the accurate CO2 value because most of it is caused by Toto Aluminum, their supplier for raw materials. Only one hour stands between Andrea and her weekend, as beads of sweat form on her face. She becomes the one thing she swore to destroy and calls her supplier to request CO2 emission data. “Sure thing, do you know digital twins?” the friendly voice on the phone answers and it finally clicks for Andrea. Toto Aluminum already has the data prepared and even better: They use the same data structures and exchange protocols, making it as easy as possible for her sustainability department to pull that data themselves.

Figure 8: The same structure repeats along the supply chain, from OEM to Tier 1 to Tier 2.

Double Trouble - So What Is a Digital Twin?

Long story short, what is a digital twin now? It is a digital representation of a part, and it has two building blocks. The first one is the shell: a wrapper that carries nothing but the identifier of the part and a list of pointers, the folder in our story. The second one is the sub-model: one self-contained dataset covering one topic, such as CO2 emissions or production data, the individual files in our story. The shell points to the sub-models, and every sub-model can be shared with a different partner. Beyond some basic information, there is no minimum requirement about what aspects and information a digital twin must carry. It can be as little as a serial number but could also contain everything you will ever know about this part.

Taking what we learned in this article and translating it into a language used in Catena-X, you would end up with this:

Figure 9: The same picture in Catena-X terms - Digital Twin Registry and Sub-Model Repository.

The digital twin does not provide value on its own. It must be used and exchanged in an intelligent way to make data-driven decisions and to help each other succeed in an increasingly competitive market.

Based on a True Story - Sort of: Digital Twins in a Real Supply Chain

Thank you for reading this article about the creation of digital twins. Our examplary story is obviously fictional and simplified, but it explains why digital twins are structured the way they are as well as ground concepts about data spaces, namely the standardized data exchange and why correct access management is important.

There are many more benefits of this structure, (for example that they are machine readable), and we skipped several details. If you are interested in those and how you could create, store and share your digital twins with your business partners as well as shape a scalable setup, we are happy to discuss this with you. Feel free to reach out: