Figure 5.3: Service Template with Capability vector and service profiles

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptuelles Schnittstellen- und Datenstrukturschaubild (IDL-/Pseudocode-Strukturdarstellung mit semantischer Annotation).
• Technischer Zweck: Modellierung des Mappings von ISO-Sensorstandards (insbesondere ISO 23150) auf serviceorientierte AUTOSAR-Schnittstellen (primär AUTOSAR Adaptive Platform / ara::com).
• Architektur-Einordnung:
  • Standardisierung generischer Sensorschnittstellen (Radar, Kamera, Lidar, Ultraschall) für ADAS/AD-Umgebungen.
  • Trennung von statischer Dienstkonfiguration (Service-Profile) und dynamischer Laufzeit-Fähigkeitserkennung (Capability Vector) zur Optimierung von Serialisierungsaufwand, Bandbreite und Speicherallokation.

2. Komponenten, Entitäten & Schnittstellen

• Service-Profile (Entwurfskonzept flex.startup / Profilierungsdimension ➁):
  • Service-Example-1 (Low-Precision / Low-Footprint Profil):
    • Basistypen mit reduzierter Wortbreite: int8 a, optional int8 b, float16 c, dynamische Längenfelder optional int8 length-x, optional int8 length-y.
  • Service-Example-2 (High-Precision / Extended Profil):
    • Skalierte Datentypen für höhere Dynamik/Auflösung: int16 a, optional int16 b, float32 c, Längenfelder optional int16 length-x, optional int16 length-y.
  • Identische Kernstrukturen in beiden Profilen:
    • Feste Felder: serviceStructTypeX d, Array fixer Größe serviceArrayTypeQ[16] q.
    • Optionale Strukturen/Pointer: optional serviceStructTypeY e, optional serviceStructTypeW f, optional serviceArrayTypeMPointer x, optional serviceArrayTypeNPionter y.
• Capability Vector (Dimension ➀):
  • Schnittstellenmethode / Getter: const bitVector capabilities(); (Abfrage der anbieterseitig unterstützten ISO-Optionals).
  • Vektorformat: Tupel aus Ein-Bit-Flags (0/1, 0/1, 0/1, 0/1, 0/1, 0/1, 0/1) gemappt auf standardisierte ISO-Optionals:
    • A: Feld b (optional int8/int16)
    • B: Struktur e (optional serviceStructTypeY)
    • C: Struktur f (optional serviceStructTypeW)
    • D: Feld length-x (optional int8/int16)
    • E: Pointer/Array x (optional serviceArrayTypeMPointer)
    • F: Feld length-y (optional int8/int16)
    • H: Pointer/Array y (optional serviceArrayTypeNPionter)

3. Dynamisches Verhalten & Sequenzablauf

1. Service Discovery & Binding (Startphase / flex.startup):
   • Der Client (z. B. Sensor Fusion Algorithmus) sucht und bindet das instanziierte Service-Interface (Service-Example-1 oder Service-Example-2) passend zu seinen Rechen- und Auflösungsanforderungen.
2. Fähigkeitsabfrage (Capability Negotiation):
   • Synchrone Abfrage der Sensorfähigkeiten über capabilities() vor Beginn des zyklischen Datenstreamings bzw. beim Initialisierungswechsel.
3. Payload-Verarbeitung & Deserialisierung:
   • Der Client wertet den Bitvektor aus. Ist Bit i nicht gesetzt (0), wird das entsprechende optionale Datum im Deserialisierer/SOME/IP-Parser übersprungen bzw. nicht allokiert.
   • Dynamische Arrays (x, y) werden nur dann dereferenziert und geparst, wenn sowohl das Längenfeld (D bzw. F) als auch der Datenpointer (E bzw. H) durch gesetzte Bits als gültig markiert sind.

4. Normative Relevanz & Entwickler-Hinweise

• SOME/IP- und Serialisierungs-Vertrag:
  • Optionale Felder bedingen eine dynamische Serialisierung (z. B. TLV-Encoding im SOME/IP-Payload) oder die strikte Auswertung des capabilities()-Bitvektors vor dem Zugriff auf Datenfelder, um Out-of-Bounds-Lesefehler oder Null-Pointer-Dereferenzierungen zu verhindern.
• C++-Interface-Design (ara::com / Adaptive AUTOSAR):
  • Optionale Attribute erfordern typischerweise Wrapper wie ara::core::Optional<T> oder std::optional<T>.
  • Dynamische Längenfelder (length-x, length-y) müssen konsistent mit der Containergröße der Pointer/Arrays (serviceArrayTypeMPointer) synchronisiert sein; Längen-Inkonsistenzen müssen applikationsseitig über Validierungsroutinen abgefangen werden.
• Architektur-Richtlinie für Sensor-Integratoren:
  • Sensor-Zulieferer müssen das statische Profil (Datentypenauflösung 8/16-Bit vs. 16/32-Bit) zur Konfigurationszeit festlegen.
  • Optionale Sensordaten (z. B. Objekterweiterungen, Vertrauenswerte, Kovarianzmatrizen) dürfen zur Laufzeit dynamisch über den Capability-Vektor de-/aktiviert werden, ohne dass eine neue Interface-Definition generiert werden muss.