Figure 7.8: State Change Sequence - Success

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm mit kombinierten Fragmenten vom Typ loop und parallelen Ausführungsannotationen).
• Technischer Zweck: Spezifikation des erfolgreichen, asynchronen Zustandswechsels einer Funktionsgruppe (Function Group State Transition) innerhalb der AUTOSAR Adaptive Platform. Es definiert das Zusammenspiel zwischen Zustandssteuerung (State Management), Prozess-Lebenszyklusverwaltung (Execution Management) und den POSIX-basierten Betriebssystemprozessen.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lebenslinien:
  • SM (State Management): Applikativer oder plattformseitiger Manager, der funktionale Systemzustände koordiniert und Zustandswechsel anfordert.
  • EM (Execution Management): Kernkomponente der Adaptive Platform Runtime zur Prozessinstanziierung, -überwachung und Zustandsdurchsetzung gemäß Manifest-Konfiguration.
  • Process A: Laufende Prozessinstanz, deren StartupConfig den Zielzustand der Funktionsgruppe (target FG state) nicht enthält.
  • Process B: Neu zu startende Prozessinstanz, deren StartupConfig dem Zielzustand der Funktionsgruppe zugeordnet ist.
• Schnittstellen & Interprozesskommunikation (IPC):
  • StateClient::SetState(): C++-API (ara::exec::StateClient), über die das SM den Zustandswechsel einer Funktionsgruppe asynchron initiiert.
  • :Future: Rückgabetyp ara::core::Future<void> zur asynchronen Synchronisation und Fehlerbehandlung.
  • SIGTERM(): Standard-POSIX-Signal zur Anforderung einer geordneten Prozessbeendigung (Graceful Termination).
  • EXIT_SUCCESS(): POSIX-Prozessrückgabewert (exit(0) / Terminierung) signalisiert an EM via OS-Event/waitpid().
  • create(): Betriebssystemaufruf (z. B. fork()/execve(), posix_spawn()) zur Instanziierung des neuen Prozesses.
  • ExecutionClient::ReportExecutionState(kRunning): C++-API (ara::exec::ExecutionClient), mit der sich ein neu gestarteter Prozess nach Abschluss seiner Initialisierung beim EM meldet.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger & Asynchroner Start:
   • SM ruft StateClient::SetState() auf.
   • EM quittiert den Aufruf unmittelbar mit einem unaufgelösten ara::core::Future-Objekt; die Zustandsänderung läuft im Hintergrund an.
2. Phase 1: Prozessbeendigung (loop [Process termination]):
   • Für alle Prozesse (Process A), die im Zielzustand der Funktionsgruppe nicht mehr aktiv sein dürfen:
   • EM sendet SIGTERM an den Prozess.
   • Process A fährt geordnet herunter und terminiert mit EXIT_SUCCESS.
3. Phase 2: Prozessstart (loop [Process Start]):
   • Für alle Prozesse (Process B), die für den Zielzustand konfiguriert sind:
   • EM erzeugt den Prozesskontext (create()).
   • Process B initialisiert sich und meldet kRunning via ExecutionClient::ReportExecutionState().
4. Nebenläufigkeit (Can happen in parallel):
   • Die Terminierung von Altprozessen und der Start von Neuprozessen können abhängig von Prozessabhängigkeiten und Plattform-Ressourcen parallel ausgeführt werden.
5. Abschluss:
   • Sobald alle Prozesse erfolgreich beendet bzw. im Zustand kRunning bestätigt wurden, setzt EM das Ergebnis im Promise und der Future des SM wird mit :Success aufgelöst.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag für Adaptive Applications:
  • Signal-Handling: Jeder Adaptive Prozess muss einen Signal-Handler für SIGTERM registrieren und innerhalb des konfigurierten enterTimeoutValue geordnet terminieren. Andernfalls greift die Eskalation über SIGKILL (nicht im Gut-Pfad dargestellt).
  • Start-Up-Synchronisation: Jeder gestartete Prozess muss zwingend ReportExecutionState(ara::exec::ExecutionState::kRunning) absetzen. Unterbleibt dieser Aufruf innerhalb des konfigurierten Startup-Timeouts, schlägt der gesamte Funktionsgruppen-Zustandswechsel fehl.
• State-Management-Implementierung:
  • Da SetState() non-blocking ist, muss das SM blockierend via Future::wait()/Future::get() synchronisieren oder Callback-Mechanismen (Future::then()) verwenden, bevor Folgeaktionen (z. B. Netzwerkfreigaben) ausgeführt werden.
• Manifest-Konfiguration (ExecutionManifest):
  • Zuordnung von Process zu FunctionGroupState steuert die Zuordnung zu den beiden Schleifenblöcken.
  • Ressourcen-/Startreihenfolgen (StartupConfig.startupOptions, Resource-Limits) müssen so definiert sein, dass parallele Prozessstarts nicht zu Deadlocks oder Ressourcen-Engpässen auf OS-Ebene führen.