Figure 7.9: State Change Sequence - Termination Timeout

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.x Sequenzdiagramm (Sequence Diagram) mit kombinierten Fragmenten (loop, opt) und Zeitdauer-Constraint ({Start-up Timeout}).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Execution Management (ara::exec, EM) in Interaktion mit State Management (SM) und einer verwalteten Prozessinstanz (Process B).
• Funktionale Einordnung: Dargestellt ist die Fehlerbehandlung während eines Function-Group-Zustandswechsels (FG State Change). Trotz der Dokumenten-Bildunterschrift (Termination Timeout) zeigt das Vektordiagramm normativ die Behandlung eines Start-up Timeouts: Ein startender Prozess meldet seinen Zustand nicht fristgerecht, woraufhin EM den Prozess zwangsweise beendet (SIGKILL) und konfigurierte Neustartversuche abarbeitet.

2. Komponenten, Entitäten & Schnittstellen

• Lebenslinien & Akteure:
  • SM (State Management): Steuernde funktionale Instanz, die über den StateClient Soll-Zustände für Function Groups anfordert.
  • EM (Execution Management): Zentraler Plattform-Dienst zur Prozess- und Zustandssteuerung, verantwortlich für Prozess-Erzeugung, Überwachung und Signalübermittlung.
  • Process B: OS-Prozess einer Adaptive Application, definiert über ein Execution Manifest.
• Schnittstellen & Interaktionspunkte:
  • ara::exec::StateClient::SetState(): Asynchrone C++-API-Methode zur Initiierung des Function-Group-Zustandswechsels; liefert ein ara::core::Future an SM zurück.
  • create(): Interne/OS-spezifische Prozesserzeugung durch EM (z. B. posix_spawn() / fork() + execve()).
  • ara::exec::ExecutionClient::ReportExecutionState(kRunning): Asynchrone IPC-Meldung der Applikation an EM zur Bestätigung der abgeschlossenen Initialisierung.
  • kill (e.g. via SIGKILL): POSIX-Betriebssystem-Signal zur unbedingten Terminierung des Prozesses.
• Kombinierte Fragmente & Constraints:
  • loop For all Process-StartupConfigs which refer to the target FG state: Iteration über alle im Manifest für den Zielzustand hinterlegten ProcessStartupConfig-Instanzen.
  • [Process Start]: Sequenzabschnitt zur Prozessaktivierung.
  • opt Start-up Timeout: Bedingter Block für den Fall, dass die Prozessmeldung das Zeitfenster überschreitet.
  • loop For numberOfRestartAttempts times: Schleife über die im Manifest konfigurierte Anzahl erlaubter Wiederanläufe.
  • {Start-up Timeout}: Zeitgrenze zwischen create() und dem Empfang von ReportExecutionState(kRunning).

3. Dynamisches Verhalten & Sequenzablauf

1. Zustandsanforderung: SM triggert via StateClient::SetState() den Zustandswechsel einer Function Group.
2. Asynchrone Quittierung: EM antwortet unmittelbar mit einem :Future an SM, um non-blocking Execution zu gewährleisten.
3. Prozessstart: EM instanziiert Process B via create() gemäß der zugehörigen ProcessStartupConfig und startet den internen Timer {Start-up Timeout}.
4. Timeout-Verletzung: Der Timer {Start-up Timeout} läuft ab, bevor Process B den Status meldet. Die nachfolgende Meldung ExecutionClient::ReportExecutionState(kRunning) trifft verspätet bei EM ein und wird als ungültig verworfen.
5. Eskalation: EM sendet ein hartes Abbruchsignal (kill (e.g. via SIGKILL)) an Process B. Der Prozess wird unverzüglich durch das Betriebssystem zerstört (gekennzeichnet durch das Terminations-Symbol X).
6. Wiederhollogik: Sofern konfiguriert, wird die Erzeugung und Überwachung bis zu numberOfRestartAttempts Mal wiederholt.
7. Transition-Abschluss: Nach Erschöpfung oder Auflösung der Fehlerbehandlung erfüllt EM das Future in Richtung SM mit :Success (sofern die Gesamtstrategie des FG-Wechsels die Fortführung erlaubt).

4. Normative Relevanz & Entwickler-Hinweise

• **ARXML-Konfiguration (Execution Manifest):**
  • Parameter startupTimeout: Definiert die harte Obergrenze für die Initialisierungsphase. Ist kein Timeout modelliert, blockiert EM unbegrenzt auf kRunning.
  • Parameter numberOfRestartAttempts: Steuert die maximale Re-try-Anzahl vor Eintritt in einen Fehlerzustand der Function Group.
• **Applikations-Implementierung (Adaptive Application):**
  • Entwickler müssen ara::exec::ExecutionClient::ReportExecutionState(ara::exec::ExecutionState::kRunning) unmittelbar nach Abschluss aller minimal notwendigen Start-Routinen (z. B. Signal-Handler-Setup, Grundinitialisierung) aufrufen.
  • Zeitaufwändige Aufgaben (z. B. Laden großer Datenstrukturen, Aufbau externer Kommunikationsbeziehungen) dürfen den Aufruf nicht verzögern; sie müssen entweder asynchron nach kRunning verlagert oder über ein ausreichend großes startupTimeout abgesichert werden.
• OS- & Ressourcenebene:
  • Die Zwangsterminierung via SIGKILL verhindert den Aufruf von exit()-Handlern, Destruktoren oder Signal-Handlern in der Applikation.
  • Nicht-flüchtige Ressourcen (Shared Memory, POSIX-Semaphoren, Dateilocks) können im OS verwaist zurückbleiben, sofern sie nicht vom Betriebssystemkernel automatisch beim Prozess-Cleanup freigegeben werden. Applikationen müssen auf Crash-Recovery nach unsauberer Terminierung ausgelegt sein.