Figure 7.4: Multi-Binding local and network example

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Strukturelles Architektur- und Deployment-Diagramm (Kommunikationstopologie für serviceorientierte Architekturen / SOA).
• Technischer Zweck: Veranschaulichung des Multi-Binding-Konzepts und der Location-Transparency in der AUTOSAR Adaptive Platform (ara::com). Es demonstriert, wie ein einzelner Service-Consumer (Client Implementation) über identische generierte Proxy-Schnittstellen sowohl lokal (intra-ECU / IPC) als auch remote (inter-ECU über SOME/IP) bereitgestellte Service-Instanzen adressiert.

2. Komponenten, Entitäten & Schnittstellen

• ECU with AP product (Lokale ECU):
  • ara::com App: Client-Prozessraum innerhalb der Adaptive Platform Runtime.
    • Client Implementation: Applikationslogik, die Service-Methoden, Events und Fields konsumiert.
    • Service Proxy: Generierte C++-Klasse (<Service>Proxy), die dem Client das typsichere Service-Interface abstrahiert.
  • Instance1 (Lokaler Service Provider):
    • Service Implementation: Konkrete C++-Implementierung des Service-Interfaces.
    • Service Skeleton: Generierte C++-Klasse (<Service>Skeleton), die Methodenaufrufe dispatcht und Events bereitstellt.
  • Service Registry / Discovery: Zentraler Plattform-Dienst zur Registrierung, Auflösung und Instanzverwaltung von Services (ara::com-Laufzeitkomponente).
  • Lokales Transport-Binding (Roter Pfad): Direkte Intra-Node-Kommunikation (z. B. Shared Memory, POSIX Domain Sockets oder Zero-Copy IPC) zwischen Service Proxy und lokalem Service Skeleton.
• Entfernte ECU & Infrastruktur:
  • Service Provider APP (Instance2): Remote-Instanz desselben Service-Typs auf einer separaten ECU.
    • Beinhaltet eigene Service Implementation und Service Skeleton.
  • Switch: Automotive-Ethernet-Switch auf physikalischer Layer-2-Ebene.
  • Netzwerk-Binding (Blauer Pfad / SOME/IP): Inter-ECU-Kommunikation via SOME/IP-Protokollstack (UDP/TCP/IP) über das Ethernet-Netzwerk.

3. Dynamisches Verhalten & Sequenzablauf

1. Service Offering:
   • Instance1 signalisiert Verfügbarkeit über das lokale Skeleton (OfferService()).
   • Instance2 publiziert Verfügbarkeit netzwerkweit via SOME/IP-SD (Service Discovery Offers).
2. Service Discovery (Discovery-Phase):
   • Der Client triggert den Lookup über die Registry-Schnittstelle: $FindService(ServiceType, AnyInstance)$
   • Service Registry / Discovery aggregiert lokale Registrierungen und über SOME/IP-SD empfangene Annoncierungen.
   • Rückgabe eines ServiceHandleContainer: Liefert Handle1 (für Instance1) und Handle2 (für Instance2) an die Client Implementation zurück.
3. Instanziierung & Binding-Auflösung:
   • Der Client wählt anhand von Deployment-Kriterien oder Prioritäten das Ziel-Handle aus und instanziiert den Proxy: auto proxy = std::make_unique<ServiceProxy>(handle);
   • Die ara::com-Middleware bindet unterhalb des Proxys transparent den korrekten Binding-Kanal ein:
     • Bei Handle1 → Lokaler IPC-Stack (Rot, minimaler Overhead, keine Netzwerkkopfdaten).
     • Bei Handle2 → SOME/IP-Serialisierung / Socket-Dispatch (Blau, Netzwerkübertragung via Switch).
4. Operationelle Phase:
   • Methodenaufrufe (Request/Response via ara::core::Future/Promise), Event-Subscriptions oder Field-Notifizierungen erfolgen über die identische Proxy-API, unabhängig davon, ob das Ziel Instance1 oder Instance2 ist.

4. Normative Relevanz & Entwickler-Hinweise

• Vollständige Location-Transparency: Der Applikationscode ist vollständig vom physischen Bereitstellungsort entkoppelt. Weder Quellcode noch C++-Header unterscheiden zwischen lokalem IPC und Ethernet-SOME/IP.
• ARXML-Deployment-Konfiguration:
  • Die Bindungsdefinition erfolgt deklarativ in den Manifesten (ServiceInstanceToMachineMapping, SomeipProvidedServiceInstance, SomeipRequiredServiceInstance).
  • Ein Service-Interface kann zur Modellierungs- und Generierungszeit gleichzeitig an mehrere Bindings (IPC und SOME/IP) gebunden werden (Multi-Binding).
• Discovery-Strategien im Code:
  • Synchron: Blockierendes FindService() zur Initialisierungszeit.
  • Asynchron: Nicht-blockierendes StartFindService(callback, ...) zur dynamischen Behandlung von neu auftauchenden Remote-Instanzen (z. B. nach verspätetem Booten entfernter ECUs).
• Latenz- und Determinismus-Implikationen:
  • Obwohl die API identisch ist, unterscheiden sich Instance1 (IPC) und Instance2 (SOME/IP) drastisch in Latenz, Jitter und Fehlersemantik (z. B. Paketverlust, Socket-Timeouts).
  • Embedded-Entwickler müssen Fehlerzustände (ara::core::ErrorCode) bei Remote-Bindings aktiv behandeln, die bei rein lokalen Aufrufen typischerweise nicht auftreten.