Figure 8.2: Example Language and Network Binding

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Schichten- und Komponentenmodell (Architekturdiagramm) mit Schnittstellen- und Binding-Allokation für einen POSIX-Prozess (Executable).
• Technischer Zweck: Darstellung des schichtenweisen Aufbaus des AUTOSAR Adaptive Platform (AP) Kommunikations-Stacks (ara::com) vom typsicheren C++-Applikationsaufruf bis zur Middleware-Transportschicht.
• Funktionale Einordnung:
  • Veranschaulicht die Entkopplung von applikationsspezifischer Schnittstellendefinition (Service Interface im ARXML) und konkreter Übertragungstechnologie (Transportprotokoll/IPC).
  • Definiert die physikalische und logische Grenze eines Executable (Prozessgrenze) gegenüber platform-weiten Diensten (OS, Execution Management, Communication Middleware).

2. Komponenten, Entitäten & Schnittstellen

• Executable (Magenta-Rahmen / Prozessgrenze):
  • Kapselt die instanziierte Applikationslogik, das generierte Language Binding sowie das Network Binding. Läuft als eigenständiger POSIX-Prozess unter Aufsicht des Execution Management.
• Application Layer (Gelber Block):
  • Beinhaltet die funktionale Software-Komponente (Adaptive Application / SWC).
  • Interagiert über standardisierte POSIX-APIs mit dem Betriebssystem, über Lifecycle-APIs mit dem Execution Management und über ara::com-Proxies/Skeletons mit der Kommunikationsschicht.
• Service-Schnittstelle / C++ API (Grüne Leiste):
  • Typsicheres, C++-basiertes API (z. B. Proxy->setX(...), Events, Fields, Methods).
  • Funktionale Analogie zur Classic Platform (CP): Entspricht dem generierten RTE-API (z. B. Rte_Write_<p>_<o>(), Rte_Read()).
• Language Binding (Oberer grauer Block):
  • Generiert aus dem formalen Software-Design (ARXML: ServiceInterface, PortPrototype).
  • Stellt C++-Klassen bereit (ProxyClass, SkeletonClass, Smart Pointer, Futures/Promises).
  • Vollständig technologieagnostisch bezüglich des Übertragungsprotokolls.
• Network Binding (Unterer grauer Block):
  • Generiert aus dem Deployment-Modell (ARXML: ServiceDeployment, z. B. SomeipServiceDeployment, DdsServiceDeployment oder lokales IpcDeployment).
  • Führt Serialisierung/Deserialisierung (Marshalling/Unmarshalling) der Nutzdaten gemäß Protocol-Header- und Endianness-Vorgaben durch.
• Treiber- / Middleware-Schnittstelle (Rote Leiste):
  • Proprietäre, nicht durch AUTOSAR standardisierte C++/C-Schnittstelle zwischen Network Binding und Transport-Engine.
  • Funktionale Analogie zur Classic Platform (CP): Entspricht hardware-nahen Interaktionsschichten wie Com_SendSignal() bzw. der PDU-Router-Schnittstelle (PduR_Transmit()).
• Com Middleware (Orangener Block):
  • Protokollspezifische Transportinfrastruktur (z. B. SOME/IP-Daemon/Stack, DDS-Core, Shared Memory / Socket IPC).
• Execution Management & Operating System (Orangene Blöcke):
  • Bereitstellung der Prozessisolation, POSIX-PSE51-Subsysteme, Scheduling und deterministischem State-Management.
• Adaptive AUTOSAR Foundation (Blauer Basis-Block):
  • Grundlegende Laufzeitinfrastruktur und gemeinsame Datentypen (ara::core::Result, ara::core::Future, ara::core::Span, Error Domains).

3. Dynamisches Verhalten & Sequenzablauf

1. Service Discovery / Bindung:
   • Applikation initiiert FindService via ProxyClass::StartFindService(). Das Network Binding wickelt das SOME/IP-SD oder DDS-Discovery ab.
2. Datenabsendung / Methodenaufruf (Senden):
   • Applikation ruft typsichere Methode oder Field-Set auf: Proxy->setX(value).
   • Language Binding: Validiert Datentypen, erzeugt synchrone oder asynchrone Kontrollflüsse (ara::core::Future).
   • Network Binding: Serialisiert Nutzdaten in Byte-Streams (Payload-PDU, Alignment, Byte-Order).
   • Com Middleware Interface: Übergibt serialisierte PDU synchron oder per Zero-Copy an die Kommunikations-Middleware (Not standardized).
   • Com Middleware: Überträgt das Paket über Kernel-Sockets (UDP/TCP via OS) oder POSIX IPC (Shared Memory) an den Empfänger.
3. Empfangspfad (Skeleton / Inverse Richtung):
   • Com Middleware empfängt Raw-Frames, Network Binding deserialisiert die Payload in C++-Typen, Language Binding löst Callbacks/Event-Subscriptions auf Applikationsebene aus.

4. Normative Relevanz & Entwickler-Hinweise

• Code-Generierung & ARXML-Entkopplung:
  • Trennung zwischen ServiceInterface (Abstraktionsebene für Anwendungsentwickler) und ServiceInstanceDeployment (Netzwerk- und Protokollkonfiguration).
  • Ein Wechsel des Transportprotokolls (z. B. von SOME/IP auf DDS oder High-Performance Shared-Memory IPC) erfordert keine Code-Änderung im Application Layer, sondern lediglich eine Neugenerierung des Network Bindings sowie ein Re-Deployment.
• Portabilität & Vendor-Lock-in:
  • Die grüne Schnittstelle (ara::com) ist portabel und normativ in den AUTOSAR AP-Spezifikationen fixiert.
  • Die rote Schnittstelle ist herstellerspezifisch (z. B. Vector MICROSAR Adaptive, EB corbos, dSPACE). Eigene Network Bindings oder manuelle Einbettungen von Drittanbieter-Stacks müssen an diese herstellerspezifischen Glue-APIs angepasst werden.
• Prozessgrenzen & Footprint:
  • Da Language- und Network-Binding direkt in das Executable gelinkt werden (statisch oder per Shared Object), fallen Serialisierungs-Overheads direkt in der Ausführungsumgebung des Applikationsprozesses an (CPU- und Stack-Last beim Marshalling).