Figure 7.28: Receive a SET Message

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm mit bedingtem Fragment alt).
• Architektur-Kontext: AUTOSAR Adaptive Platform (ara::com, SWS Communication Management, R21-11).
• Technischer Zweck: Spezifikation des serverseitigen (Skeleton/Publisher) Verarbeitungsablaufs einer eingehenden Set-Anfrage für ein Field über ein netzwerkgebundenes Protokoll (z. B. SOME/IP) unter Berücksichtigung von End-to-End-Absicherung (E2E) und Fehlerszenarien.

2. Komponenten, Entitäten & Schnittstellen

• Transmission (Lifeline):
  • Netzwerk- und Transportschicht bzw. Binding-Treiber (z. B. SOME/IP-Binding / Socket-Adapter / OS-IP-Stack).
  • Verwaltet den physikalischen Empfang und Versand der serialisierten PDUs/Payloads.
• ara::com (Lifeline):
  • Adaptive Communication Management Middleware (Skeleton-Implementierung / Binding-Dispatcher).
  • Verantwortlich für Header-Parsing, Serialisierung/Deserialisierung, Dispatching sowie E2E-Validierung (E2E_Check()) und -Generierung (E2E_Protect()).
• Publisher (Lifeline):
  • Applikationsinstanz / Service Provider, welcher die Service-Schnittstelle mit dem definierten Field bereitstellt.
• Schnittstellen & Callbacks:
  • skeletonField.SetHandler(argument): Über RegisterSetHandler() an der Skeleton-Instanz registrierte Applikations-Callback-Funktion zur Aktualisierung des Feldwerts.
  • E2E ErrorHandler(): Callback-Schnittstelle zur Benachrichtigung der Applikation über eine E2E-Prüfsummen- oder Sequenznummern-Verletzung.
  • PRS_SOMEIP_00191: Normative SOME/IP-Protokollanforderung bezüglich Return-Codes bei E2E-Fehlern (Rückgabewert signalisiert E2E-Fehler an den Client).

3. Dynamisches Verhalten & Sequenzablauf

1. Nachrichtenempfang & Pufferung:
   • Transmission meldet Message reception (serialized data) an ara::com.
   • ara::com holt die Rohdaten via Get the message (serialized data) synchron ab.
2. Vorverarbeitung & Validierung:
   • Process non protected header(): Auswertung ungesicherter Protokoll-Header (z. B. SOME/IP Message ID, Length, Request ID, Protocol Version).
   • E2E_Check(): Middleware führt die E2E-Prüfung (CRC, Alive Counter, Data ID) über den geschützten Payload- und Header-Bereich durch.
3. Verzweigung (alt):
   • Zweig [no E2E error] (Gutfall):
     • Process E2E protected header(): Entpacken des E2E-spezifischen Headers.
     • Deserialize data(): Konvertierung des Byte-Streams in typsichere C++-Argumente.
     • Aufruf von skeletonField.SetHandler(argument) auf dem Publisher.
     • Publisher setzt den Wert und liefert das Funktionsergebnis (Return Value) zurück.
     • ara::com setzt den Nachrichten-Return-Code auf E_OK.
   • Zweig [E2E error] (Fehlerfall):
     • E2E ErrorHandler() wird am Publisher aufgerufen; keine Übergabe der unvalidierten/korrupten Felddaten an den regulären SetHandler.
     • ara::com setzt den Return Code der Response auf den spezifischen E2E-Fehlerwert gemäß PRS_SOMEIP_00191 (z. B. SOME/IP Return Code 0x07 / E_E2E).
4. Antwort-Generierung (gemeinsamer Pfad):
   • Serialize return value(): Serialisierung des Rückgabewerts bzw. Fehlerstatus.
   • Add E2E protected header(): Erzeugung des E2E-Headers für die Antwort.
   • E2E_Protect(): Berechnung von CRC/Counter für die ausgehende Response. Regel: Die Antwortnachricht ist immer E2E-geschützt – unabhängig davon, ob die eingehende Anfrage einen E2E-Fehler aufwies.
   • Add non protected header(): Vervollständigung des Transport-/SOME/IP-Headers.
   • Send(): Übergabe der serialisierten Response an Transmission.

4. Normative Relevanz & Entwickler-Hinweise

• Sicherheitsisolation (Safety Integrity): Applikationscode im SetHandler wird bei korrupter Nachricht niemals mit ungültigen Daten aufgerufen. Der Integritätsschutz greift vollständig in der ara::com-Schicht vor der Deserialisierung.
• Symmetrische E2E-Absicherung: Auch Fehlerantworten (Response mit E2E-Fehler-Code) müssen normativ durch E2E_Protect() signiert werden, damit der Client die Integrität der Fehlermeldung verifizieren kann.
• Applikations-API (SetHandler): Die Applikation muss über skeletonField.RegisterSetHandler() zwingend einen Handler bereitstellen, der einen ara::core::Future oder das entsprechende Wertobjekt zurückliefert, um die Response-Serialisierung zu triggern.
• Protokoll-Konformität: Binding-Entwickler müssen sicherstellen, dass bei Fehlschlagen von E2E_Check() der SOME/IP Message Type RESPONSE mit dem normativen Fehler-Return-Code (PRS_SOMEIP_00191) erzeugt wird, statt die Nachricht stillschweigend zu verwerfen (Drop).