Add support for AAS events

[MichaelHoffmeisterFesto]

Hello,

after discussion with Birgit we've concluded to provide an issue for the AAS API to provide structured AAS events for structure change of AAS in a repository and value changes. My assumption is that by these two (generic) event types, a large fraction of use cases for AAS events in the value chain can already be covered.

Basically, the specification of the declaration of AAS events is already covered by Part 1 (only the experimental flag needs to be removed). For deliviering and handling the payloads, the API seems to be the appropriate point of specification.

The proof of concept implementation in AASX server and AASPE used exactly one API operation:

{Repository-Endpoint}/geteventmessages[/time/{start-time-of-events}]

The result was a stream of event payloads, which consisted a linear stream of events in the whole repository starting with point of time {start-time-of-events}. A client could hold a state, when the last point of time of querying the repo was and the server could be state-less.

This approach was under-complex (no specific AAS event stream), but proved to be very efficient, very simple and very reliable.

Therefore, I would propose to create at least two API operations, one for the whole repository (including ConceptDescriptions) and one per AAS.

The specification of the payloads in AASPE are attached.

Note: all properties with [JsonIgnore] should not be end up in the API specifcation

AasEventMsgEnvelope_and_payloads.zip

Note: aside from these two generic payloads, IMHO, all other event payloads could be specified rather specific to a business purpose, e.g. by the means of a SMT specification. However, structural change and update values are the basics.

[mjacoby]

I wholeheartedly welcome the initiative to progress with events in the AAS! However, I see multiple issues with the proposed way/solution that needs to be addressed in order to provide a solid solution to this and not introduce issues that complicate things in the future as they need fixing (and thereby then break backwards-compatibility).

I see the following issues when reading your proposal

declaration of AAS events is already covered by Part 1 (only the experimental flag needs to be removed)

There is a reason why this is marked experimental I tbh I have lots of issues with this definition, e.g. why does a basicEventElement have properties like messageTopic and messageBroker? To me, this feels like breaking the whole concept of having a protocol-agnostic API as it puts technology-related properties in the metamodel. What happens if a protocol does not support publish/subscribe (plain HTTP) or has a custom mechanism for events (OPC UA)?

The proof of concept implementation in AASX server and AASPE used exactly one API operation:

What about other implementations that have implemented this in a different way? There are at least 3 implementations I am aware of that support something similar to this (BaSyx, FA³ST, and NOVAAS) that follow a completely different approach than AASX server using MQTT and real pub/sub instead poll-based HTTP (see BaSyx documentation , FA³ST documentation)

So rather than going with just going with one implementation that does things quite differently than multiple other implementations and making this the standard, we should look at all aspects of the different existing implementations and try to identify common patterns and then come up with a clear and protocol-agnostic solution as well as mappings to different protocols (we can start with mapping to one or two and add more over time if required).

My guess is, that AASX and FA³ST implementation are probably not so far of regarding the payloads while BaSyx seems to only put minimal information in the events (mostly the id).

Regarding the proposed URL schema...I have never seen anything like this before, i.e. a REST interface providing a "stream" (btw, what do you mean by that? Just a list/array or an actual stream like when using Server Sent Events ?) of events. Is this something AASX server came up with from scratch or is this based on/re-using any kind of existing standard or specification?

Maybe it's time to start a workstream dedicated to events in AAS to discuss these issues...

[MichaelHoffmeisterFesto]

Thank you for your comments.

why does a basicEventElement have properties like messageTopic and messageBroker ??

Yes, I am with you. During the discussions on Part 1, we could remove those. I would also have this technology-agnostic.

I am aware of that support something similar to this (BaSyx, FA³ST, and NOVAAS) that follow a completely different approach than AASX server using MQTT and real pub/sub instead poll-based HTTP ..

Oh yes, wonderful. My hypothesis is, that different use-cases will required different technical implementations. And for a low-frequency cross-company, interoperable provision of AAS events, the HTTP approach worked like a charm. No state, no connection, no (further) certificates, ... Yes, this might by one use case among others. Currently, the API already covers HTTP and therefore I think it is a good opportunity to discuss it that way.

Note: with "low-frequency", I refer to something like product change notifications (PCN). May be per AAS there are 2-4 per year. For a repository of 33000 product types, however, quite a number (multiple per day?). Still low-frequency. But a use-case which is very very business-relevant (many customers are asking for this).

Regarding the proposed URL schema...

Just to clarify: I do not wanted to propose that routes (I think we could carry the argument(s) differently).

However, yes, we simply just a delivered a list/array of serialized payloads. Worked very good. May be we have to consider a cursor. I am not aware of such standard.

[aorzelskiGH]

Thank you for restarting the work and discussion of AAS events.

I also think that the Part 1 events shall be technology agnostic, which was always our intention.
At the same time we need to be able to add technology specific parameters in the AAS, e.g. for HTTP REST, MQTT, OPC UA.

In the AASX Server proof of concept we decided to use HTTP REST to be able to work cross company including company proxys. It has been proven that it works well, e.g. Package Explorer inside the company networks and severs on outside endpoints. Such proxy support is a must, I think.

Some companies do not allow e.g. MQTT or OPC UA in their overall IT networks. This was another reason to first prove a HTTP REST based approach.

HTTP REST also allows to use the security in the same way as for the standard HTTP REST API. This will need security mapping for e.g. MQTT or OPC UA. This fully fits with specification work in the task force security. A JWT token with claims can be checked by the access rules on the AAS server.

There is a further security topic. Messages shall not and are not allowed to be broadcasted to all business partners. A business partner shall only receive events for data which he is allowed to see and access. Company 1 shall not receive messages of company 2. This has been tested and confirmed with the HTTP REST proof of concept.

Conclusion:

• Make part 1 definition technology agnostic
• Allow different technologies for implementation (it is good to have already 3 base implementations)
• Maybe define a revised HTTP REST API first already having e.g. MQTT and OPC UA in mind for a next step

[sebbader-sap]

I have significant concerns for an event-based communication via HTTP. I am not aware of any enterprise-grade application that does so, and that's for good reasons.
Other approaches based on WebSockets, MQTT, AMQP, gRPC ... are way better suited. With events, we have reached the limits of an HTTP API, and need to introduce the next protocol binding.
Following the separation of concerns, let's not mix the state-based view of the current HTTP API with events. It will introduce so many design problems that we all have to solve (and implement!) in custom manners, while perfectly fitting stuff is already out there.

[sebbader-sap]

As I don't imagine that there will be only one event- or message-based communication pattern for AAS-information, I propose we tackle the topic on two levels:

1. "Logical" level (or "metamodel" level): What is needed to describe that something has happened? With further information like time of occurrence, time of measurement, ...

• for events on assets (e.g. machine broke down or material arrived at a site)
• and for events on Identifiables (Submodel has been created or modified)

2. "Protocol" level (or "communication" level): What is needed to exchange any kind of object from 1? Endpoints, protocols, topics, delivery insurance etc.