Figure 8.1: Service-oriented communication

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelles UML-Sequenzdiagramm (Interaktionsdiagramm).
• Architektur-Kontext: Grundlegendes Entwurfsmuster der serviceorientierten Kommunikation (SOA / SOC) in der AUTOSAR Adaptive Platform (ara::com).
• Funktionaler Zweck: Veranschaulichung des Broker-basierten Service Discovery & Binding-Prinzips (Publish-Find-Bind) zur Entkopplung von Kontroll- und Nutzdatenpfad. Es grenzt das dynamische Service-Paradigma der Adaptive Platform von der statisch vorkonfigurierten, signalbasierten Kommunikation der Classic Platform (RTE/Com-Stack) ab.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Entitäten:
  • Application 1 (Service Provider / Server): Bereitstellende AUTOSAR Adaptive Application (AA). Instanziiert das generierte Skeleton (<ServiceName>Skeleton).
  • Service Registry (Service Broker / Discovery Service): Verzeichnisdienst zur dynamischen Verwaltung von Service-Instanzen, Endpunkt-Adressen und Schnittstellen-IDs. Realisiert entweder als verteilter Dienst (netzwerkweit via SOME/IP Service Discovery) oder als lokaler Prozess/Daemon (maschinenintern für IPC).
  • Application 2 (Service Consumer / Client): Nutzende AUTOSAR Adaptive Application. Instanziiert das generierte Proxy (<ServiceName>Proxy) nach erfolgreicher Auflösung. Die anfänglich gestrichelte Lebenslinie kennzeichnet die Nicht-Verfügbarkeit des Kommunikationspfads vor dem Discovery.
• Schnittstellen / Interaktionen:
  • register: Bereitstellungsnachricht zur Veröffentlichung des Service-Angebots in der Registry.
  • find: Abfrage nach kompatiblen Service-Instanzen basierend auf Instance-ID / Specifier.
  • call: Direkte Punkt-zu-Punkt-Nutzdatenverbindung (Method Call, Event Subscription, Field Access) zwischen Client und Server unter Umgehung der Registry.

3. Dynamisches Verhalten & Sequenzablauf

1. Registrierungsphase (register):
   • Trigger: Application 1 initialisiert den Service und ruft Skeleton::OfferService() auf.
   • Ablauf: Übergabe der Service-ID, Instance-ID sowie Netzwerk- bzw. IPC-Endpunkt-Parameter an die Service Registry.
2. Discovery-Phase (find):
   • Trigger: Application 2 benötigt eine Instanz des Services.
   • Ablauf: Aufruf von Proxy::FindService() (synchron blockierend) oder Proxy::StartFindService() (asynchron via Handler/Callback). Die Service Registry liefert bei Übereinstimmung eine Liste von ServiceHandleType-Objekten zurück.
3. Kommunikationsphase (call):
   • Trigger: Application 2 instanziiert das Proxy-Objekt mit dem erhaltenen Handle.
   • Ablauf: Etablierung eines direkten Peer-to-Peer-Kanals (Data-Plane). Methodenaufrufe erfolgen synchron oder asynchron (über ara::core::Future / ara::core::Promise), Events über Publish/Subscribe-Queues, Fields über Getter/Setter/Notifier. Die Service Registry ist an diesem Nutzdatenaustausch nicht mehr beteiligt.

4. Normative Relevanz & Entwickler-Hinweise

• Trennung von Control-Plane und Data-Plane:
  • Das Discovery (register, find) beansprucht separate Protokoll- und Bandbreitenressourcen (z. B. UDP-Multicast bei SOME/IP-SD). Die Laufzeitapplikation muss Discovery-Overhead von Latenzanforderungen der Nutzdatenkommunikation (call) isolieren.
• API-Vertrag (ara::com):
  • Provider-Lifecycle: Vor Eintreffen von Anfragen muss OfferService() garantiert durchlaufen sein. Bei Deinitialisierung ist zwingend StopOfferService() aufzurufen, um verwaiste Routing-Einträge in der Registry zu verhindern.
  • Consumer-Resilienz: Da Provider dynamisch starten, beenden oder neu starten können, müssen Consumer asynchrones Polling bzw. Discovery-Callbacks (FindServiceHandler) implementieren. Ein Hard-Coding von Endpunkten verletzt den SOA-Standard.
• Transport-Bindung (Deployment):
  • Inter-ECU (Ethernet): Abbildung der Service Registry über SOME/IP-SD.
  • Intra-ECU (Inter-Process Communication): Abbildung über den herstellerspezifischen Adaptive-Platform-Core (z. B. Shared Memory, POSIX Domain Sockets / Message Queues) über einen lokalen Broker-Daemon oder Kernel-Routinen.
• Deterministik & Startup-Timing:
  • Serviceorientierte Kommunikation ist zur Initialisierungsphase nicht echtzeitdeterministisch. Zeitkritische Systeme müssen Timeouts und Fallback-Strategien für den Zeitraum vor erfolgreichem Abschluss von find definieren.