Figure 9.2: Functional Clusters in category Runtime

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm / Architektur-Übersichtsdiagramm der AUTOSAR Adaptive Platform (AP).
• Architektur-Kontext: Strukturierte Zuordnung der funktionalen Cluster (FC) zur logischen Kategorie Runtime gemäß AUTOSAR_AP_EXP_SWArchitecture (Kapitel 9.2).
• Funktionale Einordnung: Definiert die elementaren Laufzeit- und Kontrollmechanismen, die auf jedem POSIX-basierten Betriebssystem (PSE51-Profil) die Ausführungsumgebung (Adaptive Core) für Adaptive Applications (AA) und Plattform-Services bereitstellen.

2. Komponenten, Entitäten & Schnittstellen

Dargestellt sind fünf funktionale Cluster, jeweils typisiert als «aapFunctionalCluster»:

1. Execution Management (ara::exec)
   • Klassifikation: daemon-based (autonomer OS-Prozess / Plattform-Daemon).
   • Rolle: Zentraler Prozess- und Lebenszyklusverwalter. Zuständig für Initialisierung, Start/Stopp von Prozessen anhand der Execution Manifeste, Zuweisung von Ressourcenbudgets (Cgroups/POSIX-Scheduling-Parameter) und Überwachung des Ausführungsstatus.
2. State Management (ara::sm)
   • Klassifikation: daemon-based (autonomer OS-Prozess / Plattform-Daemon).
   • Rolle: Domänen- und Zustandskoordinator. Verarbeitet interne/externe Systemereignisse (Fahrzeugnetzwerk, Diagnose, Energiemanagement) und initiiert Zustandsübergänge (Function Groups / Machine States) über das Execution Management.
3. Log and Trace (ara::log)
   • Klassifikation: Bibliotheksbasiert (library-based, in-process Client-API mit optionaler DLT-Daemon-Backend-Anbindung).
   • Rolle: Standardisierte In-Process-Schnittstelle zur Erfassung strukturierter Logging- und Tracing-Daten gemäß AUTOSAR- und GENIVI/COVESA-DLT-Standards.
4. Core (ara::core)
   • Klassifikation: Bibliotheksbasiert (library-based, Header-only bzw. statisch/dynamisch gelinkte In-Process-Basisbibliothek).
   • Rolle: Fundamentale C++-Basistypen und Utilities für alle AP-Stacks und Applikationen (ara::core::Result, ErrorCode, Span, String, Vector, InstanceSpecifier, Future/Promise).
5. Operating System Interface (OSI)
   • Klassifikation: Bibliotheksbasiert / Abstraktionsschicht (library-based).
   • Rolle: Standardisierte Kapselung der POSIX PSE51-Schnittstellen (IEEE 1003.13) für Threading (pthread), Scheduling, Zeitgeber und Low-Level IPC, um Portabilität zwischen zertifizierten RTOS (z. B. QNX, PikeOS, Linux) zu garantieren.

Beziehungen & Taxonomie:

• Daemon-based vs. Library-based: EM und SM laufen als privilegierte, separierte Prozesse im User Space; Core, OSI und Log/Trace werden direkt in den Adressraum der jeweiligen Adaptive Application gelinkt.
• Es sind keine statischen Assoziationskanten gezeichnet; die Interaktion zwischen Applikationen und Daemons erfolgt über definierte IPC-Mechanismen (z. B. Unix Domain Sockets, Shared Memory, POSIX Signals).

3. Dynamisches Verhalten & Sequenzablauf (falls zutreffend)

Obwohl das Diagramm statische Bausteine abbildet, induziert die Kategorie Runtime eine feste Laufzeitkaskade:

1. Bootstrap & Daemon-Start:
   • Nach dem OS-Kernel-Boot instanziiert das Init-System über OSI das Execution Management als primären User-Space-Prozess.
   • EM startet die Basiskomponenten und den State Management-Daemon.
2. State Transitions & Prozessaktivierung:
   • SM ermittelt den Zielzustand (z. B. MachineState::Startup → MachineState::Running) und fordert die Aktivierung entsprechender Function Group States via IPC beim EM an.
   • EM forkt/execed die den States zugeordneten Adaptive Applications gemäß Execution Manifest.
3. Applikations-Laufzeit & Alive-Reporting:
   • Die Applikation initialisiert ara::core, richtet Logger via ara::log ein und meldet ihren Status via ara::exec::ExecutionClient::ReportExecutionState(ExecutionState::kRunning) an den EM-Daemon.
   • Bei fehlerhafter oder ausbleibender Zustandsmeldung greifen die im Manifest definierten Recovery Actions (Neustart, Fail-Safe State Transition via SM).
4. Controlled Shutdown:
   • SM triggert State Transition zum Shutdown/Standby; EM sendet Terminationssignale (z. B. SIGTERM) an Prozesse mit konfigurierter Termination-Timeout-Frist.

4. Normative Relevanz & Entwickler-Hinweise

• Kein direkter POSIX-Bypass: Applikationsentwickler dürfen keine nativen fork()-, exec()- oder OS-spezifischen Prozesssteuerungen nutzen. Der Prozesslebenszyklus unterliegt exklusiv dem EM (AUTOSAR_SWS_ExecutionManagement).
• Verbindlicher API-Vertrag: Jede Adaptive Application muss zwingend ara::core für die Fehlerbehandlung (ara::core::Result<T, E>) einbinden (Exceptions sind im AP-API-Design weitgehend untersagt bzw. optional).
• Execution Reporting Pflicht: Implementierung des ExecutionClient ist obligatorisch; wird der Zustand kRunning nicht innerhalb des konfigurierten startupTimeout an EM gemeldet, klassifiziert EM die Applikation als fehlerhaft.
• ARXML-Modellierung: Alle Laufzeitaspekte (Function Group Zuordnung, Resource Limits, Startup-Prioritäten, Environment Variables) müssen vollständig im ExecutionManifest modelliert werden, damit EM die Prozesse normgerecht orchestrieren kann.