Figure 9.1: Client sequence diagram

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (UML 2.x Sequence Diagram).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Spezifikationen AUTOSAR_AP_EXP_InterfacesGuidelines [Kapitel 9] sowie AUTOSAR_EXP_ARAComAPI, gültig für Releases R20-11 bis R25-11).
• Funktionale Einordnung: Veranschaulicht das synchrone Standard-Interaktionsmuster des Raw Data Stream (RDS)-Clients. Das RDS-Subsystem innerhalb der Communication Management (ara::com) Architektur dient der Übertragung unformatierter, latenzkritischer Datenströme (z. B. Sensor-Rohdaten via Ethernet über TCP/UDP-Sockets oder IEEE 1722) unter Umgehung der klassischen serviceorientierten Serialisierungs-Overheads (SOME/IP, IPC-Marshalling).

2. Komponenten, Entitäten & Schnittstellen

• Lebenslinien / Instanzen (Lifelines):
  • Application: Aufrufende Adaptive Application (Softwarekomponente / POSIX-Prozess im User-Space).
  • Client: Instanz des RDS-Client-Endpunkts (Abstraktion der ara::com::rawdatastream::RawDataStreamClient-Klasse bzw. Socket-Wrapper).
• Schnittstellenmethoden (Aufrufe von Application an Client):
  • Connect(): Synchroner Methodenaufruf zur Herstellung der Netzwerkverbindung (Socket-Verbindung zum Server-Endpunkt).
  • ReadData(): Synchroner Methodenaufruf zum Lesen eines Rohdatenstrom-Segments aus dem Socket-/Empfangspuffer.
  • Shutdown(): Synchroner Methodenaufruf zur ordnungsgemäßen Terminierung der Verbindung und Freigabe allokierter Socket-Ressourcen.
• Strukturelle Beziehung & Ausführungsfokus:
  • Der Client besitzt einen durchgehenden Aktivierungsbalken (Execution Specification) über die gesamte Verbindungssitzung hinweg (vom Empfang des Connect() bis zum Abschluss von Shutdown()).
  • Die Application weist diskrete Aktivierungsbalken für die Dauer der jeweiligen blockierenden Aufrufe auf.

3. Dynamisches Verhalten & Sequenzablauf

1. Verbindungsaufbau (Session-Start):
   • Die Application triggert Connect().
   • Der Client führt den netzwerkseitigen Verbindungsaufbau aus (z. B. TCP-Handshake oder UDP-Socket-Bindung/Zieladressierung) und bestätigt den Erfolg über die Rückgabenachricht (gestrichelter Pfeil).
   • Nach dem Return verbleibt die Sitzung auf Client-Seite im Zustand verbunden/aktiv.
2. Datenabruf (Streaming-Phase):
   • Die Application führt wiederholt synchrone ReadData()-Aufrufe aus.
   • Client holt die verfügbaren Rohdatenbytes aus dem Systempuffer ab und liefert sie synchron an die Application zurück.
   • Die vertikalen Auslassungspunkte (...) kennzeichnen die zyklische Wiederholung dieses Abfragezyklus über die gesamte Datenübertragungsdauer.
3. Verbindungsabbau (Session-Ende):
   • Die Application initiiert das geordnete Beenden der Kommunikation über Shutdown().
   • Der Client schließt die Sockets (TCP FIN/RST bzw. Resource Deallocation) und signalisiert die Beendigung via Return. Der Ausführungsfokus der Sitzung auf dem Client endet.

4. Normative Relevanz & Entwickler-Hinweise

• Zustands- und Aufrufvertrag:
  • Streng sequentielle Abhängigkeit: ReadData() setzt zwingend ein zuvor erfolgreich zurückgekehrtes Connect() voraus. Nach Ausführung von Shutdown() schlägt jeder weitere Lesezugriff fehl, solange keine Re-Initialisierung via Connect() erfolgt.
• Threading & Blocking-Verhalten:
  • Bei synchronen APIs (ReadData()) blockiert der aufrufende Thread der Application bis Daten anliegen, ein definierter Socket-Timeout greift oder ein Fehler auftritt. Im Design von echtzeitfähigen Adaptive-Applikationen ist dies in separaten Worker-Threads zu kapseln, um Blockaden von Hauptschleifen oder Deterministischen Client-Cyclen zu verhindern.
• Fehlerbehandlung:
  • Implementierungen basieren typischerweise auf ara::core::Result<T>-Rückgabewerten. Applikationsseitig müssen Netzwerkabbrüche, Connection-Resets und Puffer-Underflows nach jedem Schritt ausgewertet werden.
• Manifest- & Deployment-Bindung:
  • Verbindungsparameter (Transportprotokoll TCP/UDP, Portnummern, Ziel-IPs, Puffergrößen und Sicherheitsmechanismen wie TLS/DTLS/IPSec) werden nicht per Methodenparameter übergeben, sondern statisch über das Adaptive Application Deployment / Service Instance Manifest konfiguriert.