Figure 4.3: AD sensors connected via a second AUTOSAR AP ECU

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Hybrides UML-Architektur- und Deployment-Diagramm (Kombination aus Verteilungsdiagramm/Nodes, Schichtenmodell und logischen Software-Komponenten).
• Technischer Zweck: Spezifikationsleitfaden aus AUTOSAR_AP_EXP_SensorInterfaces zur Darstellung der Multi-ECU-Topologie für automatisierte Fahrfunktionen (AD). Veranschaulicht die Entkopplung von physischer Sensoranbindung/Vorverarbeitung (auf Autosar Adaptive ECU1) und verteilter Verarbeitung/Fusion (auf Autosar Adaptive ECU2) über standardisierte, serviceorientierte Sensorschnittstellen («FT-ADI»).

2. Komponenten, Entitäten & Schnittstellen

• Hardware-Knoten (ECUs / Execution Environments):
  • Autosar Adaptive ECU1: Primäre Hochleistungs-ECU; fungiert als Sensor-Gateway, Vorverarbeitungs- und Fusionsknoten.
  • Autosar Adaptive ECU2: Sekundäre Adaptive-ECU; konsumiert Sensordaten remote für zusätzliche/redundante Fusions- und AD-Algorithmen.
  • Sensor-ECUs (Peripherie):
    • Radar ECU: Enthält Radar Data Processing.
    • Camera ECU: Enthält Camera Sensor.
    • Lidar ECU: Enthält Lidar Sensor.
• Software-Schichten und logische Komponenten:
  • ARA-Schicht (AUTOSAR Runtime for Adaptive Applications):
    • Sensor Drivers/Preprocessing (ECU1):
      • Radar Data Processing (Host-seitige Vorverarbeitung / Decoder).
      • Camera Data Processing.
      • Lidar Data Processing.
    • «FT-ADI» Sensor Interface (auf ECU1 und ECU2):
      • Stereotyp «FT-ADI»: Feature Topic / Feature Team – Automated Driving Interfaces.
      • Standardisierte serviceorientierte Schnittstellenkomponente zur Kapselung von Sensordaten (z. B. Object Lists, Feature Maps, Rohdaten-Metadaten).
      • Fungiert auf ECU1 als Service Provider (Skeleton) und auf ECU2 als Service Consumer (Proxy).
  • Adaptive Applications Schicht:
    • Sensor Fusion: Konsumiert normalisierte Sensordaten über das «FT-ADI» Sensor Interface.
    • AD Algorithm 1 … AD Algorithm n: Nachgelagerte AD-Anwendungen (z. B. Bahnplanung, Prädiktion, Manöverregelung).
• Verbindungsarten & Protokoll-Stack:
  • Sensor-zu-ECU1:
    • Radar ECU → Ethernet → ECU1.
    • Camera ECU → HighSpeed CAN → ECU1.
    • Lidar ECU → Ethernet → ECU1.
  • ECU1-zu-ECU2 (Inter-ECU):
    • Ethernet mit Service-Middleware SOME/IP oder DDS (realisiert via ara::com).
  • Intra-ECU:
    • Inter-Process Communication (IPC) via ara::com (Shared Memory / Posix IPC) zwischen Sensor Drivers/Preprocessing, Sensor Interface und Sensor Fusion.

3. Dynamisches Verhalten & Sequenzablauf

1. Sensordatenerfassung & Ingestion:
   • Radar-, Kamera- und Lidar-Sensoren erfassen Umgebungsdaten.
   • Übertragung proprietärer/busspezifischer Roh- oder teilausgewerteter Daten an ECU1 über CAN bzw. Ethernet.
2. Normalisierung & Treiber-Preprocessing (ECU1):
   • Die Treiberkomponenten (Radar/Camera/Lidar Data Processing) parsen Bussignale, kompensieren sensorspezifische Parameter und transformieren Daten in das einheitliche AUTOSAR FT-ADI-Format.
3. Service-Bereitstellung (Publish/Subscribe via ara::com):
   • Das «FT-ADI» Sensor Interface auf ECU1 instanziiert den Service-Provider (Skeleton) und stellt Events/Fields bereit (z. B. getaktete Object-/Feature-Listen).
4. Verteilung (Lokal & Remote):
   • Pfad Lokal (ECU1): Die lokale Sensor Fusion empfängt Events synchronisiert via IPC (Zero-Copy Shared Memory).
   • Pfad Remote (ECU2): Das Service-Event wird via SOME/IP-Serializer oder DDS-RTPS über Automotive Ethernet serialisiert an ECU2 übertragen.
5. Rezeption & Fusion auf ECU2:
   • Das «FT-ADI» Sensor Interface (Proxy) auf ECU2 deserialisiert die Payload und übergibt sie an die dortige Sensor Fusion.
   • Beide Fusionsinstanzen leiten ihre aggregierten Umgebungsmodelle an die jeweiligen AD Algorithm 1..n weiter.
6. Zeitsynchronisation:
   • Voraussetzung für die Korrelation: Globale Zeitstempelung (Time Stamping via IEEE 802.1AS / AUTOSAR ara::tsync) an der Ingestion-Grenze auf ECU1, um Transportlatenzen über die Ethernet-Strecke zur ECU2 kompensieren zu können.

4. Normative Relevanz & Entwickler-Hinweise

• Dokumentencharakter: Als Explanation (EXP) besitzt das Dokument informativen und empfehlenden Charakter für Systemarchitekten, bindet jedoch die normativen Schnittstellendefinitionen der SWS-Dokumente (AUTOSAR_AP_SWS_SensorInterfaces bzw. FOA-Interfaces).
• Ortstransparenz (Location Transparency):
  • Applikationscode der Komponente Sensor Fusion bleibt auf ECU1 und ECU2 quellcodeidentisch: Zugriff erfolgt abstrahiert über generierte ara::com-Proxies/Skeletons. Der physikalische Übertragungsweg (Shared Memory vs. SOME/IP/DDS) wird rein deklarativ im Execution- und Service-Instance-Manifest konfiguriert.
• Performance- & Bandbreiten-Constraint:
  • Datenvolumen hochauflösender Sensoren (insb. Lidar/Kamera-Rohdaten) überfordert typische Inter-ECU-Ethernet-Links (z. B. 100BASE-T1 / 1000BASE-T1). Entwickler müssen im Preprocessing auf ECU1 eine Abstraktion (z. B. Objektlisten statt Rohpunktwolken) vornehmen, bevor Daten an das Inter-ECU-Interface übergeben werden.
• Safety & End-to-End (E2E) Protection:
  • Für sicherheitsrelevante AD-Funktionen (ASIL B bis D) muss die SOME/IP- bzw. DDS-Verbindung zwischen ECU1 und ECU2 mittels AUTOSAR E2E-Protection (DataID, Counter, CRC) abgesichert werden.
  • Erkennung von Paketverlusten, Laufzeitverzögerungen (Jitter) und Ausfall der ECU1 muss im Proxy auf ECU2 implementiert sein (z. B. Auswertung des Service-Availability-Status und ara::com-Subscription-States).