Figure 4.2: AD sensors directly connected to ECU

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponenten- und Verteilungsdiagramm (Systemtopologie- und Schichtenmodell).
• Architektur-Kontext: Systemmuster für die Direktanbindung externer Sensoren an ein autonomes Fahrsystem (AD – Automated Driving) auf Basis der AUTOSAR Adaptive Platform (AP) gemäß AUTOSAR_EXP_SensorInterfaces.
• Funktionaler Zweck: Standardisierte Entkopplung heterogener physikalischer Sensor-ECUs (Radar, Kamera, Lidar) und deren herstellerspezifischer Vorverarbeitung von den hochrangigen Fusions- und AD-Algorithmen im Anwendungslayer (Adaptive Applications) über das durch das AUTOSAR Functional Team definierte Schnittstellenmodell («FT-ADI» Sensor Interface).

2. Komponenten, Entitäten & Schnittstellen

Ausführungsumgebungen & Knoten (Hardware/OS-Ebene)

• Autosar Adaptive ECU: Zentraler Hochleistungs-Rechnerknoten (HPC/Domain Controller), der den POSIX/ARA-Stack hostet.
• Sensor-ECUs (Peripherie-/Satellitenknoten):
  • Radar ECU: Enthält die Komponente Radar Data Pre-Processing (Signalverarbeitung direkt am Sensor).
  • Camera ECU: Enthält die Komponente Camera Sensor (Optik/Imager und Basis-Auslesung).
  • Lidar ECU: Enthält die Komponente Lidar Sensor (Laser-Erfassung und Rohpunkterzeugung).

Schichten & Software-Komponenten (SWCs)

• Schicht Adaptive Applications:
  • AD Algorithm 1 bis AD Algorithm n: Endanwendungen für autonome Fahrfunktionen (z. B. Trajektorienplanung, Längs-/Querführung, Manöverentscheidung).
  • Sensor Fusion: Übergeordnete Softwarekomponente zur zeitlichen und räumlichen Fusionierung heterogener Objektdaten/Features zu einem konsistenten Umgebungsmodell.
• Schicht ARA (AUTOSAR Runtime for Adaptive Applications):
  • «FT-ADI» Sensor Interface: Standardisiertes Abstraktions- und Service-Interface (Stereotyp «FT-ADI» = Functional Team Automated Driving Interfaces). Dient als standardisierte Fassade/Broker für Sensordaten.
• Schicht Sensor Drivers/Preprocessing (Plattform-/Treiber-Subsystem innerhalb/unterhalb ARA):
  • Radar Data Processing: Protokolldekodierung und gerätespezifische Aufbereitung von Radardaten.
  • Camera Data Processing: Aufbereitung von Bildmerkmalen, Objektlisten oder Videoströmen.
  • Lidar Data Processing: Dekodierung und Filterung von Lidar-Punktwolken.

Bus- und Übertragungsmedien

• Ethernet: Breitbandige Punkt-zu-Punkt-Verbindung für Radar ECU → Radar Data Processing und Lidar ECU → Lidar Data Processing (geeignet für hohe Bandbreiten, z. B. Ethernet AVB/TSN, SOME/IP oder Rohdatenpakete).
• HighSpeed CAN: Bandbreitenbeschränkter, deterministischer Bus zwischen Camera ECU und Camera Data Processing (Übertragung von komprimierten Feature-/Objektlisten statt unkomprimiertem Video).

3. Dynamisches Verhalten & Sequenzablauf

1. Erfassung & satellitäre Vorverarbeitung:
   • Physikalische Sensoren erfassen die Umgebung. Auf der Radar ECU werden Reflektionsdaten bereits vor Ort vorverarbeitet (Radar Data Pre-Processing), während Kamera und Lidar Roh- oder vorstrukturierte Sensordaten generieren.
2. Signalübertragung (Inbound I/O):
   • Asynchrone Übertragung der Sensornachrichten über die physikalischen Bussysteme (Ethernet, HighSpeed CAN) an die Netzwerk-Controller der Adaptive ECU.
3. Plattformnahe Vorverarbeitung & Deserialisierung:
   • Die Komponenten Radar/Camera/Lidar Data Processing terminieren die transportspezifischen Protokolle (z. B. SocketCAN, SOME/IP-Deserialisierung, IEEE 802.1AS Zeitstempelung), parsen die proprietären Sensorformate und überführen sie in standardisierte ADI-Datenstrukturen.
4. Service-Orientierte Datenübergabe (ara::com):
   • Die Sensorverarbeitungskomponenten stellen die normalisierten Daten über das «FT-ADI» Sensor Interface bereit (typischerweise im Publish/Subscribe-Muster via Event-Pfade).
5. Applikative Fusion & Regelung:
   • Sensor Fusion konsumiert die aggregierten Sensordaten, führt Assoziation, Tracking sowie Koordinatentransformation durch und publiziert das Umgebungsmodell an die nachgelagerten Konsumenten AD Algorithm 1 .. n.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag & Entkopplung:
  • Entwickler von Fahrfunktionen (Adaptive Applications) binden ausschließlich an die vom «FT-ADI» definierten C++ Interfaces / Service Interfaces (ara::com). Jegliche Hardwareabhängigkeit von Sensormodellen, Interfaces (CAN vs. Ethernet) und Transportprotokollen ist strikt unterhalb des Sensor Interface gekapselt.
• Rolle der Sensor Drivers/Preprocessing-Komponenten:
  • Fungieren als Adapter- bzw. Bridge-Komponenten: Sie implementieren den Übergang von POSIX-I/O- oder Network-Sockets auf typisierte ara::com-Skelette/Proxies.
• Latenz- und Shared-Memory-Anforderungen:
  • Für Datenströme hoher Bandbreite (Lidar-Punktwolken, hochauflösende Radarkarten) über das Sensor Interface in die Sensor Fusion müssen Entwickler Zero-Copy-Mechanismen oder Shared-Memory IPC (z. B. Iceoryx/ara::com Shared Memory Binding) vorsehen, um CPU-Kopier-Overheads auf der Adaptive ECU zu vermeiden.
• Zeitsynchronisation (ara::tsync):
  • Da die Sensoren über unterschiedliche Busse (Ethernet, HighSpeed CAN) mit variierenden Latenzen und Zykluszeiten einlaufen, müssen die Preprocessing-Komponenten globale Zeitstempel (z. B. PTP / gPTP gemäß AUTOSAR Time Synchronization) an die Datenstrukturen des Sensor Interface binden, um eine fehlerfreie Fusionsrechnung zu ermöglichen.