Figure 3.67: Modeling of PortInterfaces for raw data stream

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm (Ausschnitt des M2-Metamodells der AUTOSAR Adaptive Platform).
• Technischer Zweck: Modellierung der Port-Interface-Hierarchie für unformatierte Byteströme (Raw Data Streams) im AUTOSAR-Manifest (AUTOSAR_TPS_ManifestSpecification, R22-11).
• Architektur-Einordnung: Ergänzung bzw. Alternative zur serviceorientierten Kommunikation über ServiceInterface (Events, Methods, Fields via SOME/IP). Raw Data Streams ermöglichen latenz- und durchsatzoptimierte Punkt-zu-Punkt-Übertragungen großer Datenmengen (z. B. Kamera-Videoströme, LiDAR-/Radar-Rohdaten, Audio) unter Umgehung des Serialisierungs-/Deserialisierungs-Overheads.

2. Komponenten, Entitäten & Schnittstellen

• PortInterface: Abstraktes Basiselement des M2-Metamodells für sämtliche Schnittstellen an Software-Ports (PortPrototype).
• AbstractRawDataStreamInterface (kursiv/abstrakt): Spezialisiert PortInterface. Fungiert als abstrakter Generalisierungsknoten für stream-basierte Interaktionsmuster und bündelt gemeinsame Eigenschaften für Byteströme.
• RawDataStreamClientInterface (konkret): Spezialisiert AbstractRawDataStreamInterface via UML-Generalisierung. Repräsentiert die Client-Rolle der Stream-Verbindung (Initiator des Verbindungsaufbaus). Wird typischerweise an einem RPortPrototype (Required Port) referenziert.
• RawDataStreamServerInterface (konkret): Spezialisiert AbstractRawDataStreamInterface via UML-Generalisierung. Repräsentiert die Server-Rolle der Stream-Verbindung (Passiver Endpunkt / Listener). Wird typischerweise an einem PPortPrototype (Provided Port) referenziert.

3. Dynamisches Verhalten & Sequenzablauf

• Klassifikation: Reines statisches Strukturdiagramm; kein Sequenzablauf im Metamodell abgebildet.
• Laufzeit-Dynamik der abgeleiteten Instanzen (ara::com):
  1. Initialisierung/Listen: Der Server (RawDataStreamServerInterface) bindet an den im Deployment definierten Netzwerk-Endpunkt (z. B. TCP/UDP-Socket) und wartet auf eingehende Verbindungen.
  2. Verbindungsaufbau: Der Client (RawDataStreamClientInterface) initiiert die Verbindung zum Ziel-Endpunkt (IP/Port).
  3. Streaming: Bidirektionaler oder unidirektionaler ungepufferter/gepufferter Bytestrom-Austausch direkt über POSIX-Socket-Abstraktionen der Plattform.
  4. Terminierung: Expliziter Verbindungsabbau durch Client/Server oder Verbindungsabriss bei Socket-Fehlern.

4. Normative Relevanz & Entwickler-Hinweise

• ARXML-Modellierung: Entwickler müssen für Rohdatenströme zwingend die Rollentrennung einhalten: Server-Komponenten nutzen RawDataStreamServerInterface am PPortPrototype, Client-Komponenten RawDataStreamClientInterface am RPortPrototype. Ein gemischter oder symmetrischer Einsatz eines einzigen Interface-Typs ist im Metamodell nicht vorgesehen.
• Service Instance & Network Deployment: Im Manifest müssen die Ports mit spezifischen Deployment-Elementen (RawDataStreamDeployment, z. B. Socket-Konfigurationen für TCP/UDP, Portnummern, Puffergrößen) verknüpft werden.
• API-Generierung (ara::com): Der AUTOSAR-Generator erzeugt anstelle von standardmäßigen SOME/IP-Skeleton/Proxy-Klassen spezialisierte Stream-Endpunkte bzw. Raw-Socket-Handles.
• Verantwortung des Applikationsentwicklers: Das Framing, die Paketgrenzen, Endianness sowie Datenintegritätsprüfungen (Checksummen) müssen vollständig in der Anwendungslogik oder einem nachgelagerten Protokoll-Layer abgewickelt werden, da die Plattform bei Raw Data Streams kein automatisches SOME/IP-Header-Parsing oder Datentypprüfung vornimmt.