Figure 4.1: AP architecture logical view

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Logisches Schichten- und Komponentenmodell (Blockarchitektur) der AUTOSAR Adaptive Platform (AP).
• Technischer Zweck: Darstellung der statischen Dekomposition der AP-Laufzeitumgebung (ARA) und deren Abgrenzung gegenüber Applikationsebene (User Applications), Betriebssystemebene (OSI-Schicht via POSIX) und unterlagerter Ausführungsumgebung (Hardware/VM/Container).
• Systemische Einordnung: Definiert die logische Struktur eines AP-Knotens gemäß AUTOSAR R21-11 (AUTOSAR_EXP_PlatformDesign). Veranschaulicht das Dualitätsprinzip zwischen Platform Foundation Functional Clusters (bibliotheksbasierte In-Process-APIs) und Platform Service Functional Clusters (serviceorientierte IPC/Netzwerk-Dienste), die für Adaptive Applications (AA) über eine einheitliche C++-API abstrahiert werden.

2. Komponenten, Entitäten & Schnittstellen

Schichten & Entitäten (Top-to-Bottom)

• User Applications:
  • Adaptive Application (AA): POSIX-konforme Nutzerprozesse mit eigenem virtuellem Adressraum.
  • Non-PF Service (ASW::XYZ, ASW::ABC): Anwendungsdienste, die über das Service-Interface von ara::com für andere AAs bereitgestellt werden (anwendungsspezifisches Service-Providing).
• AUTOSAR Runtime for Adaptive Applications (ARA): Definiert die standardisierte Laufzeitumgebung und stellt die Abstraktionsschicht für AAs dar. Unterteilt in:
  1. Platform Foundation Functional Clusters (API-orientiert, blau kodiert):
     • ara::core: Basistypen, Core-Fehlerbehandlung (ara::core::Result, ara::core::ErrorCode), Speicherallokations- und Initialisierungsmechanismen.
     • ara::com: Service-Oriented Communication (SOC). Bindet Transportprotokolle an:
       • Inter-Process Communication (IPC)
       • Signal-basierte Übersetzung (Signal PDU)
       • SOME/IP (Scalable service-Oriented MiddlewarE over IP)
       • DDS (Data Distribution Service)
     • ara::exec: Prozesslebenszyklus, Scheduling-Konfiguration und Deterministic Client Control.
     • ara::iam: Autorisierung und Zugriffskontrolle auf Schnittstellen und Ressourcen.
     • ara::crypto: PKI, Schlüsselverwaltung, kryptografische Operationen (Sym/Asym, Hashing).
     • ara::per: Persistente Datenspeicherung (Key-Value-Storage, File-Storage).
     • ara::phm: Alive-, Deadline- und Logical-Supervision von AAs.
     • ara::log: Strukturiertes Logging und Tracing (LT-Protokoll/DLT).
     • ara::idsm: Erfassung und Weiterleitung von Security-Events an den Intrusion Detection System Manager.
     • ara::tsync: Hochgenaue Zeitsynchronisation (PTP / IEEE 802.1AS).
     • ara::diag: Fahrzeugdiagnose über UDS / DoIP (Routing, Service-Handler-Anbindung).
  2. Platform Service Functional Clusters (Service-orientiert, grau kodiert):
     • ara::sm service: Zustands- und Funktionsgruppenmanagement (State Management).
     • ara::ucm service: Update and Config Management (Software-Aktualisierung / OTA).
     • ara::nm service: Netzwerk-Management (Bus-Schlaf-/Wachzustände).
• Operating System Interface:
  • Standardisiertes Subsystem via POSIX PSE51 (Minimal Realtime System Profile gemäß IEEE 1003.13) sowie C++ Standard Template Library (STL). Kapselt Threading, Mutexes, Semaphoren und Filesystem-Basisaufrufe.
• Unterlagerte Basis:
  • (Virtual) Machine / Container / Hardware: Abstraktion über Hypervisor-Partitionen, Linux-Namespaces/Container oder Bare-Metal-SoC-Ressourcen.

Schnittstellen- & Strukturbeziehungen

• In-Process-Bindings vs. Inter-Process Services:
  • Foundation FCs linken typischerweise als Shared- oder Static-Libraries direkt in den Kontext der AA ein (ara::*-Header/Libraries) und kommunizieren über Systemaufrufe direkt mit dem Kernel oder über IPC mit Background-Daemons.
  • Platform Services laufen als eigenständige Daemons und werden von AAs transparent über generierte Proxy-/Skeleton-Klassen via ara::com konsumiert.
• Abstraktion: Für die AA ist die Interaktionsform mit Plattform-Services und Non-Platform-Services identisch (strikte C++14/C++17-Interface-Semantik).

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm ist ein statisches Strukturmodell; aus den architekturellen Abhängigkeiten ergeben sich jedoch fundamentale dynamische Interaktionspfade:

1. Bootstrap & Prozessstart:
   • Plattform-Boot → OS initialisiert Hardware/Treiber.
   • ara::exec (Execution Management) startet als Init-Prozess/Master-Daemon und fährt Funktionsgruppen (Function Groups) gemäß Manifest hoch.
   • ara::exec spawnt AAs als native POSIX-Prozesse und setzt Capabilities/POSIX-Resource-Limits.
2. Service Discovery & Binding (ara::com):
   • Service-Provider (ASW::XYZ oder Platform Services wie ara::ucm) initialisieren ein Skeleton und rufen OfferService() auf.
   • Service-Consumer initialisieren einen Proxy, triggern FindService() (asynchron via Handler oder synchron polling) und binden nach Discovery an die Instanz.
   • Nachrichtenfluss erfolgt wahlweise per Shared Memory/Unix Domain Socket (IPC lokal) oder Ethernet (SOME/IP, DDS extern/intra-ECU).
3. Supervision & Health Management:
   • AA meldet zyklisch Checkpoints über ara::phm-Client-APIs (ReportCheckpoint()).
   • PhM aggregiert Status gegen definierte Transitionsregeln; bei Verletzung (Deadline/Alive) Trigger an ara::sm zur Recovery-Einleitung.

4. Normative Relevanz & Entwickler-Hinweise

• API-Schnittstellenvertrag:
  • Applikationscode darf ausschließlich auf spezifizierte ARA-Schnittstellen (ara::*), POSIX PSE51 und C++ STL zugreifen. Direkte Treiber-Zugriffe (z. B. Kernel-Module, /dev/*) oder proprietäre IPC-Mechanismen verletzen die Konformität und Portabilität.
  • Ausnahmslose Verwendung von ara::core::Result<T, E> / ara::core::ErrorCode anstelle von C++-Exceptions in sicherheitskritischen Bereichen (ASIL-Kontext).
• Konfigurations- und Bereitstellungs-Einschränkungen (Manifests):
  • Jede Interaktion erfordert AUTOSAR-Manifest-Modelle (ARXML): Execution Manifest (für ara::exec), Service Instance Manifest (für ara::com, Protokollbindung SOME/IP/IPC) und Service Interface Deployment.
  • IAM-Policies müssen explizit konfiguriert werden; unautorisierte Zugriffe einer AA auf ara::*-APIs werden zur Laufzeit durch ara::iam blockiert.
• Architekturelle Restriktionen:
  • Das Schaubild visualisiert logische Cluster, keine physischen Prozessgrenzen: Ein Foundation FC kann aus einer Client-Bibliothek plus einem dedizierten Hintergrund-Daemon bestehen.
  • Nicht alle dargestellten Functional Clusters müssen im konkreten AP-Stack-Release oder Ziel-Image instanziiert sein (Konfigurationsabhängigkeit laut Spezifikationshinweis zu R21-11).