Figure 9.30: Interfaces for raw data streams using the IEEE1722 protocol

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Schnittstellen- und Komponentendiagramm (Port- & API-Sicht) mit AUTOSAR Adaptive Platform Metamodell-Stereotypen («aap...»).
• Kontext & Zweck: Spezifikation der Applikations-Programmierschnittstellen (APIs) des Functional Clusters Raw Data Stream (RDS) in der AUTOSAR Adaptive Platform (AP) für das Streaming von Rohdaten über das IEEE 1722 Transportprotokoll (AVTP – Audio Video Transport Protocol). Dient der Anbindung hochbitratiger Sensordaten (Kamera, LiDAR, Radar) und Multimediadaten an Adaptive Applications unter Umgehung serviceorientierter Serialisierungs-Overheads (ara::com).

2. Komponenten, Entitäten & Schnittstellen

• Komponenten:
  • Adaptive Application: Anwendungskomponente im User Space, agiert als Senke (Consumer) oder Quelle (Producer) des Rohdatenstroms.
  • «aapFunctionalCluster» Raw Data Stream: Kern-Plattformcluster der Adaptive Platform Foundation; stellt die Protokoll-Implementierung (IEEE 1722 Framing, Socket- und Puffer-Management) bereit.
• Schnittstellen (PortInterfaces & APIs):
  • «aapAPI,aapPortInterface» IEEE1722RawDataStreamConsumer: Schnittstelle für Stream-Konsumenten mit Operationen:
    • + Create(): Statische Factory-Methode (unterstrichen) zur Instanziierung des Consumers anhand konfigurierter Port-Deskriptoren.
    • + Connect(): Binden des Sockets an die konfigurierte IEEE 1722 Stream-ID / Multicast-Gruppe.
    • + ReadData(): Abruf empfangener Payload-Puffer aus der AVTPDU.
    • + Shutdown(): Kontrollierter Abbau des Empfangskanals und Pufferfreigabe.
  • «aapAPI,aapPortInterface» IEEE1722RawDataStreamProducer: Schnittstelle für Stream-Produzenten mit Operationen:
    • + Create(): Statische Factory-Methode (unterstrichen) zur Erzeugung des Producers.
    • + Connect(): Initialisierung des Sendekanals (Stream-Header, AVTP Subtype, Zeitstempel-Synchronisation).
    • + WriteData(): Einspeisung von Rohdaten in den IEEE 1722 Frame-Stream.
    • + Shutdown(): Flush/Schließen des Sendekanals.
• Stereotypen & Relationen:
  • «use» «aapRequiredPort»: Gerichtete Abhängigkeit (Client-Rolle); die Adaptive Application greift über typisierte Required Ports auf die Schnittstellen zu.
  • Interface Realization (gestrichelte Linie mit geschlossener, leerer Pfeilspitze): Der funktionale Cluster Raw Data Stream implementiert beide Schnittstellen und agiert als Bereitsteller (Provider-Rolle).

3. Dynamisches Verhalten & Sequenzablauf

1. Instanziierung (Factory):
   • Aufruf von Create() durch die Applikation unter Angabe des InstanceSpecifier aus dem Ausführungsmanifest; liefert ein Instanz-Handle oder ein ara::core::Result<Instance>.
2. Kanaletablierung:
   • Synchroner oder asynchroner Aufruf von Connect(). Löst Plattform-interne OS-Socket-Konfigurationen (z. B. AF_PACKET, Raw Sockets) und VLAN-/AVB/TSN-Bindungen aus.
3. Datenübertragung (Steady-State):
   • Producer-Pfad: Zyklisches/ereignisbasiertes WriteData(). Kapselt Payload in AVTP-Frames (inkl. Sequence Number und Timestamp) und übergibt diese an den Netzwerk-Treiber.
   • Consumer-Pfad: Aufruf von ReadData() (blockierend oder über Polling/Event-Mechanismen); liefert empfangene Datenpakete direkt aus den Ringpuffern.
4. Terminierung:
   • Aufruf von Shutdown() zur Deallokation von Deskriptoren, De-Registrierung von Multicast-Gruppen und deterministischen Freigabe interner Speicherressourcen.

4. Normative Relevanz & Entwickler-Hinweise

• Abgrenzung zu ara::com: Kein SOME/IP-, DDS- oder IPC-Serialisierungs-Layer. Direkter Zugriff auf Ethernet-Layer-2/Layer-3-AVTP-Streams minimiert CPU-Last und Latenzen bei unstrukturierten Massendaten.
• Pufferverwaltung & Zero-Copy: Bei ReadData() und WriteData() ist auf speichereffiziente Übergabemechanismen (z. B. ara::core::Span, Shared-Memory-Puffer oder Smart Pointer) zu achten, um unnötige Kopieroperationen zwischen POSIX-Kernel und User Space zu vermeiden.
• Manifest-Bindung: Parameter wie IEEE 1722 StreamID, Ethernet-Multicast-Adressen, VLAN-IDs, Traffic-Klassen (IEEE 802.1Qav/Qat TSN CBS) und Puffergrößen werden nicht über die Programmierschnittstelle übergeben, sondern statisch in den Service Instance Manifests der Ports definiert.
• Fehlerbehandlung: APIs folgen dem AUTOSAR C++14-Standard ohne Exception-Handling; Methoden geben standardmäßig ara::core::Result<T> zurück, worüber Kommunikationsunterbrüche, Buffer-Overruns und Frame-Verluste applikationsseitig auszuwerten sind.