Figure 9.15: Interfaces of Execution Management required by State Management

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Komponentenschnittstellen-Diagramm (AUTOSAR Adaptive Platform Interface- & Architektursicht).
• Technischer Zweck & Einordnung:
  • Darstellung der architektonischen Entkopplung und Interaktionsschnittstellen zwischen den beiden zentralen Dämonen State Management (SM) und Execution Management (EM) gemäß AUTOSAR_EXP_SWArchitecture (Release R21-11).
  • Realisiert das Architekturprinzip „Separation of Mechanism and Policy“: State Management definiert und triggert die systemspezifische Zustandspolitik (Policy), während Execution Management die prozessuale und POSIX-bezogene Umsetzung (Mechanismus: Prozessstart, Termination, Ressourcen-/Budgetüberwachung) erzwingt.

2. Komponenten, Entitäten & Schnittstellen

Akteure & Functional Cluster

• «aapFunctionalCluster» State Management (daemon-based):
  • Aggregiert systemweite Zustandsanforderungen (z. B. von Diagnostics, Power Management, Vehicle Communication) und fordert Zustandsübergänge an.
• «aapFunctionalCluster» Execution Management (daemon-based):
  • Kernkomponente der Adaptive Platform; verwaltet den gesamten Lebenszyklus aller Prozesse und Maschinen-/Funktionsgruppen-Zustände.

Schnittstellen & Entitäten

• «aapAPI,aapNativeInterface» Execution Management::StateClient:
  • C++ Native Interface (Namespace ara::exec::StateClient).
  • Operationen:
    • + StateClient(function): Konstruktor zur Instanziierung des Clients; bindet Handler/Callbacks für asynchrone Fehlermeldungen (z. B. undefinierte Prozessabstürze, Verletzungen von Prozessabhängigkeiten).
    • + SetState(FunctionGroupState): Future: Asynchrone Anforderung eines Zustandswechsels für eine spezifizierte Funktionsgruppe; Rückgabetyp ist ein ara::core::Future<void> zur Synchronisation.
    • + GetInitialMachineStateTransitionResult(): Ermittelt das synchrone/gecachte Ergebnis des initialen Übergangs in den Maschinen-Grundzustand (MachineState) nach dem Bootstrapping.
    • + GetExecutionError(): Fragt detaillierte Fehlerursachen ab, falls ein Zustandsübergang fehlschlägt oder Prozesse abnormal terminieren.
  • Beziehung:
    • State Management besitzt eine gerichtete Abhängigkeit («use») auf StateClient.
    • Execution Management implementiert/realisiert (Realization, gestrichelte Kante mit geschlossener Dreiecksspitze) die native Schnittstelle StateClient.
• «aapAPI,aapPortInterface» Execution Management::FunctionGroup:
  • Modelliertes Port-Interface zur Adressierung einer logischen Prozessgruppe (z. B. MachineState oder applikative Funktionsgruppen wie OffroadMode, InfotainmentState).
  • Beziehung: State Management greift über «use» und «aapProvidedPort» zu; Execution Management bindet die Schnittstelle via «aapRequiredPort».
• «aapAPI,aapPortInterface» Execution Management::FunctionGroupState:
  • Modelliertes Port-Interface, das den diskreten Zielzustand einer Funktionsgruppe kapselt (dient als typisierter Parameter für SetState).
  • Beziehung: Analog über «aapProvidedPort» (SM) und «aapRequiredPort» (EM) miteinander gekoppelt.

3. Dynamisches Verhalten & Sequenzablauf

1. System-Bootstrap:
   • EM startet unmittelbar nach dem OS-Kernel und dem Platform-Init als primärer Dämon.
   • EM aktiviert die initiale MachineState (gemäß Machine Manifest) und startet grundlegende Cluster, darunter State Management.
2. Initialisierung des State Management:
   • SM instanziiert ara::exec::StateClient(errorHandlerCallback).
   • SM verifiziert den korrekten Initialisierungszustand der Maschine über GetInitialMachineStateTransitionResult().
3. Zustandstransition (Runtime-Phase):
   • Ein externes oder internes Ereignis triggert im SM eine Zustandsänderung.
   • SM ruft nicht-blockierend SetState(targetFunctionGroupState) auf.
   • EM empfängt den Request via IPC, identifiziert alle im Execution Manifest betroffenen Prozesse und führt Transitionsaktionen durch (Start via fork/exec, Termination via SIGTERM/SIGKILL, Timeout-Überwachung, Ressourcenlimits).
   • EM erfüllt das zugehörige ara::core::Promise; SM wertet den zurückgegebenen ara::core::Future aus (z. B. über .wait(), .get() oder Polling via Future-Status).
4. Fehlerbehandlung:
   • Schlägt der Start eines deterministischen Prozesses fehl oder antwortet ein Prozess nicht rechtzeitig, setzt EM den Future auf einen Fehlerzustand (ara::exec::ExecErrc).
   • SM ruft GetExecutionError() auf oder empfängt die Fehlerdetails im vorab registrierten Callback und leitet Sicherheits- oder Degradierungsmaßnahmen (Safe State Transition, Restart) ein.

4. Normative Relevanz & Entwickler-Hinweise

• Entkopplung & Zuständigkeit:
  • Applikations- und SM-Entwickler dürfen keine Low-Level-OS-Operationen (kill, system, POSIX-Signalbehandlung) für adaptive Anwendungen durchführen. Die Prozesssteuerung obliegt ausschließlich EM über die StateClient-API.
• Asynchrone Non-Blocking-Architektur:
  • SetState() arbeitet asynchron und liefert einen ara::core::Future. Der aufrufende Thread im State Management darf nicht unkontrolliert blockieren, um die Reaktionsfähigkeit auf Diagnose- oder Netzwerkereignisse nicht zu gefährden.
• Serialisierung & Concurrency:
  • Für dieselbe FunctionGroup darf zu jedem Zeitpunkt nur genau ein SetState()-Übergang aktiv sein. Ein erneuter Aufruf während einer laufenden Transition wird von EM mit einem Fehler quittiert. SM muss Transitions-Queues intern verwalten.
• Manifest-Konsistenz:
  • Die via FunctionGroup und FunctionGroupState adressierten Bezeichner müssen bitgenau mit den Identifikatoren im Execution- und Machine-Manifest (ARXML) übereinstimmen. Mismatches führen zu Laufzeitfehlern bei der Initialisierung von FunctionGroupState-Handles.
• Sicherheits- & Zugriffskonfiguration:
  • StateClient erfordert zwingend spezifische OS-Rechte (UID/GID, SELinux/AppArmor-Kontext), damit nur der autorisierte State Management-Prozess IPC-Nachrichten an den EM-Dämon absetzen darf.