Figure 1.1: Current AUTOSAR-Rust communication diagram

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptionelles Schichten- und Datenflussmodell (Architektur-Integrationsdiagramm für Multi-Language-Umgebungen C++/Rust).
• Technischer Zweck: Spezifikationsbegleitende Darstellung (AUTOSAR_AP_EXP_ARARustApplications, Releases R23-11 / R24-11) der Interoperabilität zwischen der C++-basierten Referenzarchitektur der AUTOSAR Adaptive Platform (APD – Adaptive Platform Demonstrator) und nativen Rust-Applikationen über die funktionale Gruppe ara::com.
• Funktionale Einordnung: Veranschaulichung der Service-Oriented Architecture (SOA) im Mischbetrieb. Dargestellt wird die Schichtenarchitektur aus C++-Basis-Middleware, C-ABI/FFI-Adaption Layer, sicherem Rust-Wrapper sowie den vier prinzipiellen Kommunikationspfaden (C++↔C++, C++→Rust, Rust→C++, Rust↔Rust) nach dem AUTOSAR-Proxy/Skeleton-Entwurfsmuster.

2. Komponenten, Entitäten & Schnittstellen

Laufzeitdomänen & Schichten

• APD (C++) (Native C++ Runtime Domain):
  • ara::com: Zentraler nativer C++-Middleware-Stack für serviceorientierte Interprozess- und Netzkommunikation (SOME/IP, IPC/Shared Memory).
• Rust (Memory-Safe Application Domain):
  • ara::com adaption layer: Brückenschicht (C-ABI / FFI-Schnittstelle), die C++-APIs und Laufzeitobjekte für externe Sprachbindungen zugänglich macht.
  • ara::com Rust wrapper: Idiomatische Rust-Crate; kapselt unsafe-FFI-Blöcke, übersetzt C++-Datenstrukturen in typ- und lebensdauersichere Rust-Konstrukte (Result, RAII, Rust-Lifetimes) und stellt Proxy-/Skeleton-Abstraktionen bereit.

Applikative Endpunkte (Services nach Proxy/Skeleton-Muster)

• Radar app (Pure C++ Pair):
  • Radar app / skeleton: C++ Service Provider (Server).
  • Radar app / proxy: C++ Service Consumer (Client).
• Camera app (C++-to-Rust Pair):
  • Camera app / skeleton: C++ Service Provider auf APD-Ebene.
  • Camera app / proxy: Rust Service Consumer, angebunden über den Rust-Wrapper.
• Ultrasonic app (Rust-to-C++ Pair):
  • Ultrasonic app / skeleton: Rust Service Provider (implementiert Rust-Skeleton-Trait).
  • Ultrasonic app / proxy: C++ Service Consumer im APD-Kontext.
• Lidar app (Pure Rust Pair):
  • Lidar app / skeleton: Rust Service Provider.
  • Lidar app / proxy: Rust Service Consumer.

Schnittstellen & Beziehungen

• Statische Kontroll-/Stack-Bindeglieder (durchgezogene Doppelpfeile):
  • Bidirektionale Anbindung zwischen ara::com (C++) und ara::com adaption layer.
  • Bidirektionale Anbindung zwischen ara::com adaption layer und ara::com Rust wrapper.
• Logische Service-Datenflüsse (gestrichelte Richtungspfeile):
  • Repräsentieren gerichtete Interaktion (Events, Methods, Fields) jeweils vom produzierenden skeleton zum konsumierenden proxy.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm aggregiert vier parallele Kommunikationsszenarien:

1. Pure C++ communication (Radar app):
   • Service Provider (Radar app skeleton) publiziert Daten → Direkter In-Process-/IPC-Transport über ara::com (C++) → Zustellung an Radar app proxy.
2. C++ to Rust communication (Camera app):
   • Camera app skeleton (C++) feuert Event / liefert Methoden-Response an ara::com.
   • ara::com übergibt die Nutzlast an das ara::com adaption layer (FFI-Bridge).
   • Der ara::com Rust wrapper übernimmt das Deserialisieren/Marshalling in Rust-Typen und benachrichtigt asynchron (Polling, Callback oder async/await) den Camera app proxy.
3. Rust to C++ communication (Ultrasonic app):
   • Ultrasonic app skeleton (Rust) ruft Send() auf einem Event oder beantwortet einen Methodenaufruf im sicheren Rust-Wrapper auf.
   • Der Wrapper serialisiert über FFI in das ara::com adaption layer.
   • Der native C++-Stack ara::com dispatcht die Nachricht an den Ultrasonic app proxy (C++).
4. Pure Rust communication (Lidar app):
   • Lidar app skeleton sendet Daten über den ara::com Rust wrapper.
   • Die Nachricht durchläuft das ara::com adaption layer.
   • Architektur-Besonderheit: Die Service-Discovery und das Dispatching erfolgen auch für reine Rust-zu-Rust-Kommunikation über die zentrale Plattform-Middleware (adaption layer), bevor die Daten über den Wrapper an den Lidar app proxy zugestellt werden.

4. Normative Relevanz & Entwickler-Hinweise

• Dokumentstatus: AUTOSAR_AP_EXP_* besitzt explorativen Charakter (Explanation). Das Diagramm definiert keinen finalen normativen SWS-Standard, sondern ein Referenz- und Integrationsmuster für R23-11/R24-11.
• FFI- & Memory-Safety-Vertrag:
  • Der Applikationscode in Rust bleibt vollständig frei von unsafe-Blöcken.
  • Alle Invarianten bezüglich Ownership, Zeiger-Gültigkeit und Thread-Sicherheit (z. B. Send/Sync-Marker) müssen zwingend durch den ara::com Rust wrapper garantiert werden.
• Laufzeit-Overhead & Routing-Kosten:
  • Da auch reine Rust-zu-Rust-Beziehungen (Lidar) über die Adaptionsschicht geroutet werden, fällt zusätzlicher Marshalling-/Konvertierungs-Overhead an (C-ABI-Grenzübertritt). Zero-Copy-Mechanismen (z. B. Shared Memory) erfordern aufeinander abgestimmte Pufferlayouts zwischen C++- und Rust-Datentypen.
• Code-Generierung (ARXML-Toolchain):
  • Entwickler müssen beachten, dass aus dem formalen Software-Design (ARXML-ServiceInterface) für heterogene Deployments sowohl C++-Bindings (*Proxy.h, *Skeleton.h) als auch Rust-spezifische Wrapper-Artefakte (Traits, Structs) generiert werden müssen.