Eventing Use Cases & Requirements

[sebastiankb]

The API Workstream started to work on approaches for supporting Eventing with the AAS API.
Multiple issues and presentations already suggest different solution approaches.
The purpose of this issue is to collect and discuss use cases and requirements for concrete eventing scenarios, providing a baseline for evaluating and selecting a suitable solution.

So far, 3 main Use Cases where considered in the Workstream meetings:

1. Low‑frequency updates: Changes within an AAS are rare (e.g., once a week/month/year).
2. Notify‑then‑request: If changes occur within an AAS, only a notification is sent indicating that something has changed. The actual changes must be retrieved.
3. High‑frequency updates: Changes occur at very short intervals (seconds, minutes).

Based on the use cases, the following requirements were discussed (not completed yet).

Requirement Category	Requirement	Low-frequency updates	Notify-then-request	High-frequency updates
Update Pattern	Typical update rate	Weeks / months / years	Seconds / minutes / weeks / months / years	Seconds / minutes
Update Pattern	Event volume	From low to high (e.g., new PDF document)	Notification low; the requested change from low to high	Usually low (e.g., monitoring dynamic property)
Network / Firewall	Firewall-friendly (HTTPS / 443)	Important	Important	Not important (mostly used in local network)
Network / Firewall	Local / corporate network required	Not necessarily	Not necessarily	Usually required
Network / Firewall	Long-lived connections	No	No	Yes
Performance	Latency	Low to medium	Low to high	Should be low
Performance	Throughput	Low to high	Notify: low Req-response: low–high	High
Reliability	Delivery guarantee	Important (is ACK needed?)	Important	Not important (depending on use case)
Scalability	Number of subscribers	Low to high	Low to high	Low to medium
Security	TLS	Yes	Yes	In local network not needed
Security	Fine-grained authorization
Related Submodel			Product Change Notification	Asset Interfaces Description, Time Series

[sebbader-sap]

(TF discussion on 30.04.2026)
To be discussed in a parallel issue: Are we talking about changes affecting the AAS model, or outside, or how can the separate the different requirements into feasible categories?

[mjacoby]

As discussed in today's call, I think we are missing a classification of events/event types.
To my understanding this includes (but probably not limited to)

Internal or system-level Events

These are generated by a server automatically, i.e., without explicit triggering from a user. There is a fixed set of those events which primarily address CRUD operations, such as submodel created, submodel element updated, operation invoked, etc. They carry a fixed pre-defined semantic which cannot be influenced by the user.
A client/user might user these events to monitor the status of AAS elements e.g. to display the current state in a UI or to trigger some other action if a certain condition arises like the value of a property rises above a given threshold.
Access to these events could maybe be aligned with access to the elements itself, i.e., if a user is not allowed to access a submodel or property via the REST API than this user does not receive any events about this element.

Custom or user-defined Events

This would be events that have a custom name, semantics, and/or payload, e.g. NewFirmwareAvailable, MachineStopped, etc. These might be tied only to top-level elements such as Asset, AAS, and Submodel.
For a user to know which events exist we would need to have a formal description of available events in the metamodel (similar to the existing experimental class EventElement). In case we limit these events to be tied to Submodels, we might avoid this formal definition in the metamodel by defining them in SMT specifications in text-form only, but this is not something I think is a good idea because we then loose the self-description property of AAS.

To progress in this topic we should collect use cases for events because the use cases typically include this kind of information (although often only implicitly).

[sebastiankb]

Thanks @mjacoby for the input. I'm not sure if this detailed distinction is important when considering a general approach about the Eventing topic. Basically, the subscriber should receive a message indicating that something has “changed” or that an event has occurred. At this point, it doesn't matter whether the change was caused by a machine/system or a person/custom. I think, this topic gets relevant when we consider the semantics within the change/notification message.

[mjacoby]

You are correct that it does not matter if an event has been triggered by a user or a machine. However, I still think this is relevant because it defines the the scope of what we are talking about as there are different implications.

For example, are we talking about a fixed set of predefined events (e.g., event for create, read, update delete of AAS elements) that can be explicitly listed in the specification or about custom events that are not explicitly defined in the specification in which case we would need a mechanism and data structures that allow a user to define those custom events including semantics, payload, and other details.

The is also an implicit assumption about event frequency that system-triggered events tend to have a (much) higher frequency than user-triggered events that happen only every now and then.