In-depth interoperability through embedded connected digital twins, new blog by UCL

A digital twin refers to a digital replica of physical assets (physical twin), processes, people, places, systems and devices that can be used for various purposes.

In STORY, its in-depth interoperability architecture positions embedded digital twins between reality and service-providing IT such as the actual controls, monitoring, diagnostics, etc. The digital twin is the sole access point to its corresponding reality, which results in a single source of truth design. Here, single source implies that all interactions will be observed (and even predicted) for all real-world elements that have a digital twin.

“In-depth interoperability” complements the better-known IT interoperability. “IT interoperability” both concerns syntactic interoperability (i.e. the ability to exchange data e.g. via a REST interface) and semantic interoperability (i.e. the ability to assign a correct understanding to the data e.g. by using SAREF). In contrast, in-depth interoperability focuses on the relationship between the IT and reality; it preserves all the interoperability that exists within the world-of-interest (in STORY: batteries, pumps, generators, etc.).

In an ideal world, where IT interoperability is achieved while exclusively using in-depth inter-operable components, the result matches the performance of a development from scratch. Indeed, as the IT parts of in-depth inter-operable components refrain from introducing limitations in its world-of-interest, IT interoperability enjoys the same possibilities as a design from scratch. Note however that issues inside the IT domain still are to be addressed by the IT interoperability.

In the STORY in-depth interoperability developments, each real-world resource (e.g. a pump or heat exchanger) gets its embedded digital twin. Each real-world activity (e.g. transferring heat from the solar panel to a reservoir) gets its digital twin. If an activity wants to utilize a resource, its digital twin needs to acquire the necessary rights from the resource digital twin. Overall, STORY in-depth interoperability adheres to the ARTI architecture (cf. Chapter 6 in www.sciencedirect.com/book/9780128036624/design-for-the-unexpected). The first application of this concept was made in STORY for the thermal part of the living lab in Belgium.

Resource digital twins manage all activities as if they are ‘unexpected’. They make no assumptions as this might introduce limitations. Because planned, expected and unexpected activities all have to follow the same procedures, resources are able to inter-operate with any activity, even unknown at their design time. Indeed, all activities (including the envisaged activities) are obliged to interact with resources such that they may co-exist with other activities. As a metaphor, planned activities are employees working in resources and they are not inhabitants enjoying privileges over unexpected activities that would be visitors. Conversely, activity digital twins minimize their resource requirements, allowing them to utilize whatever happens to be available, opportune or optimal.

By denying a service-providing IT direct access to reality, innovative modularity becomes possible. A resource digital twin is likely to require a suitable safety-ensuring activity to acquire the necessary rights from it before other activity digital twins may be served. E.g. a certified activity requests and obtains observation (sensor) rights and actuator preemption rights. It uses the observation rights to monitor and detect dangerous and harmful conditions in time to use its priority rights and overtake control over the actuators to ensure system safety and health.

In this modular design, other activity digital twins may request and obtain the remaining rights to implement maintenance, user services, etc. Because safety is provided modularly, these services can be allowed to use the resource more liberally, shortening development cycles and enlarging the design space and experimentation opportunities. Properly certified activities might be allowed to bring the resource in more risky states while cooperating more closely with the safety-ensuring activity.

Next to being embedded, digital twins are connected. This allows a computing process to ‘virtually navigate’  through a network of connected digital twins (similar to web crawlers).  An important benefit of digital twins being connected, mirroring the corresponding reality, is a significant reduction of the challenges imposed on IT interoperability. Indeed, digital twins only need IT interoperability with their immediate acquaintances and neighborhood: resources that are directly connected or directly contained, activities that use resources, etc. Narrow artificial intelligence will go a very long way when enjoying such favorable conditions. Finally, note how this approach renders the digital twins software that is embodied and situated, precisely the properties that today distinguish human intelligence from artificial intelligence (cf. Karina Vold, humaint-kickoffworkshop-proceedings-final.pdf).

 

An example related to STORY’s living lab in Belgium may clarify the above further:

 

Figure 1 : a sample thermal circuit.

 

Each of the resources in figure 1 has its digital twin. E.g. the digital twin of “Pipe no.1” has two parts. A first part corresponds to its type/model/… in the real world. It mainly provides technical information and specifications (e.g. material, dimensions, strength, etc.). The second part corresponds to the pipe instance. It knows and interacts with the first part; all technical information processing is delegated to this first part (e.g. to answer a query about the allowed temperatures or pressures).

The second part provides the situatedness of the digital twin. It knows the digital twin of whatever is connected to its openings (i.e. pump no.1 and temperature meter no.1); it knows the digital twin of what is inside (i.e. the digital twin of the fluid in the circuit); it knows the digital twin(s) of what encloses it (i.e. the digital twin of the aggregated resource corresponding to the entire circuit in the figure above).

Note that the fluid in the circuit is a resource. When its digital twin knows a single digital twin of any circuit component (e.g. the inlet/outlet), it is able to discover the entire circuit. Moreover, repeating this procedure allows for updating e.g. after maintenance as soon as the affected digital twins have been updated (e.g. when a pump was replaced by a new model).

The digital twin of more sophisticated resources such as pumps are “pipes plus some extra features.” E.g. the pump digital twin comprises a pipe digital twin plus on/off switching. The pump instance part provides resource allocation services as this resource is able to execute commands. The digital twins of meters and sensors normally offer a subscription service (e.g. through a publish-subscribe server such as RabbitMQ). When hard real-time metering services are offered, a resource allocation service manages the bandwidth to the measurement device.

The type part of a pump digital twin is able to interact with the fluid digital twin to compute a flow estimation where the fluid digital twin collects and generates the overall data for the remainder of the circuit (creating the resistance which the pump needs to overcome). Flow meter digital twins provide the fluid digital twin with their measurement data, which can be fused with the modeling to calibrate/improve the model, to detect anomalies such as meter malfunctioning. An iterative computation inside the models can be seeded with meter data, minimizing the number of iterations/computations required for convergence. Historical data can be combined with the model to keep the system operational without replacing a broken meter immediately. Similarly, the fluid digital twin may provide virtual temperature sensing, especially when the fluid does not need to circulate to provide user services. Overall, in-depth interoperability thus bring embodied and situated intelligence.

Activities have their own digital twin. In order to execute their activity on resources, the activity digital twin needs to acquire the proper rights: authorizations (as having a login and password), certifications (as having a pilot license), subscriptions for notifications and resource allocations. Normally, resource digital twins require certain safety activities to acquire these right first. In the above example, an activity to ensure temperatures stay within boundaries imposed by the devices is to be activated. Its activity digital twin obtains rights to observe the system state in a robust manner and obtains preemption rights over the pumps and the “excess heat disposal radiator switch”. Similarly, pumps may have an activity preventing extremely long idling and ensuring the mandatory maintenance.

Lessons we can draw so far on the application in STORY indicate that these digital twins capture (energy) domain knowledge in an ICT-accessible manner and allow to operationalize such knowhow. IT systems become aware (conscious?) of their situation and become co-workers (although savant). It is no longer necessary for humans to spot and account for every requirement in person almost from scratch for every installation. When facing large numbers of smaller installations, digital twins capture knowhow the first time and bring it to bear during the (many) subsequent implementations. Thus, they amplify the efforts from the human specialists and workers. Here, digital twins provide the leverage to go beyond one-design-fits-all solutions especially in the outskirts of the energy grid.