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.
• AUTOSAR Runtime for Adaptive Applications (ARA):
  • Platform Foundation Functional Clusters (API-orientiert, blau kodiert):
    • ara::core: Basistypen, Core-Fehlerbehandlung, Speicher- und Initialisierungsmechanismen.
    • ara::com: Service-Oriented Communication (SOC) mit Transportbindungen an IPC, Signal PDU, SOME/IP und DDS.
    • ara::exec: Prozesslebenszyklus, Scheduling und Deterministic Client Control.
    • ara::iam: Autorisierung und Zugriffskontrolle.
    • ara::crypto: PKI, Schlüsselverwaltung, kryptografische Operationen.
    • ara::per: Persistente Speicherung (Key-Value- und File-Storage).
    • ara::phm: Alive-, Deadline- und Logical-Supervision von AAs.
    • ara::log: Strukturiertes Logging und Tracing (DLT).
    • ara::idsm: Erfassung und Weiterleitung von Security-Events.
    • ara::tsync: Hochgenaue Zeitsynchronisation (PTP / IEEE 802.1AS).
    • ara::diag: Fahrzeugdiagnose über UDS / DoIP.
    • ara::fw: Firewall zur Paketfilterung, Netzwerkverkehrsüberwachung und Regelprüfung (neu platziert neben dem OS-Interface).
  • 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 und C++ STL; im rechten Bereich baulich verkürzt zur Aufnahme des Blocks ara::fw.
• Unterlagerte Basis:
  • (Virtual) Machine / Container / Hardware: Abstraktion über Hypervisor-Partitionen, Linux-Namespaces/Container oder Bare-Metal-Hardware-Ressourcen.

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).