Figure 7.33: Send a GET Message

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Architektur-Kontext: AUTOSAR Adaptive Platform (ARA), Spezifikation AUTOSAR_SWS_CommunicationManagement (Release R21-11).
• Technischer Zweck: Darstellung der clientseitigen Ablaufkette beim Senden einer Service-Orientierten GET-Anforderung (Field.Get()) über die Service-Schnittstelle von ara::com. Es visualisiert die Entkopplung von Anwendungsaufruf und Netzwerkserialisierung inklusive der normativ vorgeschriebenen End-to-End-Absicherung (E2E-Protection nach SOME/IP-Spezifikation, vgl. PRS_SOMEIP_00191).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • Client Application: Adaptive Application (AA), agiert als Service-Consumer und Proxy-Aufrufer.
  • ara::com: Laufzeitumgebung des Communication Management (Proxy-Binding, E2E-Transformer, Serialisierungs-Pipeline).
  • Transmission: Unterlagerte Netzwerk- und Transportschicht (z. B. SOME/IP-Stack, POSIX-Socket/IPC).
• Schnittstellen & Operationen:
  • Field.Get(): Asynchrone Getter-Methode des generierten Proxy-Fields.
  • Future of Field.Get() created: Asynchrones Rückgabeobjekt (ara::core::Future) an die aufrufende Applikation.
  • Serialize data(): Interne Serialisierung der Aufrufparameter/Payload.
  • Add E2E protected header(): Assemblierung der E2E-geschützten SOME/IP-Headerfelder (Client ID, Session ID, Protocol Version, Interface Version, Message Type, Return Code).
  • E2E:ProtectData(Data ID, Source ID, ...): Aufruf des E2E-Transformers/E2E-Treibers zur Berechnung von Prüfsumme (CRC) und Sequence Counter.
  • Add non E2E protected header(): Hinzufügen der ungeschützten Headeranteile (Message ID mit Service-/Method-ID sowie Length-Field).
  • Store E2E counter(): Persistierung des inkrementierten E2E-Zählers im Zustandsmodell des Proxys.
  • SendMessage(serialized data): Übergabe des fertig gerahmten Datenpakets (PDU) an die Transportschicht.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger & Immediate Return (Asynchronität):
   • Die Client Application ruft synchron Field.Get() auf.
   • ara::com erzeugt unmittelbar ein ara::core::Future-Objekt und liefert dieses an die Applikation zurück. Die aufrufende Applikation ist damit sofort wieder freigegeben (Non-Blocking API).
2. Serialisierungs- und E2E-Pipeline (ara::com intern):
   • Serialisierung: ara::com führt Serialize data() aus, um Nutzdaten/Payload vorzubereiten.
   • Geschützter Header: Konstruktion der E2E-relevanten SOME/IP-Headeranteile (Add E2E protected header()).
   • E2E-Absicherung: Ausführung von E2E:ProtectData(...) unter Verwendung von Data ID und Source ID. Die E2E-Prüfdaten (CRC, Counter) werden in den Datenstrom eingefügt.
   • Ungeschützter Header: Ergänzung der verbleibenden Header-Felder (Add non E2E protected header()), die definitionsgemäß außerhalb der E2E-Checksumme liegen (insbesondere das dynamische Längenfeld).
   • Zustandsspeicherung: Aktualisierung und Speicherung des Zählerstands (Store E2E counter()).
3. Dispatch:
   • Übergabe des finalen PDU-Puffers via SendMessage(serialized data) an die Transmission-Schicht zur physikalischen Aussendung.
   • Nach Bestätigung durch den Netzwerktreiber schließt ara::com den Sendevorgang ab (die finale Auflösung des Future erfolgt später beim Empfang der Server-Response).

4. Normative Relevanz & Entwickler-Hinweise

• Applikations-Entwickler (Client Application):
  • Striktes asynchrones Design: Field.Get() blockiert nicht bis zur Datenankunft. Der Zugriff auf den Wert muss zwingend über ara::core::Future::get(), Polling (wait(), wait_for()) oder über Callbacks (then()) koordiniert werden.
• Stack- und Middleware-Entwickler (ara::com / Transformer):
  • Header-Segmentierung nach PRS_SOMEIP_00191: Der SOME/IP-Header darf bei aktivierter E2E-Absicherung nicht als monolithischer Block serialisiert werden. Der Stack muss Header-Anteile strikt in E2E-geschützt (Client/Session ID, Typ, Return Code) und E2E-ungeschützt (Length, Message ID) auftrennen, da das Längenfeld sonst bei dynamischen Längen die E2E-Prüfsumme invalidieren würde.
  • E2E-State-Management: Store E2E counter() erzwingt eine strikte Zustandsverwaltung pro Field-Proxy/Data-ID-Kombination. Bei Überläufen oder Session-Resets müssen die jeweiligen E2E-Profil-Vorgaben (z. B. Profile 04, 07 oder E2E-P01) eingehalten werden.
  • Zero-Copy & Memory-Layout: Um Overhead im Stack zu vermeiden, muss der Puffer für Payload, E2E-Header/Trailer und den ungeschützten Header scatter-gather-fähig oder mit entsprechenden Headroom-Offsets vorreserviert sein.