Figure 7.17: Receive response to a SET Message

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm) mit kombinierten Fragmenten (alt) zur bedingten Ausführung.
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Spezifikation Communication Management (ara::com), Release R21-11.
• Technischer Zweck: Spezifikation des asynchronen Empfangs-, Prüf- und Deserialisierungspfads einer Antwortnachricht (Response) auf einen Field.Set()-Aufruf (Method Call auf ein Field mit Setter-Funktionalität) unter Einbindung von End-to-End-(E2E)-Schutzmechanismen und der E2E-Zustandsüberwachung.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Lifelines:
  • Client Application: Adaptive Application (Service Consumer), die über das generierte Proxy-Interface der Service-Instanz agiert.
  • ara::com: Adaptive Middleware-Laufzeitschicht (Service-Proxy-Binding-Implementierung inkl. E2E-State-Machine, PDU-Verarbeitung, Promise/Future-Verwaltung).
  • Transmission: Transport- und Protokollbindungsschicht (z. B. SOME/IP Daemon, Netzwerk-Stack über Ethernet/IPC).
• Interaktionspunkte & Datenstrukturen:
  • Field.Set(): Asynchrone Setter-Methode des Proxies; instanziiert und liefert unmittelbar ein ara::core::Future an die Applikation.
  • MessageReception() / GetMessage(serialized data): PDU-Empfangsindikation und Datenabruf des Bytestroms aus dem Transportpuffer.
  • Process non protected data() / Process E2E protected header(): Parsing ungeschützter (z. B. Basis-Routing-/Protokoll-Header) sowie kryptografisch/prüfsummen-geschützter Header-Anteile.
  • E2E_Check(): Validierung von Sequence Counter, CRC und Data-ID gemäß konfiguriertem E2E-Profil.
  • Output.setvalue(data) / Output.SetError(errorcode): Setzen des Ergebnisses bzw. des Fehlercodes im assoziierten ara::core::Promise.
  • Store result in SM state(): Zustandsaktualisierung in der internen E2E-Zustandsmaschine (ara::com::e2e::Result).
  • GetE2EStateMachineState(): Abfrage/Auswertung des E2E-Zustands durch die Applikation bzw. den Proxy.
  • process error domain() / process data(): Lokale Behandlungsroutinen in der Client-Applikation zur Differenzierung von Nutzdaten (ara::core::Result<T>) und Fehlern (ara::core::ErrorCode).

3. Dynamisches Verhalten & Sequenzablauf

1. Request-Phase (Asynchron):
   • Client Application initiiert Field.Set().
   • ara::com erzeugt das zugehörige ara::core::Future, gibt dieses synchron an die Applikation zurück und sendet den Request ab.
   • Entkopplung: Der Aufrufer wird nicht blockiert (Some time passes ...).
2. Empfangs- & Validierungs-Phase (Transmission → ara::com):
   • Transmission signalisiert den Eingang via MessageReception().
   • ara::com holt die serialisierten Rohdaten über GetMessage(serialized data) ab.
   • ara::com verarbeitet ungeschützte Metadaten (Process non protected data()) und führt E2E_Check() aus.
3. Verzweigung 1: Interner E2E-Check (alt [E2E check OK] / [E2E Error]):
   • Pfad [E2E check OK]:
     1. Geschützte Header werden interpretiert (Process E2E protected header()).
     2. Nutzdaten werden deserialisiert (Deserialize serialized data()).
     3. Ergebniswert wird im Promise gesetzt (Output.setvalue(data)).
   • Pfad [E2E Error]:
     1. Deserialisierung der Nutzdaten unterbleibt.
     2. E2E-Fehlercode wird im Promise hinterlegt (Output.SetError(errorcode)).
   • Der Status der E2E-Zustandsmaschine wird synchron aktualisiert (Store result in SM state()).
4. Verzweigung 2: Ergebnisabfrage & Applikationsreaktion (alt in Client Application):
   • Die Applikation fragt das Ergebnis bzw. den Status ab (GetE2EStateMachineState()).
   • Pfad [received message has type ERROR]: Der Server/Publisher hat bereits bei der Anfrage einen E2E-Fehler detektiert und eine standardisierte ERROR-Response übermittelt → Aufruf von process error domain().
   • Pfad [E2E error]: Lokaler E2E-Check auf Empfängerseite ist fehlgeschlagen → Daten werden verworfen; Client führt process error domain() aus (Reaktion obliegt der Anwendungslogik).
   • Pfad [no E2E error]: Das Future wechselt in den Zustand Ready → Der deserialisierte Rückgabewert wird ausgelesen und via process data() verarbeitet.

4. Normative Relevanz & Entwickler-Hinweise

• Deserialisierungsbarriere: Die Deserialisierung der Payload darf normativ erst nach erfolgreichem E2E_Check erfolgen. Dies schützt die Middleware und Applikation vor Speicherbeschädigungen (z. B. Buffer Overflows, fehlerhafte dynamische Längenfelder in Vektoren/Strings) durch verfälschte Pakete.
• E2E-State-Machine-Integration: Ein einzelner Prüfsummenfehler führt nicht zwingend sofort zum Applikationsabbruch. Die E2E-State-Machine aggregiert Prüfresultate über ein Schiebefenster (Store result in SM state()). Entwickler müssen prüfen, ob die Schnittstelle im Zustand Valid, Update_OK oder Update_Error betrieben wird.
• API-Vertrag (ara::core::Future / ara::core::Result):
  • Applikationen dürfen nicht blockierend auf das Future warten, sondern müssen Callback-Mechanismen (future.then()) oder geordnete Polling-Routinen nutzen.
  • Tritt ein E2E-Fehler oder eine Server-Error-Response auf, liefert Future::GetResult() keinen Wert, sondern eine ara::core::ErrorCode innerhalb einer dedizierten ErrorDomain. Ein ungeprüfter Direktzugriff auf den Wert löst normativ ara::core::Abort() aus.
• Fehlerklassifizierung: Die Applikationslogik muss zwingend zwischen funktionalen Service-Fehlern, transportbezogenen Server-Fehlern (type ERROR) und lokalen E2E-Integritätsverletzungen unterscheiden können.