Figure 7.21: Interaction of components during E2E checking of the Method request at the server side - event driven

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm mit kombinierten Fragmenten alt).
• Architektur-Kontext: AUTOSAR Adaptive Platform (ARA), Spezifikation SWS Communication Management (ara::com).
• Funktionale Einordnung: Serverseitige End-to-End-Absicherung (E2E-Protection) bei synchronen/asynchronen Methodenaufrufen (Client/Server-Kommunikation) im ereignisgesteuerten Ausführungsmodus (event-driven execution). Es definiert die Validierungs- und Dispatch-Pipeline von der Rohdatenannahme über die kryptografische/integritätsbezogene Prüfung bis zur Weiterleitung an die Skeleton-Methode der Server-Applikation.

2. Komponenten, Entitäten & Schnittstellen

• Lifelines / Entitäten:
  • Reception: Unterlagerter Transport- und Dispatch-Mechanismus (Binding-spezifisch, z. B. SOME/IP-Binding / IPC-Treiber / POSIX-Sockets), der eingehende serialisierte Pakete puffert und signalisiert.
  • ara::com: Middleware-Laufzeitschicht (Service Skeleton Binding / Runtime), die Header parst, E2E-Zustände auswertet, Deserialisierung durchführt und API-Objekte instanziiert.
  • Server Application: Domänenspezifische Applikationsschicht, die die konkrete Service-Implementierung (skeletonMethod) und E2E-Fehlerbehandlungs-Hooks (E2EErrorHandler) bereitstellt.
• Schnittstellen & Datenstrukturen:
  • MessageReception(serializedData) / GetMessage: serializedData(): Interne Binding-Schnittstelle zur asynchronen Benachrichtigung und zum synchronen Abruf des Byte-Streams (serializedData()).
  • ProcessNonProtectedHeader(serializedData): Extraktion von Transport-Headern (z. B. SOME/IP-Header: Message ID, Client ID, Session ID, Protocol Version, Message Type).
  • E2E_check(dataID, sourceID, messageType, messageResult, serializedData): Result: Standardisierter E2E-Prüfaufruf (State-Machine/CRC/Counter-Prüfung gemäß konfiguriertem E2E-Profil).
  • ProcessE2EProtectedHeader(serializedData): Parsen der E2E-geschützten Header-Anteile nach validierter Prüfsumme/Sequenz.
  • Deserialize(serializedData): arg1, ..., argN: Typisierte Rekonstruktion der Methodenargumente aus der Nutzlast.
  • skeletonMethod.<method name>(arg1, ..., argN): ara::core::Future<MethodOutput>: Typisierte C++14/C++17-Methoden-Signatur des generierten Service-Skeletons. Gibt ein ara::core::Future zur asynchronen Rückgabe des Ergebnisses zurück.
  • E2EErrorHandler(...): Callback-Schnittstelle zur Meldung von E2E-Integritätsverletzungen an die Server-Applikation.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger & Datenabruf:
   • Reception meldet über MessageReception(serializedData) ein eingegangenes Paket ereignisgesteuert an ara::com.
   • ara::com ruft mittels synchronem GetMessage die Rohdaten via serializedData() ab.
2. Header-Verarbeitung & E2E-Prüfung:
   • ara::com parst zunächst ungeschützte Metadaten via ProcessNonProtectedHeader(serializedData).
   • Unmittelbar darauf führt ara::com den Integritäts-Check E2E_check(dataID, sourceID, messageType, messageResult, serializedData): Result aus.
3. Verzweigung – E2E-Prüfergebnis (alt Result of E2E_check is okay):
   • Zweig [Result != P_ERROR] (Erfolg / tolerierbarer Status):
     • ara::com parst geschützte Header-Elemente (ProcessE2EProtectedHeader(serializedData)).
     • ara::com deserialisiert die Methodenparameter (Deserialize(serializedData): arg1, ..., argN).
     • Aufruf der konkreten Skeleton-Methode skeletonMethod.<method name>(arg1, ..., argN). Die Server-Applikation nimmt den Methodenaufruf entgegen und liefert ein ara::core::Future<MethodOutput>.
   • Zweig [Result == P_ERROR] (Integritäts-, Counter- oder ID-Fehler):
     • Abbruch der Methodenverarbeitung: Kein Deserialisieren, kein Methodenaufruf.
     • Aufruf von E2EErrorHandler(errorCode, dataID, messageCounter) zur Fehlerbehandlung durch die Server-Applikation.
4. Terminierung / E2E-Symmetrie:
   • Nach Abschluss der Verarbeitung quittiert ara::com die Interaktion gegenüber Reception über die Rückkehr-Nachricht.
   • Jede resultierende Antwortnachricht (sowohl normale RESPONSE als auch protokollierte ERROR-Antwort) auf einen E2E-geschützten Request muss vor dem Senden zwingend selbst E2E-geschützt werden (Normative Notiz im Diagramm).

4. Normative Relevanz & Entwickler-Hinweise

• Zero-Trust vor E2E-Validierung: Applikations-Code und Deserialisierungslogik sind strikt vor korrupten Payloads geschützt. Solange Result == P_ERROR, findet keine Argumenten-Deserialisierung statt (Schutz vor Buffer-Overflows und Fehlallokationen bei beschädigten Längenfeldern).
• ASIL/Sicherheitsrelevanz:
  • Der Status P_ERROR umfasst ungültige CRCs, Sequenznummernfehler (Replay-Angriffe) oder falsche dataID/sourceID.
  • Das Flag Result != P_ERROR bedeutet, dass E2E-Status wie OK oder konfigurierte Initial-/Sync-Zustände vorliegen; Entwickler müssen im Skeleton sicherstellen, ob die E2E-State-Machine für den spezifischen ASIL-Level ausreichend initialisiert ist.
• API- und Threading-Modell:
  • Der Methodenaufruf erfolgt asynchron über ara::core::Future/ara::core::Promise. Langläufer-Methoden dürfen den ara::com-Empfangs-Thread nicht blockieren.
  • E2EErrorHandler muss als deterministischer, nicht-blockierender Callback implementiert sein, um DoS-Zustände im Event-Loop des Kommunikations-Bindings zu verhindern.
• Konfigurations-Fokus (ARXML):
  • Entwickler müssen E2E-Profile (EndToEndTransformationDescription, EndToEndTransformationComSpecProps) konsistent zwischen Server und Client parametrieren (DataID, Counter-Offset, CRC-Offset, Header-Layout).
  • Bei aktivierter E2E-Methodenabsicherung muss die Antwortstrecke spiegelbildlich für denselben Service-Interface-Deployment-Pfad E2E-konfiguriert sein.