Figure 4.3: ara::com method based communication

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (sd Dynamic View).
• Technischer Zweck: Detaillierte Darstellung des asynchronen Request-Response-Nachrichtenflusses (RPC / Methodenaufruf) innerhalb des Kommunikations-Subsystems ara::com der AUTOSAR Adaptive Platform.
• Funktionale Einordnung: Veranschaulicht die Entkopplung und Schichtenarchitektur zwischen anwendungsspezifischem Code (Adaptive Applications), generierten Abstraktionsartefakten (Proxy/Skeleton), der Kern-Middleware (Communication Management) und dem protokollspezifischen Transport-Layer (Network Binding, z. B. SOME/IP oder IPC).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lebenslinien (Lifelines):
  • Client Application: Service-Konsument (Adaptive Application), interagiert ausschließlich über die generierte Proxy-Schnittstelle.
  • Proxy: Generierte C++-Klasse (<Service>Proxy), stellt typsichere Methoden des Service-Interfaces bereit und liefert Asynchronitäts-Primitive an die Applikation.
  • Communication Management Middleware: Plattform-Laufzeitumgebung von ara::com; koordiniert das Routing zwischen generierten Bindegliedern und Transport-Treibern sowie das Lifecycle-Management von Futures und Promises.
  • Network Binding: Protokoll- und transportspezifische Instanz (z. B. SOME/IP-Binding, POSIX IPC Shared-Memory-Binding); führt Serialisierung/Deserialisierung durch und bedient die Netzwerkschnittstelle.
  • Skeleton: Generierte C++-Klasse (<Service>Skeleton) auf Dienstanbieterseite; adaptiert eingehende Plattform-Aufrufe auf die konkrete Implementierung der Service-Methoden.
  • Server application: Service-Provider (Adaptive Application); implementiert die funktionale Business-Logik der Service-Schnittstelle.
• Schnittstellen- und Steuerungselemente:
  • ara::core::Future: Asynchrones Lese-Handle; repräsentiert das zukünftige Ergebnis oder einen Fehlerzustand für den Aufrufer (Client Application).
  • ara::core::Promise: Asynchrones Schreib-Handle; wird serverseitig und middlewareseitig genutzt, um den Rückgabewert bzw. Fehlercode (ara::core::ErrorCode) bereitzustellen und den Zustand der zugehörigen Future auf ready zu setzen.
  • MethodCallProcessingMode: Konfigurationsparameter des Skeletons; im Diagramm explizit annotiert für die Modi kEvent oder kEventSingleThread.

3. Dynamisches Verhalten & Sequenzablauf

1. Request-Phase (Client-Auslösung, asynchron/nicht-blockierend):
   • Die Client Application ruft method call() am Proxy auf.
   • Der Proxy delegiert via Service method call() an die Communication Management Middleware, welche Method() am Network Binding triggert.
   • Das Network Binding führt TransmitRequest() aus (Serialisierung der Methodenparameter in das PDU-/Netzwerkformat und Absenden).
   • Unmittelbar nach Absenden propagieren Network Binding, Middleware und Proxy eine Instanz von ara::core::Future zurück an die Client Application. Der Client-Thread wird nicht blockiert.
2. Server-Verarbeitungsphase (Ereignisgesteuert via Skeleton):
   • Das serverseitige Network Binding registriert den Eingang (ReceiveRequest()) und übergibt die Nachricht via ProcessRequest() an die Middleware.
   • Die Middleware leitet die Anfrage über Service method request() an das Skeleton weiter.
   • Das Skeleton ruft Execute() an der Server application auf (basierend auf kEvent / kEventSingleThread).
   • Die Server application:
     1. Erstellt intern ein ara::core::Promise() (Create ara::core::Promise()).
     2. Führt die eigentliche Algorithmen-/Funktionslogik aus (Execute implementation()).
     3. Schreibt das Ergebnis oder den Fehler in das Promise (Set Return Value / Error in Promise()).
     4. Erzeugt daraus eine Future (Create Future from Promise()) und liefert diese an das Skeleton zurück.
   • Das Skeleton gibt die Future an die Middleware weiter.
3. Response-Übertragung (Server- zu Client-Medium):
   • Die Middleware stößt am serverseitigen Network Binding ProcessReply() an.
   • Das Network Binding führt TransmitReply() aus (Serialisierung der Rückgabewerte/Fehlerstrukturen und Rücksendung über das Transportmedium).
4. Response-Empfang & Client-Auflösung:
   • Das clientseitige Network Binding empfängt die Antwort (ReceiveReply()) und reicht sie mit Reply() an die Middleware weiter.
   • Die Middleware setzt das Ergebnis über Set ara::core::Promise().
   • Dadurch wird das assoziierte Client-Handle Trigger ara::core::Future() signalisiert (Zustand: ready).
   • Die Client Application liest das Ergebnis synchron/blockierend oder polling-basiert über ara::core::Future.GetResult() aus.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag & Non-Blocking Design: Methodenaufrufe in ara::com geben grundsätzlich ara::core::Future<Output> zurück. Aufrufe von .GetResult() blockieren den aufrufenden Thread bis zum Eintreffen der Antwort oder bis zum Timeout. In harten Echtzeit- oder Event-Loop-Kontexten darf .GetResult() nicht unbedacht aufgerufen werden; stattdessen sind Polling (wait_for) oder Callbacks/Continuations zu nutzen.
• Skeleton Processing Mode Semantik:
  • Bei kEvent wird die Methode im Kontext eines von der Middleware bereitgestellten Worker-Thread-Pools ausgeführt. Die Methodenimplementierung der Server application muss vollständig reentrant und threadsicher sein.
  • Bei kEventSingleThread serialisiert die Middleware eingehende Aufrufe über einen dedizierten Thread. Dies verhindert Race-Conditions in der Applikation, birgt jedoch das Risiko von Head-of-Line-Blocking bei lang laufenden Methoden.
• Fehlerbehandlung ohne Exceptions: AUTOSAR Adaptive untersagt C++-Exceptions in sicherheitskritischen Bereichen. Fehlerfälle (z. B. definierte ApplicationErrors oder Kommunikationsfehler) werden über ara::core::Result<Output, ara::core::ErrorCode> innerhalb des Promise/Future-Paars transportiert und müssen vom Client via ara::core::Result::HasValue() validiert werden.
• Serialisierungs- und Latenz-Budget: Da das Network Binding zwei Serialisierungs-/Deserialisierungszyklen (TransmitRequest, TransmitReply) durchläuft, müssen Methoden-Signaturen hinsichtlich Payload-Größen optimiert werden (insbesondere bei Verwendung von SOME/IP über Ethernet). Für hochfrequente oder volumige Nutzdaten (z. B. Sensor-/Kameradaten) ist das Event-Paradigma (mit Shared Memory / Zero-Copy) dem Request-Response-Methodenaufruf vorzuziehen.