Figure 7.8: Interaction of components during E2E check

1. Diagrammtyp & Architektur-Kontext

UML-Sequenzdiagramm (sd Subscriber) zur Darstellung der Interaktion von Komponenten während der End-to-End-Absicherung (E2E-Check) bei Methodenaufrufen im AUTOSAR Adaptive Platform Communication Management (ara::com). Das Diagramm illustriert den Ablauf für Server-Skelette sowohl im ereignisgesteuerten Modus (kEvent / kEventSingleThread) als auch im Polling-Modus (kPoll) einschließlich E2E-Validierung, Methodenverarbeitung und E2E-geschützter Antwortgenerierung.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm definiert drei funktionale Instanzen (Lebenslinien):

• Server application: Anwendungsinstanz des Servers, die den E2E-Fehler-Handler registriert (RegisterE2EErrorHandler), Methoden implementiert (skeletonMethod.<method name>) und Fehlermeldungen bei E2E-Fehlern empfängt.
• ara::com: Laufzeitumgebung der Service-orientierten Kommunikation im Adaptive AUTOSAR System. Sie koordiniert Header-Verarbeitung, E2E-Prüfung (E2E_check), Deserialisierung, Methodenaufruf-Dispatching, Serialisierung, E2E-Schutz (E2E_protect) sowie Promise/Future-Synchronisation.
• Reception: Untergeordnete Empfangsschicht bzw. Transport-/Netzwerkschnittstelle, die serialisierte Daten empfängt (MessageReception), gepufferte Nachrichten bereitstellt (GetMessage) und serialisierte Antwortnachrichten versendet (SendMessage).

Schnittstellen und Operationen umfassen:

• skeletonMethod.RegisterE2EErrorHandler(e2e_error_handler)
• MessageReception(serializedData) / GetMessage: serializedData / SendMessage(serializedData)
• ProcessNextMethodCall : Future(bool) / Future(true) / Future(false)
• E2EErrorHandler(errorCode, dataID, messageCounter) (bzw. E2EErrorHandler(NoNewDta, dataID, 0))
• ProcessNonProtectedHeader(&serializedData) / ProcessE2EProtectedHeader(&serializedData)
• E2E_check(dataID, &serializedData): Result / E2E_protect(dataID, messageCounter, serializedData)
• Deserialize(&serializedData): arg1, ..., argN / Serialize(output | error_code): serializedData
• skeletonMethod.<method name>(arg1, ..., argN): ara::core::Future<MethodOutput>
• Promise.set_value(output) / Promise.set_error(error_code) / Promise.set_error(error_code (Repeated | WrongSequence | Error))
• AddE2EProtectedHeader(&serializedData) / AddNonProtectedHeader(&serializedData)

3. Dynamisches Verhalten & Sequenzablauf

Der Ablauf gliedert sich in folgende Phasen:

1. Initialisierung: Die Server application registriert über skeletonMethod.RegisterE2EErrorHandler(e2e_error_handler) den E2E-Fehlerbehandler bei ara::com.
2. Nachrichtenempfang nach Verarbeitungsmodus (alt ProcessingMode):
   • Zweig [kEvent | kEventSingleThread]: Bei ereignisgesteuertem Betrieb übergibt die Schicht Reception eingehende Nachrichten über MessageReception(serializedData) direkt an ara::com.
   • Zweig [kPoll]: Die Server application ruft synchron ProcessNextMethodCall : Future(bool) auf. ara::com fragt die Schicht Reception mittels GetMessage: serializedData ab. Innerhalb von alt Message available liefert ara::com bei Vorhandensein ([available]) Future(true) zurück. Liegt keine Nachricht vor ([not available]), wird E2EErrorHandler(NoNewDta, dataID, 0) an der Server application aufgerufen, gefolgt von Future(false); es wird keine Antwortnachricht generiert.
3. Vorverarbeitung und E2E-Prüfung: ara::com verarbeitet den ungeschützten Header (ProcessNonProtectedHeader(&serializedData)) und führt die E2E-Prüfung aus (E2E_check(dataID, &serializedData): Result).
4. Auswertung des Prüfergebnisses (alt Result of E2Echeck is okay):
   • Zweig [P_OK]: ara::com verarbeitet den geschützten Header (ProcessE2EProtectedHeader(&serializedData)), deserialisiert die Argumente (Deserialize(&serializedData): arg1, ..., argN) und ruft die Methode auf der Server application auf (skeletonMethod.<method name>(arg1, ..., argN)). Innerhalb von alt method result setzt die Anwendung je nach Ausführungsausgang entweder Promise.set_value(output) ([success]) oder Promise.set_error(error_code) ([error]) und gibt ein Future an ara::com zurück.
   • Zweig [P_ERROR]: Bei fehlgeschlagener Prüfung ruft ara::com den Handler E2EErrorHandler(errorCode, dataID, messageCounter) auf der Server-Anwendung auf und setzt intern Promise.set_error(error_code (Repeated | WrongSequence | Error)) mit dem Fehlercode der E2EError-Domäne.
5. Serialisierung, E2E-Absicherung und Versand: Sowohl bei erfolgreicher Methodenverarbeitung als auch bei Fehlern (Anwendungs- oder E2E-Fehler) serialisiert ara::com Nutzdaten bzw. Fehlercode (Serialize(output | error_code): serializedData), fügt geschützte Header an (AddE2EProtectedHeader(&serializedData)), sichert die Nachricht via E2E_protect(dataID, messageCounter, serializedData) ab, ergänzt nicht-geschützte Header (AddNonProtectedHeader(&serializedData)) und sendet das Paket über SendMessage(serializedData) an die Schicht Reception.

4. Normative Relevanz & Entwickler-Hinweise

• Symmetrische E2E-Absicherung von Responses: Jede Antwort (reguläre Response oder Fehlermeldung) auf eine E2E-geschützte Anfrage muss selbst E2E-geschützt werden (E2E_protect).
• Verhalten bei Polling ohne Nachricht: Wenn im Polling-Modus keine Nachricht abholbar ist, wird der Fehlerhandler mit NoNewDta (E2EErrorHandler(NoNewDta, dataID, 0)) aufgerufen; es wird keine Antwortnachricht erzeugt oder gesendet.
• E2E-Fehlerbehandlung: Erkennt ara::com einen E2E-Fehler (P_ERROR), wird der Anwendungs-E2EErrorHandler mit Parametern errorCode, dataID und messageCounter informiert. Zudem wird eine Fehlernachricht erzeugt, deren ErrorDomain auf E2EError gesetzt ist; der konkrete Fehlercode richtet sich nach dem E2E-Ergebnis (Repeated, WrongSequence, Error).
• Architekturhinweis: Im Kopfbereich des Diagramms lautet der Diagrammtitel fälschlicherweise sd Subscriber, obwohl inhaltlich und anhand der Lebenslinien (Server application) die Service-Skelett- bzw. Server-Empfangsseite modelliert ist.