Figure 10.1: Use cases for Execution Management

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Use-Case-Diagramm (Anwendungsfalldiagramm) mit AUTOSAR-Adaptive-Platform-Profilstereotypen («aapUseCase», «aapFunctionalCluster», «aapTriggers», «aapParticipates»).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R22-11), AUTOSAR_EXP_SWArchitecture, Kapitel 10 (Execution Management).
• Technischer Zweck: Spezifikation der funktionalen Kern-Use-Cases des Functional Clusters Execution Management (EM) zur Lebenszyklus- und Prozessverwaltung. Es definiert die Interaktionsgrenzen zwischen dem EM-Dienst, externen Systemaktoren (Betriebssystem, Applikationen) und koordinierenden Plattform-Clustern (State Management, Platform Health Management).

2. Komponenten, Entitäten & Schnittstellen

Systemgrenzen & Use Cases

• Systemgrenze Execution Management (innerhalb der Adaptive Platform):
  • «aapUseCase» Start Adaptive Platform: Initiales Bootstrapping der Adaptive Platform nach OS-Start.
  • «aapUseCase» Change Function Group State: Dynamisches Umschalten von Funktionsgruppen-Zuständen (Starten/Stoppen von Prozessen, Resource-Allocation, Zustandsüberwachung).
  • «aapUseCase» Shutdown Adaptive Platform: Kontrolliertes Herunterfahren aller Plattform- und Anwendungsinstanzen vor dem System-Poweroff/Reboot.

Akteure ((from Actors))

• Operating System: POSIX-konformes Betriebssystem (z. B. Linux, QNX). Dient als Execution-Host, Prozess-Scheduler und Resource-Provider.
• Adaptive Application: POSIX-Nutzerprozesse, die auf der Plattform laufen und deren Lebenszyklus durch EM geregelt wird.

Funktionscluster («aapFunctionalCluster», Eigenschaft: daemon-based)

• State Management (SM): Plattform-Dienst zur Deklaration und Anforderung von Zielzuständen der Maschine und Funktionsgruppen.
• Platform Health Management (PHM): Plattform-Dienst zur Überwachung des System- und Prozessgesundheitsstatus (Alive-, Deadline-, Logical-Supervision).

Beziehungen, Stereotypen & Abhängigkeiten

• Include-Beziehungen («include»):
  • Start Adaptive Platform $\xrightarrow{\text{«include»}}$ Change Function Group State: Der Hochlauf erzwingt zwingend den Übergang der Funktionsgruppe MachineState in einen definierten Initialzustand (z. B. Startup bzw. Running).
  • Shutdown Adaptive Platform $\xrightarrow{\text{«include»}}$ Change Function Group State: Der Shutdown erzwingt die Transition der Funktionsgruppen in den Zustand Off/Terminating.
• Triggers-Beziehungen («aapTriggers»):
  • Operating System → Start Adaptive Platform: Der OS-Init-Prozess (z. B. systemd oder SysV-Init) instanziiert EM als ersten Plattform-Daemon.
  • State Management → Change Function Group State: SM fordert Zustandswechsel über die EM-Steuerschnittstelle an.
  • State Management → Shutdown Adaptive Platform: SM leitet bei Abschaltbedingungen (z. B. Klemme 15 aus, Unterspannung) den Plattform-Shutdown ein.
  • Adaptive Application → Change Function Group State: Spezifische Interaktionen bzw. Zustandsmeldungen der Applikationen triggern Folgeaktionen im EM.
• Partizipations-Beziehungen («aapParticipates»):
  • Operating System ↔ Change Function Group State: OS stellt Primitiven bereit (fork, exec, POSIX-Signale, cgroups, Core-Affinities).
  • Operating System ↔ Shutdown Adaptive Platform: OS nimmt letzte Prozessbereinigungen vor und vollzieht den Systemhalt/Reboot.
  • Platform Health Management ↔ Change Function Group State: PHM überwacht die Prozesszustände während Transitionen und nimmt an Wiederherstellungs-/Reaktions-Mechanismen teil.
  • Adaptive Application ↔ Change Function Group State: Applikationen nehmen aktiv am Zustandswechsel teil (Signalisierung von Bereitschaft oder Terminierung).

3. Dynamisches Verhalten & Sequenzablauf

A. Initialer Systemstart (Start Adaptive Platform)

1. OS-Init («aapTriggers»): OS startet den EM-Daemon als Root-/Privileged-Prozess.
2. Manifest-Parsing: EM liest das Execution Manifest und Machine Manifest ein.
3. Inkludierter State Change («include»): EM überführt die initiale Funktionsgruppe (z. B. MachineState) in den Startzustand.
4. Daemon-Spawning: EM erzeugt notwendige Basis-Dienste (u. a. State Management, Platform Health Management, Communication Management).

B. Funktionsgruppen-Zustandswechsel (Change Function Group State)

1. Zustandsanforderung: State Management sendet über ara::exec::StateClient::SetState() einen asynchronen Umschaltbefehl an EM.
2. Prozessverwaltung via OS («aapParticipates»):
   • Starten: EM instanziiert Prozesse über POSIX posix_spawn() / fork() + execve() mit konfigurierten UID/GID, cgroups, Scheduler-Policies (SCHED_FIFO/SCHED_RR/SCHED_OTHER) und Resource-Limits.
   • Stoppen: EM sendet SIGTERM an nicht mehr im Zielzustand aktive Prozesse; nach Ablauf eines Grace-Timeouts (terminationTimeout) folgt SIGKILL.
3. Execution State Reporting («aapParticipates»): Neu gestartete Applikationen melden ihren internen Zustand via IPC an EM (ara::exec::ExecutionClient::ReportExecutionState(kRunning)).
4. Health Check («aapParticipates»): PHM validiert Deadlines und Checkpoints während des Hochlaufs der Prozesse.
5. Abschluss: EM komplettiert das an SM zurückgegebene ara::core::Future<void>.

C. Plattform-Herunterfahren (Shutdown Adaptive Platform)

1. Shutdown-Initiierung: State Management detektiert die Shutdown-Bedingung und triggert den Shutdown-Use-Case bei EM.
2. Inkludierter State Change («include»): EM fährt kaskadierend alle Funktionsgruppen herunter, bis alle nicht-essentiellen Prozesse beendet sind.
3. Ressourcenfreigabe & OS-Übergabe («aapParticipates»): Nach Exit aller Plattformprozesse signalisiert EM dem Betriebssystem die Beendigung; das OS trennt Dateisysteme und schaltet die Hardware ab oder führt einen Warmstart durch.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (ExecutionClient):
  • Jede Adaptive Application muss nach Initialisierung zwingend ara::exec::ExecutionClient::ReportExecutionState(ara::exec::ExecutionState::kRunning) aufrufen.
  • Bleibt diese Meldung innerhalb des im Execution Manifest definierten Start-Timeouts aus, klassifiziert EM den Prozess als fehlerhaft (Startup Failed) und initiiert die konfigurierte Failure-Action (z. B. Restart oder Eskalation an PHM).
• Signal-Handling & Shutdown-Verhalten:
  • Applikationsentwickler müssen sicherstellen, dass SIGTERM unverzüglich verarbeitet wird (Ressourcenfreigabe, Persistierung flüchtiger Zustände via ara::per).
  • Dauert das Beenden länger als der konfigurierte terminationTimeout, erzwingt EM den Prozessabbruch via SIGKILL (Gefahr von Datenkorruption ohne synchrone Persistierung).
• Berechtigungskonzept & Rollentrennung:
  • Normale Applikationen besitzen keinen Zugriff auf ara::exec::StateClient (Zustandswechsel sind exklusiv für State Management autorisiert).
  • Applikationen dürfen Zustände nur über anwendungsspezifische Schnittstellen bei SM anfordern, niemals direkt bei EM manipulieren.
• Manifest-Konfiguration:
  • Pflicht zur exakten Deklaration der Prozess-Zuordnung zu FunctionGroup und FunctionGroupState im ARXML-Manifest (StartupConfig, ProcessExecutionConfig).
  • Parameter wie CPU-Affinitäten, Prioritäten, Watchdog-Cycle-Times und Alive-Check-Intervalle (für PHM) müssen statisch aufeinander abgestimmt sein, um State-Change-Timeouts im EM zu verhindern.