DT Events

The entire WLDT Library and the associated DTs modeling has been designed as an event-driven system where each component is (almost) fully decoupled from the other and focused on a specific responsibilities. The communication among these independent components (e.g., Physical Adapters, Digital Adapters, Model, Storage, Shadowing Function etc ..) is implemented through an event-driven system and and effective exchange of messages and depicted in the reported Figure.

In order to better understand the type and nature of the available events this section provides additional information about the characteristics and responsibility for each category and are of interest in the Digital Twin.

Physical Asset Events#

Those events maps every bidirectional interaction with the Physical Asset (or multiple assets) that the DT is in charge of digitalizing. Involved events are related to:

• Physical Asset Description: Associated to any variation in the description of the Physical Asset through the structure denoted as PhysicalAssetDescription (PAD)
  • New Physical Asset Description: Maps the availability of a new PAD from a specific target Physical Asset through a Physical Adapter
  • Updated Physical Asset Description: Maps the availability of an updated PAD from a specific target Physical Asset through a Physical Adapter
• Physical Asset Variation: Associated to any variation of the Physical Asset in terms of Properties, Events and Relationships Instances (previously declared in the PAD)
  • Property Variation: Maps a variation of a Physical Property (e.g., temperature value of 25 Celsius Degrees)
  • Event Notification: Maps an event notification generated by the Physical Asset (e.g., Over-Heating)
  • Relation Instance Variation: Maps a variation of Relationships instance associated to a Relationship type declared in the PAD
• Physical Asset Action Request: Maps an event coming from the DT’s Core for the Physical Asset (managed by the Physical Adapter) to trigger an action in the physical world (e.g., turn on the switch)

Each Physical Property, Physical Event and Physical Action declared in the PAD is identified by a key and characterized by a type (e.g., an ontology or domain-specific data type) and by a contentType describing how its value or payload is represented (e.g., text/plain, application/json). For Physical Properties the content type defaults to the class name of the initial value (e.g., java.lang.Double).

Digital Twin’s Events#

Those events are on the other end in charge of mapping event generate by the DT itself during its evolution and across its life-cycle. They can be associated to the following aspects:

• Life Cycle Variation: Maps a change in the life cycle’s state of the DT for example moving from Bound to Synchronized
• DT State Variation: Maps a variation in the State of the DT communicating the new State and the list of associated changes
• DT State Event Notification: Maps an event generated by the DT for example mapping an event notification coming from the Physical Asset (e.g., Over-Heating) or a “new” notification from the DT (e.g., Anomaly-Detected)
• Digital Action Request: Maps an action request on an available action exposed by the DT and that is requested by and external application. This Action trigger can be internally managed by the DT or can generate then a trigger for a Physical Action as previously described.

Augmentation Function Events#

Those events map the interactions between the Digital Twin Model, the Augmentation Manager and the Augmentation Function Handlers that host the Augmentation Functions (stateless and stateful) registered in the DT. They are published on the same WLDT Event Bus used by all the other components and all share the base event type dt.augmentation.function, extended with the Handler Id and the Function Id when the event is related to a specific function. Involved events are related to:

• Augmentation Function Registration: Associated to the availability of the Augmentation Functions in the DT. They are published by the Augmentation Function Handler and observed by the Digital Twin Model, which keeps an up-to-date list of the available functions and notifies the Shadowing Function through the discovery callbacks
  • Function Registered: Maps the registration of a new Augmentation Function in a Handler (AugmentationFunctionRegistrationWldtEvent, type dt.augmentation.function.registered)
  • Function Unregistered: Maps the removal of an Augmentation Function from a Handler (AugmentationFunctionUnRegistrationWldtEvent, type dt.augmentation.function.unregistered)
• Augmentation Function Request: Associated to the requests generated by the Digital Twin Model (e.g., after a Physical Asset variation or a DT’s life cycle change) and sent to a specific function of a specific Handler. The payload is an AugmentationFunctionRequest containing the context of the execution
  • Execute Request: Maps the request to execute a Stateless Augmentation Function (AugmentationFunctionExecuteWldtEvent, type dt.augmentation.function.execution.execute.<handlerId>.<functionId>)
  • Start Request: Maps the request to start a Stateful Augmentation Function, which will then keep running and producing results over time (AugmentationFunctionStartWldtEvent, type dt.augmentation.function.execution.start.<handlerId>.<functionId>)
  • Stop Request: Maps the request to stop a running Stateful Augmentation Function (AugmentationFunctionStopWldtEvent, type dt.augmentation.function.execution.stop.<handlerId>.<functionId>)
• Augmentation Function Output: Associated to the outcome of the execution of an Augmentation Function. They are published by the Handler and observed by the Digital Twin Model
  • Function Result: Maps the availability of new results produced by a function. The payload is an AugmentationFunctionResultList containing a list of AugmentationFunctionResult (e.g., a predicted property value, an anomaly event or a new relationship) (AugmentationFunctionResultWldtEvent, type dt.augmentation.function.result.<handlerId>.<functionId>)
  • Function Error: Maps an error notified by a function during its execution (e.g., an invalid context or an exception). The payload is an AugmentationFunctionError that also reports the identifier of the request that generated it (AugmentationFunctionErrorWldtEvent, type dt.augmentation.function.error)

Since all the events share the same base type, any component can observe the entire augmentation activity of the DT by using the wildcard dt.augmentation.function.*. This is the approach adopted, for example, by the Storage Layer to automatically persist registrations, requests, results and errors of the Augmentation Functions.