If it is not a service, it is not a Digital Twin (part 1)
What makes a Digital Twin? Lots of things are being said and written about Digital Twins. So in this first article of a series, I want to paint our vision of the Digital Twin. The vision behind SmartShape.
With an emphasis on the “digital” side of things. This word is used and abused in many ways. Tot alk about the Digital Twin, we must not forget - and maybe even start with - its physical counterpart. And the problems digitalizing it are supposed to solve.
We say that the Digital Twin must be free from the limitations of the physical world. Too often, Digital Twins a implemented as files on someone’s computer. I want to explain why this is not the right solution. Worse, it’s a paradox. I want to explain how “digital” in itself is not a silver bullet and why doing things this way won’t solve anything.
To address this, I’ll use a metaphor based on the actual physical world.
Imagine a building. A 50.000m² building with dozens of rooms, hundreds of equipments, HVAC, piping, electrical networks and everything. Now imagine this very building can only be entered by one person at a time. If you want two people to enter the building, you must first build a copy of the building. And you’ll have to do so for each person that will enter.
Sounds like the craziest limitation ever, right? So limiting in fact that the very building is actually useless. And its Digital Twin is just as useless for the exact same reason if only one person can use it at a time. So much that if it’s not collaborative, it’s not really a Digital Twin.
“But my Digital Twin is digital…”
… one might say. And so what? Does it necessarily imply that it escapes the rules of the physical world? Certainly not.
To understand this, let’s consider a classic review process with the following conditions:
- Alice designs a new CAD model for a new project
- Bob the client wants to review and approve the project based on the CAD model
To do so, Bob needs to validate multiple aspects of the projects, and will not review it all by himself. Instead, he will delegate each aspect to another stakeholder. Each stakeholder will receive a copy of the original CAD design and add its comments to it. Hereby producing a new revision of the original design. And each revision is a new file.
This workflow has many major flaws:
- There will be as many copies of the design as they are people who need to see it. This is the digital equivalent of our “building that can only be entered by one person” in the introduction.
- If Alice keeps on working on her design during the review, then the review process as a whole will likely produce outdated comments based on an outdated design. Even worse: Alice might produce an even more problematic design because she has not taken into account some crucial initial feedback from the reviewers.
- If Alice stops working on her design, then the process is entirely serialized and as slow as it can be.
- Since comments have to be reconciled, they are likely created as new in yet another “review package” copy of the design that Bob will send to Alice (step 4). Hereby losing any kind of traceability. And it is most likely some of them will disappear in the process due to human error.
Now factor in the fact that a medium-size project will actually require multiple models coming from multiple CAD systems and reviewed by different teams. Such review process itself will produce hundreds of copies with outdated or missing data. At which point one might wonder: which copy is the “right one”? Probably none of them.
And that’s just for a review process… anything more complex that involves adding or editing data will produce order of magnitude more copies and complexity.
Toward a single source of truth
Obviously, processes based on Digital Twins implemented using “files” don’t scale. One has to chose between a fast but costly process that produces chaos in the form of errors/deprecated information, or a slow serialized one that lacks agility. In the end, you end up burning too much cash in both cases anyway.
Why? Because a “digital” file is still, in the end, just a “physical” list of 0s and 1s on some computer’s hard drive. And the only way to distribute/work on such file is to produce copies, and copies of copies, and so on… The coined term “Digital Twin” sure is a very poor choice of words because not only does it translate the idea of such copies, but actually encourages it by definition. Copies which, in the physical world, would translate into building a copy a building for each person who will enter it.
It doesn’t sound so ludicrous in the digital world because copying files is way simpler and faster than building actual copies of a physical product. But in the digital age, it definitely is just as slow and bloated. So how can we leverage the actual benefits of the digital world to create a true Digital Twin?
The Digital Twin must be accessible by all stakeholders, with the latest data, in real-time. It must span all devices and all teams. To be a truly single source of truth, it must not just provide collaboration features. But collaboration must be a first class citizen.
Digital Twin as a Service
To address the one-to-many challenges explained previously, one needs a one-to-many solution. And that solution is to consider that Digital Twins must be implemented as services.
In the upcoming part 2, I will explain how the “Digital Twin as a Service” is the only true Digital Twin.