Figure 7.26: Receive response to a GET Message

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm mit kombinierten Fragmenten alt).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Spezifikation AUTOSAR_SWS_CommunicationManagement (ara::com), Release R21-11.
• Technischer Zweck: Spezifikation des clientseitigen Empfangspfads einer Antwortnachricht auf einen asynchronen Field-Getter (Field.Get()) unter Berücksichtigung von End-to-End-(E2E-)Schutzmechanismen und E2E-Zustandsautomaten (SWS_CM_90458).

2. Komponenten, Entitäten & Schnittstellen

• Lebenslinien & Akteure:
  • Client Application: Adaptive Application (Consumer/Client-Rolle), interagiert über die typisierte Proxy-Klasse mit dem Field-Interface.
  • ara::com: Middleware-Laufzeitschicht (Proxy-Implementierung, Deserialisierungs-Pipeline, Promise/Future-Handling sowie E2E-Check-Wrapper).
  • Transmission: Unterlagerte Kommunikations- und Bindingschicht (z. B. SOME/IP-Binding, IPC, OS-Sockets/Treiber).
• Entitäten & Datenstrukturen:
  • Future of Field.Get(): Instanz von ara::core::Future<FieldType>, asynchron an die Applikation zurückgegeben.
  • Output (Output.setvalue / Output.setError): Assoziiertes ara::core::Promise-Objekt im ara::com-Stack, das das korrespondierende Future komplettiert.
  • serialized data: Rohdatenpuffer der Payload inklusive E2E-Header/-Footer (CRC, Counter, Data ID).
  • SM state() / E2E State Machine: Interner Zustandsautomat zur E2E-Auswertung gemäß Spezifikation (Zustände wie E2E_SM_VALID, E2E_SM_DEGRADED, E2E_SM_INVALID).

3. Dynamisches Verhalten & Sequenzablauf

1. Initialer Aufruf (asynchron):
   • Client Application ruft Field.Get() auf ara::com auf.
   • ara::com instantiiert das Promise/Future-Paar und liefert das ara::core::Future synchron an den Aufrufer zurück.
   • Zeitversatz („Some time passess ...“) während des Netzwerktransports und der Serververarbeitung.
2. Empfangstrigger & Deserialisierungsvorbereitung:
   • Transmission signalisiert MessageReception() an ara::com.
   • ara::com holt die Payload via GetMessage(serialized data) von der Transportschicht ab.
   • Process non protected data(): Extrahieren ungeschützter Protokoll-Header (z. B. SOME/IP Message ID, Request ID / Session ID).
   • E2E_Check(): Verifikation der Prüfsumme (CRC), des Sequenzzählers und der Data ID gegen das konfigurierte E2E-Profil.
3. Kombiniertes Fragment alt (E2E-Validierung im Stack):
   • Pfad [E2E check OK]:
     • Process E2E protected header(): Parsing der E2E-geschützten Header-Elemente.
     • Deserialized serialized data(): Typkonforme Deserialisierung der Nutzlast.
     • Erfolgreiche Antwort: Aufruf von Output.setvalue(data) setzt das Future auf Ready mit gültigem Rückgabewert.
     • Fehlerantwort des Servers: Aufruf von Output.setError(errorcode) setzt das Future auf Ready mit Fehlerobjekt (ara::core::ErrorCode / ApApplicationError).
   • Pfad [E2E Error]:
     • Store result in SM state(): Fehlermeldung wird an die E2E State Machine übergeben und dort persistiert. Das Daten-Promise wird nicht erfolgreich erfüllt.
4. Zustandsprüfung & Applikationsreaktion:
   • Client Application fragt via GetE2EStateMachineStateGetter() den aktuellen E2E-Status bei ara::com ab.
   • Kombiniertes Fragment alt (Verarbeitung in der Applikation):
     • Pfad [received message has type ERROR]: Server hat einen E2E- oder Protokollfehler erkannt und explizit eine Fehlernachricht retourniert. Verzweigung in process error domain().
     • Pfad [E2E error]: Lokaler E2E-Check ist fehlgeschlagen. Der Rückgabewert darf unter ASIL-Gesichtspunkten keinesfalls konsumiert werden; Verzweigung in process error domain().
     • Pfad [no E2E error]: E2E-Validierung erfolgreich, Future ist ready. Die Applikation ruft den Wert ab und führt process data() aus.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Referenz SWS_CM_90458: Legt fest, dass vor der Verwendung von Rückgabewerten geschützter Field-Get-Operationen der E2E-Zustand (GetE2EStateMachineStateGetter()) durch die Applikation zu prüfen ist, wenn ASIL-D-Integritätsanforderungen dies fordern.
• API-Vertrag (ara::core::Future):
  • Entwickler dürfen nach einem Field.Get() nicht blind auf Future::get() blockieren, ohne den E2E-Status zu validieren. Ein E2E-Fehler auf Netzwerkebene führt dazu, dass die Nutzdaten ungültig sind oder der Future in einen Fehlerzustand übergeht.
• Separation von E2E-Fehler und Application Error:
  • Das Diagramm verdeutlicht zwei orthogonale Fehlerquellen:
    1. Transport-/E2E-Fehler: Verursacht durch Bitkipper, Frame-Verlust oder Replay-Angriffe, detektiert via E2E_Check().
    2. Server-seitiger Anwendungsfehler: E2E-Check ist formal intakt, aber der Server beantwortet den Getter mit einem definierten ApApplicationError (Output.setError).
• Stack-Implementierung:
  • Der ara::com-Treiber/Binding-Stack muss sicherstellen, dass Process non protected data() zwingend vor E2E_Check() ausgeführt wird (um die Nachrichtenassoziation herzustellen), die eigentliche Payload-Deserialisierung (Deserialized serialized data()) aber strikt erst nach erfolgreichem [E2E check OK] erfolgt, um Sicherheitsrisiken durch fehlerhafte Rohdaten zu verhindern.
• Getter-spezifische E2E-Zustandsabfrage: Ab Release R25-11 wird für die E2E-Zustandsabfrage eines Felds explizit die Methode GetE2EStateMachineStateGetter() herangezogen. Dies stellt sicher, dass der Zustand der E2E-Zustandsmaschine dediziert für die Getter-Interaktion abgefragt wird (in Abgrenzung zu Setter- und Notifier-Kanälen desselben Felds).