Figure 3: 1 Execution States

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Phasen- und Lebenszyklusmodell (Zustandsdiagramm eines POSIX-Prozesses auf Abstraktionsebene).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Subsystem Execution Management (EM; SWS Execution Management, EXP Adaptive Platform Interfaces Guidelines).
• Funktionale Einordnung: Definiert den standardisierten Lebenszyklus eines Adaptive Application Process von der Instanziierung durch den Execution Manager über die anwendungsseitigen Ausführungszustände (Initializing, Running, Terminating) bis zum Prozessende. Dient als Referenz für das Zustands-Reporting an ara::exec sowie die deterministische Prozess-Orchestrierung über Function Group States.

2. Komponenten, Entitäten & Schnittstellen

• Externe Plattform-Entität:
  • create process allocate resources (Elliptischer Eingangsknoten): Repräsentiert die POSIX-Betriebssystem- und EM-Ebene. Beinhaltet fork()/execve(), Adressraum-Isolation, Zuordnung von OS-Ressourcen (POSIX Threads, cgroups, Memory Locks/Limits, CPU-Affinities, Scheduling-Attribute gemäß Execution Manifest).
• Adaptive Application Boundary (Umschließender Block):
  • Isolierter User-Space-Prozesskontext (ProcessExecution), innerhalb dessen die C++-Applikationslogik abläuft.
• Ausführungszustände (Interne Prozesszustände):
  • Initializing: Vorbereitungsphase vor der funktionalen Dienstbereitstellung (Instanziierung von AUTOSAR-Laufzeitmodulen, Binding von Proxies/Skeletons in ara::com, Laden von Konfigurationsdaten).
  • Running: Operativer Produktivzustand (Abarbeitung zyklischer Tasks, Event-Loops, Bereitstellung von Diensten via OfferService()).
  • Terminating: Kontrollierte Deinitialisierungsphase (Zustandssicherung via ara::per, Rücknahme von Service-Angeboten, Thread-Join, Freigabe von OS-Ressourcen, geordneter Exit).
• Schnittstellen & Transitionen:
  • Initialer Zustandsübergang (Blockpfeil Initializing → Running): Anwendungsinterne Transition, gekoppelt an die Meldung via ara::exec::ExecutionClient.
  • Terminierungsübergang (Blockpfeil Terminate → Terminating): Extern über POSIX-Signale (SIGTERM) durch den EM oder intern durch Anwendungsbeschluss ausgelöst.

3. Dynamisches Verhalten & Sequenzablauf

1. Prozessstart (EM → OS):
   • Execution Management evaluiert einen Function-Group-Zustandswechsel und instanziiert den Prozess anhand des Modells (ProcessExecution).
2. Phase Initializing:
   • Eintritt in die main()-Funktion. Initialisierung statischer Variablen, IPC-Kanäle und Plattform-Komponenten.
3. Zustandsmeldung kRunning (SWS_EM_01053):
   • Sobald die Applikation vollständig betriebsbereit ist, meldet sie ihren Zustand aktiv an den EM:

     ara::exec::ExecutionClient executionClient;
     executionClient.ReportExecutionState(ara::exec::ExecutionState::kRunning);

   • Der EM überwacht diese Transition gegen das im Manifest hinterlegte startupTimeout.
4. Phase Running:
   • Normale Ausführung der Kernfunktionalität und Event-getriebene Kommunikation über ara::com.
5. Signal Terminate & Phase Terminating (SWS_EM_01070, SWS_EM_01071):
   • Der EM sendet typischerweise SIGTERM an den Prozess (z. B. infolge eines Function Group State-Wechsels initiiert durch State Management).
   • Der Signal-Handler fängt SIGTERM ab und triggert die Termination-Routine:
     1. Deregistrierung von Diensten (StopOfferService()).
     2. Persistierung flüchtiger Zustände über ara::per.
     3. Beendigung und Join aller Worker-Threads.
     4. Geordneter Prozess-Exit (exit(0) bzw. Rücksprung aus main()).
   • Erfolgt der Exit nicht innerhalb des im Manifest konfigurierten terminationTimeout, erzwingt der EM die Beendigung hart via SIGKILL (SWS_EM_01071).

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag & Meldezeitpunkt:
  • ReportExecutionState(kRunning) darf erst aufgerufen werden, wenn alle Ressourcen allokiert und konsumierende/anbietende Schnittstellen voll funktionsfähig sind. Ein zu früher Report führt zu Folgefehlern abhängiger Prozesse; ein verspäteter Aufruf führt zum Timeout-Kill durch den EM.
• Deterministisches Timing (Manifest-Konfiguration):
  • startupTimeout: Muss so dimensioniert sein, dass ungünstigste Initialisierungsdauern (Worst-Case Execution Time / Kaltstart) abgedeckt sind.
  • terminationTimeout: Begrenzt die Zeitspanne für Terminating. Aufwändige Aufräumarbeiten (z. B. Deallokation jedes einzelnen Heap-Objekts) sollten zugunsten des OS-Cleanups übersprungen werden; kritisch sind ausschließlich persistente Datenkonsistenz (ara::per::UpdateTopLevelRootKeys) und saubere Service-Abmeldungen.
• Signal-Sicherheit:
  • SIGTERM darf die Applikation nicht abrupt terminieren. Entwickler müssen POSIX-Signalmasken (pthread_sigmask) konfigurieren und Signale synchron über dedizierte Signal-Threads (sigwait / sigwaitinfo) oder Signal-sichere Event-Pipes verarbeiten, um Deadlocks in Non-reentrant-Funktionen zu verhindern.