Figure 9.14: 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» StateClient:
  • C++ Native Interface (Namespace ara::exec::StateClient).
  • Operationen:
    • + Create(function): Statische Factory-Methode zur Erzeugung der Client-Instanz; 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» FunctionGroup:
  • Modelliertes Port-Interface zur Adressierung einer logischen Funktionsgruppe.
  • Operationen:
    • + Create(): Statische Factory-Methode zur Erzeugung bzw. Bindung eines Funktionsgruppen-Handles.
  • Beziehung:
    • State Management greift über «use» und «aapRequiredPort» auf die Schnittstelle zu.
    • Execution Management implementiert/realisiert das Port-Interface (Realization).
• «aapAPI,aapNativeInterface» FunctionGroupState:
  • C++ Native Interface zur Repräsentation des diskreten Zielzustands einer Funktionsgruppe (dient als typisierter Parameter für SetState).
  • Operationen:
    • + Create(): Statische Factory-Methode zur Erzeugung eines FunctionGroupState-Objekts.
  • Beziehung:
    • State Management greift über eine direkte «use»-Abhängigkeit auf die Schnittstelle zu.
    • Execution Management implementiert/realisiert die Schnittstelle (Realization).
• «aapAPI,aapNativeInterface» ExecutionClient:
  • C++ Native Interface (Namespace ara::exec::ExecutionClient), über das Anwendungen und Plattform-Dämonen ihren Ausführungszustand an das Execution Management melden.
  • Operationen:
    • + Create(): Statische Factory-Methode zur Erzeugung der ExecutionClient-Instanz.
    • + ReportExecutionState(ExecutionState): Meldet den aktuellen Ausführungszustand (z. B. kRunning) an den Execution Management Dämon.
  • Beziehung:
    • State Management greift über eine gerichtete «use»-Abhängigkeit auf ExecutionClient zu.
    • Execution Management implementiert/realisiert (Realization) die native Schnittstelle ExecutionClient.

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 und ara::exec::ExecutionClient über die statischen Factory-Methoden Create().
   • SM meldet seinen Ausführungszustand (ExecutionState::kRunning) via ExecutionClient::ReportExecutionState() an EM.
   • SM verifiziert den korrekten Initialisierungszustand der Maschine über StateClient::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.