Figure 7.2: The currently supported use cases for Raw Data Streams, and which artifacts in the Deployment model that shall be used to configure the different use cases

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Deployment- und Kommunikations-Topologiediagramm (Netzwerk- und Konfigurations-Metamodell-Mapping).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AUTOSAR_AP_SWS_RawDataStream, Schnittstelle ara::com::raw).
• Funktionaler Zweck: Das Schaubild definiert die vier normativ zulässigen Kommunikations-Topologien für ungekapselte Datenströme (z. B. Sensor-Rohdaten wie Kamera/LiDAR, Video/Audio-Streaming) über Ethernet (L4 TCP/UDP) und ordnet diesen Topologien die korrespondierenden Konfigurationsartefakte des AUTOSAR-Deployment-Metamodells (EthernetRawDataStream[Server|Client]Mapping) zu.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Rollen

• Client / Client 1 … Client N: Adaptive Applikationen als Senke (Consumer) des Rohdatenstroms bzw. Quelle für Steuerkommandos.
• Server: Adaptive Applikation als Quelle (Producer) des Rohdatenstroms bzw. Empfänger von Steuerkommandos.

Metamodell-Entitäten & Konfigurationsparameter

• EthernetRawDataStreamServerMapping (Server-seitiges Deployment):
  • localTcpPort: Lokaler TCP-Listen-Port des Servers (UC1).
  • localUdpPort: Lokaler UDP-Port des Servers (UC2, UC3, UC4).
  • remoteClientConfig.unicastUdpCredentials.udpPort: Ziel-UDP-Port des Unicast-Clients (UC2).
  • remoteClientConfig.multicastCredentials.udpPort: UDP-Port der Multicast-Gruppe zur Verteilung (UC3, UC4).
• EthernetRawDataStreamClientMapping (Client-seitiges Deployment):
  • localTcpPort: Lokaler Quell-Port des Clients für TCP (UC1).
  • localUdpPort: Lokaler Quell-Port des Clients für UDP (UC2).
  • remoteServerConfig.unicastCredentials.tcpPort: Ziel-TCP-Port des Servers (UC1).
  • remoteServerConfig.unicastCredentials.udpPort: Ziel-UDP-Port des Servers für Unicast-Datagramme (UC2, UC4; im Original-Diagramm bei UC2 als udpPortt typografisch fehlerhaft annotiert).
  • remoteServerConfig.multicastCredentials.udpPort: Multicast-Port der Empfangsgruppe (UC3, UC4).
  • multicastCredentials: Multicast-Gruppenkonfiguration (IP/Port) für den Client-seitigen Gruppenbeitritt (UC4).

Unterstützte Topologien & Kardinalitäten

1. Use Case 1 (1:1 TCP unicast): Punkt-zu-Punkt, bidirektionaler Byte-Stream, verbindungsorientiert über TCP.
2. Use Case 2 (1:1 UDP unicast): Punkt-zu-Punkt, bidirektionaler Datagramm-Austausch über UDP.
3. Use Case 3 (1:N UDP Multicast): Punkt-zu-Mehrpunkt, unidirektional; Server verteilt Datenstrom an N Clients via Multicast.
4. Use Case 4 (1:N UDP + 1:1 UDP Hybrid): Kombination aus 1:N-Multicast-Verteilung (Server → Clients) und separater 1:1-UDP-Unicast-Verbindung (Client 1 ↔ Server) für Kontroll- und Steuerdaten.

3. Dynamisches Verhalten & Sequenzablauf

• Use Case 1 (TCP Unicast):
  • Verbindungsaufbau: Client initiiert den TCP-3-Way-Handshake aktiv gegen remoteServerConfig.unicastCredentials.tcpPort. Server bindet passiv an localTcpPort.
  • Datenübertragung: Sequentieller, vollduplexer Rohdaten-Bytestrom mit Flusssteuerung und Fehlerkorrektur via TCP.
• Use Case 2 (UDP Unicast):
  • Initialisierung: Server und Client binden Sockets an ihren jeweiligen localUdpPort.
  • Datenübertragung: Asynchrones Senden von UDP-Datagrammen an die Gegenstelle ohne Verbindungshandshake.
• Use Case 3 (1:N UDP Multicast):
  • Ablauf: Server sendet Datagramme an die konfigurierte Multicast-IP/Port (multicastCredentials.udpPort).
  • Gruppenbeitritt: Clients treten der Multicast-Gruppe über L3/L4-Protokolle (IGMP/MLD) bei und empfangen den Stream passiv. Rückkanal existiert nicht.
• Use Case 4 (1:N Multicast + 1:1 Unicast Control):
  • Streaming-Pfad: Kontinuierlicher Multicast-Datenstrom vom Server an alle abonnierten Clients (1 … N).
  • Kontroll-Pfad: Client 1 öffnet parallel einen Unicast-UDP-Kanal zum Server zur Übertragung von Kontrollbefehlen (z. B. PTZ-Kamerasteuerung, dynamische Frameraten-Anpassung, Latenz-ACKs).

4. Normative Relevanz & Entwickler-Hinweise

• Einschränkung des Lösungsraums: Die dargestellten vier Use Cases sind die einzig normativ definierten Kommunikationsmuster der Raw-Data-Stream-Spezifikation. Andere Topologien (wie N:M-Multicast oder aggregierte N:1-Unicast-Streams auf dieselbe Socket-Instanz) sind vom Standard nicht abgedeckt und erfordern proprietäres Demultiplexing auf Applikationsebene.
• Deklaratives Socket-Binding im Deployment:
  • Der Codegenerator des Adaptive-Stacks generiert aus den Mapping-Artefakten die konkrete Socket-Konfiguration (bind(), connect(), setsockopt()).
  • Fehlen localTcpPort bzw. localUdpPort im Deployment, wählt der zugrunde liegende POSIX-IP-Stack ephemere Ports. Für deterministische Firewall- und Switch-Konfigurationen (ACLs) sind feste Ports zwingend zu modellieren.
• Multicast-Abonnement: Bei UC3 und UC4 übernimmt der Stack das Beitreten zur Multicast-Gruppe (IP_ADD_MEMBERSHIP / IPV6_JOIN_GROUP) deklarativ anhand der konfigurierten multicastCredentials. Die Applikation interagiert ausschließlich über die High-Level-Methoden von ara::com::raw.
• Spezifikations-Inkonsistenzen / Errata:
  • In UC2 weist das Diagramm einen Tippfehler auf (udpPortt statt udpPort).
  • In UC3 zeigt die Beschriftung an den Clients irrtümlich auf EthernetRawDataStreamServerMapping.remoteServerConfig... – semantisch und metamodell-konform muss auf Client-Seite zwingend EthernetRawDataStreamClientMapping instanziiert werden. Verbindlich für die ARXML-Serialisierung ist stets das XML-Schema (AUTOSAR_MOD_AISpecification).