Figure 5.1: Sensor Interfaces dependencies to other AUTOSAR Adaptive Applications.

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Informelles Architektur-Blockdiagramm / Schichten- und Komponentenmodell der AUTOSAR Adaptive Platform (AP).
• Architektur-Kontext:
  • Funktionale Verortung im Bereich Fahrerassistenzsysteme (ADAS) und hochautomatisiertes Fahren (AD) gemäß AUTOSAR_SWS_SensorInterfaces.
  • Veranschaulicht die Entkopplung von sensornahen Datenquellen (Camera Sensor, Radar Sensor) und datenverarbeitenden Senken (Data Fusion) durch die domänenspezifische Abstraktionsschicht der Automated Driving Interfaces (ADI) auf Basis der Kommunikations-Middleware ara::com.
  • Ziel ist die Gewährleistung von Interoperabilität, Austauschbarkeit und Hardware-Unabhängigkeit heterogener Sensorik über standardisierte Dienstschnittstellen (Service-Oriented Architecture, SOA).

2. Komponenten, Entitäten & Schnittstellen

• Adaptive Applications (POSIX-Prozesse):
  • Camera Sensor (Adaptive Application): Kapselt die sensorspezifische Erfassung, Signalaufbereitung und Extraktion (z. B. Objektlisten, Fahrspurgeometrien, Verkehrszeichen, Roh-/Feature-Daten). Agiert primär als Service-Provider (Skeleton).
  • Radar Sensor (Adaptive Application): Kapselt Radartreiber und Signalverarbeitung (z. B. Reflexionspunkte/Detections, Cluster, getrackte Radarobjekte). Agiert primär als Service-Provider (Skeleton).
  • Data Fusion (Adaptive Application): Konsumiert Datenströme mehrerer Sensormodalitäten zur Bildung eines konsistenten, globalen Umfeldmodells (Environment Model). Agiert als Service-Consumer (Proxy) für die Sensor-Services und ggf. als Provider für nachgelagerte Planungsmodule (Trajectory/Motion Planning).
• Automated Driving Interfaces (ADI):
  • Standardisierte Schicht domänenspezifischer ServiceInterface-Definitionen und Datentypen (ARXML-beschrieben).
  • Beinhaltet normative Datenstrukturen wie Koordinatensysteme/Posen (ISO 8855 / ISO 23150), Zeitstempel (ara::tsync), Messunsicherheiten (Kovarianzen), Objektlisten und Freiraumgitter (Grid Maps).
• ara::com (Communication Management):
  • Standard-Funktionscluster der AUTOSAR Adaptive Platform.
  • Stellt die plattform- und transportunabhängige Service-Kommunikation (Publish/Subscribe über Events, Field-Properties sowie synchrone/asynchrone Methodenaufrufe) bereit.
• Beziehungsgefüge:
  • Vertikale Abhängigkeiten: Die Applikationen greifen über die typisierten ADI-C++-Bindings auf ara::com zu.
  • Horizontale Interaktion: Keine direkten Schnittstellen oder proprietären IPC-Kanäle zwischen den Anwendungen; die Kopplung erfolgt lose und rein dienstorientiert über Service-Instanzen.

3. Dynamisches Verhalten & Sequenzablauf

• Dienstinitialisierung & Discovery (SOA-Lifecycle):
  1. Service Offer: Die Sensor-Applikationen instanziieren die generierten Service-Skeletons der ADI-Definitionen und publizieren diese via ara::com::Skeleton::OfferService().
  2. Service Search: Data Fusion initiiert ara::com::Proxy::StartFindService() / FindService() zur Ermittlung verfügbarer Sensor-Instanzen.
  3. Subscription: Nach Instanziierung des Proxies abonniert Data Fusion die relevanten ADI-Sensor-Events (Event::Subscribe(CacheSize)).
• Zyklischer Datenfluss (Publish/Subscribe-Pfad):
  1. Erfassung & Zeitstempelung: Sensor-Anwendung erfasst Rohdaten, versieht sie mit einem hardware-synchronisierten Timestamp (ara::tsync / IEEE 802.1AS) und befüllt das ADI-konforme Datenmodell.
  2. Dispatchen: Publikation über Event::Send() (bzw. zero-copy Allokation via SampleAllocateePtr).
  3. Empfang & Verarbeitung: Benachrichtigung der Fusionsanwendung über Event-Receive-Handler (SetReceiveHandler) oder zyklisches Polling mittels GetNewSamples().
• Synchronisation & Verarbeitungslogik:
  • Asynchroner Multipath-Empfang: Daten aus Kamera und Radar treffen mit unterschiedlichen Latenzen und Abtastraten ein. Die Fusion synchronisiert die Messungen über die in den ADI-Headern enthaltenen Zeitstempel und Posen temporär und räumlich.

4. Normative Relevanz & Entwickler-Hinweise

• Architektur- und API-Vorgaben:
  • Strikte Einhaltung der in AUTOSAR_SWS_SensorInterfaces definierten Datentypen, Einheiten (SI-Einheiten, Radiant, Meter) und Koordinatensysteme; Vermeidung herstellerspezifischer Erweiterungen im ADI-Datenstrom.
• Performance & Shared-Memory (Zero-Copy):
  • Hochbitratige Sensordatenströme (insb. Kamerasensoren, hochauflösende Radarpunktwolken) erfordern zwingend optimierte ara::com-IPC-Bindings (z. B. Shared Memory / LoLa).
  • Entwickler müssen Zero-Copy-APIs (Allocate() / Send()) nutzen, um mehrfache Serialisierungs- und Kopiervorgänge zwischen den Adressräumen der POSIX-Prozesse zu verhindern.
• Synchronisationsanforderung (ara::tsync):
  • Alle Sensor-Events müssen über eine gemeinsame, netzwerkweit synchronisierte Zeitbasis referenziert sein, um eine valide zeitliche Assoziation in der Data Fusion zu ermöglichen.
• ARXML-Modellierung & Deployment:
  • Konfiguration von AdaptiveApplicationSwComponentType mit korrespondierenden ProvidedPortPrototypes (Sensor) und RequiredPortPrototypes (Fusion).
  • Zuweisung zu konkreten Service-Instanzen (ProvidedSomeipServiceInstance / RequiredSomeipServiceInstance für Netzwerkübertragung oder interne IPC-Service-Instances) im Execution- und Service-Instance-Manifest.
• Funktionale Sicherheit (ASIL):
  • Beim Datenaustausch über Partitions- oder Steuergerätegrenzen hinweg sind End-to-End-Schutzmechanismen (E2E-Protection) innerhalb der ara::com-Konfiguration zwingend zu aktivieren, um Verfälschungen, Jitter oder Paketverluste detektieren zu können.