Figure 24.1: Sensor Interfaces Architecture

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptionelles Schichten- und Komponentenarchitektur-Diagramm (funktionale Dekomposition).
• Technischer Zweck & Einordnung:
  • Verortung in der AUTOSAR Adaptive Platform (AP), Domäne Fahrerassistenz/Automatisiertes Fahren (Perception & Sensor Subsystem).
  • Systematische Entkopplung von Sensordaten-Erzeugern unterschiedlicher Autonomie- und Integrationsgrade von den übergeordneten Steuerungs- und Fusionsfunktionen.
  • Standardisierung des Datenzugriffs über eine einheitliche, serviceorientierte Middleware-Abstraktion (Sensor Interfaces auf Basis von ara::com).

2. Komponenten, Entitäten & Schnittstellen

Entitäten nach Klassifikation (gemäß Farblegende)

• Adaptive Application (Orange – native AP-Prozesse):
  • Application: Übergeordnete logische Einheit im User Space (POSIX PSE51) mit Zugriff auf die Sensor-Middleware.
  • Smart Sensor: Nativer AP-Sensor-Stack, der Akquise und Auswertung in einer AP-Anwendung vereint.
  • Sensor Adapter (mittig & rechts): Brückenkomponenten / Proxies zur Transformation proprietärer oder externer Sensor-Streams in standardisierte AP-Services.
• Other Application (Grau – Non-AP / Externe Systeme):
  • Simple Sensor: Low-Level-Hardware bzw. Microcontroller-Knoten ohne eigene Rechenkapazität für komplexe Merkmalsextraktion.
  • Legacy Smart Sensor: Existierende ECUs (z. B. AUTOSAR Classic Platform, proprietäre Radar-/Kamera-Controller) mit integrierter Signalverarbeitung, aber nicht-AP-konformer Schnittstelle.
• Functional Elements (Dunkelrot – modulare Funktionsblöcke / Verarbeitungsstufen):
  • Reception: Rohdatenerfassung, Hardware-Sampling, Treiberabstraktion (z. B. MIPI CSI-2, GMSL, SPI, CAN-FD).
  • Processing: Signalverarbeitung, Objekterkennung, Filterung (z. B. Kalman-Filter, Feature Extraction, DNN-Inferenz).
  • Post-Processing: Koordinatentransformation (Sensor- auf Fahrzeug-Koordinatensystem), Latenzkompensation, Formatkonvertierung.
  • Data Fusion Application: Zeitliche und räumliche Fusionierung redundanter/komplementärer Sensormodalitäten.
  • Automated Driving Function: Trajektorienplanung, Situationsanalyse und Aktoranforderung.
• Sensor Interfaces (Blauer Balken):
  • Serviceorientierte Abstraktionsschicht. Modelliert als AUTOSAR Adaptive Service Interfaces (ara::com), typischerweise realisiert über Events und Fields (Publish/Subscribe-Semantik).

Integrationsmuster & Beziehungen

1. Nativer Pfad (Smart Sensor): Direktbindung an Sensor Interfaces. Vollständige Kapselung von Reception und Processing in der Adaptive Application.
2. Adapter-Pfad für einfache Sensoren (Simple Sensor → Sensor Adapter): Simple Sensor liefert Rohdaten via Bus/Hardware-Link an den Sensor Adapter. Dieser übernimmt das Processing auf AP-Knotenebene und publiziert das Ergebnis.
3. Adapter-Pfad für Bestands-Sensoren (Legacy Smart Sensor → Sensor Adapter): Vorverarbeitete Objektdaten/Features werden über Legacy-Bussysteme (z. B. SOME/IP, Classic PDU) empfangen; der Adapter führt lediglich das Post-Processing zur Angleichung an das semantische AP-Datenmodell durch.

3. Dynamisches Verhalten & Sequenzablauf

• Trigger & Ingestion:
  • Zyklischer oder unterbrechungsgesteuerter Trigger am physischen Sensor stößt Reception an.
• Synchronisation & Vorverarbeitung:
  • Zeitstempelung der Sensordaten an der Quelle gemäß gPTP / IEEE 802.1AS (ara::ts).
  • Asynchrone Übergabe von Roh- bzw. Feature-Daten an die Verarbeitungsstufen (Processing / Post-Processing).
• Publikationspfad (Provider-Rolle):
  • Nach Abschluss von Processing bzw. Post-Processing serialisiert die jeweilige Adaptive Application (Smart Sensor oder Sensor Adapter) die Datensätze und sendet sie über ara::com::Event::Send() oder aktualisiert ein ara::com::Field.
• Konsumptionspfad (Consumer-Rolle):
  • Data Fusion Application und Automated Driving Function abonnieren Events (Subscribe()).
  • Datentransfer erfolgt je nach Deployment lokal via IPC/Shared Memory (Zero-Copy für hochbitratige Punktwolken/Bilder) oder netzwerkweit via SOME/IP-Binding.
  • Konsumtion erfolgt ereignisgesteuert via Event-Receive-Handler oder polling-basiert über GetNewSamples().

4. Normative Relevanz & Entwickler-Hinweise

• API- und Service-Vertrag:
  • Entwickler von Application (Fusion/AD) programmieren strikt gegen die abstrakten Sensor Interfaces (definierte ARXML-Datentypen / C++ Proxies). Die physische Herkunft (Adapter vs. nativer Smart Sensor) ist für den Konsumenten transparent.
• Sensor-Adapter-Implementierung:
  • Adapter fungieren als Protokollumsetzer und Puffer. Sie müssen Taktschwankungen, Jitter und Protokollinkonsistenzen externer Sensoren kompensieren.
  • Kritisch für funktionale Sicherheit (ISO 26262): Validierung von Plausibilität, Alive-Countern und CRC bereits im Adapter vor Einspeisung in die Sensor Interfaces.
• Ressourcenallokation & Scheduling:
  • Processing innerhalb eines Sensor Adapter erfordert hohe Rechenleistung (GPU/NPU/DSP-Bindung); muss im Execution Manifest mit entsprechenden CPU-Affinitäten, Prioritäten und Cgroups konfiguriert werden.
  • Post-Processing ist latenzkritisch, erfordert jedoch primär deterministische CPU-Zyklen zur Transformation von Koordinatenmatrizen.
• Konfigurationsartefakte:
  • Bereitstellung passender Service Instance Deployment Manifests für IPC- und Network-Bindings, um Bandbreitenengpässe zwischen Adaptern und Konsumenten zu vermeiden.