Figure 7.34: Send a SET Message

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm gemäß OMG UML 2.5).
• Technischer Zweck: Spezifikation des ausgehenden Kontroll- und Datenflusses bei Aufruf einer Set()-Methode eines Feldes (Field::Set) auf Client-Seite innerhalb der AUTOSAR Adaptive Platform (AUTOSAR_SWS_CommunicationManagement).
• Architektonische Einordnung: Veranschaulicht das Zusammenspiel zwischen Applikationsschicht (Client Application), Middleware-Bindeglied (ara::com Proxy/Skeleton-Implementierung) und der Netzwerk-Transportschicht (Transmission, z. B. SOME/IP über UDP/TCP) unter Einbettung der funktionalen Sicherheit (End-to-End Protection / E2E gem. SWS_CM_10464).

2. Komponenten, Entitäten & Schnittstellen

• Lebenslinien / Instanzen (Akteure & Komponenten):
  • Client Application: Adaptive Application (Prozess im POSIX-Userspace), welche die generierte Client-Proxy-Schnittstelle konsumiert.
  • ara::com: Service-Oriented Communication Middleware (Proxy-Instanz, Serialization Engine, E2E-Protector/Transformer).
  • Transmission: Unterlagerte Transportschicht / Network Binding (z. B. SOME/IP Daemon, Socket-Kommunikation, Kernel-Netzwerkstack).
• Schnittstellen & Signaturen:
  • Field.Set(): Asynchrone Schnittstelle des Service-Proxies zur Modifikation eines Remote-Feldwerts (ara::core::Future<SetResultType>).
  • Serialized data(): Interne Serialisierungsroutine (Transformation nativer Datentypen/Payload in Byte-Stream, z. B. via CommonAPI/SOME/IP-Serialization).
  • Add E2E protected header(): Erzeugung und Voranstellung der sicherheitsrelevanten Protokollkopfdaten (u. a. Client ID, Session ID, Protocol Version, Interface Version, Message Type, Return Code).
  • E2E_Protect(Data ID, Source ID, ...): Schnittstelle zum E2E-Schutzmechanismus (Generierung von CRC, Counter, Data ID gem. konfiguriertem E2E-Profil).
  • Add non E2E protected header(): Komplettierung des Protokoll-Headers um ungeschützte Felder (z. B. SOME/IP Message ID, Length).
  • Store E2E counter(): Zustandshaltung des inkrementierten Sendecounters pro Data/Source-ID.
  • SendMessage(serialized data): Übergabe des fertig gepackten und geschützten Byte-Arrays an die Übertragungsschicht.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger & Future-Generierung (Synchroner Return):
   • Die Client Application ruft Field.Set(value) an der ara::com-Proxy-Instanz auf.
   • ara::com erzeugt unmittelbar ein ara::core::Future-Objekt und gibt dieses synchron an den Aufrufer zurück (Future of Field.Set() created). Die Applikation wird somit nicht blockiert.
2. Serialisierung:
   • ara::com serialisiert den als Methodenargument übergebenen Wert in das Ziel-Wire-Format.
3. Konstruktion des E2E-geschützten Header-Bereichs:
   • Zusammenbau der Header-Felder, die der E2E-Prüfsummenbildung unterliegen (Client ID, Session ID, Protocol Version, Interface Version, Message Type = REQUEST, Return Code).
4. E2E-Absicherung:
   • Aufruf der Berechnungslogik (E2E_Protect), Parametrisierung über Data ID, Source ID, aktuellen Sequenzzähler; Berechnung der CRC über Header-Teile und Nutzdaten.
5. Vervollständigung des Headers (gem. SWS_CM_10464):
   • Hinzufügen der nicht-E2E-geschützten Header-Anteile (insb. Message ID / Request ID und Length-Feld) an den Gesamtrahmen.
6. Zustandsspeicherung:
   • Persistierung des aktuellen E2E-Counters (Store E2E counter()) für Folgeberechnungen.
7. Netzwerkübertragung:
   • Interne Vorbereitung und anschließende Übergabe der serialisierten PDU/Botschaft via SendMessage(serialized data) an die Transmission-Instanz (asynchroner Netzwerkversand).

4. Normative Relevanz & Entwickler-Hinweise

• Nicht-blockierendes API-Design: Entwickler müssen beachten, dass Field.Set() sofort mit einem ara::core::Future zurückkehrt. Das Eintreffen der Server-Bestätigung bzw. des Rückgabewerts (Return Code / ggf. Exception) muss applikationsseitig via GetResult(), Polling (wait(), wait_for()) oder Callback (Then()) abgefragt werden.
• E2E-Header-Split (SWS_CM_10464):
  • Strikte Trennung bei der PDU-Serialisierung: Nicht der gesamte SOME/IP-Header ist E2E-abgesichert.
  • Felder wie das Length-Feld oder dynamische Routing-Felder verbleiben außerhalb des Schutzbereichs, um Middlebox-Verarbeitung / Repacking zu erlauben, ohne die E2E-Signatur ungültig zu machen.
  • Die Reihenfolge ist zwingend normativ: Serialisierung Payload → geschützter Header → CRC/Counter-Berechnung → ungeschützter Header-Anhang.
• Ressourcen & Performance: Die E2E-Transformation erfolgt im Kontext des Middleware-Sendepfads. Bei hochtaktigen Feldmodifikationen sind Counter-Persistierung und CRC-Berechnungen deterministisch zu budgetieren.