Figure 7.1: Technical Architecture of Communication Management

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Technisches Schichten- und Komponentenarchitektur-Diagramm (Block-/Strukturdiagramm nach AUTOSAR Adaptive Platform Spezifikationsstandard).
• Technischer Zweck: Spezifikation der vertikalen Entkopplung und der Protokoll-Bindings von ara::com innerhalb der Adaptive Platform Foundation (APF) gegenüber der Applikationsschicht (Adaptive Application) und der Hardware-Abstraktion (Virtual Machine / Hardware).
• Funktionale Einordnung: Veranschaulicht die Realisierung der serviceorientierten Kommunikation (Service-Oriented Architecture, SOA). Es definiert den Pfad vom typisierten C++-API-Aufruf (Proxy/Skeleton) über protokollunabhängige Dispatching- und Service-Discovery-Mechanismen hinab zu konkreten Transportkanälen für Inter-Process Communication (IPC, intra-machine) und Netzwerkprotokolle (SOME/IP via TCP/IP/Ethernet, inter-machine).

2. Komponenten, Entitäten & Schnittstellen

Schichten und Akteure (Top-Down):

1. Adaptive Application (Applikationsebene):
   • Konsumiert und offeriert Services typisiert über generierte C++-Interfaces (Proxy- und Skeleton-Klassen).
2. ara::com API & Bindings (Zwischenschicht Applikation / Foundation):
   • ara::com API: Einheitliche, sprachspezifische Programmierschnittstelle für Events, Methods und Fields.
   • C++ Language Binding: Generierte typsichere Abbildung des formalen Service Interface Models (ARXML) auf native C++-Konstrukte (z. B. std::future, Callbacks, typsichere Structs).
   • Communication Binding: Protokoll-Adaptionsschicht; entkoppelt das Language Binding von der physischen Übertragungsart (Serialisierung/Deserialisierung in payloadspezifische Formate).
3. Communication Management (Kern-Subsystem der APF):
   • Dispatching and Discovery: Zentrale Routing- und Vermittlungseinheit für Service-Instanzen (FindService, OfferService, Routing von Methodenaufrufen und Event-Subscriptions).
   • Netzwerk-Pfad (Inter-Machine):
     • SOME/IP Transport: Serialisierung/Packaging nach AUTOSAR SOME/IP-Standard (inkl. SOME/IP-SD).
     • TCP/IP: Betriebssystem-/Stack-Sockets (L4).
     • Ethernet Driver: L2-Netzwerkanbindung an physische/virtuelle Netzwerk-Controller.
   • IPC-Pfad (Intra-Machine):
     • IPC Transport: Protokoll- und Speicherabstraktion für knotenlokale Kommunikation.
     • IPC: POSIX-/OS-spezifische Primitiven (Shared Memory, Unix Domain Sockets, Message Queues).
4. Execution Management (APF Core):
   • Gekoppelt über eine Steuerungs-/Zustandsschnittstelle (API / bidirektionale Kontrollbeziehung).
   • Zuständig für Lebenszyklusüberwachung, Initialisierung, Prozessüberwachung und State-Transitions (z. B. Freigabe von Ressourcen für Communication Management).
5. (Virtual) Machine / Hardware:
   • Physische Execution Environment (Microcontroller/SoC, Hypervisor, OS-Kernel).

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm modelliert statische Abhängigkeiten, determiniert jedoch folgende Laufzeitpfade:

1. Service Discovery Phase (Kontrollpfad):
   • Ein Service Provider offeriert via ara::com einen Dienst (OfferService()).
   • Dispatching and Discovery verarbeitet den Aufruf:
     • Lokal: Registrierung im knoteninternen IPC-Registry-Directory.
     • Remote: Übergabe an SOME/IP Transport zur Aussendung von SOME/IP-SD-Multicast/Unicast-Nachrichten über UDP/IP.
2. Datenaustausch / RPC / Event Distribution (Datenpfad):
   • Egress: Methodenaufruf oder Event-Trigger am Proxy/Skeleton → Übergabe über ara::com API → Serialisierung im Communication Binding → Routingentscheidung in Dispatching and Discovery:
     • Ziel intra-machine: Weiterleitung an IPC Transport → Null-Copy / Shared Memory oder OS-Pipe.
     • Ziel inter-machine: Weiterleitung an SOME/IP Transport → Socket Write (TCP/IP) → Senden via Ethernet Driver.
   • Ingress: Empfang via Interrupt/Socket bzw. IPC-Signal → Deserialisierung → Dispatching an den zuständigen Threadpool des Skeletons/Proxys via synchronem Return oder asynchroner std::future/Callback-Benachrichtigung.
3. Lebenszyklus-Synchronisation:
   • Asynchroner/Event-basierter Abgleich zwischen Execution Management und Communication Management: Dienste dürfen erst gebunden bzw. nach außen offeriert werden, wenn die zugehörigen Prozesse den Running-State erreicht haben.

4. Normative Relevanz & Entwickler-Hinweise

• Transparenz des Bindings (Entwicklungsvertrag):
  • Applikationscode darf keine Abhängigkeiten zu konkreten Transportschichten (SOME/IP, POSIX IPC) aufweisen. Die Zuweisung von Service-Instanzen zu IP-Ports oder IPC-Channels erfolgt rein deklarativ über die Deployment-Manifeste (ARXML) zur Kompilier-/Generierzeit.
• Serialisierungs-Overhead & Zero-Copy:
  • Für IPC-Kommunikation ist die Nutzung von Shared-Memory-Mechanismen optimiert. Entwickler müssen auf POD- (Plain Old Data) und ara::core-konforme Typen achten, um aufwendige Deep-Copies im Communication Binding zu vermeiden.
• Portabilität (POSIX/OS-Abhängigkeit):
  • Die Trennung von SOME/IP Transport vs. TCP/IP sowie IPC Transport vs. IPC isoliert OS-spezifische API-Calls (z. B. Linux epoll vs. QNX Channels). Plattform-Portierer implementieren die unteren Transport-Treiber, während Bindings und Generatoren standardkonform bleiben.
• Thread-Safety & Nebenläufigkeit:
  • Der Dispatching and Discovery-Block erfordert reentrante bzw. Thread-sichere Callbacks. Applikationen müssen darauf vorbereitet sein, dass Event-Empfänger und Methoden-Handler auf Threadpools der Communication Management-Laufzeitumgebung ausgeführt werden.