Figure 7.10: State Change Sequence - Start-up Timeout

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm mit kombinierten Fragmenten loop und opt).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP) – Execution Management (gemäß AUTOSAR_AP_SWS_ExecutionManagement, Anforderungen RS_EM_00101, SWS_EM_02250).
• Technischer Zweck: Spezifikation des Fehlerbehandlungs- und Wiederanlaufmechanismus (Recovery) bei Verletzung des Start-up-Timeouts während einer Funktionsgruppen-Zustandstransition (Function Group State Transition).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • SM (State Management): Plattform-Applikation zur systemweiten Steuerung von Funktionsgruppen und Betriebsmodi.
  • EM (Execution Management): Zentraler Daemon zur Prozess- und Zustandsverwaltung auf dem Adaptive Core.
  • Process B: Instanziierter POSIX-Betriebssystemprozess einer konfigurierten Adaptive Application.
• Schnittstellen & Methoden:
  • ara::exec::StateClient::SetState(): Asynchrone Methode des State-Client-APIs zur Anforderung eines Funktionsgruppen-Zustandswechsels.
  • ara::core::Future: Asynchrones Rückgabeobjekt an SM zur Status- und Fehlerüberwachung der Transition.
  • OS-Prozess-APIs: create() (z. B. posix_spawn() / fork() + exec()) und kill (z. B. SIGKILL) zwischen EM und OS-Prozess.
  • ara::exec::ExecutionClient::ReportExecutionState(kRunning): IPC-basiertes Reporting des Prozesses an EM zur Signalisierung der Betriebsbereitschaft.
• Manifest- / Modell-Entitäten:
  • Process-StartupConfigs: Zuordnung von Prozessen und Startparametern zum Zielzustand einer FunctionGroup.
  • {Start-up Timeout} (startupTimeout): Zeitgrenze im Metamodell für den Eingang von ReportExecutionState(kRunning).
  • numberOfRestartAttempts: Konfigurierter Zähler für maximal zulässige Neustartversuche vor Abbruch der Transition.

3. Dynamisches Verhalten & Sequenzablauf

1. Zustandsanforderung: SM triggert die Transition via StateClient::SetState(). EM quittiert synchron mit einem Future.
2. Evaluierung der Startkonfigurationen: Über das äußere Fragment loop For all Process-StartupConfigs which refer to the target FG state [Process Start] ermittelt EM alle im Zielzustand zu aktivierenden Prozesse.
3. Prozessstart & Timeout-Überwachung (opt Start-up Timeout / loop For numberOfRestartAttempts times):
   • EM erzeugt Process B via create().
   • Zeitgleich startet EM den internen Timer {Start-up Timeout}.
   • Trifft ExecutionClient::ReportExecutionState(kRunning) nicht vor Ablauf des Timeouts ein (oder wie im Diagramm dargestellt erst nach Fristüberschreitung), greift die Timeout-Behandlung.
   • EM terminiert Process B forciert via kill (e.g. via SIGKILL).
   • Dieser Zyklus wiederholt sich bis zum Erreichen von numberOfRestartAttempts.
4. Fehlerextension & Transition-Abbruch:
   • Nach Erschöpfung aller Neustartversuche bricht EM die gesamte Function Group State Transition ab.
   • EM löst das Future mit dem Fehlerwert :kFailed (bzw. ara::exec::ExecErrc::kFailed) auf.
5. Systemfolgezustand:
   • Die betroffene Funktionsgruppe verbleibt im Zustand Undefined Function Group State.
   • Die Fehlerbehandlung wird explizit an den State Manager delegiert („SM has to react“).

4. Normative Relevanz & Entwickler-Hinweise

• Applikations-Entwickler (Process B):
  • Aufruf von ExecutionClient::ReportExecutionState(ara::exec::ExecutionState::kRunning) muss im Prozesszyklus so früh wie möglich erfolgen; zeitintensive Initialisierungen (z. B. Blockierendes I/O, IPC-Bindungen, große Speicherallokationen) dürfen das Absetzen dieses Reports nicht verzögern.
  • Da EM bei Timeout mit SIGKILL terminiert, greifen keine Signal-Handler oder Destruktoren. Persistente Ressourcen (z. B. Shared Memory, POSIX Semaphoren/Mutexes, Temp-Files) müssen crash-konsistent und idempotent initialisiert werden.
• System- & Integrations-Konfiguration (ARXML):
  • startupTimeout muss die ungünstigste Systemauslastung (Worst-Case Execution Time beim Bootstrapping, CPU-Scheduling-Latenzen) berücksichtigen, um False-Positive-Timeouts zu verhindern.
  • numberOfRestartAttempts steuert die Transitionsdauer im Fehlerfall: Ein hoher Wert bindet Rechenzeit und verzögert die Fehlererkennung im SM; ein Wert von 0 führt sofort zum Abbruch der Funktionsgruppen-Transition.
• State-Management-Entwickler (SM):
  • Jeder Aufruf von StateClient::SetState() muss zwingend auf Fehlerzustände (kFailed) des Future überwacht werden.
  • Für den Eintritt in den Undefined Function Group State muss eine deterministische Notfallstrategie implementiert sein (z. B. Transitionsversuch in einen Fail-Safe State, Degradationsmodus oder Plattform-Reset).