Figure 7.28: Nested recovery example

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML 2.0 Sequenzdiagramm mit Interaktionsfragmenten (alt, kombinierte Aktivierungsbalken, State-Machine-Notizen und Anforderungsankern).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Functional Cluster State Management (SM) in Interaktion mit Platform Health Management (PHM) und Execution Management (EM).
• Technischer Zweck: Spezifikation des deterministischen Verhaltens von SM bei geschachtelten Recovery-Aktionen (Nested Recovery), wenn während einer laufenden Zustandsüberführung infolge eines Fehlers eine weitere Recovery-Anforderung für dieselbe übergeordnete SM-Zustandsmaschine eintrifft.

2. Komponenten, Entitäten & Schnittstellen

Akteure / Prozesse («process»)

• EM (Execution Management): Verantwortlich für Prozesslebenszyklus (Spawn/Terminate) und Überwachung des Prozesszustands.
• State Management (SM): Koordiniert Systemzustände, Function Groups (FGs) und führt konfigurierte Recovery-Aktionen aus.
• PHM (Platform Health Management): Führt Alive-, Deadline- und Logical-Supervision durch und fordert Recovery-Aktionen an.
• process1 (zugeordnet zu FG1): Erster überwachter Anwendungsprozess in Funktionsgruppe 1.
• process2 (zugeordnet zu FG2): Zweiter überwachter Anwendungsprozess in Funktionsgruppe 2.

Schnittstellen & Interaktionen

• checkpoint: Kontrollpunkt-Meldungen von Prozessen an PHM zur Laufzeitüberwachung.
• RecoveryHandler(FunctionGroup, ErrorCode): Asynchrone/synchrone Recovery-Schnittstelle von PHM an SM (z. B. RecoveryHandler(FG1, 23), RecoveryHandler(FG2, 100)).
• undefinedStateCallback(FunctionGroup, ErrorCode): Callback von EM an SM bei unerwarteter Prozessbeendigung (FG2, 100).
• kSMCanNotHandleRecovery: Negativer Rückgabewert von SM an PHM, falls die angeforderte FG nicht verwaltet wird.
• ErrorRecoveryTable: Interne SM-Konfigurationsmatrix zur Abbildung von (FunctionGroup, ErrorCode) -> TargetState.

3. Dynamisches Verhalten & Sequenzablauf

Phase 1: Primäre Fehlererkennung & Erste Recovery-Aktion

1. process1 meldet reguläre Checkpoints an PHM; nach einem internen Fehler bleibt ein Checkpoint aus (missing checkpoint).
2. PHM startet einen Überwachungstimer (timeout starts) und ruft RecoveryHandler(FG1, 23) an SM auf.
3. Ausnahme-Zweig (alt [FG1 does not exist] / [SWS_SM_00030]): Existiert die Ziel-FG nicht in der SM-Konfiguration, antwortet SM unmittelbar mit kSMCanNotHandleRecovery (Eskalation an PHM).
4. Regulärer Pfad: SM ermittelt die zuständige Zustandsmaschine (find affected StateMachine), welche sowohl FG1 als auch FG2 kontrolliert.
5. Tabellen-Lookup: ErrorCode 23 mappt auf Zielzustand S_Recovery.
6. SM triggert die Transition: transit StateMachine to S_Recovery.
7. process1 wird durch EM beendet (terminate). Im weiteren Verlauf der Recovery-Sequenz wird process2 gestartet (spawn) und sendet initiale Checkpoints.

Phase 2: Kaskadierter Fehler & Geschachtelte Recovery (Nested Recovery)

1. process2 terminiert unerwartet (unexpected terminated).
2. EM meldet den undefinierten Zustand via undefinedStateCallback(FG2, 100) an SM.
3. Zeitgleich/in Folge detektiert PHM den Ausfall, startet einen zweiten Timer (second timeout starts) und ruft RecoveryHandler(FG2, 100) auf.
4. SM identifiziert, dass auch FG2 von derselben bereits aktiven StateMachine kontrolliert wird.
5. Neuer Lookup: ErrorCode 100 mappt auf den Zustand S_Off (höhere Priorität / finale Abschaltung).
6. Die laufende Transition wird überschrieben: transit StateMachine to S_Off.

Phase 3: Quittierung geschachtelter Aufrufe ([SWS_SM_00031])

1. Sobald der finale Zustand S_Off reached eingenommen wurde, quittiert SM beide noch offenen RecoveryHandler-Aufrufe an PHM mit void:
   • RecoveryHandler(FG2, 100) -> void
   • RecoveryHandler(FG1, 23) -> void
2. PHM stoppt beide laufenden Recovery-Timeouts.

4. Normative Relevanz & Entwickler-Hinweise

• Zustandsmaschinen-Granularität: Steuert eine StateMachine mehrere Function Groups (hier FG1 und FG2), müssen Entwickler kaskadierende Fehlerszenarien einkalkulieren. Fehlerhafte Teilkomponenten können übergeordnete Gesamtzustandsänderungen erzwingen.
• Konformität zu SWS_SM_00031 (Nested Recovery Handling): Eintreffende Recovery-Anfragen an eine bereits in Transition befindliche StateMachine dürfen nicht verworfen werden. SM muss den Zustandsübergang auf das jüngste/prioritäre Ziel anpassen und alle akkumulierten RecoveryHandler-Aufrufe erst nach Erreichen des konsolidierten Endzustands erfolgreich (void) zurückgeben.
• Konformität zu SWS_SM_00030 (Fehlerpfad): Liegt keine Mapping-Regel für eine Funktionsgruppe vor, ist synchron kSMCanNotHandleRecovery zu melden, damit PHM unverzüglich Plattform-Fallbacks (z. B. Watchdog-Reset / MCU-Reset) einleiten kann.
• Timeout-Budgetierung (PHM-Integration): Der vom PHM gestartete Timeout läuft ab dem Aufruf von RecoveryHandler. Bei geschachtelten Transitionen summiert sich die Latenz (z. B. Beenden von process1 + Anlauf/Absturz process2 + Übergang nach S_Off). Das Timeout-Budget in den PHM-Recovery-Aktionen muss zwingend auf die Worst-Case-Transitionszeiten von SM und EM ausgelegt sein, um Fehlauslösungen von System-Resets zu verhindern.