Figure 6.10: Creating a service

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm) mit Sprachdomänen-Partitionierung (Rust vs. C++).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Spezifikation AUTOSAR_AP_EXP_ARARustApplications (R23-11 bis R25-11).
• Technischer Zweck: Darstellung des Foreign Function Interface (FFI)- und Adapter-Musters zur Instanziierung und Bereitstellung (Service Offering) eines ara::com-Service-Skeletons aus einer in Rust implementierten Adaptive Application (App) über einen bestehenden, standardisierten C++-ara::com-Middleware-Stack.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm unterteilt die Interaktionspartner strikt in zwei Sprach- und Laufzeitdomänen:

Rust-Laufzeitdomäne

• Executor: Asynchroner Task-Scheduler / Event-Loop der Rust-Applikation, steuert Thread-Aktivierung und Idle-Zustände.
• App: Domänenspezifische Applikationslogik; implementiert den konkreten Service-Trait bzw. das Struct RadarImp.
• Skeleton (gen): Codegeneriertes Rust-Skeleton (aus ARXML-Service-Interfaces generierte typsichere Rust-Fassade).
• ara crate: Statische Rust-Laufzeitbibliothek (ara-Crate); fungiert als Registry und Speicherschutz für Function-Pointer-Tabellen und FFI-Handle-Verwaltung.

C++-Laufzeitdomäne

• Adapter (gen): Codegenerierter C++/C-Bridge-Adapter; stellt C-kompatible ABI-Symbole bereit, instanziiert C++-Objekte und konvertiert Typen/Vtables.
• Adapter (static): Statische C++-Adapter-Laufzeitbibliothek; kapselt generische ara::com-Skeleton-Interaktionen (z. B. OfferService()).
• Skeleton (gen): Nativer, aus ARXML generierter C++-ara::com-Service-Skeleton (radarSkeleton).

Datenstrukturen & Schnittstellen

• RadarImp: Konkrete Rust-Instanz der Service-Geschäftslogik.
• Function Table (Vtable): C-kompatible Funktionstabelle (extern "C"-Funktionszeiger) zur späten dynamischen Auflösung von Methodenaufrufen über die Sprachgrenze hinweg.
• Objekt-Handles: Opaque Pointers zur Identifikation der C++-Skeleton-Instanz in der Rust-Domäne.

3. Dynamisches Verhalten & Sequenzablauf

Phase 1: Service-Erzeugung & FFI-Registrierung (create_service)

1. Trigger: App initiiert die Service-Erstellung synchron über create_service am generierten Rust-Skeleton (gen).
2. Lokale Instanziierung: Skeleton (gen) fordert über RadarImp::new die Instanz der Anwendungslogik von App an.
3. Cross-Language-Allokation: Skeleton (gen) ruft über C-FFI make_radarimp am C++ Adapter (gen) auf.
4. C++-Konstruktion: Adapter (gen) erzeugt intern die Instanz (new radarimp) und ruft synchron den Konstruktor radarSkeleton ctor des C++ Skeleton (gen) auf.
5. Handle- & Vtable-Rückgabe: Adapter (gen) übergibt object and implementations (Instanz-Zeiger und Funktionszeigertabellen) zurück an Rust-Skeleton (gen).
6. Vtable-Persistierung: Skeleton (gen) registriert die FFI-Dispatch-Tabelle über set_implementations im statischen ara crate („Remember implementations function table“).
7. Return: Beendigung von create_service; Kontrolle kehrt zu App zurück.

Phase 2: Service-Bereitstellung (offer_service)

1. Offering-Trigger: App ruft offer_service am Rust-Skeleton (gen) auf.
2. Indirekter FFI-Dispatch: Skeleton (gen) dispatcht den Aufruf über die zuvor hinterlegte Funktionstabelle (via function table) an den C++ Adapter (gen).
3. Stack-Delegation: Adapter (gen) delegiert an die statische Basisinfrastruktur Adapter (static) via OfferService.
4. Middleware-Aktivierung: Adapter (static) führt den Methodenaufruf object method (radarSkeleton::OfferService()) auf dem nativen C++-Skeleton (gen) aus. Das Service-Interface ist damit am Bus (z. B. SOME/IP, IPC) registriert.
5. Return: Synchrone Rückkehr der Aufrufskette bis zur App.

Phase 3: Übergang in den Ruhezustand

1. Thread-Yield: App übergibt die Thread-Kontrolle via sleep an den Executor, um auf asynchrone Ereignisse/Methoden-Invocations zu warten.

4. Normative Relevanz & Entwickler-Hinweise

• Konsequenz für Applikationsentwickler (Rust):
  • Die Rust-Applikation interagiert ausschließlich mit Safe-Rust-Abstraktionen (Skeleton (gen)). Unsafe-FFI-Operationen sind vollständig in generierten Adaptern und der ara-Crate gekapselt.
  • Das Lifecycle-Management erfordert nach offer_service das Verharren des Ausführungsfadens über den Executor (kein unkontrolliertes Terminieren der main-Funktion).
• Konsequenz für Stack- und Toolchain-Entwickler:
  • Zweistufiger Codegenerator: Es müssen zwei synchrone Artefaktpaare aus dem ARXML generiert werden: Das reguläre C++-Skeleton inkl. C-Bridge (Adapter (gen)) sowie das Rust-Skeleton inkl. Bindings.
  • Speicher-Ownership & Lebensdauer: Das erzeugte C++-Skeleton-Objekt und die Rust-Instanz RadarImp müssen über native Heap-Handles synchron gehalten werden (Box/Pinning). Vorzeitiges Deallokieren auf einer Seite führt zu Use-After-Free bei nachfolgenden IPC-Callbacks.
  • ABI-Stabilität: Der Aufrufmechanismus via function table erzwingt eine strikte C-ABI-Kompatibilität (#[no_mangle], extern "C") ohne C++-spezifische Name-Mangling- oder Exception-Mechanismen über die Sprachgrenze hinweg.
• Spezifikatorische Einordnung: Als EXP (Explanation) definiert das Dokument den Referenzansatz für hybride Rust/C++-Architekturen in der Adaptive Platform, um bestehende C++-zertifizierte Kommunikationsstacks ohne Neuzertifizierung in Rust wiederzuverwenden.