Figure 7.1: Methodology: C++ Language Binding generation

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: AUTOSAR-Methodik- und Build-Pipeline-Diagramm (Datenfluss-/Generierungsprozess).
• Architektur-Kontext:
  • Beschreibt den Übergang von der modellierten M2/M1-Ebene (ARXML) in den konkreten C++-Quellcode gemäß AUTOSAR_AP_SWS_LanguageBindingForModeledAPdatatypes.
  • Verortet im Design- und Compile-Time-Workflow der AUTOSAR Adaptive Platform (AP): Schnittstellenbeschreibungen verschiedener FCs (Functional Clusters wie ara::com, ara::per) definieren typisierte Payloads über CppImplementationDataType.
  • Realisiert die Anforderung RS_AP_00111 durch automatische Generierung standardisierter, plattform- und typsicherer C++-Header (impl_type_<symbol>.h) zur Entkopplung von Datenmodellierung und Compiler-Übersetzung.

2. Komponenten, Entitäten & Schnittstellen

• Eingangsartefakte (AUTOSAR XML / Manifeste):
  • ServiceInterface (app_svc_x.arxml): Service-orientierte Schnittstelle (ara::com).
  • KeyValueStorageInterface (app_kvs_x.arxml): Persistenz-Schnittstelle (ara::per).
  • OtherInterface: Generische Erweiterung für weitere funktionale Cluster (z. B. Diagnostics, TimeSync).
  • CppImplementationDataType (M2-Metaklasse, «atpVariation», spezialisiert AbstractImplementationDataType):
    • .category = VECTOR / .shortName = MyVector: Mapped auf dynamisch wachsende Sequenzcontainer (ara::core::Vector).
    • .category = ARRAY / .shortName = MyArray: Mapped auf statisch dimensionierte Arrays (ara::core::Array / std::array).
    • .category = ASSOCIATIVE_MAP / .shortName = MyMap: Mapped auf assoziative Key-Value-Container (ara::core::Map).
    • .category = VARIANT / .shortName = MyVariant: Mapped auf typisierte Union-Typen (ara::core::Variant).
• Transformations- und Build-Werkzeuge:
  • ARA Language Binding Generator: Modellcompiler/Codegenerator der Adaptive Toolchain.
  • C++ Compiler: Zielplattform-Cross-Compiler (C++14/C++17/C++20 Toolchain für POSIX/OS, z. B. QNX, Linux).
• Generierte Artefakte (Granulare C++ Header):
  • impl_type_<symbol>.h bzw. impl_type_<shortName>.h (SWS_LBAP_00002, SWS_LBAP_00003): Isolierte C++ Header pro CppImplementationDataType.
• Anwendungs- und Zielartefakte:
  • Application Implementation source code (*.cpp, *.h): Entwickler-Quellcode der Adaptive Application.
  • Adaptive Application object code (*.o): Kompilierte Translation Units / Binärartefakte.
• Beziehungen & Kardinalitäten:
  • 1 : n: Ein Interface-ARXML enthält mehrere CppImplementationDataType-Definitionen.
  • 1 : 1: Jeder CppImplementationDataType wird deterministisch in exakt eine dedizierte Header-Datei impl_type_<symbol>.h überführt (SWS_LBAP_00003).
  • n : 1 (Wiederverwendung): Mehrere heterogene Schnittstellen (ServiceInterface, KeyValueStorageInterface) referenzieren denselben Typ (hier: MyArray); der Generator stellt Idempotenz sicher (impl_type_MyArray.h existiert projektweit nur einmal).

3. Dynamisches Verhalten & Sequenzablauf

• 1. Modell-Injektion (Design-Time / Offline):
  • Bereitstellung der Software-Beschreibungsdateien (*.arxml) mit typisierten Elementen (CppImplementationDataType) für Service- und Persistenz-Schnittstellen.
• 2. Codegenerierungs-Phase (Pre-Compile Step):
  • Der ARA Language Binding Generator parst die Manifeste und löst Namespaces (TPS_MANI_01212) sowie Typabhängigkeiten auf.
  • Deterministische Ausgabe der typisierten Header-Dateien: $$\text{ARXML-Typ } X \xrightarrow{\text{Generator}} \text{C++ Header: } \texttt{impl\_type\_}X\texttt{.h}$$
  • Anwenden von Include-Guards (#ifndef, #pragma once) und Erzeugung der standardisierten C++ Type Aliases (using MyVector = ara::core::Vector<...>;).
• 3. Übersetzung / Compilation (Compile-Time):
  • Synchrone Kompilierung: Der C++ Compiler bindet impl_type_*.h transitiv über Service-Proxies/Skeletons oder direkt in den Anwendungscode (*.cpp, *.h) ein.
  • Erzeugung der Binärobjekte (*.o) für das Ziel-POSIX-Betriebssystem.
• Fehler- und Abbruchbedingungen:
  • Syntax-/Schema-Fehler im ARXML führen zum sofortigen Abbruch des Binding-Generators.
  • Unvollständige Typdefinitionen oder zyklische Typ-Verschachtelungen ohne Pointer/Smart-Pointer-Kapselung brechen im C++-Compiler mit unvollständigen Typen (Incomplete Types / ODR-Verletzungen) ab.

4. Normative Relevanz & Entwickler-Hinweise

• Granularitätsgebot (SWS_LBAP_00003):
  • Verbot monolithischer „God-Header“. Jeder modellierte Typ erzwingt eine eigene Header-Datei impl_type_<symbol>.h. Dies minimiert Compiler-Abhängigkeiten und optimiert inkrementelle Builds massiv.
• Dateinamen- und Symbolkonvention (SWS_LBAP_00002):
  • Das Präfix impl_type_ ist normativ vorgeschrieben. Als Suffix dient entweder das im Metamodell definierte symbol oder der shortName des CppImplementationDataType.
• Container-Mapping (TPS_MANI_01176, TPS_MANI_01212):
  • Datentypen der Kategorie VECTOR, ARRAY, ASSOCIATIVE_MAP und VARIANT müssen zwingend auf die entsprechenden Typen des Namespace ara::core:: abgebildet werden (Vector, Array, Map, Variant), um Speichersicherheit, Determinismus und Allokationskontrolle in sicherheitskritischen Automotive-Umgebungen (ASIL-Konformität) zu gewährleisten.
• One Definition Rule (ODR) & Schnittstellen-Sharing:
  • Wird ein Typ wie MyArray sowohl über ServiceInterface als auch über KeyValueStorageInterface verwendet, darf kein Namensraum-Konflikt entstehen. Der Generator muss garantieren, dass identische fully qualified Typen im gleichen C++-Namespace liegen und redundant inkludierte Header idempotent bleiben.
• Entwickler-Restriktion:
  • impl_type_*.h-Dateien sind reine Generierungsartefakte. Manuelle Modifikationen sind verboten, da sie bei erneutem Build überschrieben werden. Anpassungen an Speicherlayouts, Größen oder Allokatoren müssen ausschließlich im AUTOSAR-Authoring-Tool auf ARXML-M2-Ebene vorgenommen werden.