Figure 5.2: ISO mapping to Smart Sensors Services

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptuelles Architektur- und Mapping-Diagramm (Dekomposition von Schnittstellenanforderungen in Service-Schnittstellen).
• Technischer Zweck: Transformation der standardisierten Datenschnittstellen-Definition für intelligente Sensoren (Smart Sensors gemäß ISO 23150 / ISO-Umfeldsensordefinition) in modulare Service-Interfaces der AUTOSAR Adaptive Platform (ara::com).
• Funktionale Einordnung: Bildet die Brücke zwischen externen Sensor-Standards und der serviceorientierten Architektur (SOA) in Adaptive AUTOSAR. Es trennt vorverarbeitete Umfelddaten strikt in abstrahierte, technologieunabhängige Objekte (Object Level) und technologiespezifische Roh- bzw. Merkmalsdetektionen (Feature Level).

2. Komponenten, Entitäten & Schnittstellen

ISO Definition Smart Sensor (Eingangsdomäne)

Strukturiert Sensorausgaben in zwei Abstraktionsebenen und vier Datenkategorien:

• Object Level:
  1. object/tracking list: Zeitlich konsistente, gefilterte/getrackte dynamische und statische Objekte.
  2. road mark list: Fahrbahnmarkierungen (z. B. Spur- und Begrenzungslinien, Richtungspfeile).
  3. land mark list: Stationäre Landmarken und Infrastrukturmerkmale (z. B. Leitpfosten, Schilder, Schilderbrücken).
• Feature Level:
  1. detection list per technology (4x): Detektionspunkte/-cluster vor der Objektbildung für vier Sensor-Physiken.

AUTOSAR Smart Sensor Services (Zielarchitektur / ara::com Service Interfaces)

Überführung in disjunkte Service-Interfaces, die modular kombiniert werden können:

• Object Level Services (Technologieunabhängig):
  • tracking service: Bereitstellung von Track-/Objektlisten.
  • roadmark service: Bereitstellung semantischer Fahrbahnmarkierungsdaten.
  • landmark service: Bereitstellung geometrischer/semantischer Landmarkendaten.
• Feature Level Services (Technologiespezifisch):
  • <Sensor Technology> detection service: Generisches Basismuster/Template für Detektionslisten.
  • Konkrete Ausprägungen (1:n-Spezialisierung/Instanziierung):
    • Camera detection service: Optische Merkmale, Pixel-Cluster, Kanten.
    • LIDAR detection service: 3D-Punktwolken, Reflexionsintensitäten.
    • Radar detection service: Reflexionspunkte, Radialgeschwindigkeiten (Doppler), Radar Cross Section (RCS).
    • USS detection service: Ultraschall-Echos, Laufzeiten, Abstandsschätzungen.

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

• Kommunikationsmuster: Statisches Strukturmapping ohne sequenzielle Zeitachse. Laufzeitkommunikation erfolgt rein ereignisbasiert (Publish/Subscribe via ara::com::Event / SOME/IP-Events oder IPC).
• Aktualisierungsraten & Latenzen:
  • Feature Level: Hochfrequente, zyklische Übertragung (z. B. 20–50 Hz) mit minimaler Sensorlatenz für echtzeitkritische Low-Level-Fusion oder Rohdatenverarbeitung.
  • Object Level: Zyklische Bereitstellung nach Tracker-Filterung (z. B. Kalman-Filter, Multi-Target-Tracking) mit höherem Abstraktionsgrad.
• Dienst-Kopplung: Vollständig orthogonal; ein Smart Sensor kann je nach Rechenkapazität und Sensoraufbau ausschließlich Feature-Level-Services (Near-Sensor-Processing), ausschließlich Object-Level-Services oder eine Kombination aus beiden publizieren.

4. Normative Relevanz & Entwickler-Hinweise

• Dokumentenstatus: Teil von AUTOSAR_AP_EXP_SensorInterfaces (Explanatory Document). Es besitzt empfehlenden Leitfaden-Charakter (Best Practice), definiert jedoch das Referenzmodell für die Auslegung von ServiceInterface-Beschreibungen in ARXML.
• Service-Granularität & Bandbreiten-Optimierung:
  • Die Entflechtung in separate Services (tracking, roadmark, landmark, <Tech> detection) verhindert monolithische Datentypen.
  • Adaptive Applikationen (z. B. Trajektorienplaner, Lokalisierung) abonnieren selektiv nur die benötigten Teilströme (Subscribe()). Dies minimiert Deserialisierungs- und Serialisierungs-Overhead sowie Buslast (SOME/IP bzw. Zero-Copy Shared Memory IPC).
• ISO 23150-Konformität: Implementierer von Sensortreibern und Fusion-Stacks müssen die Datenstrukturen (z. B. Koordinatensysteme nach ISO 8855, Existenzwahrscheinlichkeiten, Kovarianzmatrizen) kompatibel zum ISO 23150-Datenmodell in C++-Strukturen kapseln.
• Abstraktionsgrad für Konsumenten:
  • Konsumenten des Object Level bleiben unabhängig von der verbauten Sensortechnologie (Hardware-Abstraktion).
  • Konsumenten des Feature Level sind hardware-/physik-gebunden und typischerweise proprietären Vorverarbeitungs- oder Sensorfusions-Komponenten vorbehalten.