Figure 10.3: Use cases for Raw Data Stream

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Anwendungsfalldiagramm (Use Case Diagram) mit geschachtelten Systemgrenzen (System Boundary: Adaptive Platform, Sub-System / Functional Cluster: Raw Data Stream).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (Release R24-11), Spezifikation AUTOSAR_AP_EXP_SWArchitecture.
• Technischer Zweck: Definition der primären Interaktionsmuster für den Cluster Raw Data Stream. Der Mechanismus dient dem transporteffizienten, serialisierungsfreien Streaming von Rohdaten (z. B. Audio/Video, Radardaten, Sensor-Rohströme oder Diagnose-Bulk-Data) mit hohem Durchsatz und minimalem Overhead an den Standard-Service-Interfaces (ara::com) vorbei.

2. Komponenten, Entitäten & Schnittstellen

• Akteure (Actors):
  • Adaptive Application ((from Actors)): Primärer, aktiver Akteur im Userspace, der den Kommunikationszyklus aus Applikationssicht steuert.
  • Operating System ((from Actors)): Sekundärer, passiv/unterstützender Akteur (POSIX OS-Kernel / Treiber / Netzwerk-Stack).
• Systemgrenzen & Subsysteme:
  • Adaptive Platform: Umfassender Plattformkontext der AUTOSAR-AP-Middleware.
  • Raw Data Stream: Spezifischer Funktionscluster / Middleware-Dienst zur Kapselung und Abstraktion der Datenstromübertragung.
• Use Cases (Anwendungsfälle):
  • Send Raw Data Stream: Kontinuierliches Senden unstrukturierter Byteströme in den Zielkanal.
  • Receive Raw Data Stream: Kontinuierliches Empfangen unstrukturierter Byteströme aus der Quelle.
• Stereotypen & Beziehungen:
  • «aapTriggers»: Gerichtete Assoziation von Adaptive Application auf beide Use Cases. Kennzeichnet die AA als initiierenden Auslöser für Aufbau, Datentransfer und Terminierung.
  • «aapParticipates»: Assoziation zwischen Operating System und beiden Use Cases. Kennzeichnet das OS als ausführende/teilnehmende Entität, welche die zugrundeliegenden I/O- und Transportressourcen bereitstellt.

3. Dynamisches Verhalten & Sequenzablauf

• Sende-Pfad (Send Raw Data Stream):
  1. Initialisierung/Trigger: Die AA initiiert den Stream über die plattformspezifische API (z. B. Stream-Deskriptor, Socket- oder Pipe-Abstraktion).
  2. Datenübergabe: Die AA übergibt kontinuierlich Puffersegmente (Payload ohne Serialisierungs-Overhead) an den Cluster.
  3. OS-Partizipation: Der Cluster delegiert das Routing an das OS (z. B. über POSIX-Socket-I/O, Shared Memory oder Zero-Copy-IPC), welches die Daten auf physische Schnittstellen oder interne IPC-Kanäle leitet.
• Empfangs-Pfad (Receive Raw Data Stream):
  1. Bereitstellung/Trigger: Die AA registriert Listener, Callback-Handler oder Polling-Mechanismen auf den Datenstrom.
  2. OS-Signalisierung: Das OS nimmt eingehende Frames auf Treiberebene entgegen, puffert diese und signalisiert Datenverfügbarkeit (z. B. via Event-Notification, epoll/poll).
  3. Zustellung: Der Cluster stellt die Rohdaten via Zero-Copy-Mechanismen oder Bytestream-Reader der AA im Userspace bereit.
• Synchronizität & Latenz: I/O-Pfade sind primär asynchron bzw. non-blocking ausgelegt, um Blockaden im deterministischen Scheduling der AA bei Burst-Traffic zu verhindern.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag & Abgrenzung:
  • Entwickler dürfen für diesen Use Case keine SOME/IP-Serialisierung oder ereignisbasierte ara::com-Proxy/Skeleton-Bindung erwarten; Datenformate müssen applikationsseitig selbst validiert und interpretiert werden.
  • Pufferübergaben nutzen typsichere Bytestrom-Container (z. B. ara::core::Span<const std::uint8_t>).
• Plattform- & OS-Konfiguration:
  • Das zugrundeliegende OS muss POSIX-konforme Stream- bzw. Puffer-Mechanismen mit hinreichender Bandbreite und Puffergrößen (z. B. Socket Receive/Send Buffer) garantieren.
  • Das Execution Manifest der AA muss die entsprechenden Berechtigungen (Resource/Network Limits, POSIX-Capabilities, Access Control Lists) für die jeweilige OS-Ressource deklarieren.