Figure 7.4: process Lifecycle

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Formaler Zustandsübergangsgraph / Finite State Machine (FSM) des Prozesslebenszyklus (Process Lifecycle).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Execution Management (EM).
• Technischer Zweck: Definition der normativen Zustände und Zustandsübergänge, die eine Prozess-Instanz (Process) von der Initialisierung durch das Betriebssystem (POSIX OS) über die aktive Ausführung bis zur kontrollierten Terminierung und Bereinigung durchläuft. Das Modell synchronisiert die Ausführungszustände einzelner Applikationsprozesse mit den übergeordneten Function Groups (FG) und Machine States.

2. Komponenten, Entitäten & Schnittstellen

• Entitäten & Zustände (Zustandsmenge gemäß SWS_EM_01401):
  • Idle: Der Prozess existiert lediglich als Konfiguration/Manifest (ProcessDesign, Process-Modell), ist jedoch nicht im Betriebssystem instanziiert. Es sind keine OS-Ressourcen alloziert.
  • Starting: Eintrittszustand nach Anforderung der Ausführung. Der OS-Prozess wird erzeugt (z. B. via fork/exec), Adressraum und Dateideskriptoren werden initialisiert, Ressourcen (Speicher, CPU-Budget, OS-Prioritäten, Scheduling-Policies) werden zugeteilt.
  • Running: Der Prozess ist operativ und nimmt am regulären Scheduling teil. Die Applikationslogik läuft.
  • Terminating: Einleitungszustand für das kontrollierte Herunterfahren. Der Prozess erhält den Auftrag zur Selbstreinigung.
  • Terminated: Der Prozess ist vollständig beendet. Alle zugeordneten OS- und Plattform-Ressourcen (Threads, Semaphore, Shared Memory, Dateihandles) sind freigegeben.
• Schnittstellen & Interaktionspunkte:
  • Interne Schnittstelle / OS-Primitives: Interaktion zwischen EM-Daemon und dem POSIX-Betriebssystem-Kernel (Prozess-Spawn, PID-Verwaltung, Signal-Handling).
  • Applikationsschnittstelle (ara::exec): Interaktion via Inter-Process Communication (IPC) über den ara::exec::ExecutionClient.
  • Stereotypen / Metamodellbezug: Process («atpPrototype»), instanziiert aus Executable («atpStructureElement»); gebunden an einen Machine-Kontext über ProcessToMachineMapping.

3. Dynamisches Verhalten & Sequenzablauf

Die Sequenz beschreibt den deterministischen Lebenszykluspfad eines Prozesses (SWS_EM_01402, SWS_EM_01403):

1. Trigger Execute (Idle → Starting):
   • Ursache: Anforderung eines Zustandswechsels in einer Function Group (z. B. durch den State Management Cluster via ara::exec::StateClient), in welcher der Prozess im Manifest für den Zielzustand aktiviert ist.
   • Aktion: EM instanziiert den Prozess über POSIX-Systemaufrufe (posix_spawn / execve), wendet Ressourcenlimits an (ProcessExecutionError, CPU-Affinität, cgroups, RT-Scheduling-Attribute).
2. Trigger Schedule / ReportExecutionState (Starting → Running):
   • Ursache: Der Prozess hat seine statische Initialisierung (z. B. ara::core::Initialize()) abgeschlossen.
   • Synchronisation: Der Prozess muss aktiv ara::exec::ExecutionClient::ReportExecutionState(ara::exec::ExecutionState::kRunning) aufrufen.
   • Monitoring: EM überwacht diesen Übergang mit einem im Manifest definierten Startup-Timeout (startupTimeout). Erfolgt die Meldung nicht rechtzeitig, greift das Fehlerbehandlungsregime (SWS_EM_02241).
3. Trigger Terminate (Running → Terminating):
   • Ursache: Zustandswechsel der Function Group (Prozess wird im Zielzustand nicht mehr benötigt) oder allgemeiner Machine-Shutdown.
   • Aktion: EM sendet ein definiertes Terminierungssignal (typischerweise SIGTERM) an den Prozess.
4. Übergang nach Terminated (Terminating → Terminated):
   • Regulärer Pfad: Der Prozess fängt SIGTERM ab, schließt Kommunikationsendpunkte (ara::com), beendet Threads und ruft ara::core::Deinitialize() auf, gefolgt vom Exit (exit(0)).
   • Eskalationspfad: Überschreitet der Prozess die konfigurierte terminationTimeout-Dauer, erzwingt EM die Beendigung via SIGKILL.
   • Abschluss: EM registriert den Exit-Status (waitpid), gibt verbleibende Bindungen frei und überführt den Zustand nach Terminated bzw. zurück nach Idle.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (ExecutionClient Pflicht): Jeder Adaptive-Application-Prozess muss deterministisch ExecutionClient::ReportExecutionState(kRunning) melden. Ein Unterlassen führt zum Timeout durch das Execution Management und zur Einstufung als fehlerhafter Prozessstart.
• Signal-Handling & De-Initialisierung: Applikationen dürfen SIGTERM nicht blockieren oder ignorieren. Es muss ein Signal-Handler oder Signal-Watcher registriert sein, der den geordneten Abbruch (Shutdown-Phase) innerhalb des im Manifest parametrierten terminationTimeout sicherstellt.
• Manifest-Konfiguration:
  • startupTimeout: Muss so kalibriert sein, dass Worst-Case-Startzeiten (inkl. TLB-, Cache-Warmup und deterministischer Speicherallokation) abgedeckt sind, ohne Diagnose-Eskalationen unnötig zu verzögern.
  • terminationTimeout: Muss ausreichend dimensioniert sein, um persistente Daten (ara::per) konsistent zu flushen und IPC-Verbindungen sauber abzubauen.
• Ressourcenallokations-Einschränkung: Das Schaubild visualisiert normativ: Dynamische Ressourcenallokation ist im Zustand Starting zu vollziehen. Im Zustand Running gilt für ASIL-relevante Systeme das Prinzip der statischen Ressourcenbindung (kein unkontrolliertes dyn. Nachallozieren von Heap/Threads im Regelbetrieb).