There are several popular definitions for digital twins. Mine is that a digital twin is a low-resolution model of a remote system, usually of a single aspect or dimension of that system. This model defines an abstraction, the basis for understanding what the remote system is doing, and for predicting what it might do. Because the twin is abstract, it requires neither the computing power of the original nor does it require the user of the twin to understand systems that he does not. A twin is simpler if the twinned system is simpler.
Much of the buildings controls industry remain enmired in the model of monolithic big programs. Some innovators have embraced the actor model, small programs that interact with each other through formal messages. An actor should encapsulate technical volatility, that is, keep the other actors unaware of changes in technology or controls. This model is ideal for edge-based computing, which should ideally follow cloud-native principles.
As the actors get smaller, it is easier to twin them. I have written before about moving to that cloud-native actor model (most recently in the September 2022 issue). When actors and their twins are small enough, they simplify predicting failures and improving cybersecurity.
When you twin a simple actor, you decide which behaviors are important. Even complex systems can expose one or more simple Connection Profiles. One Connection Profile may be for energy use, another for vibration analysis. As a twin listens to the connection, it records patterns of behavior. Eventually, those patterns will become predictable, the basis for a model, and then a model-actor. This should be part of commissioning.
Once you have a model actor, you have a tool for theory-free management of IoT and you have a model for cyber-physical security.
Many approaches to integrating things into systems of systems bring compounding complexity into those systems. In a complex system of systems, it is unlikely that the developer has expertise in each system as does the original developer of each system. In the unlikely circumstance that the developer possesses such detailed knowledge of each system, nobody but the original integrator will be able to maintain the system of systems. The system of systems will not last, will not support growth to include additional systems, and will lose value over time.
A model actor is built not by replicating the entire complex system, but instead by specifying the outwardly observable behaviors of a complex system. If I send the system and its model actor a message, they should each in turn respond by sending similar messages to other systems. This can enable to develop systems of systems using the model actors as components, free from the risks of manipulating a system that operates a physical process—risks that may be dangerous or expensive.
Cybersecurity for physical systems is potentially much more complicated than cybersecurity for pure software systems. A may hack a system by feeding it poor or incorrect sensor data or physically damaging a component that will cause the system to misbehave. If that system is part of a system of systems, a single physical system may then misinform other systems, causing them to fail in ways that appear identical to proper operation. A physical system operated outside its proper bounds may harm that system in undefined ways
A model actor lets a system of systems detect when a whole system is behaving badly. If a model-actor has a history of predicting the responses of the modeled system, then that is evidence of damage or harm or degradation of the modeled system. In effect, the model-actor becomes part of continuous unit testing of a complex system.
The CNS/CP specification under development by PADI defines a model for describing the complex interactions between systems, defining named connection profiles for system interactions. Systems connected by CNS/CP do not require that integrators have a deep understanding of the remote system; instead, they define the limited interactions two such systems will have. If a system is an actor that can communicate as described by a connection profile, then the model-actor can interact in the same way.
A continuing problem of complex systems of systems is that they often respond in unanticipated and undesirable ways. Energy storage systems frequently discharge completely long before the moment a smart grid needs it most. Environmental controls may respond to new energy-saving policies at a pace that reduces the utility of the space managed. If we name the internal processes of such systems as controls, we can name the abstract management of these systems as policies. The bad outcomes named in this paragraph are examples of policy failures in systems of systems.
If I can run each new policy through the model actors before I use it in my actual integration, then I can try out each policy in advance, watching the simulation of the model-actor responding to live behavior with the other systems under the new policies. By keeping the interactions and behaviors local, one can run and test policy changes in systems of systems without losing privacy or security, or resilience by bringing all interoperations up into the cloud.
Standard connections for integrating systems of systems will be demonstrated at this year’s AHR show. These will naturally focus on using connection profiles where they can demonstrate quick benefits for systems of systems. The real value is in cybersecurity: they define limited interactions, they create system groups that can be twinned, and they enable service-based security monitoring.
