Figure 7.3: Execution States

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Zustandsübergangsdiagramm / Prozess-Lebenszyklusmodell (Process Lifecycle State Machine) der AUTOSAR Adaptive Platform (AP), kombiniert mit vorgelagerter OS-Prozessinstanziierung.
• Funktionale Einordnung: Definiert gemäß AUTOSAR_SWS_ExecutionManagement (Kapitel Process Lifecycle Management, RS_EM_00103, SWS_EM_01055) die normativen Ausführungszustände (Execution States) einer Prozessinstanz eines Executable.
• Systemischer Zweck: Kapselung und deterministische Steuerung des Anwendungslebenszyklus durch das Execution Management (EM) zur Synchronisation von Startup, Normalbetrieb und geordnetem Shutdown (Graceful Termination) in Abhängigkeit von Funktionsgruppen-Zuständen (FunctionGroupState / MachineState).

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Entitäten:
  • OS / Loader-Ebene (Oval links): create process / allocate resources repräsentiert die Ausführungsumgebung (POSIX-OS / Kernel), getriggert durch den EM-Daemon (Erzeugung via fork/exec bzw. OS-spezifische APIs, Allokation von Adressraum, Filedeskriptoren, Cgroups, Scheduling-Parametern).
  • Adaptive Application Process (Umfassender Rahmen): Repräsentiert die Prozessgrenze einer laufenden Process-Instanz im User Space.
  • Zustandsmenge (Rechteckige Knoten):
    • Initializing: Interner Startzustand der Applikation direkt nach Prozessgenerierung.
    • Running: Normativer Betriebszustand zur Abarbeitung der Nutzfunktionalität.
    • Terminating: Shutdown-Zustand zur geordneten Ressourcenfreigabe und Datensicherung.
• Schnittstellen & Interaktionspunkte:
  • ara::exec::ExecutionClient: C++-Schnittstelle zwischen Prozess und EM (ara/exec/execution_client.h).
  • ExecutionClient::ReportExecutionState(ExecutionState::kRunning): Primärer IPC-Meldepfad vom Applikationsprozess an den EM-Daemon (SWS_EM_01004).
  • POSIX-Signalschnittstelle: Transportmedium für den Terminate-Trigger (primär SIGTERM, im Eskalationsfall SIGKILL).

3. Dynamisches Verhalten & Sequenzablauf

1. Instanziierung & Eintritt in Initializing:
   • EM aktiviert eine Funktionsgruppe (FunctionGroupState), identifiziert die zugehörigen Prozesse anhand des Manifests und initiiert die Prozesserzeugung (create process, OS-Ressourcenallokation).
   • Der Prozess startet in der main()-Funktion und betritt den Zustand Initializing.
   • Aktionen: Dateninitialisierung (application data initialization), Initialisierung der ARA-Laufzeit (ara::core::Initialize()), Allokation applikationsspezifischer Speicherstrukturen, Instanziierung von Service-Skeletten/Proxies (ara::com).
2. Transition Initializing → Running:
   • Trigger / API-Aufruf: Sobald die Initialisierung abgeschlossen und der Prozess bereit für die Bearbeitung von Requests ist, ruft der Prozess synchron ReportExecutionState(ara::exec::ExecutionState::kRunning) auf (SWS_EM_01004).
   • Synchronisation im EM: EM quittiert den Zustand intern. Erst wenn alle abhängigen Prozesse einer Gruppe kRunning gemeldet haben, gilt der Funktionsgruppen-Zustandswechsel als erfolgreich abgeschlossen.
3. Zustand Running:
   • Vollständiger Payload-Betrieb (perform main functionality): Abarbeitung von Event-Loops, zyklischen Tasks und serviceorientierter Kommunikation.
4. Transition Running → Terminating (Terminate-Trigger):
   • Trigger: Ein Zustandswechsel der übergeordneten FunctionGroup oder ein Machine-Shutdown veranlasst EM, den Prozess zu beenden.
   • Signalisierung: EM sendet ein POSIX-Signal (standardmäßig SIGTERM) an den Prozess.
   • Alternativpfad: Autonome Beendigung durch den Prozess selbst bei intern detektiertem Terminierungsbedarf.
5. Zustand Terminating & Exit:
   • Graceful Shutdown: Der Signal-Handler bzw. Shutdown-Thread leitet die Aufräumarbeiten ein (store data, free resources, exit): Persistierung flüchtiger Daten via ara::per, Deregistrierung von Services (StopOfferService()), Freigabe von Ressourcen und Aufruf von ara::core::Deinitialize().
   • Terminierung: Prozess beendet sich regulär mit Exit-Status 0.
   • Abbruch-/Eskalationspfad (Timeout): Reagiert der Prozess nicht innerhalb der im Manifest spezifizierten Process.terminationTimeout, erzwingt EM die Terminierung hart via SIGKILL.

4. Normative Relevanz & Entwickler-Hinweise

• Meldepflicht für Applikationsentwickler (SWS_EM_01004):
  • Das Melden von kRunning via ExecutionClient::ReportExecutionState() ist strikt normativ vorgeschrieben.
  • Bleibt der Aufruf innerhalb der im Manifest konfigurierten Initialisierungs-Timeout-Spanne (StartupConfig.startupOptions bzw. Monitoring-Timer) aus, interpretiert EM den Vorgang als Startup-Fehler (Startup Failed), terminiert den Prozess und führt die konfigurierte Recovery-Strategie (z. B. Neustart-Zähler-Inkrement, Zustands-Rollback) aus.
• Restriktionen im Zustand Initializing:
  • Keine blockierenden oder zeitlich unbestimmten I/O- und Netzwerkoperationen ohne Timeout-Absicherung; das Prozess-Startzeitbudget wird durch EM deterministisch überwacht.
• Shutdown-Konfiguration (terminationTimeout):
  • Das Zeitfenster für den Zustand Terminating ist durch Process.terminationTimeout im ARXML-Deployment-Modell begrenzt.
  • Zeitintensive Sicherungsoperationen (z. B. umfangreiche NVRAM-/Flash-Writes) müssen architektonisch inkrementell zur Laufzeit in Running erfolgen, um ein hartes Abschießen durch SIGKILL zu verhindern.
• Signal-Handling & Threading:
  • Entwickler müssen sicherstellen, dass SIGTERM blockiert und über dedizierte Signal-Threads (sigwaitinfo/Event-Demultiplexer) behandelt wird, um Deadlocks bei der Ressourcenfreigabe in asynchronen Signal-Handlern zu vermeiden.