Figure 7.20: Interaction of components during E2E checking of the Method request at the server side - polling

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm) mit kombinierten Fragmenten (alt-Blöcke für Fallunterscheidungen) und asynchronen/synchronen Nachrichtenflüssen.
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Communication Management (ara::com), Spezifikationsdokument AUTOSAR_AP_SWS_CommunicationManagement (Sektion End-to-End Communication / E2E Protection).
• Technischer Zweck: Spezifikation der serverseitigen Abarbeitung eingehender, E2E-geschützter Methodenaufrufe (Request-Response oder Fire-and-Forget) im Polling-Modus (ara::com::MethodCallProcessingMode::kPoll). Das Diagramm definiert den Ablauf von Pufferabfrage über E2E-Validierung bis hin zum Dispatch an die Skeleton-Methodenimplementierung bzw. Fehlerbehandlung via Callback.

2. Komponenten, Entitäten & Schnittstellen

Beteiligte Lebenslinien (Akteure & Schichten):

• Server application: Adaptive Application (AA), implementiert die Diensterbringung auf Basis der generierten Skeleton-Klasse (skeletonMethod.<method name>) sowie den registrierten E2EErrorHandler.
• ara::com: Middleware-Laufzeitumgebung / Skeleton-Infrastruktur. Übernimmt E2E-Header-Parsing, E2E-Prüflogik, Deserialisierung und Dispatching.
• Reception: Unterlagerte Transport- und Bindungsschicht (z. B. SOME/IP-Binding, IPC, BSD Sockets/Transport Adapter), welche eingehende Datagramme puffert.

Schnittstellen, Signaturen & Datenstrukturen:

• ProcessNextMethodCall(): ara::core::Future<bool>: Polling-API der Skeleton-Basisklasse zur expliziten Triggerung der Bearbeitung der nächsten anstehenden Methoden-Nachricht.
• MessageReception(serializedData): Asynchroner Ingress-Trigger der Transportbindung bei Paketempfang.
• GetMessage: serializedData: Abruf der rohen Bytefolge (serializedData) aus dem Empfangspuffer.
• ProcessNonProtectedHeader(serializedData): Parsing transportrelevanter Metadaten (z. B. Session ID, Protocol Version, Length, Interface/Method ID).
• E2E_check(dataID, sourceID, messageType, messageResult, serializedData): Result: Aufruf der normativen E2E-Bibliothek zur Prüfung von Prüfsumme (CRC), Message Counter und Alive Counter.
• ProcessE2EProtectedHeader(serializedData): Extraktion geschützter E2E-Header-Felder vor Payload-Zugriff.
• Deserialize(serializedData): arg1, ..., argN: Deserialisierung der Nutzdaten in typisierte C++-Parameter.
• skeletonMethod.<method name>(arg1, ..., argN): ara::core::Future<MethodOutput>: Aufruf der konkreten Implementierung der Servicemethode in der Applikation.
• E2EErrorHandler(errorCode, dataID, messageCounter): Applikativer Fehler-Callback bei E2E-Fehlern (Result == P_ERROR) oder ausbleibenden Nachrichten (kNoNewData, 0, 0).

3. Dynamisches Verhalten & Sequenzablauf

1. Paketeingang (Hintergrund):
   • Reception nimmt serialisierte Daten über das Netzwerk/IPC entgegen (MessageReception(serializedData)) und legt sie in einer Bindungs-Queue ab.
2. Aktivierung durch Applikation:
   • Server application ruft synchron/asynchron ProcessNextMethodCall() an ara::com auf.
   • ara::com fragt die Bindungsebene via GetMessage nach Daten ab.
3. Verzweigung alt Message available:
   • Pfad [not available]:
     • ara::com signalisiert der Applikation das Fehlen neuer Daten über den Callback E2EErrorHandler(kNoNewData, 0, 0).
     • Es wird explizit keine Antwortnachricht generiert oder versendet.
   • Pfad [available]:
     • ara::com parst den ungeschützten Header (ProcessNonProtectedHeader).
     • ara::com führt die E2E-Prüfung aus: E2E_check(dataID, sourceID, messageType, messageResult, serializedData).
4. Verzweigung alt Result of E2E_check is okay:
   • Pfad [Result != P_ERROR] (Erfolg / tolerierbarer Status):
     • ara::com liest den E2E-geschützten Header aus (ProcessE2EProtectedHeader).
     • Deserialisierung der Argumente: Deserialize(...) -> arg1, ..., argN.
     • Methodenaufruf an die Applikation: skeletonMethod.<method name>(arg1, ..., argN). Die Applikation liefert ein ara::core::Future<MethodOutput> zurück.
   • Pfad [Result == P_ERROR] (Kritischer E2E-Fehler, z. B. CRC-Mismatch, Counter-Sprung):
     • ara::com bricht den Methoden-Dispatch ab.
     • Aufruf von E2EErrorHandler(errorCode, dataID, messageCounter) zur Benachrichtigung der Server-Applikation.
5. Abschluss & Return:
   • Der initiale Methodenaufruf ProcessNextMethodCall() wird abgeschlossen und gibt ara::core::Future<bool> an die Server-Applikation zurück (signalisiert true, wenn eine Nachricht abgearbeitet wurde, sonst false).

4. Normative Relevanz & Entwickler-Hinweise

• Threading & Ausführungsmodell: Bei Konfiguration auf kPoll erfolgen Deserialisierung, E2E-Prüfung und Methoden-Dispatch im Thread-Kontext, der ProcessNextMethodCall() ausführt. Der Entwickler kontrolliert damit Jitter und CPU-Budget des Methodenaufrufs vollständig selbst.
• E2E-Fehlersemantik (P_ERROR): Im Fehlerfall darf die Skeleton-Methode niemals aufgerufen werden. Die Applikation muss über den registrierten E2EErrorHandler auf Fehlerzustände (z. B. degraded mode, Safe State, Zählerstände) reagieren.
• Symmetrische E2E-Schutzpflicht: Jede ausgehende Antwort (MethodOutput oder ApApplicationErrorDomain-Fehler) auf eine E2E-geschützte Anfrage muss zwingend selbst E2E-geschützt werden (Normativer Hinweis: „Any response (ERROR or normal RESPONSE) to an E2E protected request shall be E2E protected itself“).
• Verhalten bei Pufferleerstand (kNoNewData): Führt der Polling-Aufruf zu keinem Treffer im Eingangspuffer, triggert die Middleware den E2EErrorHandler mit Fehlercode kNoNewData und Null-Parametern (0, 0). Es erfolgt keine Netzwerkreaktion.