Figure 5.4: Service Registering flow for capability vector checking

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm mit assoziierter IDL-/Interface-Strukturdefinition (Service-Interface-Deklaration in Pseudo-C++/IDL).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (ara::com / Service-Oriented Architecture) im Kontext von AUTOSAR_EXP_SensorInterfaces.
• Technischer Zweck: Dynamische Feature-Aushandlung auf Applikationsebene („Capability Vector Checking“). Standardisiert das Auffinden und Validieren von optionalen Sensordatenfeldern (z. B. nach ISO-Profilen) zwischen Service-Provider (Sensor) und Service-Consumer (User), um Schnittstellen-Explosion bei variabler Sensorausstattung zu vermeiden.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • Provider: Sensor-Dienstleister (z. B. Smart Sensor ECU / Sensor Application). Hält eine feste Merkmalsausprägung (CAP = 1101 bzw. CAP = 1110).
  • SD / Registry: AUTOSAR Service Discovery Daemon bzw. Kommunikations-Registry (ara::com Runtime Broker).
  • User: Sensor-Consumer / Client-Applikation mit spezifischen Mindestanforderungen an den Datenstrom (CAP = 0001).
• Service-Interface Service-Example:
  • Methode:
    • const bitVector capabilities(): Liefert den Bitvektor der aktuell vom Provider implementierten optionalen Features/Attribute.
  • Pflichtfelder (Mandatory Data Elements):
    • int16 a
    • float32 c
    • serviceStructTypeX d
  • Optionale Felder (Optional Data Elements mit ISO-Profilzuordnung):
    • optional int16 b (zugeordnet ISO-Profil A)
    • optional serviceStructTypeY e (zugeordnet ISO-Profil B)
    • optional serviceStructTypeW f (zugeordnet ISO-Profil C)
• Kardinalitäten / Bit-Mapping:
  • Jedes Bit im bitVector repräsentiert ein diskretes optionales Datenfeld bzw. Funktionsprofil. Bit 0 (LSB) korrespondiert hier mit dem vom User geforderten optionalen Datensatz.

3. Dynamisches Verhalten & Sequenzablauf

1. Service Announcement: Provider publiziert seine Dienstverfügbarkeit via OfferService(Service-Example) an die zentrale SD / Registry.
2. Service Discovery: User fragt über FindService(Service-Example) nach passenden Diensten an. Die SD / Registry antwortet mit dem Service-Handle (Handle of Service-Example Provider). Zu diesem Zeitpunkt ist nur die grundlegende Interface-ID validiert, nicht jedoch der Umfang der optionalen Member.
3. Capability Handshake (Client-to-Provider RPC): Der User initiiert über das erhaltene Handle einen synchronen/asynchronen RPC-Methodenaufruf capabilities() direkt an den Provider.
4. Evaluierung & Verzweigung (Subset-Prüfung via Bitmaske):
   • Positivpfad (Match): Provider meldet 1101. Prüflogik: (CAP_User \ & \ CAP_Provider) == CAP_User → (0001_2 \ & \ 1101_2) = 0001_2 (Bedingung erfüllt: OK). Das geforderte optionale Feature ist vorhanden; der Verbindungsaufbau / das Event-Subscription wird fortgesetzt.
   • Negativpfad (Mismatch): Anderer/rekonfigurierter Provider meldet 1110. → (0001_2 \ & \ 1110_2) = 0000_2 ≠ 0001_2 (Bedingung verletzt: KO). Dem Provider fehlt das vom Consumer zwingend benötigte optionale Feld.
5. Abbruchbedingung: Bei KO verwirft der User das Provider-Handle; es erfolgt keine Datenübertragung oder Event-Abonnierung für diese Service-Instanz.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag & Guarding: Consumer-Applikationen dürfen optionale Felder (std::optional<T> / ara::core::Optional<T>) nicht unkonditioniert dereferenzieren. Vor dem Zugriff auf optionale Nutzdaten ist der Aufruf von capabilities() und die Bitmasken-Prüfung zwingend durchzuführen.
• SOME/IP-Serialisierung (Wire-Level): Optionale Struct-Elemente bedingen auf Transportebene (SOME/IP-Transformation) TLV-Encoding (Tag-Length-Value) gemäß AUTOSAR PRS SOME/IP. Der capabilities()-Mechanismus dient der applikativen Vorabprüfung, um Deserialisierungs- und Typfehler zur Laufzeit zu unterbinden.
• Initialisierungslatenz: Die zusätzliche Roundtrip-Latenz des RPCs capabilities() nach dem SD-Find verlängert die Time-to-Service. Für harte Echtzeitanforderungen sollte geprüft werden, ob Capabilities statisch via SOME/IP-SD-Instance-IDs/Endpoint-Options oder Manifest-Konfiguration (ServiceInstanceDeployment) vorausgewählt werden können.