Events Overview Events are a very versatile mechanism of the Asset Administration Shell. The following subclauses describe some use cases for events. They summarize different types of events to depict requirements, introduce a SubmodelElement EventElement to enable declaration of events of an Asset Administration Shell. Further, the general format of event messages is specified. Note: the concept of event is still in the experimental phase. Please be aware that backward compatibility cannot be ensured for future versions of the metamodel. Brief Use Cases for Events Used in Asset Administration Shells Event use cases are briefly outlined in the following: An integrator has purchased a device. Later in time, the supplier of the device provides a new firmware. The integrator wants to detect the offer of a new firmware and wants to update the firmware after evaluating its suitability ("forward events"). A dependent Asset Administration Shell ("D4") detects events from a parent or type Asset Administration Shell ("D1"), which is described by the derivedFrom relation. An illustration of the use case is given in Figure 1. An integrator/operator operates a motor purchased from a supplier. During operation, condition monitoring incidents occur. Both parties agree on a business model providing availability. The supplier wants to monitor device statuses which are located further in the value chain ("reverse events"). An illustration of the use case is given in Figure 1. Figure 1. Forward and Reverse Events An operator is operating a certain I4.0 component over time. Changes that occasionally occur to these I4.0 components from different systems shall be tracked for documentation and auditing purposes. This can be achieved by recording events over time. An illustration of the use case is given in Figure 2. Figure 2. Tracking of Changes via Events An operator is operating different I4.0 components, which are deployed to manufacturer clouds. The operator wants to integrate data from these components, according to DIN SPEC 92222. For this purpose, information needs to be forwarded to the operator cloud ("value push"). An illustration of the use case is given in Figure 3. Figure 3. Value Push Events Across Clouds Input and Output Directions of Events We can distinguish between incoming and outgoing events. See Table 1 for more information on the event directions. Table 1. Directions of Events Direction Description Out The event is monitoring the Referable it is attached to. An outer message infrastructure, e.g. by OPC UA, MQTT or AMQP, will transport these events to other Asset Administration Shells, further outer systems and users. In The software entity, which implements the respective Referable, can handle incoming events. These incoming events will be delivered by an outer message infrastructure, e.g. OPC UA, MQTT or AMQP, to the software entity of the Referable. Types of Events The uses cases described in Brief Use Cases for Events Used in Asset Administration Shells need different types of events. Each event type is identified by a semanticId and features a specialized payload. Table 2 gives an overview of types of events. The possible directions of an event are described in Input and Output Directions of Events. Table 2. Types of Events Group Direction Motivation / Conditions Structural changes of the Asset Administration Shell Out CRUD[1] of Submodels, Assets, SubmodelElements, etc. 1. Create, Retrieve, Update, Delete In Detect updates on parent/type/derivedFrom Asset Administration Shell Updates of properties and dependent attribute Out update of values of SubmodelElements time-stamped updates and time series updates explicit triggering of an update event Operation element of Asset Administration Shell Out monitoring of (long-lasting) execution of OperationElement and updating events during execution Monitoring, conditional, calculated events Out e.g. when voiding some limits (e.g. stated by Qualifiers with expression semantics) Infrastructure events Out Booting, shutdown, out of memory, etc. of software entity of respective Referable (Asset Administration Shell, Submodel) Repository events In/ Out Change of semantics of IRDIs (associated concept definition) Security events Out logging events access violations, unfitting roles and rights, denial of service, etc. Alarms and events Out alarms and events management analog to distributed control systems (DCS) Custom Event Types Custom event types can be defined by using a proprietary, but worldwide unique, semanticId for this event type. Such customized events can be sent or received by the software entity of the respective referable, based on arbitrary conditions, triggers, or behavior. While the general format of the event messages needs to comply with this specification, the payload might be completely customized. Event Scopes Events can be stated with an observableReference to the Referables of Asset Administration Shell, Submodels, and SubmodelElements. These Referables define the scope of the events, which are to be received or sent. Table 3 describes the different scopes of an event. Table 3. Event Scopes Event attached to … Scope AssetAdministrationShell This event monitors/represents all logical elements of an Administration Shell, such as AssetAdministrationShell, AssetInformation, Submodels. Submodel This event monitors/represents all logical elements of the respective Submodel and all logical dependents. SubmodelElementList and SubmodelElementCollection and Entity This event monitors/represents all logical elements of the respective SubmodelElementCollection, SubmodelElementList or Entity and all logical dependents (value or statement resp.). SubmodelElement (others) This event monitors/represents a single atomic SubmodelElement, e.g. a data element which might include the contents of a Blob or File.