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(): bool: Synchrone Polling-API der Skeleton-Basisklasse zur Triggerung der Bearbeitung der nächsten anstehenden Methoden-Nachricht (gibt direkt bool zurück).
• 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 ProcessNextMethodCall(): bool an ara::com auf.
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 keine Antwortnachricht erzeugt und der Polling-Aufruf liefert direkt synchron false zurück.
   • Pfad [available]:
     • ara::com ruft die gepufferten serialisierten Daten mittels GetMessage: serializedData von Reception ab.
     • ara::com verarbeitet den ungeschützten Header über ProcessNonProtectedHeader(serializedData).
     • Validierung des E2E-Schutzes mittels E2E_check(dataID, sourceID, messageType, messageResult, serializedData): Result.
     • Verzweigung alt Result of E2E_check is okay:
       • Pfad [Result != P_ERROR] (Erfolg):
         • ara::com verarbeitet den E2E-geschützten Header (ProcessE2EProtectedHeader(serializedData)).
         • Deserialisierung der Nutzdaten über Deserialize(serializedData): arg1, ..., argN.
         • Dispatching an die Skeleton-Methodenimplementierung via skeletonMethod.<method name>(arg1, ..., argN): ara::core::Future<MethodOutput>.
       • Pfad [Result == P_ERROR] (Fehlerfall):
         • ara::com benachrichtigt die Server-Applikation über den registrierten Fehler-Handler via E2EErrorHandler(errorCode, dataID, messageCounter).
         • Die Servicemethode wird nicht aufgerufen.
4. Abschluss:
   • Der synchrone Aufruf ProcessNextMethodCall() kehrt mit einem booleschen Statuswert (true bei erfolgreicher Bearbeitung) zur Server application zurück.

4. Normative Relevanz & Entwickler-Hinweise

• Synchrone Polling-Semantik: Die Umstellung von ProcessNextMethodCall() von ara::core::Future<bool> auf synchrones bool eliminiert den asynchronen Future-Overhead. Die Server-Applikation erhält das Resultat der Abfrage (true = Nachricht abgearbeitet, false = keine Nachricht vorhanden) unmittelbar im aufrufenden Thread.
• Verhalten bei Pufferleerstand: Die linke Hinweisbox präzisiert normativ, dass bei Nichtvorhandensein von Nachrichten ProcessNextMethodCall() direkt false zurückgibt, keine Antwortnachricht generiert wird und kNoNewData an den E2EErrorHandler gemeldet wird („In case no messages are available, i.e. ProcessNextMethodCall() returns false, no response message is created, and kNoNewData is reported.“).
• Bedarfsgesteuerter Abruf: Der Abruf der serialisierten Daten (GetMessage) erfolgt nun erst innerhalb des [available]-Zweigs der Fallunterscheidung statt vorab vor der Pufferprüfung.
• E2E-Validierung & Fehlerbehandlung: Die E2E-Prüfung erfolgt synchron innerhalb von ProcessNextMethodCall(). Bei Prüffehler (P_ERROR) wird die Applikationsmethode nicht aufgerufen und stattdessen der registrierte E2EErrorHandler getriggert.
• Antwortschutz: Unverändert gilt, dass jede Antwort (Response oder Error) auf einen E2E-geschützten Methodenaufruf selbst zwingend E2E-geschützt übertragen werden muss.