Figure 6.1: AP start-up sequence

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: High-Level-Ablaufdiagramm / Kontrollfluss- und Phasenmodell des Plattform-Lebenszyklus.
• Funktionale Einordnung: Definiert die deterministische Initialisierungs- und Transitionsschleife der AUTOSAR Adaptive Platform (AP) nach dem Hardware-/Kernel-Boot. Im Zentrum steht der funktionale Cluster Execution Management (EM) (ara::exec), der als primärer Nutzerprozess (Init-Prozess/PID 1 oder direkter Nachfolger) die Prozesslebenszyklen und Zustandswechsel steuert.

2. Komponenten, Entitäten & Schnittstellen

• OS Boot: Außerhalb von EM liegende Betriebssystem-Bootphase (Bootloader, POSIX-Kernel-Initialisierung, Treiberschicht, Start von EM als privilegierter Root-Prozess).
• Execution Management (EM): Zentraler System-Daemon für Prozess-Orchestrierung, Ressourcen-Zuweisung (Cgroups, Scheduling-Attribute), Budgetüberwachung und State-Enforcement.
• Artefakte / Datenstrukturen:
  • Machine Manifest: Modelliert maschinenspezifische Ressourcen (Kerne, Speicher, Function Groups, Machine States, Netzwerkschnittstellen).
  • Execution Manifest Instance(s): Instanzspezifische Deskriptoren je auszuführendem Prozess (StartupConfig, deterministische Startup-Abhängigkeiten, Prozessprioritäten, UID/GID, Ressourcengrenzen, Zuordnung zu Function-Group-Zuständen).
  • (processed): Vorkompilierte, binäre oder parser-optimierte Repräsentationen der ARXML-Manifeste zur Minimierung von Startup-Latenzen.
• Schnittstellen & Akteure (implizit/normativ zugeordnet):
  • ara::exec::ExecutionClient: IPC-Schnittstelle zwischen gestartetem Applikationsprozess und EM zur Rückmeldung des Laufzeitzustands (kRunning).
  • ara::exec::StateClient: IPC-Schnittstelle, über die der Cluster State Management (SM) Zustandswechsel (SetState) an EM anfordert.

3. Dynamisches Verhalten & Sequenzablauf

1. Phase 1 – Initial Transition (OS Boot → Read Manifests):
   • Übergabe der Kontrolle vom POSIX-Kernel an den EM-Daemon.
   • EM parst synchron alle hinterlegten (vorverarbeiteten) Machine- und Execution-Manifeste, baut den internen Abhängigkeitsgraphen auf und ermittelt die initiale MachineState-Konfiguration (z. B. Startup oder Verify).
2. Phase 2 – Application Launch (Start Application(s)):
   • EM instanziiert Prozesse iterativ/parallel (fork/exec bzw. OS-spezifische Primitiven) gemäß deklarierter Startreihenfolge (startupDependencies) und Ausführungsmodi.
   • Zuweisung von Scheduling-Policies (z. B. SCHED_FIFO, SCHED_RR), CPU-Affinities und Sicherheitskontexten.
3. Phase 3 – State Settlement (Enter Machine State):
   • Synchronisation auf Prozessbereitschaft: Prozesse melden über ExecutionClient::ReportExecutionState(kRunning) ihre Bereitschaft.
   • Sobald alle für den Zielzustand erforderlichen Pflichtprozesse laufen und rückgemeldet haben, gilt der Maschinenzustand bzw. die FunctionGroup als eingenommen.
4. Phase 4 – State Change Cycle (Stop Application(s) → Start Application(s)):
   • Trigger: Anforderung eines Zustandswechsels durch State Management via StateClient.
   • Terminierung: Nicht mehr für den Zielzustand konfigurierte Prozesse werden geordnet gestoppt (Graceful Shutdown via POSIX-Signal SIGTERM mit konfigurierbarem Timeout; bei Timeout-Überschreitung forcierte Terminierung via SIGKILL).
   • Re-Activation: Rücksprungschleife (State Change) startet nach erfolgreichem Stop die für den neuen Zustand definierten Folge-Applikationen.

4. Normative Relevanz & Entwickler-Hinweise

• Deterministischer Boot-Pfad: Manifeste dürfen zur Laufzeit nicht über dynamische Remote-Pfade nachgeladen werden; die Integrität muss über Authenticated/Secure Boot und persistente, verarbeitete Ablagen sichergestellt sein.
• API-Meldepflicht für Applikations-Entwickler:
  • Jede Adaptive Application muss zwingend nach Erreichen der operativen Betriebsbereitschaft ara::exec::ExecutionClient::ReportExecutionState(ara::exec::ExecutionState::kRunning) aufrufen.
  • Unterbleibt diese Meldung vor Ablauf des im Execution Manifest konfigurierten startupTimeout, wertet EM den Prozessstart als fehlgeschlagen (Folge: Recovery-Aktion, Watchdog-Eingriff oder State-Transition-Rollback).
• Signal Handling & Graceful Termination:
  • Applikationen müssen Signal-Handler für SIGTERM registrieren, um State-Changes nicht zu blockieren, Ressourcen sauber freizugeben und persistente Puffer zu flushen.
• State Management Coupling:
  • EM entscheidet nicht eigenständig über funktionale State Changes; die Policy-Entscheidung obliegt exklusiv dem State Management. EM fungiert rein als ausführende Instanz (Mechanism vs. Policy Trennung).