Figure 7.5: SOME/IP Bridge

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Informelles Komponenten- und Bereitstellungsdiagramm (Deployment/Component Architecture Diagram) mit Fokus auf Kommunikationspfade und Protokoll-Brücken.
• Technischer Zweck & Einordnung: Illustration der standorttransparenten Dienstabstraktion (Location Transparency) der AUTOSAR Adaptive Platform (ara::com) unter Verwendung einer zentralen SOME/IP Bridge (Daemon-basierter Binding-Ansatz). Das Diagramm veranschaulicht, wie lokale Inter-Process-Communication (IPC) und netzwerkübergreifende SOME/IP-Kommunikation für die Applikation transparent über dieselben ServiceProxy- und ServiceSkeleton-Schnittstellen abgewickelt werden.

2. Komponenten, Entitäten & Schnittstellen

• ECU with AP product (Lokales Steuergerät / Host 1):
  • ara::com App (Applikationsprozess):
    • Client Implementation: Anwendungslogik, die Service-Methoden konsumiert, Events empfängt oder Fields subscribiert.
    • Service Proxy: Sprachgebundene C++-Klasseninstanz (ara::com-Client-Interface) mit Transport-Binding-Routing.
    • Instance1 (Service Implementation & Service Skeleton): Lokale Instanz eines angebotenen Dienstes innerhalb desselben oder eines benachbarten Applikationsprozesses auf der lokalen AP-ECU.
  • Platform Middleware / Runtime Daemons:
    • Service Registry / Discovery: Zentraler Discovery-Dienst auf der ECU zur Auflösung von Dienstinstanzen (InstanceIdentifier, InstanceSpecifier), Handhabung von FindService-Anfragen und Bereitstellung von Endpunktinformationen.
    • SOME/IP Bridge: Zentraler Kommunikations-Daemon, der das SOME/IP-Netzwerkprotokoll (Serialisierung/Deserialisierung, Session Handling, TCP/UDP-Socket-Kommunikation) kapselt und Brückenfunktionalität zwischen lokalem IPC und externem Ethernet bereitstellt.
• Remote ECU (Host 2):
  • Beinhaltet eine ara::com App mit Instance2 (Service Implementation & Service Skeleton).
• Physikalische & logische Netzwerke:
  • Switch: Ethernet-Switch zur physikalischen Kopplung beider ECUs auf OSI-Schicht 2.
  • SOME/IP: Protokollverbindung (Layer 5–7 über UDP/TCP) zwischen den ECUs.
• Schnittstellen & Verbindungsbeziehungen:
  • Schwarzer Pfeil (Client Implementation → Service Registry/ Discovery): Registrierungs- und Discovery-Lookup (ara::com::runtime::ResolveInstanceIDs bzw. ServiceProxy::StartFindService / FindService).
  • Rote Verbindung (Service Proxy ↔ Instance1 / Service Skeleton): Direkter lokaler IPC-Pfad (z. B. Shared Memory, POSIX Message Queues, Domain Sockets) für knoteninterne Dienstaufrufe ohne Ethernet-Stack-Overhead.
  • Grüne Verbindung (Service Proxy ↔ SOME/IP Bridge): Lokaler IPC-Transportkanal zur Delegierung von Aufrufen externer Instanzen an die Brücke.
  • Blaue Verbindung (SOME/IP Bridge ↔ Instance2 / Service Skeleton): SOME/IP-PDU-Transfer über den Netzwerk-Stack und Switch.

3. Dynamisches Verhalten & Sequenzablauf

1. Service Discovery / Auflösung:
   • Die Client Implementation initiiert über den generierten Proxy eine Dienstsuche (FindService) bei der lokalen Service Registry / Discovery.
   • Die Registry signalisiert, ob die Zielinstanz lokal (Instance1) oder extern auf einer entfernten ECU (Instance2) verfügbar ist.
2. Lokaler Kommunikationspfad (Intra-ECU via IPC):
   • Ziel: Instance1.
   • Der Service Proxy adressiert das lokale Service Skeleton direkt über den schnellen IPC-Kanal (roter Pfad).
   • Die Kommunikation erfolgt ohne Ethernet-PDU-Serialisierung / SOME/IP-Header-Overhead; Methodenaufrufe (ara::core::Future) und Events werden direkt im User-Space vermittelt.
3. Netzwerkweiter Kommunikationspfad (Inter-ECU via SOME/IP Bridge):
   • Ziel: Instance2.
   • Der Service Proxy leitet Methodenaufrufe oder Subscriptions lokal per IPC an die SOME/IP Bridge weiter (grüner Pfad).
   • Die SOME/IP Bridge packt die Daten in standardkonforme SOME/IP-Nachrichten (Header mit MessageID, Length, RequestID, ProtocolVersion, InterfaceVersion, MessageType), übernimmt das SOME/IP-SD (Service Discovery over Wire) und sendet die Frames über TCP/UDP und den Ethernet-Switch (blauer Pfad) an Instance2.
   • Antworten (Replies, Notifications) der Remote-Instanz laufen invers über die Bridge zurück zum lokalen Proxy.

4. Normative Relevanz & Entwickler-Hinweise

• Standorttransparenz (API-Vertrag): Der Applikationscode der Client Implementation ist vollständig entkoppelt von der Netzwerktopologie. Ob Instance1 oder Instance2 adressiert wird, erfordert keinerlei Quellcodeänderung; das Routing entscheidet sich deklarativ über das Deployment-Manifest (ARXML).
• Daemon-basiertes vs. Library-basiertes Binding: Das Schaubild dokumentiert die Daemon-Architektur (SOME/IP Bridge). In modernen Adaptive-Plattformen existiert alternativ das Library-basierte Binding, bei dem der SOME/IP-Serialisierer direkt in den Applikationsprozess gelinkt ist und native Sockets öffnet. Die Bridge-Variante reduziert den Footprint der Anwendungs-Binaries und zentralisiert Socket-/Firewall-Ressourcen, führt jedoch zu einem zusätzlichen Context-Switch (IPC-Hop zwischen App und Bridge).
• Konfigurationsanforderungen (Manifest):
  • ServiceInterfaceDeployment: Definition des SOME/IP-Bindings (Method IDs, Event IDs).
  • ServiceInstanceToPortPrototypeMapping: Zuordnung von ProvidedServiceInstance und RequiredServiceInstance zu den jeweiligen Endpunkten (SomeipServiceInstanceToMachineMapping).
  • Konfiguration von Transport-Eigenschaften (UDP vs. TCP, IP-Adressen, Ports).
• Laufzeit- und Performance-Aspekte:
  • Entwickler müssen bei Inter-ECU-Calls (SOME/IP Bridge) höhere Latenzen und asynchrone Fehlerfälle (z. B. Paketverlust, Timeouts via ara::core::ErrorCode) einplanen, während Intra-ECU-IPC deterministischer und signifikant latenzärmer agiert.