Figure 7.11: State dependent Process control

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Zeitablauf- und Zustandsübergangsdiagramm (Timing/State-Transition-Diagramm) über einer gemeinsamen horizontalen Zeitachse t.
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Execution Management (ara::exec, SWS Document ID 721).
• Technischer Zweck: Veranschaulichung der deterministischen Lebenszyklussteuerung von Prozessen (Process) in Abhängigkeit von übergeordneten Zustandsumschaltungen der Funktionsgruppen (FunctionGroupState) und der Maschinen-Zustände (MachineFG). Dargestellt wird die Kopplung zwischen Zustandswechseln, Prozess-Abhängigkeiten (ExecutionDependency) und der Wiederverwendung bzw. Reinitialisierung von Startkonfigurationen (StateDependentStartupConfig).

2. Komponenten, Entitäten & Schnittstellen

• Function Groups & States (Zustandsdomänen):
  • MachineFG: Dedizierte, plattformweite Funktionsgruppe für den Lebenszyklus der Maschine/Plattform-Instanz (Zustände: Off, Startup, Running, Diagnostics, Shutdown).
  • Function Group 1 (FG1): Applikative Funktionsgruppe (Zustände: FG1:Off, FG1:Running).
  • Function Group 2 (FG2): Applikative Funktionsgruppe mit multiplen Betriebsmodi (Zustände: FG2:Off, FG2:Running, FG2:Fallback, FG2:Diag).
  • Schraffierte Übergangsphasen: Transiente Phasen (Transition State), in denen Execution Management die Ein- und Ausphasung der zugeordneten Prozesse koordiniert.
• Prozess-Entitäten (Process / Manifest-Modell):
  • Prozesse A bis G mit jeweils den drei diskreten statischen Lebenszyklus-Zuständen: Idle, Running, Terminated.
• Metamodell-Elemente & Abhängigkeitsstrukturen:
  • StateDependentStartupConfig [Kardinalität 1..\*]: Mappt einen Process auf einen oder mehrere FunctionGroupStates.
  • StartupConfig: Spezifiziert Startparameter, Umgebungsvariablen, Resource Limits und Scheduling-Attribute.
  • ExecutionDependency: Deklarative Startbedingung (hier: Ende von Prozess A schaltet Start von Prozess B frei).
• Relevante Schnittstellen & Akteure:
  • State Management (ara::sm): Trigger für Funktionsgruppen-Zustandswechsel über FunctionGroup::SetState().
  • Execution Management (ara::exec): Realisiert Prozessspawns (posix_spawn / fork+execve), Signalüberwachung (SIGTERM/SIGKILL) und Auswertung des Reportings via ApplicationClient::ReportExecutionState().

3. Dynamisches Verhalten & Sequenzablauf

1. Phase Startup (MachineFG):
   • Prozess A: Startet aus Idle in Running bei Aktivierung von Startup. Es handelt sich um einen Self-terminating Process (Initialisierungs-/Flash-Check-Aufgabe), der sich regulär selbst beendet und in Terminated wechselt.
   • Prozess B: Konfiguriert mit ExecutionDependency auf Prozess A. Bleibt in Idle, bis A den Zustand Terminated meldet (gestrichelter Kausalitäts-Pfeil). Erst danach erfolgt der Zustandsübergang nach Running.
2. Phase Running (MachineFG) & different StartupConfigs:
   • Prozess B: Ist sowohl für Startup als auch für Running konfiguriert, jedoch mit unterschiedlichen StateDependentStartupConfigs [constr_10411]. Execution Management terminiert B beim Verlassen von Startup und startet die Instanz in Running mit neuen Parametern neu (symbolisiert durch die Zickzack-Bruchkante).
   • Prozess C: Referenziert ausschließlich MachineFG:Running. Verlässt Idle und wechselt synchron mit Erreichen des Zielzustands in Running.
3. Applikative Function Groups (FG1 & FG2):
   • FG1: Beim Eintritt in FG1:Running starten Prozesse D und E parallel in Running. Mit Transition nach FG1:Off werden beide kontrolliert nach Terminated überführt.
   • FG2: Beim Wechsel von FG2:Off nach FG2:Running starten Prozesse F und G.
   • Zustandswechsel FG2:Running → FG2:Fallback:
     • Prozess F (different StartupConfigs): Wird gestoppt und mit veränderter Startkonfiguration für FG2:Fallback neu instanziiert (Re-Execution / Bruchlinie).
     • Prozess G (same StartupConfig): Referenziert beide Zustände über dieselbe StartupConfig. Prozess G läuft während der gesamten Transition unterbrechungsfrei in Running weiter (kein Restart-Overhead).
4. Phase Diagnostics & Deaktivierung:
   • Anforderung von MachineFG:Diagnostics durch State Management.
   • Nicht für Diagnostics konfigurierte Prozesse (wie B und C) werden durch EM über den regulären De-Escalation-Pfad (SIGTERM → Termination Timeout → ggf. SIGKILL) in den Zustand Terminated überführt.

4. Normative Relevanz & Entwickler-Hinweise

• Vermeidung unnötiger Prozessneustarts: Referenzieren mehrere aufeinanderfolgende States einer Funktionsgruppe dieselbe Prozessinstanz, muss im Execution Manifest (ExecutionManifest.arxml) zwingend dieselbe StartupConfig referenziert werden (Verhalten wie Prozess G). Unterschiedliche Konfigurationen (wie bei B und F) erzwingen zwingend Termination und POSIX-Neustart mit Verlust von flüchtigem Prozesskontext und Re-Initialisierungslatenz.
• Synchronisation über ExecutionDependency: Abhängigkeiten zwischen Prozessen innerhalb derselben Phase dürfen nicht über Heuristiken (z. B. Polling, Sleeps), sondern müssen deklarativ über ExecutionDependency modelliert werden. EM blockiert den Startfolgeprozess deterministisch, bis der Vorgänger den geforderten Zustand (z. B. kTerminated oder kRunning via ApplicationClient) erreicht hat.
• Transition State Semantik: Ein Function-Group-Zustandswechsel gilt erst dann als erfolgreich abgeschlossen (ara::core::Future aus SetState resolved), wenn:
  1. Alle Prozesse des vorherigen Zustands, die im Zielzustand nicht mehr aktiv sind, sauber terminiert wurden.
  2. Alle neu zu startenden Prozesse des Zielzustands erfolgreich gestartet sind und ihren Zustand gemeldet haben.
• Applikationsdesign für Self-terminating Processes: Prozesse mit deterministischem Einmal-Ablauf (Prozess A) müssen ihren Exit-Code sauber zurückliefern (exit(0)) und dürfen keine Recovery Actions (z. B. Restart on Non-Zero) auslösen.