One of my favorite tech cartoons goes back many decades, to an era where it was common to relate compute power to what might be called “mathematician years”. You’d say “this computer can do in an hour what a hundred mathematicians a decade to do”. In this cartoon, a man comes home, tosses his briefcase on the sofa, and says “Today I made a mistake that would have taken a hundred mathematicians a thousand years to make!” Faster outcomes, in short, don’t guarantee favorable ones, and computers are all about fast.
In today’s world, this may be an especially critical point because we’re tentatively moving into the world of “real-time” systems. Autonomy, meaning giving a non-human system the ability to operate with little or no human control, has already been linked to accidents in many areas, including vehicles. As we work to cede more things to automated systems, we need to think about how to ensure they don’t just do the wrong thing faster and more efficiently.
Most of us have at least some experience with failures in autonomy. A smart home or office, for example, may be scheduled to turn on and off lights at certain times, but sometimes they don’t all change on command. In this sort of situation, the problem may cause little more than an inconvenience. More serious is a problem where a security sensor is supposed to turn on a light, or when a motion sensor is supposed to open a gate for vehicles.
The greatest challenges come in more complex multi-event applications, or where there’s supposed to be a kind of cascade of interaction. Suppose our gate was triggered by reading a truck RFID or manifest QR code, and that was also supposed to deliver routing instructions to the driver, add to inventory, etc? Or suppose that we had an assembly line system that had to move the car along, move parts to the right place, and weld?
For simple applications where event triggers action, it’s possible in some cases (like turning on a light or opening gate) to repeat the action command after a short interval. In other there may be a need for another sensor to determine whether an action was taken. In effect, what we’re doing is verifying the state, meaning verifying the synchronization between the real world and our application’s view of it.
This state verification is easier if there is an explicit and organized notion of the application state, and you can see that what we’re approaching here is the idea of a digital twin. In many IoT applications, there is no real way of establishing the state of the real-world system, other than to put it into a goal state explicitly and assume the commands worked. This is less likely to come about, and likely easier to fix, if the application retains a digital twin model of the system.
One reason for this is that explicit state is easier to understand and review. If you have a real-word system of a dozen elements, and you build a model in 1:1 correspondence, you are forced to ask specific questions about state that relate directly to the real world. Is Gate 2 up or down? Just asking that question as a programmer forces you to consider how you’d know, meaning to relate the state of Gate 2 to some sensor(s). And if its state is wrong, you can ask what command would change it, and how the change is verified.
Another benefit of a true twin is that you explicitly confront the question of when to “force state” and in what direction. Should you command the model state be applied to the real world, or obtain the real-world state to make the model conform to it? This question of forcing state is critical in planning a response to something like a system failure in the application or a power failure in the real world, because in some cases the system state might be recorded and considered authoritative, and sometimes the other way.
A third benefit is an improved handling of event-handling dependencies based on state. Suppose you have two sensors that can control the same gate. A vehicle pulling up to Sensor 1 triggers it to open, and the software then allows 30 seconds after that sensor reports “no motion” to close it. Now suppose the second sensor is triggered by a vehicle moving the other way, but the software is still in the state of waiting 30 seconds to close, and that time expires. Does the gate close on the second vehicle?
You might well be asking “So what if there are other benefits to a digital-twin-based structure to IoT applications?” The reason I think this is important is that some of the issues I’ve mentioned here are almost certainly present in any real-world IoT application, which means that the value of a digital twin can be realized almost everywhere. Which means that middleware tools to implement such a thing should also be valuable, even essential.
Smart and autonomous things bring applications and us, real people, together. Even if we’re not actively a part of a real-world system, we may well be in places where such systems impact us. You don’t need to be in a misbehaving autonomous vehicle to get hit by it, or be working on an assembly line to be injured by something it does or builds. Our coming-home programmer’s mistake might have messed up your purchase, your bank balance, your credit, but unless it was an error in real-time software, you’ll probably survive it. If it was, you’d be wise to hope that the synchrony between the real world and the real-world application is strong.
There’s not enough general discussion being devoted to this topic, and the most useful concept, the idea of an explicit digital twin, isn’t linked to as many IoT or edge computing missions as it could and should be. One thing that we could hope to change that is AI.
For AI to do its job, it has to work within the real world, which means there almost has to be a model of the real world available for it, to provide the relationships among elements, the scope of controls, and the context of the available telemetry. It’s hard for me to envision a real-world system simple enough to work without a model, and still complex enough to justify AI. But we’ll see; the market isn’t always logical.
