Figure 7.32: Receive a GET Message

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm mit kombiniertem Fragment (alt-Verzweigung).
• Technischer Zweck: Spezifikation des serverseitigen Nachrichtenempfangs- und Antwortablaufs für eine Field.Get()-Anfrage innerhalb der AUTOSAR Adaptive Platform (AUTOSAR_SWS_CommunicationManagement, R21-11).
• Funktionale Einordnung: Detailliert die Interaktion zwischen Transport-/Binding-Schicht (Transmission), der Middleware-Laufzeitumgebung (ara::com) und der Server-Applikation (Publisher / Skeleton) unter Berücksichtigung von End-to-End-(E2E)-Schutzmechanismen (E2E-Profile).

2. Komponenten, Entitäten & Schnittstellen

• Transmission (Lifeline): Protokoll- und transportspezifisches Binding (z. B. SOME/IP über UDP/TCP bzw. IPC) zur Entgegennahme der Rohdaten vom Netzwerk.
• ara::com (Lifeline): Kommunikations-Middleware / Skeleton-Binding. Zuständig für Protokoll-Header-Parsing, Serialisierung/Deserialisierung, Dispatching sowie E2E-Validierung und -Absicherung (E2E_Check, E2E_Protect).
• Publisher (Lifeline): Applikationsseitige Dienstanbieter-Instanz (Skeleton des Service Interfaces), die den Zustand des Fields verwaltet.
• Schnittstellen & Operationen:
  • Message reception (serialized data) / Get the message (serialized data) / Send(): Asynchrone Low-Level-PDU-/Socket-Schnittstelle zwischen Binding und Middleware.
  • skeletonField.GetHandler(): Applikativer Callback/Handler des Skeletons zur Abfrage des aktuellen Feldwertes (ara::core::Future<T>).
  • E2E ErrorHandler(): Melde-Callback zur Notifikation der Applikation über aufgetretene E2E-Prüffehler.
  • Interne Verarbeitungsroutinen: Process non protected header(), E2E_Check(), Process E2E protected header(), Deserialize data(), Serialize return value(), Add E2E protected header(), E2E_Protect(), Add non protected header().

3. Dynamisches Verhalten & Sequenzablauf

1. Nachrichtenempfang & Vorverarbeitung:
   • Transmission signalisiert Message reception an ara::com.
   • ara::com holt die serialisierten Nutzdaten via Get the message() ab.
   • ara::com parst den ungeschützten Header (z. B. SOME/IP Message ID, Length, Request ID, Protocol/Interface Version) und führt die Integritäts-/Sequenzprüfung via E2E_Check() aus.
2. Bedingte Verzweigung (alt):
   • Pfad [no E2E error]:
     • ara::com verarbeitet den E2E-geschützten Header und deserialisiert die Payload (Deserialize data()).
     • Synchroner Aufruf von skeletonField.GetHandler() auf dem Publisher.
     • Der Publisher liefert den aktuellen Feldwert zurück.
     • ara::com setzt den Message Type auf RESPONSE und den Return Code auf E_OK (0x00).
   • Pfad [E2E error]:
     • Der applikative Get-Handler wird nicht ausgeführt; stattdessen wird E2E ErrorHandler() am Publisher getriggert.
     • ara::com setzt den Message Type auf ERROR und den Return Code auf den normativen E2E-Fehlercode gemäß PRS_SOMEIP_00191.
3. Antwortgenerierung & Rücksendung:
   • Unabhängig vom Ergebnis des E2E-Checks der Eingangsnachricht wird der Rückgabewert/Fehlercode serialisiert (Serialize return value()).
   • ara::com fügt den E2E-geschützten Header ein und wendet E2E_Protect() an (Generierung von CRC, Counter, Data ID für die Antwortnachricht).
   • Ergänzung des ungeschützten Headers (Add non protected header()).
   • Übergabe an Transmission via Send() zur Übertragung der geschützten Antwort an den Initiator des Requests.

4. Normative Relevanz & Entwickler-Hinweise

• E2E-Symmetrie & Unabhängigkeit: Die Antwortnachricht auf einen Field-Get-Request wird immer E2E-geschützt – auch dann, wenn die eingehende Anfrage aufgrund eines E2E-Fehlers abgelehnt wurde. Stack-Entwickler müssen sicherstellen, dass der E2E-State-Machine-Kontext für Response-Botschaften auch im Fehlerfall intakt bleibt.
• Isolierung der Applikationslogik: Bei E2E-Validierungsfehlern darf skeletonField.GetHandler() unter keinen Umständen aufgerufen werden, um Korruption oder undefiniertes Applikationsverhalten durch unzulässige Anfragen zu verhindern.
• Konfigurations- & SOME/IP-Binding:
  • Der Return Code für E2E-Fehler muss strikt PRS_SOMEIP_00191 entsprechen (z. B. SOME/IP Return Code 0x87 bzw. profilabhängige E2E-Fehlercodierung).
  • Applikationsentwickler müssen über RegisterGetHandler() zwingend einen non-blocking/reentrant-fähigen Handler registrieren und optional den E2E-Fehlerpfad überwachen (Monitoring via Error-Hook).