Figure 7.2: Distributed discovery approach

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Deployment- und Kommunikationstopologie-Diagramm (Architekturmuster der Dienstfindung im Steuergerät und Bordnetz).
• Technischer Zweck: Darstellung des verteilten Service-Discovery-Ansatzes (Distributed Discovery Approach) innerhalb der AUTOSAR Adaptive Platform (ara::com) unter Verwendung einer zentralen Vermittlungsinstanz (Discovery Bridge) zur Entkopplung von prozesslokaler Middleware und netzwerkweitem SOME/IP-SD (Scalable service-Oriented MiddlewarE over IP Service Discovery).
• Systemische Einordnung: Lösungsansatz zur Vermeidung von Port-Kollisionen (UDP-Port 30490 für SOME/IP-SD) und redundanter Netzwerklast, wenn mehrere unabhängige POSIX-Applikationsprozesse auf einer Adaptive-ECU eigene Middleware-Instanzen betreiben, aber mit externen Adaptive- (AP) und Classic-Platform-Steuergeräten (CP) interoperieren müssen.

2. Komponenten, Entitäten & Schnittstellen

• ECU with AP product from vendor V1:
  • ara::com App (POSIX-Prozesse): Eigenständige Betriebssystem-Prozesse im User Space, die als Service Provider (Skeleton) und/oder Service Consumer (Proxy) agieren.
  • Middleware Impl. with SD: Linkbare Laufzeitbibliothek (In-Process Middleware), die statisch oder dynamisch in jede Applikation eingebunden ist und lokale Dienstfindungslogik (z. B. Shared-Memory- oder Domain-Socket-basiertes IPC-SD) bereitstellt.
  • Discovery Bridge: Lokaler Vermittlungs-Daemon/Adapterprozess auf Betriebssystemebene. Hält die Schnittstelle zwischen der internen, verteilten Middleware-SD und dem externen IP-Netzwerk.
• Switch: Layer-2-Ethernet-Switch zur Weiterleitung von Unicast- und Multicast-Ethernet-Frames (SOME/IP-SD-Nachrichten) im fahrzeuginternen Backbone.
• ECU with AP/CP product:
  • Heterogene Kommunikationspartner im Fahrzeugnetz (Adaptive oder Classic Platform), auf denen Service Provider oder Consumer Apps laufen und die über standardkonformes SOME/IP-SD mit der Vendor-V1-ECU interagieren.
• Schnittstellen & Relationen:
  • Intra-ECU Peer-to-Peer: Direkte bidirektionale Dienstfindung und Datenpfade zwischen den Middleware Impl. with SD-Instanzen für reinen Inter-Prozess-Datenaustausch (IPC).
  • Intra-ECU zu Bridge: Lokale Registrierungs- und Discovery-Schnittstelle (IPC) zwischen jeder Applikations-Middleware und der Discovery Bridge.
  • Inter-ECU (Off-Board): Standardisierte SOME/IP Service discovery-Verbindung (UDP Multicast/Unicast, IANA-Port 30490) zwischen der Discovery Bridge und dem Switch bzw. den entfernten ECUs.

3. Dynamisches Verhalten & Sequenzablauf

1. Lokales Offering / Finding (Intra-ECU):
   • Eine ara::com App initiiert OfferService() bzw. FindService().
   • Die integrierte Middleware Impl. with SD prüft über lokale IPC-Pfade, ob Instanzen innerhalb derselben ECU existieren.
2. Bridging zur Außenwelt (Inter-ECU Egress):
   • Ist eine Service-Instanz laut Deployment-Manifest für externe Netzwerke exponiert, meldet die Applikations-Middleware den Offer-Zustand über IPC an die Discovery Bridge.
   • Die Discovery Bridge aggregiert lokale Angebote und überführt sie in AUTOSAR-konforme SOME/IP-SD-Nachrichten (Initial-, Repetition- und Main-Phase mit konfigurierter TTL und Cycle Time) auf dem externen Netzwerk-Interface.
3. Externes Discovery (Inter-ECU Ingress):
   • Eingehende SOME/IP-SD-Nachrichten (Offers/Finds) von entfernten AP/CP-Steuergeräten werden exklusiv von der Discovery Bridge empfangen und geparst.
   • Die Bridge leitet relevante Service-Zustände selektiv per IPC an die jeweiligen Middleware Impl. with SD-Instanzen weiter, woraufhin die Applikationen über ara::com::FindServiceHandler bzw. ara::com::ServiceHandleContainer benachrichtigt werden.
4. Nutzdatenpfad:
   • Nach Abschluss des Discovery-Vorgangs erfolgt der SOME/IP-Nutzdatenaustausch (Events, Methods, Fields) entweder direkt Socket-zu-Socket zwischen Applikation und Ziel-ECU oder über definierte Transport-Layer-Endpunkte.

4. Normative Relevanz & Entwickler-Hinweise

• Transparenz des API-Vertrags:
  • Für den Applikationsentwickler bleibt die Existenz der Discovery Bridge vollkommen transparent. Die Standard-C++-APIs (ara::com::runtime, Skeleton- und Proxy-Klassen) bleiben unverändert nach AUTOSAR SWS Communication Management spezifiziert.
• Stack-Architektur & Port-Arbitrierung:
  • Löst das POSIX-Problem konkurrierender Binds auf den Standard-SOME/IP-SD-Multicast-Port (224.0.0.x:30490 bzw. FF0x-Scope für IPv6). Ausschließlich die Discovery Bridge öffnet und bindet den externen SD-Socket; einzelne Applikationen benötigen keine Raw-Netzwerk-Privilegien für SD.
• Manifest- & Deployment-Konfiguration (ARXML):
  • Konfigurationsverantwortliche müssen im Service Instance Manifest (SomeipProvidedServiceInstance, SomeipConsumedServiceInstance) präzise festlegen, welche Services strikt lokal verbleiben (reine IPC-Bindung) und welche über die Bridge nach außen propagiert werden.
  • Timing-Parameter (z. B. InitialDelayMin/Max, RepetitionsBaseDelay, CyclicOfferDelay) werden im Kontext der Discovery Bridge parametriert, um Network Flooding zu verhindern.
• Lifecycle- und Crash-Handling:
  • Bei abruptem Terminieren einer ara::com App (z. B. SIGKILL durch Execution Management) muss die Discovery Bridge den Verbindungsabriss detektieren und unverzüglich eine SOME/IP-SD StopOfferService-PDU auf das Netzwerk senden (TTL = 0), um verwaiste Endpunkte auf Remote-ECUs zu verhindern.