Figure 7.10: Find Service using abstract network binding

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Architektur- und Implementierungs-Codebeispiel (Gegenüberstellung zweier API-Muster mit Manifest-Binding-Mapping).
• Technischer Zweck: Veranschaulichung der Service-Discovery-Abstraktion in der AUTOSAR Adaptive Platform (ara::com). Dargestellt wird die Entkopplung der Applikationssoftware von transport- und deploymentspezifischen Parametern (z. B. SOME/IP-Instanz-IDs) über das AUTOSAR-Manifest-Modell.
• Funktionale Einordnung: Lokalisierung von Service-Instanzen durch einen Client (Proxy) zur Laufzeit. Das Schaubild vergleicht die direkte, vollabstrakte Suche über einen logischen Portbezeichner (InstanceSpecifier) mit der zweistufigen, expliziten Instanzauflösung (InstanceIdentifier).

2. Komponenten, Entitäten & Schnittstellen

• ara::core::InstanceSpecifier: Typisierter String-Wrapper, der den vollqualifizierten Modellpfad eines logischen Port-Prototyps einer Adaptive Application repräsentiert (z. B. "/x/y/z/MyPort").
• RadarServiceProxy: Vom Binding-/Generierungs-Framework erzeugte typsichere Proxy-Klasse für das Service-Interface RadarService.
• ServiceHandleContainer (serviceHandleContainer): Container von Interface-Handles (HandleType), die gültige Bindeglieder zu entdeckten Service-Instanzen darstellen.
• InstanceIdentifierContainer / InstanceIdentifier: Deployment-spezifische Kennung(en) einer konkreten Service-Instanz im Kommunikations-Stack (repräsentiert das Netzwerk-Binding).
• ResolveInstID: Hilfsfunktion der Laufzeitumgebung zur Auflösung eines modellierten InstanceSpecifier in konkrete InstanceIdentifier auf Basis des lokalen Deployments.
• Manifest (ServiceInstanceToPortPrototypeMapping): Konfigurationsartefakt (ARXML/Execution Manifest), das die Zuordnung zwischen dem abstrakten Port ("x/y/z/MyPort") und der physischen Transportadresse (SOME/IP:43) festlegt.
• Kardinalitäten & Relationen:
  • 1:1 bzw. 1:n Mapping: Ein InstanceSpecifier mappt über das Manifest auf mindestens eine (im Beispiel genau eine) konkrete Service-Instanz (SOME/IP:43).
  • Assoziation: Der Konstruktor von RadarServiceProxy konsumiert ein einzelnes Handle aus dem ServiceHandleContainer zur Bindung der RPC-/Event-Endpunkte.

3. Dynamisches Verhalten & Sequenzablauf

Oberer Pfad: Direkte, vollabstrakte Service-Suche (Empfohlener Standard)

1. Instanziierung des Port-Identifikators: Erstellung von ara::core::InstanceSpecifier portName via Kontext-Präfix und Port-Name.
2. Abstrakter Suchaufruf: Aufruf von RadarServiceProxy::FindService(portName). Die ara::com-Middleware übernimmt die interne Manifest-Auflösung gegen das Binding (SOME/IP:43) transparent und fragt den Service-Discovery-Daemon (z. B. vsomeip / daemon-intern) ab.
3. Ergebnisprüfung: Abfrage von serviceHandleContainer.size > 0.
4. Proxy-Konstruktion: Bindung des Proxy-Objekts proxy(serviceHandleContainer[0]) an die gefundene Instanz.

Unterer Pfad: Explizite, zweistufige Service-Suche

1. Instanziierung des Port-Identifikators: Erstellung von ara::core::InstanceSpecifier portName.
2. Explizite Bindungs-Auflösung: Ermittlung der konfigurierten Instanz-IDs via ResolveInstID(portName). Rückgabe der konkreten InstanceIdentifierContainer instIDs (Manifest-Lookup im User-Code).
3. Konkreter Suchaufruf: Aufruf der Überladung RadarServiceProxy::FindService(instIDs[0]). Suche erfolgt direkt mit der physischen Instanz-ID.
4. Ergebnisprüfung & Konstruktion: Identisch zu Pfad 1 bei Vorhandensein valider Handles.

Hinweis zum Steuerfluss: Dargestellt ist jeweils die synchrone, abfragende Variante (FindService). Sie liefert einen Snapshot zum Aufrufzeitpunkt (im Gegensatz zum asynchronen Observer-Muster via StartFindService mit FindServiceHandler-Callback).

4. Normative Relevanz & Entwickler-Hinweise

• Location Transparency & Portabilität: Der obere Code-Pfad realisiert vollständige Transportabstraktion. Wird der Service von SOME/IP auf IPC umkonfiguriert oder die Instanz-ID im Manifest geändert, bleibt der Applikationscode unverändert kompilier- und lauffähig.
• API-Auswahl:
  • FindService(InstanceSpecifier) (oben) ist für Endanwender/Applikationsentwickler normativ vorgeschrieben, um Kopplung an spezifische Netze zu verhindern.
  • FindService(InstanceIdentifier) (unten) ist primär für Diagnose-, Test-Frameworks oder dynamisch rekonfigurierbare Gateways relevant, die gezielt numerische oder binding-spezifische Instanzen adressieren müssen.
• Konfigurationsverträge:
  • Existiert im Deployment-Manifest kein passendes ServiceInstanceToPortPrototypeMapping für den gebildeten String context + "MyPort", schlägt die Auflösung fehl (leerer Container bzw. kInstanceNotFound).
• Timing & Determinismus im Embedded-Kontext:
  • Der synchrone Aufruf FindService blockiert bis zum Vorliegen des lokalen Stack-Cache-Ergebnisses. In System-Startphasen führt dies bei noch nicht propagierten Service-Offers zu leeren Ergebnissen (size == 0). Für robuste ECU-Kommunikation ist in Produktionscode stattdessen das asynchrone StartFindService(...) vorzuziehen.