Figure 5: 3 Interaction between States

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Hybrides Interaktions- und Zustandskorrelationsdiagramm (Swimlane-basierte Darstellung paralleler Zustandsautomaten mit synchronen/asynchronen Kontrollflüssen).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R18-03 / R1.4.0), Functional Cluster Execution Management (EM) in Kooperation mit State Management (SM).
• Technischer Zweck: Spezifikation der hierarchischen Kausalitätskette zwischen:
  1. Function Group States (High-Level-Systemzustände, durch SM angefordert),
  2. Process States (Betriebssystem-Lebenszyklus aus Sicht des EM),
  3. Application States (interne Software-Zustände der Adaptive Application).

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Funktionscluster:
  • State Management (SM): Führt die Arbitrierung externer Requests durch (z. B. Fahrzeugzustand, Diagnose, Fehlermanagement via ara::com) und bestimmt Zielzustände von Funktionsgruppen.
  • Execution Management (EM): Verantwortlich für Start-/Stopp-Orchestrierung, Ressourcenallokation und Überwachung auf OS-Ebene.
  • Application Process: Die konkrete Prozessinstanz einer Adaptive Application (AA) im POSIX-Adressraum.
• Zustandsebenen:
  • FG1 State: Diskrete Zustände einer Funktionsgruppe (FG1:State1, FG1:State2, FG1:State3), verwaltet durch EM.
  • Process State (EM-Sicht): Idle → Starting → Running → Terminating → Terminated.
  • Application State (Prozess-Sicht): Initializing → Running → Terminating.
• Schnittstellen & Interaktionspfade:
  • SetState(FunctionGroup, State) / return (success): Steuer- und Quittierungsschnittstelle zwischen SM und EM (asynchrones Pattern via Future/Callback).
  • ara::exec::ExecutionClient::ReportApplicationState(): IPC-Schnittstelle der Anwendung zum EM zur Statussignalisierung (Running, Terminating).
  • POSIX OS-Primitives:
    • Prozessinstanziierung: fork()/exec(), Ressourcenlimitierung (Cgroups, Quotas).
    • Signalisierung: Terminate() (typischerweise SIGTERM, bei Timeout SIGKILL).
    • Synchronisation/Reaping: waitpid() zur Erkennung des Beendens und Freigabe von Kernelstrukturen.

3. Dynamisches Verhalten & Sequenzablauf

Phase 1: Aktivierung / Hochlauf (Übergang zu FG1:State2)

1. Trigger: SM empfängt Events/Requests, arbitriert diese und triggert EM via *SetState*(FG1, State2).
2. Manifest-Lookup: EM ermittelt über das Execution Manifest, dass die Applikation für FG1:State2 konfiguriert ist.
3. Prozessgenerierung: EM überführt den Process State von Idle nach Starting: erzeugt den OS-Prozess (create process), bindet Ressourcen/Rechte ein und schedult den Thread/Prozess.
4. Initialisierung: Der Prozess startet in Initializing (BSS/Data, lokale Variablen, Initialisierung interner Stacks/Services).
5. Aktivmeldung: Nach Abschluss der Initialisierung ruft die Anwendung ReportApplicationState(Running) auf.
6. Zustandskonsolidierung: EM schaltet den Process State auf Running.
7. Bestätigung: Sobald alle Prozesse der Gruppe stabil in Running sind, schließt EM die Transition ab (FG1:State2) und sendet return (success) an SM.

Phase 2: Deaktivierung / Herunterfahren (Übergang zu FG1:State3)

1. Trigger: SM fordert Zustandswechsel auf FG1:State3 an, in dem der Prozess nicht mehr ausgeführt werden soll.
2. Terminierungssignal: EM initiiert die Transition, wechselt den Process State auf Terminating und sendet Terminate() (SIGTERM) an den Prozess.
3. Shutdown der Applikation: Prozess fängt das Signal ab, geht in den internen Zustand Terminating, sichert persistente Daten und bereinigt Ressourcen.
4. Statusmeldung (optional): Der Prozess meldet ReportApplicationState(Terminating) an EM.
5. OS-Exit & Reaping: Der Prozess terminiert (exit()). EM fängt dies über POSIX waitpid ab.
6. Ressourcenfreigabe: EM überführt den Process State nach Terminated und gibt reservierte OS-Ressourcen frei.
7. Transition-Abschluss: EM schaltet die Funktionsgruppe auf FG1:State3 und quittiert an SM via return (success).

4. Normative Relevanz & Entwickler-Hinweise

• API-Meldepflicht (ara::exec): Jede Adaptive Application muss nach Abschluss der Initialisierungsphase explizit ara::exec::ExecutionClient::ReportApplicationState(ara::exec::ApplicationState::kRunning) absetzen.
• Timeout-Überwachung (Startup): Das Melden von kRunning unterliegt einem im Manifest definierten startupTimeout. Erfolgt die Meldung nicht rechtzeitig, stuft EM den Prozessstart als fehlgeschlagen ein (führt ggf. zum Neustart oder Recovery-Eskalation).
• Signal Handling & Graceful Termination:
  • Applikationen müssen Signal-Handler für SIGTERM bereitstellen.
  • Das Herunterfahren (Speichern in NVM/Persistency, Schließen von ara::com-Instanzen) muss innerhalb des im Execution Manifest parametrierten terminationTimeout erfolgen.
  • Verstreicht der Timeout ohne Prozessende, sendet EM normativ SIGKILL.
• Manifest-Modellierung: Das Verhalten des Prozesses bezüglich Start/Stopp ist deklarativ an FunctionGroupState-Instanzen gebunden. Ein Prozess darf sich nicht selbstständig über Standard-POSIX-Mittel in andere Systemmodi befördern; die Führungsrolle liegt strikt beim SM.