Figure 7.11: Find Service using abstract network binding - ANY

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptionelles API- und Deployment-Mapping-Diagramm (Synthese aus C++-Codefragmenten, Manifest-Mappings und relationalen Zuweisungspfaden).
• Technischer Zweck: Spezifikatorische Darstellung des Service-Discovery-Musters „ANY“ (Wildcard-Suche) innerhalb des Functional Clusters ara::com (Communication Management) der AUTOSAR Adaptive Platform.
• Architektur-Einordnung: Visualisiert die Entkopplung von applikativer Service-Suche (FindService) und konkretem Transport-Binding (SOME/IP, DDS, User-Defined/IPC). Es zeigt, wie Bindings und Instanzzuordnungen vom Applikationscode in das Service Instance Deployment Manifest verlagert werden, um late binding zur Integrationszeit zu ermöglichen.

2. Komponenten, Entitäten & Schnittstellen

Applikative C++-Klassen & Schnittstellen (ara::com / ara::core)

• RadarServiceProxy: Generierte C++-Proxy-Klasse des Service-Konsumenten für das Interface RadarService.
• RadarServiceProxy::FindService(...): Statische Such-API der Proxy-Klasse, dargestellt in drei Überladungsformen:
  1. Signaturlos / Globale Suche: FindService() – instanz- und portunabhängige Suche.
  2. Port-gebunden: FindService(ara::core::InstanceSpecifier) – Suche gebunden an einen modellierten PortPrototype.
  3. Instanz-gebunden: FindService(ara::com::InstanceIdentifier) – Suche parametriert mit einer zuvor aufgelösten Instanz-ID.
• ara::core::InstanceSpecifier: Stark typisierter Identifikator für die Instanz eines Ports im Prozesskontext (context + "MyPort"), der die modellierte Hierarchie (x/y/z/MyPort) abbildet.
• ara::com::InstanceIdentifier / InstanceIdentifierContainer: Repräsentiert die binding-spezifische Instanz-ID.
• ResolveInstID(...): Hilfsfunktion zur Manifest-basierten Auflösung eines InstanceSpecifier in konkrete InstanceIdentifier-Objekte.
• serviceHandleContainer: Rückgabecontainer (ara::com::ServiceHandleContainer<RadarServiceProxy::HandleType>) zur Aufnahme gefundener Service-Instanzen; dient als Eingabe für den Proxy-Konstruktor RadarServiceProxy(handle).

Manifest-Entitäten (ARXML Service Instance Deployment)

• "x/y/z/MyPort" : * (Marker 1): Globaler Wildcard. Keine Einschränkung auf Technologie oder Instanz; vollständige Abstraktion durch den Integrator.
• "x/y/z/MyPort" : SOME/IP:* (Marker 2): Protokoll-gebundener Wildcard. Bindet den Port an alle verfügbaren SOME/IP-Instanzen.
• "x/y/z/MyPort" : DDS:* (Marker 3): Protokoll-gebundener Wildcard. Bindet den Port an alle verfügbaren Data Distribution Service (DDS)-Instanzen.
• "x/y/z/MyPort" : USERDEFINED:* (Marker 4): Wildcard für herstellerspezifische oder proprietäre IPC-Transport-Bindings.

Relationen & Zuordnungsmatrix

• Code 1 (Parameterlos): Wird ausschließlich durch Manifest 1 (*) abgedeckt, da die Software keinerlei Port- oder Protokollfilterung vorgibt.
• Code 2 (InstanceSpecifier): Wird durch Manifest 1 (*), Manifest 2 (SOME/IP:*) und Manifest 3 (DDS:*) abgedeckt. Die Laufzeitumgebung löst den Port dynamisch auf das konfigurierte Binding auf.
• Code 3 (InstanceIdentifier via ResolveInstID): Wird durch Manifest 2 (SOME/IP:*), Manifest 3 (DDS:*) und Manifest 4 (USERDEFINED:*) bedient, da spezifische Instanzbezeichner direkt an den Binding-Treiber übergeben werden.

3. Dynamisches Verhalten & Sequenzablauf

1. Port-Identifikation:
   • Instanziierung von ara::core::InstanceSpecifier portName(context + "MyPort") durch String-Konkatenation des Software-Cluster-Kontexts mit dem Port-Namen.
2. Instanzauflösung (nur Variante 3):
   • Synchroner Aufruf von ResolveInstID(portName).
   • Die ara::com-Laufzeit konsultiert das lokale Service Instance Manifest und liefert einen InstanceIdentifierContainer mit Kardinalität ≥ 1 zurück (im Codebeispiel annotiert mit instIDs.size == 1).
3. Service Discovery Trigger (FindService):
   • Synchroner, blockierender Aufruf von FindService(...).
   • Die Discovery-Schicht filtert eintreffende oder gecachte Service-Offers (z. B. SOME/IP-SD OfferService-Nachrichten oder DDS Participant Announcements) gemäß dem konfigurierten Manifest-Prädikat (1 bis 4).
4. Ergebnisauswertung & Proxy-Konstruktion:
   • Abfrage if (serviceHandleContainer.size > 0).
   • Bei mindestens einem Treffer: Übergabe des ersten Handles (serviceHandleContainer[0]) an den Konstruktor von RadarServiceProxy.
   • Ab diesem Zeitpunkt ist der Proxy an die konkrete Service-Instanz gebunden; Methodenaufrufe, Events und Fields sind einsatzbereit.

4. Normative Relevanz & Entwickler-Hinweise

• Entkopplung & Architektur-Vorgabe:
  • Variante 2 (FindService(portName)) repräsentiert das normative AUTOSAR-Standardmuster. Applikationscode bleibt vollständig technologieagnostisch. Der Wechsel zwischen SOME/IP, DDS oder shared memory IPC erfordert keine Neukompilierung, sondern lediglich eine Anpassung des Service Instance Manifests durch den Integrator.
  • Variante 1 (FindService()) umgeht die Port-Modellierung und birgt in Multi-Instance-Szenarien erhebliche Kollisionsrisiken.
• Blockierendes vs. Asynchrones Verhalten:
  • Der dargestellte synchrone Aufruf FindService() blockiert den ausführenden Thread bis zum Timeout oder Eintreffen von Instanzen. In harten Echtzeitsystemen und während des Systemstarts ist zwingend das asynchrone Pendant RadarServiceProxy::StartFindService(handler, ...) mit Callback-Registrierung zu verwenden, um Thread-Starvation zu vermeiden.
• Risiko bei Wildcard-Matching (ANY / *):
  • Befinden sich mehrere Instanzen desselben Service im Netzwerk (z. B. redundante Radarsensoren Front/Rear), liefert serviceHandleContainer mehrere Handles. Der unreflektierte Zugriff auf Index 0 (serviceHandleContainer[0]) führt zu nicht-deterministischem Verhalten, da die Reihenfolge der gemeldeten Handles nicht durch AUTOSAR garantiert ist.
• Manifest-Konsistenz:
  • Der im C++-Code verwendete String (context + "MyPort") muss zur Laufzeit bitgenau dem port-prototype-blueprint bzw. PortPrototype.shortName im ARXML-Deployment entsprechen. Ein Mismatch führt zu einem leeren Container ohne Compile-Time-Fehler.