Figure 7.22: Interaction of components during E2E protection of the Method response at the server side

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm mit kombinierten Fragmenten alt).
• Architektur-Kontext: AUTOSAR Adaptive Platform (ara::com / Communication Management), Release R25-11.
• Technischer Zweck: Spezifikation des serverseitigen Ablaufes zur E2E-Absicherung (End-to-End Protection nach ISO 26262) von Methodenantworten (Method Responses). Das Diagramm definiert das Zusammenspiel zwischen E2E-Prüfergebnis der eingehenden Request-Nachricht, Ausführung/Fehlerbehandlung in der Server-Applikation und der anschließenden E2E-Serialisierung und Paketierung vor dem Versand.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Entitäten (Lebenslinien)

• Server application: Adaptive Application (Server-Kontext), welche die generierte Skeleton-Klasse instanziiert, die Geschäftslogik implementiert und optionale E2E-Fehler-Callbacks registriert.
• ara::com: Middleware-Laufzeitumgebung (Communication Management Daemon / Binding / Skeleton-Infrastruktur), die Request-Dispatching, E2E-Validierung, E2E-Schutzberechnung sowie Serialisierung kapselt.
• Reception: Kommunikations- und Transportschicht (IPC / SOME/IP-Binding / Netzwerk-Interface-Stack), zuständig für den physischen Nachrichtentransfer.

Schnittstellen & Funktionsaufrufe

• skeletonMethod.<method name>(arg1, ..., argN): ara::core::Future<MethodOutput>: Synchroner Aufruf der Applikationsmethode durch das Skeleton. Die Rückgabe erfolgt asynchron über ein ara::core::Future-Objekt.
• Promise.set_value(output) / Promise.set_error(error_code): Methoden von ara::core::Promise zur Bereitstellung des regulären Returnwerts oder eines anwendungsspezifischen ara::core::ErrorCode (ApApplicationErrorDomain).
• E2EErrorHandler(errorCode, dataID, messageCounter): Registrierter Fehler-Callback auf Serverebene zur Notifikation über E2E-Prüffehler des eingehenden Requests (gemäß SWS_CM_10472).
• Interne Stack-Operationen (ara::com):
  • Serialize(output | error_code): serializedData
  • AddE2EProtectedHeader(serializedData)
  • E2E_protect(dataID, sourceID, messageType, messageResult, messageCounter, serializedData)
  • AddNonProtectedHeader(serializedData)
• SendMessage(serializedData): Übergabe des vollständig geschützten Serialisats an das Transport-Layer.

3. Dynamisches Verhalten & Sequenzablauf

Das Verhalten gliedert sich in zwei Phasen: Verzweigung nach E2E-Prüfstatus des Requests und anschließende obligatorische E2E-Antwortabsicherung.

Phase 1: Auswertung des Request-E2E-Checks (alt Result of E2E_check is okay)

1. Regulärer Pfad [Result != P_ERROR]:
   • Der eingehende Methodenaufruf bestand die E2E-Prüfung (E2E_check lieferte OK oder einen tolerierten Zustand).
   • ara::com ruft die Skeleton-Methode der Server-Applikation auf.
   • Sub-Fragment [success]: Die Applikation schließt die Berechnung erfolgreich ab und setzt den Rückgabewert via Promise.set_value(output).
   • Sub-Fragment [error]: Bei logischen Fehlern setzt die Applikation einen Fehlercode via Promise.set_error(error_code).
2. Fehlerpfad [Result == P_ERROR]:
   • Der Request war ungültig/korrupt (CRC-Fehler, Counter-Fehler, Timeout, DataID-Mismatch).
   • Die Skeleton-Methode wird nicht ausgeführt.
   • ara::com triggert den E2EErrorHandler(errorCode, dataID, messageCounter) der Applikation, um den Fehler zu protokollieren bzw. den Sicherheitsstatus zu aktualisieren.

Phase 2: Generierung und Versand der E2E-Antwort (Normative Invariante)

• Gemäß UML-Notiz gilt: Jede Antwort (reguläre Response wie auch Applikations- oder Protokollfehler) auf einen E2E-geschützten Request muss zwingend selbst E2E-geschützt werden.

1. Serialisierung: ara::com serialisiert entweder den Payload (output) oder den error_code in serializedData.
2. E2E-Header-Injektion: Hinzufügen des geschützten Headers (AddE2EProtectedHeader).
3. E2E-Absicherung: Berechnung der Schutzdaten via E2E_protect unter Verwendung von:
   • dataID: Eindeutige Kennung des Response-Datenstroms.
   • sourceID: Instanz-/Client-/Server-Identifikator.
   • messageType: Klassifizierung (Request / Response / Error).
   • messageResult: Statusfeld (OK vs. Application Error).
   • messageCounter: Inkrementeller Zähler zur Erkennung von Loss/Replay.
   • serializedData: Nutzdaten inklusive E2E-Header.
4. Transport-Header: Hinzufügen von ungeschützten Protokoll-Headern (z. B. SOME/IP-Header, Message Type, Session ID).
5. Dispatch: Übergabe an den Transportlayer via SendMessage(serializedData).

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (Applikationsentwickler):
  • Methoden mit E2E-Schutz müssen non-blocking über ara::core::Future / ara::core::Promise realisiert werden.
  • Tritt ein E2E-Fehler auf Request-Ebene auf (P_ERROR), wird die eigentliche Methode nie aufgerufen. Sicherheitsrelevante Zustände müssen bei Bedarf über den E2EErrorHandler-Callback synchronisiert werden (SWS_CM_10472).
• Stack- und Binding-Entwickler (SOME/IP, IPC, E2E-Library):
  • E2E-Profile (z. B. Profile 04, 07, 22) für Methods erfordern separate Schutzparameter für Request und Response (u. a. symmetrische oder versetzte dataIDs gemäß Service-Interface-Deployment).
  • Serialisierte Fehlermeldungen (ara::core::ErrorCode) müssen das gleiche E2E-Layout durchlaufen wie reguläre Payload-Daten (SWS_CM_10312, RS_E2E_08541).
  • messageCounter muss threadsicher je Server-Methoden-Instanz verwaltet und bei jeder Antwort monoton inkrementiert werden.
• Konfiguration (ARXML / Manifest):
  • Für das Methoden-Deployment (SomeipMethodDeployment) muss E2E-Protection explizit für die Response konfiguriert sein (EndToEndTransformationDescription). Fehlt die Response-Konfiguration, wird die Antwort ohne E2E-Trailer/Header übertragen, was bei aktiver Client-E2E-Erwartung zu einem Kommunikationsabbruch führt.