Modul ara::exec — Execution Management

Das Modul Execution Management verwaltet als zentraler Plattform-Daemon den deterministischen Lebenszyklus von POSIX-Prozessen auf der AUTOSAR Adaptive Platform (AUTOSAR AP SWS ExecutionManagement S. 18). Es nimmt Ausführungszustände über den ExecutionClient entgegen ([SWS_EM_02003]) und setzt von State Management beauftragte Funktionsgruppen-Transitionen asynchron durch das Starten und Beenden von Prozessen um ([SWS_EM_02278]). Wesentliche Randbedingungen sind das Verbot funktionsgruppenübergreifender Startabhängigkeiten sowie die strenge Fehlereskalation bei Fristverletzungen (SWS ExecutionManagement S. 65).

mehr ›

Das funktionale Cluster Execution Management (EM) bildet den zentralen Plattform-Daemon der AUTOSAR Adaptive Platform zur deterministischen Prozessverwaltung und Lebenszyklussteuerung im POSIX-Benutzerraum (AUTOSAR AP SWS ExecutionManagement S. 18). Es trennt strikt zwischen Richtlinienentscheidung (Policy) und technischer Durchsetzung (Mechanism): Während State Management die Zielzustände vorgibt, kontrolliert EM die Prozesserzeugung, Reihenfolgen und Signalbehandlung (AUTOSAR AP EXP SWArchitecture S. 56). Über den [SWS_EM_02562] ExecutionClient melden Anwendungen und Plattformdienste ihren Zustand [SWS_EM_02000] kRunning via [SWS_EM_02003] ReportExecutionState(), während State Management über den [SWS_EM_02276] StateClient Zustandswechsel anfordert (AUTOSAR AP EXP SWArchitecture S. 48).

Kontextdiagramm: Einbettung des Execution Management als zentraler Daemon zwischen State Management, POSIX-Betriebssystem und Client-Prozessen. Quellen: AUTOSAR AP EXP SWArchitecture S. 56, AUTOSAR AP SWS ExecutionManagement S. 18, [SWS_EM_02003], [SWS_EM_02278].

Nach dem Start durch das Betriebssystem initiiert EM das State Management und synchronisiert dieses über [SWS_EM_02279] GetInitialMachineStateTransitionResult() auf den Maschinenzustand Startup (AUTOSAR AP SWS ExecutionManagement S. 52). Nachfolgende Transitionen von [SWS_EM_02586] FunctionGroup-Zuständen werden mit [SWS_EM_02278] SetState() asynchron angestoßen: EM terminiert nicht mehr benötigte Prozesse geordnet per SIGTERM, startet Folgeprozesse unter Beachtung lokaler Startabhängigkeiten und löst das resultierende Future ein, sobald alle Prozesse betriebsbereit sind (AUTOSAR AP SWS ExecutionManagement S. 53, SWS ExecutionManagement S. 71).

Sequenzdiagramm: Erfolgreicher Zustandswechsel einer Funktionsgruppe mit geordneter Prozessbeendigung und Prozessneustart. Quellen: AUTOSAR AP SWS ExecutionManagement S. 53, AUTOSAR AP SWS StateManagement S. 26, [SWS_EM_02278], [SWS_EM_02003].

Zur Absicherung von Echtzeitanforderungen unterstützt EM deterministisches Prozess-Pre-Mapping zur Vermeidung von Page-Faults (SWS ExecutionManagement S. 82) sowie deterministische Worker-Pools und Synchronisationsmechanismen (SWS ExecutionManagement S. 86, SWS ExecutionManagement S. 92). Verletzt ein Prozess sein Startzeitfenster, greift die Fehlerbehandlung: EM beendet den Prozess, versetzt die Funktionsgruppe in einen Undefined State, ruft den registrierten Callback auf ([SWS_EM_02276]) und stellt Fehlerdetails über [SWS_EM_02542] GetExecutionError() und die Modulfehlerdomäne [SWS_EM_02281] ExecErrc bereit (AUTOSAR AP SWS ExecutionManagement S. 54).

mehr ›

Systemgrenzen und funktionale Rolle des Execution Management

Das Modul exec (Execution Management, EM) bildet den zentralen Plattformdienst der AUTOSAR Adaptive Platform zur deterministischen Prozess- und Lebenszyklusverwaltung im POSIX-basierten User Space (AUTOSAR AP SWS ExecutionManagement S. 18). Architekturprägend ist die strikte Trennung von Steuerungsentscheidung (Policy) und technischer Durchsetzung (Mechanism): Während das funktionale Cluster State Management übergeordnete Betriebsmodi und Transitionsentscheidungen fällt, fungiert Execution Management als ausführende Instanz für Prozessallokation, Startreihenfolgen, Überwachung und Terminierung (AUTOSAR AP EXP SWArchitecture S. 56).

Execution Management realisiert native C++-Laufzeitschnittstellen für zwei komplementäre Rollen: Über die Klasse [SWS_EM_02562] ara::exec::ExecutionClient melden Anwendungsprozesse sowie plattforminterne Daemons (wie Diagnostic Management, Platform Health Management oder Communication Management) ihren Ausführungszustand an den Daemon (AUTOSAR AP EXP SWArchitecture S. 48, AUTOSAR AP SWS CommunicationManagement S. 34). Über die Schnittstelle [SWS_EM_02276] ara::exec::StateClient interagiert State Management mit dem Daemon, um Funktionsgruppen- und Maschinentransitionen anzufordern und Statusmeldungen abzufragen (AUTOSAR AP SWS ExecutionManagement S. 17).

Kontextdiagramm: Einbettung des Execution Management als zentraler Daemon zwischen State Management, POSIX-Betriebssystem und Client-Prozessen. Quellen: AUTOSAR AP EXP SWArchitecture S. 56, AUTOSAR AP SWS ExecutionManagement S. 18, [SWS_EM_02003], [SWS_EM_02278].

Zustandsarchitektur und mehrstufiges Lebenszyklusmodell

Die Zustandsverwaltung im Execution Management operiert auf drei miteinander korrelierten Hierarchieebenen: den übergeordneten Funktionsgruppenzuständen (Function Group States), den externen Betriebssystem-Lebenszykluszuständen aus Sicht des Daemons (Process States) sowie den prozessinternen Zuständen (Execution States) (AUTOSAR EXP PlatformDesign S. 29, AUTOSAR AP SWS ExecutionManagement S. 62). Auf Dämon-Ebene durchläuft ein konfigurierter Prozess typischerweise die Kette Idle, Starting, Running, Terminating und Terminated (AUTOSAR AP SWS StateManagement S. 32).

Für die prozessinterne Sicht definiert das Modul die Enumeration [SWS_EM_02000] ara::exec::ExecutionState. Normativ an das Execution Management meldbar ist dabei der Zustand kRunning über die Elementfunktion [SWS_EM_02003] ReportExecutionState(). Vorgelagerte Phasen wie Initializing sind für Execution Management implizite Zustände, die unmittelbar mit dem ersten Scheduling des POSIX-Prozesses vor der Ausführung von Nutzcode beginnen ([SWS_EM_02000], AUTOSAR EXP AdaptivePlatformInterfacesGuidelines S. 11). Applikative Betriebs- und Energiemodi (PowerModes) stellen keine Betriebssystemzustände dar, sondern sind logisch an die aktive Lebenszyklusphase Running gekoppelt (AUTOSAR AP SWS StateManagement S. 32).

Zustandsdiagramm: Korrelation der Funktionsgruppenzustände mit den Lebenszyklusphasen im Execution Management und den internen Prozesszuständen. Quellen: AUTOSAR EXP PlatformDesign S. 29, AUTOSAR AP SWS ExecutionManagement S. 32, [SWS_EM_02000].

Deterministischer Plattformhochlauf und Initialisierung

Der Start der AUTOSAR Adaptive Platform erfolgt in einer strikt koordinierten Sequenz ausgehend vom Betriebssystem-Kernel (AUTOSAR EXP SWArchitecture S. 148). Das Betriebssystem startet Execution Management über dessen Programmeinstiegspunkt main() (AUTOSAR AP SWS ExecutionManagement S. 52). Unmittelbar nach der Selbstinitialisierung erzeugt Execution Management den Prozess des State Management (AUTOSAR AP SWS StateManagement S. 25).

Sobald State Management initialisiert ist, meldet es seine Betriebsbereitschaft mit [SWS_EM_02003] ReportExecutionState(ExecutionState::kRunning) via ExecutionClient an Execution Management (AUTOSAR AP SWS ExecutionManagement S. 52). Im Anschluss synchronisiert sich State Management über [SWS_EM_02279] GetInitialMachineStateTransitionResult() auf den Abschluss der initialen Maschinen-Transition in den Zustand Startup; diese Methode liefert ein ara::core::Future<void> zurück ([SWS_EM_02279], AUTOSAR EXP SWArchitecture S. 151). Erst nach erfolgreicher Einlösung dieses Futures fordert State Management den Wechsel in nachfolgende Funktionsgruppenzustände an (AUTOSAR AP SWS StateManagement S. 24).

Sequenzdiagramm: Plattform-Hochlauf von der Betriebssysteminitiierung über den Start von State Management bis zur Freigabe des Folgezustands. Quellen: AUTOSAR AP SWS ExecutionManagement S. 52, AUTOSAR AP SWS StateManagement S. 25, [SWS_EM_02279], [SWS_EM_02003].

Steuerung von Funktionsgruppen und asynchrone Zustandstransitionen

Zustandswechsel werden applikativ über Repräsentanten der Klassen [SWS_EM_02586] ara::exec::FunctionGroup und [SWS_EM_02324] ara::exec::FunctionGroupState modelliert. Zur Gewährleistung deterministischer Ressourcenverwaltung ist FunctionGroup nicht kopierbar ([SWS_EM_02322], [SWS_EM_02327]), sondern ausschließlich verschiebbar ([SWS_EM_02328], [SWS_EM_02329]) und über Instanzvergleiche evaluierbar ([SWS_EM_02267], [SWS_EM_02268]). FunctionGroupState verbindet eine Funktionsgruppe mit einem Zielzustand ([SWS_EM_02324]) und unterstützt sowohl Kopier- als auch Verschiebesemantik ([SWS_EM_02325], [SWS_EM_02330], [SWS_EM_02331], [SWS_EM_02332], [SWS_EM_02273], [SWS_EM_02274]).

State Management leitet eine Transition durch Aufruf von [SWS_EM_02278] StateClient::SetState() ein, was synchron ein ara::core::Future<void> zurückgibt (AUTOSAR AP SWS StateManagement S. 31). Execution Management führt daraufhin die Transitionskette aus: Laufende Prozesse, die im Zielzustand nicht mehr konfiguriert sind, erhalten ein SIGTERM-Signal (AUTOSAR AP SWS ExecutionManagement S. 53). Nach deren Terminierung startet EM die für den Zielzustand vorgesehenen Prozesse und wartet auf deren Statusmeldung über [SWS_EM_02003] ReportExecutionState() (AUTOSAR AP SWS StateManagement S. 26, AUTOSAR SWS ExecutionManagement S. 49). Erst wenn alle beteiligten Prozesse erfolgreich angelaufen sind, wird das Future von SetState() positiv eingelöst (AUTOSAR AP SWS ExecutionManagement S. 53).

Startabhängigkeiten (Execution Dependencies) dürfen niemals über die Grenzen einer einzelnen Funktionsgruppe oder gar über unterschiedliche Zustände hinweg definiert werden (SWS ExecutionManagement S. 65). Bei Zustandswechseln führt Execution Management die Auflösung der Startabhängigkeiten strikt für die Prozesse des angeforderten Zielzustands (RequestedState) durch (SWS ExecutionManagement S. 71). Weichen die Startkonfigurationen eines Prozesses zwischen Ausgangs- und Zielzustand voneinander ab, erzwingt Execution Management dessen Neustart (SWS ExecutionManagement S. 65).

Sequenzdiagramm: Erfolgreicher Zustandswechsel einer Funktionsgruppe mit geordneter Prozessbeendigung und Prozessneustart. Quellen: AUTOSAR AP SWS ExecutionManagement S. 53, AUTOSAR AP SWS StateManagement S. 26, [SWS_EM_02278], [SWS_EM_02003].

Prozesskonfiguration, Speicherallokation und Vorab-Mapping

In realen Systemen existieren neben Standardanwendungen auch Prozesse ohne integriertes Zustandsreporting (Non-reporting Processes). Solche Prozesse treten nach dem Start automatisch in den Ausführungszustand Running über (SWS ExecutionManagement S. 44). Um Abhängigkeitsketten dennoch abzusichern, kann ein projektbezogener Begleitprozess (Companion Process) vorgeschaltet werden, der die funktionale Einsatzbereitschaft des Non-reporting-Prozesses evaluiert und stellvertretend [SWS_EM_02003] kRunning meldet, bevor abhängige Nachfolgeprozesse gestartet werden (SWS ExecutionManagement S. 44, SWS ExecutionManagement S. 48).

Hinsichtlich des Ressourcenbedarfs begrenzt der Parameter resourceConsumption.memoryUsage den durch den Prozess selbst allokierbaren Hauptspeicher, was auf POSIX-Systemen typischerweise über RLIMIT_AS umgesetzt wird (SWS ExecutionManagement S. 82, SWS ExecutionManagement S. 104). Zur Gewährleistung zeitlichen Determinismus und funktionaler Sicherheit unterstützt Execution Management das Vorab-Mapping (Pre-mapping): Ist Process.preMapping im Manifest aktiviert, mappt EM den Code und die Datenbereiche des Prozesses vollständig in den physischen Speicher vor (SWS ExecutionManagement S. 82). Dies verhindert Verzögerungen durch bedarfsgesteuertes Nachladen (Demand-Loading) beim Erstzugriff, sichert die ständige Verfügbarkeit sicherheitskritischer Fehlerbehandlungsroutinen und schützt vor späteren Fehlern durch beschädigte Dateisysteme (SWS ExecutionManagement S. 82).

Deterministische Ausführungszeit und Synchronisationsmodelle

Für echtzeitkritische Anwendungen stellt Execution Management Mechanismen zur deterministischen Ausführung bereit (SWS ExecutionManagement S. 79). Zyklische Prozesse interagieren über eine Wartepunkt-API mit dem Client, die Modi wie Service-Discovery, Initialisierung, Ausführung und Terminierung kontrolliert (SWS ExecutionManagement S. 79). Parallele Datenverarbeitung wird über Worker Pools abstrahiert: Um Datendeterminismus sicherzustellen, ist ein Datenaustausch zwischen nebenläufigen Instanzen von WorkerRunnable untersagt (SWS ExecutionManagement S. 86).

Zur Synchronisation mehrerer redundanter oder verteilter Prozesse kommt der DeterministicSyncMaster zum Einsatz (SWS ExecutionManagement S. 92). Bei ereignisgesteuerter Aktivierung entscheidet eine konfigurierbare Richtlinie (etwa eine M-aus-N-Mehrheitsentscheidung), wann Synchronisationsantworten versendet werden (SWS ExecutionManagement S. 92). Bei periodischer Aktivierung erfolgt eine einmalige Synchronisation zu Beginn, woraufhin ein globaler Zeitstempelpuffer den Startzyklus festlegt und nachfolgende Zyklen autonom über lokale Zähler und Fristüberwachung gesteuert werden (SWS ExecutionManagement S. 92). Der Sync-Master kann entweder als eigenständiger Prozess bereitgestellt oder im Rahmen eines Software-Lockstep-Frameworks als Bibliothek integriert werden (SWS ExecutionManagement S. 94, SWS ExecutionManagement S. 95).

Verhalten im Fehlerfall

Im Fehlerfall gliedert sich die Architektur nach dem allgemeinen Fehlertoleranzschema in Fehlererkennung (Error Detection) und anschließende Fehlerbehebung (Error Recovery) (SWS ExecutionManagement S. 86, SWS ExecutionManagement S. 107). Tritt während eines Funktionsgruppen-Zustandswechsels ein Start-up-Timeout auf – beispielsweise weil ein startender Prozess innerhalb der parametrierten Frist kein [SWS_EM_02003] ReportExecutionState(kRunning) absetzt –, bricht Execution Management den regulären Ablauf ab (AUTOSAR AP SWS ExecutionManagement S. 54).

Die interne Eskalation dürfte in diesem Fall die zwangsweise Terminierung des fehlerhaften Prozesses via SIGKILL umfassen; nach Ausschöpfen konfigurierter Neustartversuche wechselt die betroffene Funktionsgruppe in einen unbestimmten Zustand (Undefined Function Group State) (AUTOSAR AP SWS ExecutionManagement S. 54, [SWS_EM_02542]). Frage Q-5a8b6ad2e9e22eb4 (offen) Bei Eintritt in einen unbestimmten Zustand löst Execution Management den bei der Instanziierung von StateClient übergebenen Callback undefinedStateCallback aus ([SWS_EM_02276], [SWS_EM_02561]). State Management kann daraufhin über [SWS_EM_02542] GetExecutionError() das zugehörige Ereignis ara::exec::ExecutionErrorEvent abfragen, welches die fehlerhafte Funktionsgruppe ([SWS_EM_02546]) und den Fehlercode [SWS_EM_02541] ExecutionError ([SWS_EM_02545]) bereitstellt ([SWS_EM_02542]). Befindet sich die Funktionsgruppe wieder in einem definierten Zustand, schlägt GetExecutionError() fehl ([SWS_EM_02542]).

Sequenzdiagramm: Fehlerbehandlung beim Start-up-Timeout eines Prozesses während einer Zustandstransition. Quellen: AUTOSAR AP SWS ExecutionManagement S. 54, [SWS_EM_02278], [SWS_EM_02276], [SWS_EM_02542].

Zur einheitlichen Fehlerbehandlung verfügt das Modul über die Fehlerdomäne [SWS_EM_02286] ara::exec::ExecErrorDomain (abrufbar über [SWS_EM_02290] GetExecErrorDomain(), Identifikationsname über [SWS_EM_02287] Name(), Textmeldungen über [SWS_EM_02288] Message()). Spezifische Ausführungsfehler werden durch den Enumerationscode [SWS_EM_02281] ExecErrc abgebildet (wie kNoCommunication) und über [SWS_EM_02291] MakeErrorCode() konstruiert. Bei aktivierter Ausnahmebehandlung können Fehler über [SWS_EM_02289] ThrowAsException() als [SWS_EM_02283] ExecException geworfen werden. Zudem stellt der Destruktor [SWS_EM_02002] ~ExecutionClient() sicher, dass zuvor übernommene Handler für SIGTERM wieder auf ihren Ursprungswert zurückgesetzt werden, während bei Prozesserzeugung übergebene Abbruch-Callbacks bei Empfang eines Beendigungssignals greifen ([SWS_EM_02560], [SWS_EM_02562]). Weitergehende Wiederherstellungsaktionen (Recovery Actions wie Prozessneustart oder Übergang in Notbetrieb) werden in Kooperation mit dem Platform Health Management orchestriert (AUTOSAR SWS ExecutionManagement S. 54).

Weiterführende Detailbelege

Die nachfolgende Übersicht ordnet die maßgeblichen Spezifikationsanforderungen und Belegstellen den behandelten Themengebieten zu:

Themenbereich	Wesentliche Belege	Funktionale Bedeutung
Prozess-Zustandsmeldung	[SWS_EM_02000], [SWS_EM_02003], [SWS_EM_02562]	Definiert ExecutionState, Erzeugung von ExecutionClient und Meldung von kRunning.
Funktionsgruppen-Steuerung	[SWS_EM_02278], [SWS_EM_02586], [SWS_EM_02324]	Asynchrone Zustandstransition via SetState(), Instanziierung von FunctionGroup und FunctionGroupState.
Plattformhochlauf	[SWS_EM_02279], AUTOSAR AP SWS ExecutionManagement S. 52	Synchronisation des State Management auf den initialen Maschinenzustand Startup.
Fehlerbehandlung & Callbacks	[SWS_EM_02276], [SWS_EM_02542], [SWS_EM_02281]	Registrierung des undefinedStateCallback, Abfrage von ExecutionErrorEvent, Fehlerdomäne ExecErrc.
Speicherdeterminismus	SWS ExecutionManagement S. 82	Vollständiges Pre-Mapping von Prozessen zur Vermeidung von Latenzen durch Demand-Loading.