In my last blog I talked about the fact that tech needed a new driver, a new and compelling business case or set of business cases. What? Well, in my view, there’s only one answer. You can call it “digital twinning” or “industrial metaverse” or (my own term) “metaverse of things” or MoT, but whatever you call it, it’s probably the key to unlocking a whole new range of IT and network spending. The question is less whether that’s true than when and how it will happen, and I propose to try to answer at least a part of that question here.
Digital twinning is the heart of any generally realistic “metaverse” concept, because a metaverse is a virtual world that synchronizes with pieces of the real world. In the “social metaverse” model, what synchronizes are the people who participate, meaning their movements, actions, speech, etc. In an industrial or MoT model, the synchronization is limited to a specific real-world system. Whatever gets synchronized, the goal is to represent in the metaverse the important things about the corresponding real-world elements. Thus, all digital twinning is really an IoT application, based on some collection of sensors that can detect and communicate the state of those real-world elements.
IoT is best viewed as an event-driven process, where some condition detected by a sensor is communicated in real time as an event. In MoT, I believe that these events drive the state of elements in the digital twin, which is a model representing that real-world system. When one element receives an event from a sensor, it may change its own state, which then generates other events. At any moment in time, the collective state of the elements, which represents the state of the metaverse-twin, can be analyzed, visualized, etc.
I describe the metaverse as a model, by which I mean it’s a kind of graph or topology of objects that represents the relationships that the real-world system establishes, and any policies that are imposed to enforce specific relationship behaviors. A metaverse of people, a social metaverse, might have no specific relationships imposed (any-to-any) but it might have policies that limit how those open connections can be used, to prevent “virtual fights” for example.
I’ve always envisioned the MoT model as being a hierarchy. At the top is the “system” being represented. Below that are subsystems that, for an example of an assembly line, could be the steps along the pathway. Within each of these would be the specific elements, which might be discrete objects or sub-subsystems. The purpose of this is to collect things that are interreactive in something, so that their dependence on event-sharing and exchange would be known. In my approach, a high-level (subsystem) could interact with its subordinate elements through event exchanges, and with the level above (system) both to represent broad state changes and to communicate with other subsystems at its own level. All this sounds good, but let’s put aside the specifics to a point below.
You can understand the problem of “event exchange” here by considering social media metaverse issues. If we assume that a social metaverse is the entire world population, then the number of interactions that could be signaled would swamp any possible compute and network framework. But every human on earth isn’t trying to interact with all the others, or even particularly interested in them. Our social horizon is much smaller, and if we represent a group of people who elect to be mutually aware (let’s use Vonnegut’s term for it, a “karass”) then we could consider a karass to be a subsystem in the model, and its members the contained element. The world would be made up of millions of karasses, and yet the problem of managing interactions for all of them would be manageable.
The biggest advantage of the subsystem approach to managing event exchange is that you can distribute it. If we have five karasses distributed over the globe, we can distribute their hosting for the simple reason that by definition those karasses won’t likely interact much if at all. If they do, we could establish a policy that says that a karass is like a meeting room, where those inside interact freely but where an outsider has to initiate a request, virtually “knocking on a door” or “ringing a phone”. That would open a pathway between the karasses, and that in turn might mean that the two decide to join, to go into the same virtual room.
We can apply this to the MoT model just as easily. Each factory in even a multi-enterprise industrial system could be a karass, and each process within it could be another subordinate karass. We have to make elements of the process capable of exchanging events because processes would be by definition cooperative activities. But when a process subordinate karass is done with something, the karass generates an event to the next process karass in line.
Organizing elements in a digital twin process is essential to making it scalable and effective, but organization depends on the model structure. Get that wrong and everything is wrong, and that’s a challenge because there’s not a clear way to decide what the best, or even what a good, model might look like. Now is the time we have to revisit the simple approach I noted above, in terms of how it might actually be implemented.
A strict hierarchical model, like an organization chart, is a reasonable starting point in modeling a digital twin because it’s a suitable way to model something like a network service. The top-level system is a box/object, and it decomposes into the step objects. But the steps have to be in order, meaning that the real-world sequential or other relationships that the system is built from have to be the basis for the model. That means that a digital twin model is really likely to look more like a graph or a workflow diagram. Each element has a set of relationships, so we might view an assembly line as a string of objects that are joined by an event flow. Within each there could be a similar structure, one that could also be a simple string or perhaps several parallel strings if there are multiple activities within a high-level element that could be done in parallel. In this approach, the model represents both structure and sequence.
This works for an assembly line, but what about for a “social metaverse?” For that, there is no specific structure or sequence so the same model approach isn’t helpful. I’ve suggested in the past that a metaverse would have a karass in the form of what I called a “locale”, which is a virtual place that people have elected to inhabit through their avatars. A locale is then a high-level element that contains the subordinate elements consisting of both avatars representing real people, avatars representing virtual people, and avatars representing objects that make up the surroundings, like furniture. In this case, the locale object has to be responsible for the collective view of the social community it represents, and it’s the nexus of the event flow.
The point here is that the model approach has to be customized to the system that’s being twinned, but that structure has the common objective of coordinating the flow of events among the elements of the digital twin. There is always a flow of events (and of controls) between a real-world element and the corresponding element in the digital twin, but the model has to be able to mediate what happens when something in the real world triggers a condition that has meaning outside that pairwise relationship.
This doesn’t mean that you can’t create a generalized set of tools, a Platform-as-a-Service middleware in effect, that would allow you to build digital twins. What it does mean is that there has to be a way of constructing each of the objects and what it contains and describing the behaviors that each object asserts and the ways that objects can exchange events. You could do this by building objects and state/event tables at a very low level, but that would risk introducing errors. A more graphical or low-code approach would be preferred.
There are a lot of low-level tools that could be pressed into service for MoT, but there aren’t any of those PaaS-middleware tools available yet, and nobody has told me about any that are in development. If there’s going to be real progress in this area, we’ll need that to change because a significant breadth of applications is essential in building momentum, and without good development tools that’s just not in the cards.
