Figure 7.23: Interaction of components during E2E checking of the Method response at the client side

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm mit kombinierten Fragmenten (alt-Blöcke für bedingte Verzweigungen).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Communication Management (ara::com).
• Technischer Zweck: Spezifikation des clientseitigen Ablaufs beim Empfang, der E2E-Validierung (End-to-End-Protection) und der Bereitstellung der Antwort (Method Response) eines synchronen/asynchronen Methodenaufrufs. Zeigt die Interaktion zwischen Applikationsschicht, Middleware (ara::com-Service-Proxy) und Transportschicht/Empfangsinstanz (Reception).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • Client application: Adaptive Application (AA), die als Service-Consumer (Proxy-Instanz) eine Methode aufgerufen hat und auf das Methoden-Ergebnis wartet.
  • ara::com: Service-Orientierte Middleware-Laufzeitumgebung (generierter Client-Proxy & Binding-Implementierung, z. B. SOME/IP-Binding mit E2E-Transformator).
  • Reception: Unterlagerter Transport-/Netzwerkstack (z. B. Socket-Handler, PDU-Router / IPC / Binding-Empfangsthread).
• Objekte & Datenstrukturen:
  • Output: Instanz eines Asynchronie-Primitivs (ara::core::Promise / ara::core::Future), das das Rückgabeobjekt kapselt (ara::core::Result<OutputData, ara::core::ErrorCode>).
  • serializedData: Rohdatenstrom des Netzwerk-Frames (Header + Payload).
  • SMState: Globaler Zustand der E2E-Zustandsmaschine (State Machine State, z. B. E2E_SM_VALID, E2E_SM_DEBOUNCED, E2E_SM_INVALID).
  • Result: E2E-Prüfstatus (ProfileCheckStatus, z. B. P_OK, P_ERROR, P_REPEATED, P_WRONGSEQUENCE).
• Schnittstellen & Operationen:
  • GetResult(): Output: Client-API zur Rückgabe des Future-Objekts bzw. Abfrage des Methoden-Ergebnisses.
  • GetMessages(): serializedData: Interne Schnittstelle zum Abholen gepufferter Netzwerkdaten.
  • E2E_check(dataID, sourceID, messageType, messageResult, serializedData): Core-E2E-Algorithmus zur Integritäts- und Zählerprüfung.
  • GetSMState: Proxy-API zur Abfrage des aktuellen E2E-Zustandsmaschinen-Status.

3. Dynamisches Verhalten & Sequenzablauf

1. Anforderung & Empfang:
   • Client application fordert das Ergebnis via GetResult() an; ara::com delegiert an Reception (GetMessages()).
   • Reception synchronisiert/blockiert via wait for response (Future) bis zur Verfügbarkeit des Netzwerkpakets und liefert serializedData an ara::com zurück.
2. Kombiniertes Fragment alt new method response (E2E-Validierung durch ara::com):
   • Header-Vorverarbeitung: ProcessNonProtectedHeader(serializedData) extrahiert ungeschützte Transportinformationen.
   • Zähler-Kompensation: set meesage counter to sent message counter -1 synchronisiert die Sequenznummer-Erwartungshaltung mit der zuvor gesendeten Anfrage.
   • E2E-Prüfung: E2E_check(...) prüft CRC, Message Counter, Data ID, Source ID und Message Type/Result gegen die E2E-Header-Werte und erzeugt Result.
3. Kombiniertes Fragment alt handle ProfileCheckStatus:
   • Zweig [Result == P_OK]:
     • ProcessE2EProtectedHeader(serializedData): Verarbeitet geschützte Metadaten.
     • Deserialize(serializedData): data: Extrahiert die typisierten Out-Parameter/Rückgabewerte.
     • Output.setvalue(data): Erfüllt den Promise mit Nutzdaten (ara::core::Result enthält Wert).
   • Zweig [Result != P_OK]:
     • Output.setError(error_code(Result)): Schlägt den Promise fehl (ara::core::Result enthält ComErrorDomain-Fehlercode basierend auf dem E2E-Prüffehler).
   • Status-Persistierung: Store Result in global SMState aktualisiert die zugehörige E2E-Zustandsmaschine.
   • Rückkehr des Kontrollflusses an die Applikation.
4. Applikationsseitige Auswertung:
   • Client application fragt optional den Zustand über GetSMState ab.
5. Kombiniertes Fragment alt handle result (Applikationsebene):
   • Zweig [Received Error Domain]: Aufruf von process Error Domain (Fehlerbehandlung bei E2E-Verletzung oder Kommunikationsfehler).
   • Zweig [Received Data]: Aufruf von Access data (reguläre Verarbeitung der Methodenantwort).

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (ara::core::Future / ara::core::Result):
  • E2E-Prüffehler bei Methodenantworten werden nicht stillschweigend verworfen, sondern führen zwingend zu einem gesetzten Fehlerstatus im Promise/Future-Rückgabewert (Output.setError).
  • Die Applikation darf nach Auflösung des Future nicht ungeprüft auf Daten zugreifen, sondern muss das ara::core::Result via .HasValue() oder Fehlerdomänenabfrage (.Error()) validieren.
• Zustandsbehaftung (E2E State Machine):
  • E2E-Profile bei Methoden (Request/Response) aktualisieren die E2E-Zustandsmaschine (SMState) des Proxy. Ein einzelner P_ERROR triggert je nach Konfiguration des Debouncings (WindowSize, MinOkState, MaxErrorState) nicht sofort einen ungültigen Gesamtzustand (E2E_SM_INVALID).
• Serialisierung & Binding-Einschränkung:
  • Die Deserialisierung der Payload findet normativ erst nach erfolgreicher E2E-Integritätsprüfung (Result == P_OK) statt. Dies verhindert Pufferüberläufe oder Typfehler durch korrumpierte Nutzdaten auf Stack-Ebene (Defense in Depth).