Figure 5.1: Future Architectures for Smart Sensor APIs

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Hybrides Architekturschaubild (links: Schichten- und Komponentenmodell der AUTOSAR Adaptive Platform / ARA; rechts: Topologie- und Deployment-Szenarien).
• Technischer Zweck: Spezifikationsbegleitende Konzeptdarstellung (AUTOSAR_EXP_SensorInterfaces) zur Verortung des ara::adi service (Smart Sensor API / Abstract Device Interface) innerhalb des Adaptive Platform (AP) Stacks sowie Veranschaulichung der drei Ziel-Topologien zur Erfassung hochbitratiger Sensordaten (z. B. Radar, Lidar, Kamera, Ultraschall) für ADAS/AD-Applikationen.
• Funktionale Einordnung: Definiert die Standardisierungsgrenze zwischen fahrzeugeigenen ADAS/AD-Applikationen auf High-Performance-Compute-Plattformen (HPC) und intelligenten Sensorknoten (Smart Sensors), wahlweise angebunden über native AP-Instanzen oder AUTOSAR Classic Platform (CP) Steuergeräte.

2. Komponenten, Entitäten & Schnittstellen

Schichtenarchitektur (Adaptive Platform Stack, linke Bildhälfte)

• User Applications:
  • Adaptive Application: SWCs für Fahrfunktionen (ADAS/AD).
  • ASW::XYZ / ASW::ABC Non-PF Service: Anwendungsnahe Dienste außerhalb der AUTOSAR-Plattform-Standardisierung.
• AUTOSAR Runtime for Adaptive Applications (ARA):
  • Functional Clusters (APIs): ara::com (Transportprotokolle: SOME/IP, DDS, lokales IPC), ara::core (Basistypen, Result/Future-Handling), ara::exec (Deterministic Client, Execution Management), ara::time (Synchronisation via gPTP / IEEE 802.1AS), ara::log, ara::iam, ara::crypto, ara::phm, ara::per, ara::rest.
  • Functional Clusters (Services): ara::state service, ara::diag service, ara::s2s service (Signal-to-Service Mapping für CP-Interoperabilität), ara::nm service, ara::ucm service.
• Smart Sensor Service Erweiterung:
  • ara::adi service (Smart Sensor API / Abstract Device Interface): Als Service Cluster an der Schnittstelle zwischen Hardware/Kernel-Abstraktion (OS-Treiber/POSIX PSE51) und ARA-Middleware verortet. Bietet standardisierte Service-Schnittstellen zur Konfiguration, Statusüberwachung und Datenakquise von Sensoren.
• Basis-Infrastruktur:
  • POSIX PSE51 OS / C++ STL OS-Laufzeitumgebung.
  • (Virtual) Machine / Container / Hardware.

Topologie- & Deployment-Szenarien (rechte Bildhälfte)

1. Szenario 1 – All Smart Sensors @ Adaptive Platform:
   • Zentral-ECU (AP) führt ADAS/AD-Applikationen aus.
   • Sensoren hängen entweder direkt lokal an der AP-Plattform (Interface-Treiber/PCIe/MIPI/GbE) oder an abgesetzten AP-Satelliten (über Automotive Ethernet / SOME/IP / DDS).
2. Szenario 2 – All Smart Sensors @ Classic Platform:
   • Zentral-ECU (AP) aggregiert Rohdaten oder vorverarbeitete Sensordaten ausschließlich über AUTOSAR Classic (CP) ECUs.
   • Anbindung über Signal-to-Service Gatewaying (ara::s2s) oder PDU-basiertes SOME/IP.
3. Szenario 3 – Hybrid (Smart Sensors @ Adaptive & Classic Platform):
   • Mischtopologie: Lokale Direktverbindung hochbitratiger Sensoren am AP-Knoten, ergänzt um CAN/Ethernet-angebundene CP-Sensor-ECUs (z. B. Ultraschall/Radsensoren) und AP-Satelliten-ECUs (z. B. Front-Kamera/Imaging-Radar).

3. Dynamisches Verhalten & Sequenzablauf

• Lokaler Datenpfad (AP-nativ):
  • Sensor triggert Hardware-Interrupt / DMA-Pufferung im Host-OS.
  • ara::adi greift über POSIX-Treiberdateideskriptoren / Shared Memory auf Sensorframes zu.
  • Bereitstellung an die Adaptive Application via ara::com (Zero-Copy IPC) oder typsichere C++-Methoden/Events des ADI-Services.
• Entfernter Datenpfad (AP-zu-AP / CP-zu-AP):
  • Sensorerfassung erfolgt auf Satellitenknoten (CP via Basic Software Stack IoHwAb/CDD/Rte oder AP via lokalem ara::adi).
  • Serialisierung der Sensordaten und Metadaten (Zeitstempel, Gültigkeit, Covarianz-Matrizen).
  • Transport über Ethernet (SOME/IP-Events oder DDS-Topics). Bei CP-Knoten ohne SOME/IP-Stack übernimmt ara::s2s die Signal-zu-Service-Transformation im Empfangs-AP-Host.
• Synchronisation & Monitoring:
  • Zeitharmonisierung über ara::time gewährleistet korrelierte Sensordatenfusion.
  • Laufzeitüberwachung der Sensor-Streams durch ara::phm (Alive Supervision, Deadline Monitoring).

4. Normative Relevanz & Entwickler-Hinweise

• Architektur- und API-Design:
  • Die Anwendungslogik (ADAS/AD) ist strikt hardwareunabhängig zu implementieren: Zugriffe auf Sensordaten dürfen nicht direkt auf OS-Level oder per hardcodiertem Treiber erfolgen, sondern müssen über Service-Schnittstellen (ara::com Skeleton/Proxy oder dedizierte ara::adi-Service-Instanzen) gekapselt werden.
• Portabilität & Skalierbarkeit:
  • Durch die standardisierte Abstraktion bleibt die Applikationssoftware kompatibel zu allen drei Szenarien (reine AP-Satelliten, klassische CP-Peripherie oder Mischformen), ohne dass die C++-Applikationsschicht neu kompiliert werden muss.
• Latenz- und Bandbreitenaspekte:
  • Für Rohdatenströme (z. B. Raw-Video, Punktwolken) ist in Szenario 1 & 3 der Zero-Copy-Datenaustausch innerhalb des AP-Knotens zu evaluieren.
  • In Szenario 2 limitieren die PDU-Payload-Größen und Gateway-Latenzen der CP-ECUs die Übertragung unkomprimierter Daten; typischerweise werden hier objektbasierte Sensordaten (Objektlisten) übertragen.