Figure 5.5: Service Registering flow Smart Sensor API

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Hybrides UML-Sequenzdiagramm mit assoziiertem C++11/C++14-Code-Mapping (ara::com-API-Aufrufe).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Domäne ADAS / Sensor-Subsysteme gemäß AUTOSAR_EXP_SensorInterfaces.
• Funktionaler Zweck: Standardisierter Service-Registrierungs- und Discovery-Ablauf für Smart-Sensor-APIs (exemplarisch: Radar-Sensor). Dargestellt wird die dynamische Dienstinitialisierung, Feature-/Capability-Abfrage zur Laufzeit (Feature-Discovery) sowie die anschließende bedingte Ereignis-Abonnierung (Event Subscription) zwischen Sensor-Provider (Skeleton) und Sensor-Konsument/Client (Proxy).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Rollen:
  • provider (Smart Sensor / Radar-Instanz): Implementiert das Service-Skeleton (smartSensorRadar_skeleton, Namespace-Beispiel renault::ex::smartsensor::...).
  • client (ADAS-Konsument / z. B. EnvironmentModel): Nutzt die Service-Proxy-Instanz (smartSensorRadar_proxy).
• Schnittstellen & Entitäten (ara::com):
  • Service Discovery: OfferService() (Skeleton-seitig) und StartFindService() mit Übergabe eines Find-Service-Handlers (FindServiceHandler Callback / Lambda).
  • Handle-Container: ara::com::ServiceHandleContainer<...::HandleType> zur Speicherung von Service-Instanzreferenzen (Kardinalität 0..*, im Code handles.size() > 0).
  • Synchronisationsprimitive: std::mutex (smartSensorRadar_proxy_mutex) und std::lock_guard zur thread-sicheren Instanziierung des Smart-Pointers (std::make_shared<...::proxy::radar>).
  • Methoden-Interface (Request/Response): getCapabilitySignature() mit Rückgabetyp ara::core::Future<CapabilitySignatureType>.
  • Event-Interfaces (Publish/Subscribe):
    • baseEvent: Pflicht-Ereigniskanal für Sensor-Basisdaten.
    • optionalEvent: Optionaler Ereigniskanal für erweiterte Sensordaten (abhängig von der Hardware-Fähigkeit).
  • Cache-Policy: ara::com::EventCacheUpdatePolicy::kNewestN mit Sample-Puffergröße N = 1.

3. Dynamisches Verhalten & Sequenzablauf

1. Service Registration & Discovery (Schritt 1):
   • Provider: Signalisiert Dienstbereitschaft über das Netzwerk via smartSensorRadar_skeleton->OfferService() (über SOME/IP-SD oder IPC).
   • Client: Registriert asynchronen Discovery-Listener via StartFindService(...). Bei Eintreffen verfügbarer Handles erfolgt die Ausführung des Callbacks serviceAvailabilityCallback(std::move(handles)).
   • Client: Sichert die Instanziierung thread-sicher über einen Mutex-Lock ab und erzeugt die Proxy-Instanz smartSensorRadar_proxy basierend auf handles[0].
2. Capability Signature Check (Schritt 2):
   • Client: Initiiert nicht-blockierenden Methodenaufruf smartSensorRadar->getCapabilitySignature(), der ein Future-Objekt liefert.
   • Client: Synchronisiert/blockiert den Thread explizit via capability_future.get() zur Auswertung der Sensor-Signatur.
   • Entscheidungslogik: Makro/Funktion SENSOR_CAPABILITY_OPTIONAL(capability) prüft, ob optionale Sensor-Features unterstützt werden; Flag sensor_optionals wird auf OK oder FAILED gesetzt.
3. Event Subscription (Schritt 3):
   • Client: Abonniert obligatorisch baseEvent.Subscribe(kNewestN, 1).
   • Client: Bedingtes Abonnement: Nur bei sensor_optionals == OK wird optionalEvent.Subscribe(kNewestN, 1) aufgerufen.
   • Provider: Startet nach erfolgreicher Subscription das Publizieren der entsprechenden Events an den Client.

4. Normative Relevanz & Entwickler-Hinweise

• AP-Design-Pattern: Trennung von Basis- und Options-Ereignissen ermöglicht dynamische Skalierbarkeit über verschiedene Sensor-Hardware-Revisionen (Low-End vs. High-End Smart Sensoren) bei identischem generiertem Service-Interface.
• Blockierendes Warten vermeiden: Der im Schaubild dargestellte Aufruf capability_future.get() blockiert den aufrufenden OS-Thread bis zur Antwort des Sensors. In sicherheitskritischen / harten Echtzeit-Anwendungen (z. B. ASIL-D Thread-Kontexten) ist zwingend stattdessen ara::core::Future::then() (asynchrones Chaining via Continuation) oder wait_for() mit Timeout-Überwachung einzusetzen.
• Lebenszyklus- & Concurrency-Management: Die Absicherung per std::lock_guard ist obligatorisch, da der FindService-Callback aus dem Kontext des ara::com-Reactor-/Worker-Threads ausgelöst wird, während die Proxy-Nutzung im Anwendungs-Thread erfolgt.
• SOME/IP-SD Netzwerklast: Das dynamische Abfragen der Capabilities (getCapabilitySignature) erzeugt Round-Trip-Time (RTT) im Startzyklus. Bei deterministischen Systemen mit statischem Sensor-Setup kann die Capability-Zuordnung alternativ direkt in den Manifest-Dateien (Execution- & Service-Instance-Manifest) modelliert werden.