Figure 9.1: Overview of the AUTOSAR Adaptive Platform and its building block categories

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Paketdiagramm (High-Level Building Block / Architectural Category Overview).
• Technischer Zweck: Statische, logische Domänen-Strukturierung der AUTOSAR Adaptive Platform (AP) in funktionale Baustein-Kategorien (Building Block Categories). Es bildet die oberste Taxonomie-Ebene des Kapitels 9 („Building Block View“) in AUTOSAR_EXP_SWArchitecture (R21-11) und gruppiert die darin spezifizierten Functional Clusters (FC).

2. Komponenten, Entitäten & Schnittstellen

• Root-Paket / Namensraum:
  • AUTOSAR Adaptive Platform: Umfassender Architekturrahmen, der die Laufzeitumgebung (ARA – AUTOSAR Runtime for Adaptive Applications) sowie Systemdienste über einem POSIX-basierten Betriebssystem kapselt.
• Kategorie-Pakete (Building Block Categories):
  • Runtime: Kapselt Basisfunktionen für Prozess- und Systemlebenszyklus (z. B. Execution Management [EM], State Management [SM], OS-Interface/POSIX PSE51-Subset).
  • Communication: Kapselt serviceorientierte Inter-Prozess- und Netzwerkkommunikation (z. B. Communication Management [ara::com], SOME/IP, IPC, Network Management).
  • Storage: Kapselt persistente Datenspeicherung (z. B. Persistency [ara::per] via Key-Value-Storage und File-Storage).
  • Security: Kapselt kryptografische Operationen und Zugriffskontrolle (z. B. Cryptography [ara::crypto], Identity and Access Management [IAM]).
  • Safety: Kapselt Überwachungs- und Absicherungsfunktionen (z. B. Platform Health Management [PHM], Watchdog Interface).
  • Configuration: Kapselt Systemkonfiguration und Software-Update-Mechanismen (z. B. Update and Configuration Management [UCM]).
  • Diagnostics: Kapselt Diagnoseprotokolle und Fehlermanagement (z. B. Diagnostic Management [ara::diag] via DoIP, UDS).
• Beziehungen & Stereotypen:
  • Reine UML-Package-Komposition (AUTOSAR Adaptive Platform enthält disjunkte Sub-Packages).
  • Auf dieser Abstraktionsebene sind keine direkten Abhängigkeitsrelationen («use», «import») modelliert.

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

• Verhaltensmodell: Nicht zutreffend; rein statisches Struktur- und Taxonomiediagramm.
• Architektonischer Interaktionspfad:
  • Adaptive Applications (AAs) greifen typischerweise prozessübergreifend über standardisierte C++-Sprachbindungen (ara::*) auf die instanziierten Functional Clusters der jeweiligen Kategorie zu.
  • Inter-Cluster-Kommunikation (FC-to-FC) erfolgt plattformintern und ist auf dieser Diagrammebene weder zeitlich noch sequenziell festgelegt.

4. Normative Relevanz & Entwickler-Hinweise

• Dokumentenstatus (EXP): AUTOSAR_EXP_SWArchitecture ist ein rein erläuterndes Dokument (Explanation). Es definiert keine normativen [SWS_...]-Anforderungen, legt jedoch die verbindliche Referenzarchitektur und Nomenklatur für alle nachgelagerten normativen Spezifikationen fest.
• Schnittstellenstandardisierung:
  • Application-to-Cluster: Streng normativ über C++14/17-Header im Namensraum ara::<cluster> spezifiziert.
  • Cluster-to-Cluster (FC-to-FC): Gemäß R21-11 explizit nicht standardisiert. Plattform-Vendors implementieren Inter-Cluster-Kommunikation und Zugriffskontrollen (z. B. IAM-Policy-Enforcement in Communication/Storage) herstellerspezifisch.
• Stack- und Applikations-Design:
  • Die Kategorisierung spiegelt keine zwingende Betriebssystem-Prozessarchitektur wider: Ein Functional Cluster kann als eigenständiger POSIX-Daemon, als Library innerhalb des Applikationskontexts oder als OS-Kernelmodul realisiert sein.
  • Entwickler dürfen keine Annahmen über synchrone/asynchrone FC-Interaktionen ableiten; diese sind ausschließlich in den jeweiligen Fach-SWS (z. B. AUTOSAR_SWS_CommunicationManagement, AUTOSAR_SWS_ExecutionManagement) definiert.