Figure 4.1: Scope of Sensor Interface Standardization

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Funktionales Architektur- und Schnittstellenabgrenzungsdiagramm (System Boundary & Scope Definition Diagram).
• Kontext & Zweck: Das Diagramm entstammt dem Konzept-/Erläuterungsdokument AUTOSAR_AP_EXP_SensorInterfaces der AUTOSAR Adaptive Platform (AP). Es definiert die normative Demarkationslinie für Standardisierungsaktivitäten im Bereich des automatisierten Fahrens (AD / ADAS). Kernzweck ist die exakte funktionale und strukturelle Eingrenzung, auf welcher Abstraktionsstufe der Wahrnehmungspipeline (Perception Pipeline) standardisierte Datenschnittstellen definiert werden und welche Ebenen herstellerspezifisch bzw. proprietär bleiben.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Funktionsblöcke (Hierarchie von oben nach unten)

1. Automated Driving Functions (AD function 1 bis AD function m):
   • Domänenapplikationen für Bahnplanung, Längs-/Querführung und Verhaltensentscheidung (z. B. Trajectory Planner, ACC, LKA).
2. Sensordatenfusion (Fusion unit):
   • Zentrale logische Instanz zur räumlich-zeitlichen Zusammenführung heterogener Sensordaten in ein konsistentes Umgebungsmodell (World Model / Free Space Grid / Dynamic Object List).
3. Sensornahe Verarbeitungsstufen & Algorithmen:
   • CV Algorithm (Computer Vision): Bildverarbeitungseinheit zur semantischen Segmentierung, Objekterkennung, Spurerkennung und Verkehrszeichenklassifikation.
   • Tracking (Radar): Filterungs- und Tracking-Instanz (z. B. Kalman-/E-Filter) auf Basis von Radar-Reflexionen.
   • Tracking (LIDAR): 3D-Punktwolkenverarbeitung zur Clusterung, Segmentierung und Track-Generierung.
   • USS ECU (Ultrasonic Sensors ECU): Auswerte- und Triangulationseinheit für Nahfeld-Ultraschall-Echos.
4. Physikalische Sensor-Frontends:
   • Camera, Radar, LIDAR, USS (jeweils mit Kardinalität 1..*).

Schnittstellenebenen & Standardisierungs-Scope

• Ebene 1 (Logical Interface – Fusion to AD Functions):
  • Nutzlast: Fusionierte Objekte (Fused Objects), Freirauminformationen (free space information).
  • Status: Außerhalb des Fokus dieses Dokuments (separate Standardisierungsebene für Umgebungsmodelle).
• Ebene 2a (Scope of Standardization – Single Sensor to Fusion Unit):
  • Im Standardisierungsumfang (blau umrandet): Standardisierte logische Serviceschnittstelle zwischen sensorspezifischer Vorverarbeitung und Fusion.
  • Kamera-Nutzlast: Vorverarbeitete Rohdaten, Objekte, Fahrspurmarkierungen (lane markings), Verkehrszeichen (traffic signs).
  • Radar/LIDAR/USS-Nutzlast: Vorverarbeitete Rohdaten (pre-processed raw data), diskrete Objektlisten (objects).
• Ebene 2b (Electrical & Mechanical Interface – Sensor to Fusion):
  • Physikalischer Layer (Kabelbäume, Steckverbinder, Montagepunkte); normativ Out-of-Scope.
• Ebene 3a (Raw Data Logical Interface / Front End & Measurement):
  • Rohdatenschnittstellen (Kamera-Frames, Radar-Reflexionen, LIDAR-Point-Clouds, USS-Echos) sowie Trace-/Messschnittstellen; proprietär/herstellerspezifisch, Out-of-Scope.
• Ebene 3b (Electrical & Mechanical Interface on Raw Data Level):
  • Sensorelektronik und Transceiver-Hardware (z. B. CSI-2, GMSL, FPD-Link, proprietäre DSI/LIN-Busse); Out-of-Scope.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm bildet den gerichteten, mehrstufigen Datenfluss der Erfassungskette ab (Bottom-Up):

1. Erfassung (Physikalischer Layer): Transducer erfassen analoge Signale und digitalisieren diese auf Chipebene (Ebene 3b).
2. Rohdatentransfer (Ebene 3a):
   • Synchroner oder getakteter Stream von Rohdaten (Frames, Reflections, Point Cloud) über sensorspezifische Low-Level-Treiber an die Verarbeitungsinstanzen (CV Algorithm, Tracking, USS ECU).
3. Merkmalsextraktion & Vorverarbeitung:
   • Lokale Signalverarbeitung generiert deterministische geometrische und semantische Primitiven (Tracks, Bounding Boxes, Feature Points).
4. Publish-Subscribe-Transfer (Ebene 2a – Standardisierter Pfad):
   • Die Sensorverarbeitungseinheiten publizieren modellierte Sensorschnittstellen-Events über die Adaptive Platform Kommunikationsmiddleware (ara::com bzw. SOME/IP / IPC).
   • Die Übertragung erfolgt typischerweise asynchron und ereignis- bzw. zyklusgesteuert mit strikter Zeitstempelung (synchronisiert über Autosar Time Synchronization / IEEE 802.1AS).
5. Fusion & Prädiktion (Ebene 1):
   • Zyklischer Fusionszyklus konsolidiert eingehende Sensortracks zu einem kohärenten Umgebungszustand für die AD-Planungsfunktionen.

4. Normative Relevanz & Entwickler-Hinweise

• Dokumentenstatus: Als EXP (Explanatory Document) besitzt die Spezifikation informativen und konzeptionellen Charakter; sie formuliert das Architekturfundament für die konkreten SWS-Typdefinitionen der Adaptive Platform.
• Fokus auf Ebene 2a (ara::com Service Interfaces):
  • Applikations-Entwickler (Fusion / AD): Dürfen sich ausschließlich auf standardisierte Datentypen abstützen (z. B. standardisierte Koordinatensysteme nach ISO 8855, Kovarianzmatrizen für Zustandsunsicherheiten, Klassifikationswahrscheinlichkeiten und Güteindikatoren / Confidence Values).
  • Treiber- & Sensor-Hersteller (Tier-1 / Tier-2): Die Transformation proprietärer Sensordaten in die standardisierten Formate von Ebene 2a obliegt der Sensornahsoftware. Proprietäre Rohdatenformate (Ebene 3a) müssen nicht AUTOSAR-konform offengelegt werden, solange der exportierte ara::com-Service auf Ebene 2a typkonform implementiert ist.
• Latenz- und Synchronisationsanforderungen:
  • Da Ebene 2a heterogene Vorverarbeitungszeiten aufweist (z. B. aufwendige Inferenz bei CV Algorithm vs. schnelle Detektion bei Radar), müssen die Datenstrukturen auf Ebene 2a zwingend hochpräzise globale Zeitstempel (Time of Validity / Time of Measurement) beinhalten, um Phasenverschiebungen in der Fusion unit via Extrapolation kompensieren zu können.
• Architektur-Entkopplung: Die Standardisierung auf Ebene 2a ermöglicht den austauschbaren Einsatz von Sensoren unterschiedlicher Hersteller, ohne die zentrale Fusionslogik refaktorisieren zu müssen.