Figure 7.1: Centralized discovery approach

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Systemarchitektur- und Deployment-Diagramm (Prozess- und Netzwerktopologie) mit Darstellung von Prozessgrenzen, IPC- und Ethernet-Verbindungen.
• Kontext: AUTOSAR Adaptive Platform (AP), Spezifikation AUTOSAR_EXP_ARAComAPI (Releases R17-03 bis R18-03), Kapitel Service Discovery.
• Funktionaler Zweck: Veranschaulichung des zentralisierten Dienstentdeckungs-Ansatzes (Centralized Discovery Approach) innerhalb einer Adaptive-ECU. Das Diagramm demonstriert die Kapselung des externen SOME/IP-SD-Netzwerkverkehrs in einem einzelnen, zentralen Plattform-Daemon (Service Registry / Discovery) im Gegensatz zu einem dezentralen Peer-to-Peer-Discovery pro Applikationsprozess.

2. Komponenten, Entitäten & Schnittstellen

• Knoten & Hardware-Topologie:
  • ECU with AP product from vendor V1: Host-Steuergerät mit Adaptive Platform Stack.
  • Switch: Layer-2-Ethernet-Switch zur Kopplung der Steuergeräte im Fahrzeug-Bordnetz.
  • ECU with AP/CP product (2 Instanzen): Externe Kommunikationspartner im Netzwerk, realisiert entweder als Adaptive Platform (AP) oder Classic Platform (CP).
• Entitäten innerhalb der Adaptive-ECU (Vendor V1):
  • ara::com App (4 Instanzen im Diagramm): Unabhängige Betriebssystem-Prozesse (OS-Prozesse), die als Service-Provider (Skeleton) oder Service-Consumer (Proxy) agieren.
  • Middleware Impl.: In den jeweiligen Applikationsprozess eingebundene Laufzeitbibliothek / Binding-Stub von ara::com.
  • Service Registry / Discovery: Zentraler Plattform-Daemon der Adaptive-Laufzeitumgebung. Hält die lokale Diensttabelle vor und verwaltet Netzwerkschnittstellen für Service Discovery.
• Schnittstellen & Protokollbeziehungen:
  • Intra-ECU (Service discovery): Lokale Interprozesskommunikation (IPC; typischerweise POSIX Domain Sockets, Message Queues oder Shared Memory) zwischen der Middleware Impl. jeder App und dem zentralen Service Registry / Discovery-Daemon.
  • Inter-ECU (SOME/IP Service discovery): Standardkonformes SOME/IP-SD-Protokoll über Ethernet (UDP, Standard-Port 30490) via Switch zu den externen Steuergeräten (ECU with AP/CP product).
• Kardinalitäten:
  • N Applikationsprozesse (ara::com App) greifen über N IPC-Kanäle auf genau 1 zentralen Daemon (Service Registry / Discovery) zu (N:1).
  • 1 zentraler Daemon bündelt das SOME/IP-SD über ein physisches Interface zu M externen Steuergeräten (1:M).

3. Dynamisches Verhalten & Sequenzablauf

1. Lokale Registrierung (Service Offer / Find):
   • Provider-Pfad: Eine ara::com App instanziiert ein Service-Skeleton und ruft OfferService() auf. Die prozesslokale Middleware Impl. serialisiert die Registrierungsanfrage und sendet sie via lokalem IPC an den Service Registry / Discovery-Daemon.
   • Consumer-Pfad: Ein Client ruft FindService() (synchron) oder StartFindService() (asynchron mit Handler) auf. Die Anfrage wird via IPC an den zentralen Daemon übermittelt.
2. Lokale vs. Globale Auflösung:
   • Intra-ECU-Routing: Liegen Consumer und Provider auf derselben ECU (Vendor V1), löst der Daemon das Matching lokal auf und tauscht die IPC-Transportendpunkte (z. B. Shared-Memory-Handles) aus, ohne dass SOME/IP-Pakete das Netzwerk belasten.
   • Inter-ECU-Export: Ist der Service für externe Kommunikation konfiguriert (Deployment-Manifest), transformiert der Daemon das lokale Offer in ein standardkonformes SOME/IP-SD-PDU (OfferService-Entry mit Type, Instance-ID, IP/Port-Optionen) und sendet es periodisch/eventgetrieben über den Ethernet-Switch.
3. Externes Finden & Callback-Zustellung:
   • Empfängt der Daemon von einer externen ECU (AP/CP product) ein SOME/IP-SD OfferService, gleicht er dies mit offenen lokalen Suchanfragen ab.
   • Bei Übereinstimmung benachrichtigt der Daemon die anfragende Applikation via IPC. Die Middleware Impl. erzeugt das Proxy-Objekt und triggert den registrierten FindServiceHandler-Callback im Anwendungskontext.

4. Normative Relevanz & Entwickler-Hinweise

• API-Transparenz für Applikations-Entwickler:
  • Die Wahl des Discovery-Ansatzes (zentral via Daemon vs. dezentral in jedem Prozess) ist eine architektonische Implementierungsentscheidung des Plattform-Vendors.
  • Der C++-API-Vertrag gemäß ara::com bleibt vollkommen identisch (ara::com::runtime, Proxy::StartFindService, Skeleton::OfferService). Der Applikationscode ist portabel und unabhängig von der Daemon-Topologie.
• Konsequenzen für Stack- und Plattform-Entwickler:
  • Vermeidung von Port-Kollisionen: Da SOME/IP-SD standardmäßig auf UDP-Port 30490 lauscht, verhindert die zentrale Registry Bind-Konflikte (SO_REUSEPORT-Limitierungen), die entstehen würden, wenn jede ara::com App eigenständig einen Socket öffnen würde.
  • Laufzeit-Overhead: Lokale Service-Lookups erfordern zwingend mindestens zwei Context-Switches (App → Daemon → App) und IPC-Serialisierung.
  • Robustheit & Lifecycle: Der Service Registry / Discovery-Daemon muss vor allen ara::com Apps durch das Execution Management (ara::exec) hochgefahren werden (Startup-Dependencies im Machine/Execution Manifest). Stürzt der Daemon ab, schlägt jegliches dynamische Discovery fehl; bestehende Datenverbindungen (z. B. bestehende IPC-/SOME/IP-Payload-Streams) können je nach Binding-Realisierung weiterlaufen oder in Timeouts laufen.
• Interoperabilität (Classic & Adaptive):
  • Nach außen (On-Wire) agiert der Daemon streng nach AUTOSAR SOME/IP-SD Spezifikation (AUTOSAR_SWS_ServiceDiscovery). Classic-Platform-Steuergeräte interagieren transparent über deren BSW-Module (SomeIpSd, SoAd, BswM) mit der Adaptive-ECU.