We’ve heard about, and I’ve talked about, the concept of a “digital twin”. Interest in the concept is growing, and with that growth we’re seeing an interesting division of mission appearing. It turns out that just as we have “identical” and “fraternal” twins in human biology, we have “control” and “simulate” twins in the world of digital twinning. Will that division confuse and undermine or enrich and validate?
Most of the interest in digital twins that enterprises have reported to me represent modeling a process to improve your ability to automate it. I recently blogged about how a true enterprise expert in process automation sees the digital twin concept as such a tool. There is a second mission, though, and that’s the mission of simulation. If we had an accurate digital twin of a business process, could we use it to test out actions before taking them? In theory, yes, but what difference would there be in how this simulation mission is implemented versus the traditional “control” mission? Could both missions be supported from a single twin? Answering these questions is the only way to answer the question the first paragraph of this blog poses.
There are already digital twin stories that stress the simulation mission (HERE and HERE, for example), but they don’t address what that mission requires from an implementation. I’ve been fiddling with my own implementation (first based on C++ and then Rust) and I also got input on the simulation mission from 19 enterprises. Here’s what I’ve found.
Of those 19 enterprises, 11 had “looked at” simulation via digital twins, and 8 had actually implemented something. The first interesting fact that emerges from the 19 overall is that their view of implementation requirements differs between the two groups.
Light exposure to the simulation mission seems to result in treating it like software testing. You build a twin like you build an application. In a process automation mission, sensors feed the twin like real user data feeds the application. In a simulation mission “test data” is fed instead. The functionality of the system is built by/into the model, so changing the data source is all that’s needed to change the mission.
The expert I mentioned in the blog I reference above made an incidental comment on this point even though the company was supporting process automation missions only. The comment was that the logic of the process itself wasn’t necessarily represented, only the relationship between sensor events and control functions. It turns out that this is a profound difference for at least some digital twin applications, as it applies to simulation.
Say we have an assembly line where a conveyor system moves stuff along at some pace, with perhaps starts or stops as needed. The steps along the line are triggered in most cases by the arrival of something on the conveyor, as a sensor detects it. You can’t install a door on a car body till the body reaches the point where the door is held and attached. The physical system’s activity can be detected, and this activity is the trigger for control functions to be initiated.
Now look at a simulation. Yes, we can generate a sensor event for “car body arriving”, but when do we generate it? The timing of the event in the real world is set by the movement of the conveyor, but there is no conveyor in the simulation. We’d have to be able to time the sensor test events to represent the process system’s behavior.
Why couldn’t we just record and play back the events? We could, presuming two things. First, we have to presume that our simulation doesn’t involve things that change event timing. Second, we have to assume that no control action taken will itself alter event timing. The 8 enterprises who actually implemented a digital-twin simulation tool all agree that neither assumption is likely valid, and my own fiddling with a model reaches the same conclusion. The reasons are easiest to illustrate by considering an assembly line conveyor process and a truck transportation process.
In an assembly line conveyor process, we can assume that the line moves at a fixed speed or that it’s stopped. We can assume that the position of something is signaled by a sensor event and that the timing of these events is determined by the conveyance rate. Thus, we can play a recorded set of events to drive the process. However, what are we simulating? The presumption is that some change is being assessed, and how does that change get reflected in this model?
In our truck transportation process, we can assume that it consists of three steps, loading the truck at the source, the travel to the destination, and unloading the truck. We can see here that the problem is that none of these processes has a fixed period of completion, nor would we expect them to. We really have three independent processes, with each activating in succession by the completion of the prior one, or by a trigger event for the task overall (“Deliver this order to 128 Main Street”).
You can see that we could also frame the assembly line implementation in the same way. We could say that each step in the process is an independent sub-process, and that the linkage of the belt is now a transportation step whose duration is normally fixed. We need then to consider our model as a series of models, each of which is a kind of black box, known by its inputs (the events it receives) and outputs (the events and commands it generates). In a simulation, we drive the model of each sub-process with stuff we simulate, so if one sub-process drives the next then we have to simulate that driving event.
My work, and the comments of the 8 enterprises, suggests that while it may be possible to create a single software model that does everything in both process automation and simulation, it’s easier and safer to assume that a simulation replaces a real-world black-box interior with a simulation interior. Thus, each sub-element in the digital twin has an API that connects its inputs and outputs. Those APIs are then linked either to a software stub that interfaces with real process control sensors/effectors, or to a stub that simulates them. You can simulate any sub-element, or any set of them including all of them, by replacing the “real-world” stub with the “simulator” stub.
This, it turns out, isn’t unlike the way that testing real-time software, including protocol handlers, is often done. I did a number of data generators designed to inject test data into a protocol handler by simulating a message received at a specific time. It’s easier to build the simulator/injector at the time the overall software (the digital twin, in this case) is built because the design of the two needs to be coordinated for easy use. I think it’s also an indicator that, if you want to test digital twins, the same elements that provide for simulation will also allow for better testing.
Simulation is clearly a valuable mission for digital twins, and particularly in missions where the twin reflects company operation, but that broad mission demonstrates that supporting simulation will sometimes require more than simple stimulus-response thinking. This is where AI would come in, according to the expert I cited in the referenced blog, and the majority of the enterprises who offered detailed comments. In the long run, digital twins and AI might be twins themselves, at least in the sense that they’re faces of the same coin.
