Figure 7.1: Functional elements communicating via ADI

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelles Architektur- und Schichtenmodell / Funktionsblock- und Schnittstellentopologie (Komponenten- und Konnektorsicht).
• Technischer Zweck: Spezifikation der Integrationsmuster für Umfeldsensorik in der AUTOSAR Adaptive Platform (AP). Das Diagramm visualisiert die Entkopplung von Sensordaten-Erzeugern (Hardware, Firmware, Vorverarbeitung) und übergeordneten ADAS/AD-Konsumenten über die standardisierten Automated Driving Interfaces (ADI) gemäß AUTOSAR_AP_SWS_SensorInterfaces.
• Systemische Einordnung: Definiert die architektonischen Grenzen zwischen nativen Adaptive Applications (AA) auf Basis von ARA (ara::com) und externen/nicht-adaptiven Entitäten (Other Application, z. B. Classic Platform ECUs, Bare-Metal-Sensorknoten oder proprietäre Smart-Sensoren).

2. Komponenten, Entitäten & Schnittstellen

Entitätstypen (gemäß Legende)

• Adaptive Application (Hellorange): Native AUTOSAR Adaptive Plattform-Prozesse, die im POSIX-OS-Userland ausgeführt werden und ARA-Dienste nutzen.
• Other Application (Dunkelgrau): Plattformfremde oder nicht-native Software- bzw. Firmware-Instanzen (z. B. AUTOSAR Classic, sensorintegrierte DSP/ASIC-Firmware, externe Sensor-Steuergeräte).
• Functional Element (Rot abgerundet): Abgegrenzte funktionale Verarbeitungsblöcke (Algorithmen- oder I/O-Bausteine) innerhalb einer Applikationsgrenze.

Vertikale Schichten & Akteure

• Top-Tier / Konsumenten (Application [Adaptive Application]):
  • Data Fusion Application (Funktionales Element): Multimodale Sensordatenfusion, Objekttarget-Tracking und Umfeldmodellierung.
  • Automated Driving Function (Funktionales Element): Trajektorienplanung, Situationsanalyse und Verhaltenssteuerung.
• Schnittstellenebene (Automated Driving Interfaces (ADI)):
  • Standardisierte, serviceorientierte Service-Interfaces (ara::com Service Contracts, modelliert in ARXML/Franca IDL).
  • Transportieren normierte Sensordatenstrukturen (z. B. Objektlisten, Tracking-Zustände, Roh-/Merkmalsdaten, Lidar-/Radar-Pointclouds, Kamera-Detektionen, Freiraumgeometrien).
• Bottom-Tier / Erzeuger (Drei komplementäre Integrationsmuster):
  1. Direct Smart Sensor Pattern:
     • Smart Sensor [Adaptive Application]: Voll integrierter, AP-fähiger Sensor.
     • Enthaltene Elemente: Reception (Sensordatenerfassung/Treiberanbindung) und Processing (Signalverarbeitung/Merkmalsextraktion). Publiziert direkt auf die ADI.
  2. Simple Sensor Adapter Pattern:
     • Simple Sensor [Other Application]: Nicht-intelligenter Sensor (z. B. Rohdaten-Kamerakopf, Basissensorik) mit funktionalem Element Reception.
     • Sensor Adapter [Adaptive Application]: Bridge-Applikation auf der AP; enthält das Element Processing (z. B. Objekterkennung auf Rohdaten) und wandelt das proprietäre Interface in standardisierte ADI-Dienste um.
  3. Legacy Smart Sensor Adapter Pattern:
     • Legacy Smart Sensor [Other Application]: Externer intelligenter Sensor (z. B. bestehende Classic-ECU oder Tier-1-Smart-Kamera mit Onboard-Tracking); enthält Reception und Processing.
     • Sensor Adapter [Adaptive Application]: Übersetzungskomponente auf der AP; führt Post-Processing durch (z. B. Koordinatentransformation nach ISO 8855, Zeitstempelharmonisierung, Repräsentationsanpassung) und stellt das Ergebnis via ADI bereit.

3. Dynamisches Verhalten & Sequenzablauf

1. Datenerfassung (Reception):
   • Physische Signalwandlung und Frame-Empfang (z. B. über MIPI CSI-2, Ethernet, CAN-FD, SPI) am Sensorknoten bzw. Treiber-Frontend.
2. Primärverarbeitung (Processing):
   • Tiefpassfilterung, Rauschunterdrückung, Objekterkennung, Clustering oder Feature-Extraction. Findet entweder sensor-lokal (Smart Sensor, Legacy Smart Sensor) oder zentral im AP-Host (Sensor Adapter für Simple Sensor) statt.
3. Harmonisierung & Normalisierung (Post-Processing):
   • Bei Legacy-Sensoren: Transformation proprietärer Bus-Nachrichtenstrukturen in standardisierte ADI-Koordinatensysteme (Fahrzeug- vs. Sensorkoordinaten), Standardisierung von Kovarianzmatrizen sowie Resynchronisation der Zeitstempel via ara::tsync (IEEE 802.1AS / gPTP).
4. Service-Orientierte Publikation (ADI via ara::com):
   • Die Erzeuger fungieren als Service-Skeleton / Event-Publisher und stellen Daten als Events oder Fields (Push-Prinzip, zyklisch oder Event-getriggert) bereit.
5. Abonnement & Fusion:
   • Data Fusion Application und Automated Driving Function agieren als Service-Proxies, abonnieren die ADI-Events asynchron, verarbeiten die normalisierten Datenströme deterministisch und triggern die nachgelagerte Aktorik.

4. Normative Relevanz & Entwickler-Hinweise

• Entkopplungsgebot: Applikationsentwickler für Fusions- und Fahrfunktionen dürfen keine proprietären Treiberschnittstellen oder hardwarespezifischen APIs referenzieren. Der Softwarevertrag besteht ausschließlich gegen die typisierten Service-Interfaces der ADI.
• Adapter-Pflicht für Non-AP-Sensoren: Für Drittanbieter- oder Classic-Plattform-Sensoren muss zwingend ein Sensor Adapter als native Adaptive Application implementiert werden. Dieser kapselt proprietäre Socket-/Bus-Zugriffe (z. B. POSIX-Sockets, Raw-Ethernet, Device-Nodes unter /dev) und exponiert ein konformes ara::com-Skeleton.
• Latenz- und Determinismus-Einschränkungen: Da der Sensor Adapter zusätzliche IPC- bzw. Prozesswechsel verursacht, ist bei hochfrequenten Rohdatenströmen (z. B. unkomprimierte Video- oder Radar-Cube-Streams) Shared-Memory-IPC (z. B. Zero-Copy via ara::com) vorzusehen.
• Zeitbasis & Synchronisation: Alle über die ADI bereitgestellten Datenstrukturen erfordern standardisierte Zeitstempel (AUTOSAR Timestamp-Format), um in der Data Fusion Application zeitlich korrelierbar zu sein.