Digital Model, Digital Shadow, and Digital Twin

There have been a number of papers, presentations, and discussions arising recently that attempt to define a set of digital constructs as subcategories of digital twins. The grouping consists of the digital model (“DM”), the digital shadow (“DS”)[1], and digital twins (“DT”). In this brief paper, I will look at each of these and give my view on this terminology and DT taxonomy.

Figure 1 shows the most common model of the DM, DS, DT taxonomy. It originates in a paper in 2018. The key differentiator in these different DT types is the two types of data flow between the physical object and the virtual object. These two types are manual data flow and automatic data flow.?

Figure?1

My analysis of the flaws in this taxonomy is that it is infinitely recursive, that it differentiates only on the type of data flows, that the type of data flows, manual and automatic, are undefined and thus cause constant name changes, and regresses to being functionally siloed.

The first flaw is that this taxonomy of DM, DS, and DT is a description of the types of DTs. That does not make a lot of sense, since how can a DT be a type of itself? The claim here is that subcategories of a DT is a DM, DS, and DT. However, logically this becomes infinitely recursive if a DT is a subcategory of itself.?

The next flaw, which is one of the biggest, is why would the type of data flow[2]?differentiate between type of subcategories? Why should that make any difference to the physical or virtual object. The object getting the data has no way of knowing whether the data originated in a manual or automatic fashion. It is simply data coming in. The physical or virtual object sending the data doesn’t know what happens to the data it is sending automatically. The data could be going to an intermediary who would manually decide what data should be sent.?

The next flaw that this surfaces is that the use of “manual” and “automatic” is undefined. We could conclude that automatic meant that the data was sent as the result of the processing capability in the physical or virtual object. However, what does it even mean for a physical or virtual object to send data “manually”? That could only mean that these objects include a human operator as part of the object. This means the DT subcategory would change constantly depending on how data was sent. If the physical and virtual objects both sent it programmatically, then it’s a DT. If the human operator sends the data from the virtual object, then it’s a DM or DS. But whether it’s a DM or DS changes depending on whether the physical object is transmitting its data manually or automatically. It does not get more confusing or unworkable than this!

To add to the confusion, we see that there is only a DT if data is transmitted automatically both ways. So human involvement is nowhere to be found in a DT. The physical object transmits data to its virtual counterpart, which would do something with the data and transmit data back, all automatically. By that requirement, there a very, very few actual DTs.

The next critique of this model taxonomy is limited to the objects themselves. Contrasting Figure 1 with Figure 2, which is my Digital Twin Model, Figure 1 only consists of the objects themselves. Figure 2 are physical and virtual objects within a physical or virtual environments. However, it is not enough to simply have data about the physical and virtual objects. These objects exist within an environment, either physical or virtual, that we need to know about.

Figure?2

My final critique is the same one I called out in my recent paper. Having different constructs depending on the lifecycle results is a return to a siloed functional-oriented perspective and not a product, i.e., object, lifecycle-oriented one. The DT was always intended to underly and exist through the entire lifecycle. The implicit but fuzzy claim here is that the DM occurs at the beginning of the product lifecycle.?

I have always been a proponent of DMs as independent entities uncoupled to anything physical. They are invaluable when we are contemplating new products. We use DMs in virtual space at a fraction of the time and cost of physical objects to investigate the feasibility of certain designs and behavioral effects. We may use them in trade studies to decide on the better approach for a product. Under certain conditions, a DM may evolve into a type of DT, the Digital Twin Prototype (DTP), once we decide to go ahead with producing a product[3]. However, a DM is not a type or subcategory of a DT. A DM is its own concept or category. The existence, let alone the type, of data flows to something physical has no relevance to DMs.

The DS is even a bigger enigma. It shows an automatic data flow from the physical object to the virtual object and a manual data flow from the virtual object to the physical object. In addition, to make matters even more confusing, the usual explanation of the DS is that a change in the physical object results in a change to the virtual object, but not vice versa. That sounds like a perfect definition of a data black hole! Data goes to the virtual object, never to be seen again. I would like to see the DS simply disappear as shadows naturally do.

In summary, there are numerous reasons I’ve identified why the DM, DS, DT subcategory terminology and taxonomy is fatally flawed. It lacks logic, is infinitely recursive, uses an irrelevant differentiator (type of data flow), and lacks usefulness. I don’t fault its origination five years ago. There was very little understood and written on DTs at the time. I had only recently (2017) proposed the types of DTs: Prototype (DTP), Instance (DTI), and Aggregate (DTA). However, for the reasons cited here, it is time to retire the DM, DS, and DT trilogy as an explanation of DTs. It’s also time to abandon the DS completely.

[1]?There are a number of completely different descriptions in the literature of what a DS is. I am using what seems to be the most common.

[2]?There is the issue of this DM, DS, DT model only specifying data and never information. My DT Model has data moving from the physical to the virtual but sending information from the virtual back to the physical. The difference between data and information and its uses is a topic that deserves attention, which I will do at some point in time.

[3]?This is the topic of a different paper.