DT Events
On this page
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 asPhysicalAssetDescription
(PAD)New Physical Asset Description
: Maps the availability of a new PAD from a specific target Physical Asset through a Physical AdapterUpdated 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)
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 fromBound
toSynchronized
DT State Variation
: Maps a variation in the State of the DT communicating the new State and the list of associated changesDT 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.