Figure 8.1: Type model of building blocks

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Statisches UML-Klassendiagramm / Metamodell-Strukturdiagramm (Typmodell).
• Architektur-Kontext:
  • Definiert die hierarchische Dekomposition und das Metamodell der Basiselemente (Building Blocks) der AUTOSAR Adaptive Platform (AP) gemäß AUTOSAR_EXP_SWArchitecture.
  • Dient der formalen Strukturierung der Plattform-Architektur: Es ordnet funktionale Fähigkeiten groben Domänen zu (Category) und zerlegt diese in standardisierte funktionale Einheiten (Functional Clusters), welche sich wiederum in Spezifikations-Verträge (Interfaces) und Implementierungsbausteine (Components) gliedern.

2. Komponenten, Entitäten & Schnittstellen

• Entitäten:
  • Category:
    • Oberste architektonische Gruppierungsebene (z. B. Platform Management, Foundation, Services).
    • Bündelt thematisch verwandte Funktionsbereiche der Adaptive Platform.
  • Functional Cluster:
    • Zentrale architektonische Funktionseinheit der Adaptive Platform (z. B. Execution Management, Communication Management, Persistency, Diagnostics).
    • Kann architektonisch entweder als Foundation Cluster (bibliotheksbasiert, im Prozesskontext der Applikation) oder als Service Cluster (separater Daemon/Adaptive Application) realisiert sein.
  • Interface:
    • Spezifiziert die normativen Zugriffspunkte und Kontrakte des Functional Clusters.
    • Umfasst C++-Programmierschnittstellen (Standard-APIs im Namensraum ara::*), Manifest-/Modell-Definitionen (ARXML) sowie IPC-/Netzwerk-Service-Verträge.
  • Component:
    • Repräsentiert die konkrete Software-Implementierungseinheit innerhalb des Clusters (z. B. Shared Libraries, Hintergrund-Dienste/Daemons, Treiberabstraktionen oder interne Hilfsmodule).
• Beziehungen & Kardinalitäten (Kompositionen):
  • **Category ◆–1..*→ Functional Cluster:**
    • Strenge Komposition: Eine Category besteht aus mindestens einem oder mehreren Functional Clusters. Ein Functional Cluster existiert ausschließlich im Kontext seiner zugeordneten Kategorie.
  • **Functional Cluster ◆–1..*→ Interface:**
    • Strenge Komposition: Ein Functional Cluster kapselt und exponiert mindestens ein normatives Interface (Kardinalität 1..*).
  • **Functional Cluster ◆–1..*→ Component:**
    • Strenge Komposition: Ein Functional Cluster besteht zur Implementierungszeit aus mindestens einer oder mehreren Components (Kardinalität 1..*).

3. Dynamisches Verhalten & Sequenzablauf

• Klassifikation: Reines statisches Strukturmodell (Typmodell). Es existieren keine dynamischen Sequenzen, Zustandsübergänge oder Signalflüsse im Diagramm selbst.
• Laufzeitbezug der Entitäten:
  • Interaktion: Applikationen (Adaptive Applications) binden zur Laufzeit gegen die Interfaces eines Functional Clusters.
  • Ausführungspfade:
    • In-Process: Direkter synchroner Aufruf über statisch/dynamisch gelinkte Bibliotheken (Component) des Clusters (Foundation-Pattern).
    • Inter-Process (IPC): Asynchroner/synchroner Aufruf via ara::com bzw. OS-IPC an den zuständigen Cluster-Daemon (Component), z. B. bei State- oder Execution-Management.
  • Fehlerbehandlung: Fehler werden über cluster-spezifische ara::core::Result<T> bzw. ara::core::ErrorCode synchron oder via Callbacks/Futures asynchron an den Aufrufer propagiert; Systemfehler werden an das Diagnostic/Health Management weitergeleitet.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Verbindlichkeit:
  • Das Interface ist normativ standardisiert (SWS-Dokumente der Adaptive Platform, z. B. SWS Execution Management). Die C++-Headersignatur unter ara::* und die Datentypen stellen den unveränderlichen API-Vertrag dar.
  • Die Aufteilung in interne Components ist herstellerspezifisch (Plattform-Vendor/Stack-Implementierer-Freiheit), solange die Interface-Semantik und das geforderte Prozessmodell eingehalten werden.
• Auswirkungen auf Stack- & Plattform-Entwickler:
  • Bei der Implementierung eines neuen Functional Clusters muss sichergestellt werden, dass sämtliche exponierten Interfaces die Anforderungen an Thread-Safety, Reentrancy und Lifecycle (Init/Deinit) der AUTOSAR AP erfüllen.
  • Trennung von Deklaration (Interface) und Realisierung (Component) erzwingt lose Kopplung und Austauschbarkeit modularer Cluster-Bestandteile (z. B. Austausch des Logging-Backends oder IPC-Treibers).
• Auswirkungen auf Applikations-Entwickler:
  • Applikationen dürfen ausschließlich gegen die bereitgestellten Interfaces programmieren. Direkte Zugriffe auf interne Components oder proprietäre Symbole eines Functional Clusters verletzen die Konformität und zerstören die Portabilität zwischen AUTOSAR-Adaptive-Distributionen.