Figure 7.12: Error Recovery

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm) mit kombinierten Fragmenten (alt, opt), State-Invariants (Current State: On, Current State: Recovery) und Annotationsblöcken.
• Technischer Zweck: Spezifikation des standardisierten Fehlerbehebungsmechanismus (Error Recovery) im AUTOSAR Adaptive Platform Functional Cluster State Management (SM).
• Funktionale Einordnung: Dargestellt ist die Koordination zwischen dem Platform Health Management (ara::phm), dem Execution Management (ara::exec) und dem State Management (SM), wenn Laufzeit- oder Transitionsfehler auftreten. Das Diagramm modelliert das Verriegeln externer Zustandsanforderungen, das Ermitteln des Fehlerkontexts, die Überführung in einen definierten Wiederherstellungszustand (Recovery State) via ErrorRecoveryTable und die Abarbeitung assoziierter Aktionen (ActionLists).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • «Service» StateMachineService: Service-Interface (Skeleton/Proxy-Muster in ara::com) für externe funktionale Cluster oder Applikationen zur Initiierung von Zustandsübergängen via RequestTransition(TransitionRequest).
  • «Service» StateMachineNotification: Service-Interface für Zustands-Broadcasts/Events (z. B. InTransition, Zieldatenmeldungen).
  • State Management: Zentraler logischer Orchestrator (Adaptive Core FC).
  • ara::exec::StateClient: C++-API des Execution Management (EM) zur Funktionsgruppen-Steuerung (FunctionGroup) und Fehlerabfrage.
  • ara::phm::RecoveryAction: Schnittstelle des Platform Health Management (PHM) zur Weiterleitung überwachter Health-Fehler an SM.
• Datenstrukturen & Parameter:
  • ExecutionErrorEvent: Datenstruktur enthaltend Kontextdaten, mindestens FunctionGroup und ExecutionError (Fehlercode/ID).
  • ErrorRecoveryTable: Konfigurierte Nachschlagetabelle zur Zuordnung von (FunctionGroup, ExecutionError) -> StateMachineState (Recovery).
  • ActionListItems: Konfigurierte Aktionen, die an den Zustand Recovery gebunden sind (z. B. Prozessneustart, Plattform-Reset).
  • Fehlercode kRecoveryTransitionOngoing: Rückgabewert zur Signalisierung abgewiesener Anfragen während aktiver Fehlerbehandlung.

3. Dynamisches Verhalten & Sequenzablauf

1. Fehlererkennung & Trigger (Initiale Invariante: Current State: On):
   • Alternative 1 (PHM-Trigger): ara::phm::RecoveryAction meldet via RecoveryHandler(ExecutionErrorEvent) einen Alive-/Deadline-/Logical-Supervision-Fehler.
   • Alternative 2 (EM-Trigger, asynchron/außerhalb Transition): ara::exec::StateClient meldet via undefinedStateCallback(ExecutionErrorEvent) einen Prozessabsturz oder unerwarteten Prozessausstieg.
   • Alternative 3 (EM-Trigger, Transitionsfehler): ara::exec::StateClient liefert synchron/asynchron einen Fehlerstatus (z. B. kFailed) bei einer laufenden Funktionsgruppen-Transition.
2. Verriegelung externer Transitionsanfragen (Sperrphase):
   • Ab Eingang der Fehlermeldung sperrt SM die Annahme neuer Transitionen.
   • Optionaler Parallelpfad (opt): Eintreffende RequestTransition(...)-Aufrufe an StateMachineService werden unmittelbar abgewiesen und synchron mit kRecoveryTransitionOngoing beantwortet.
3. Fehlerkontext-Auflösung & Notifikation:
   • Optionaler Zweig (opt bei Transitionsfehler EM): SM fragt via GetExecutionError(FG) bei ara::exec::StateClient den genauen ExecutionErrorEvent ab.
   • SM sendet InTransition an Abonnenten von «Service» StateMachineNotification.
   • SM bestimmt anhand von ExecutionErrorEvent.FunctionGroup die betroffene State Machine und liest den Zielzustand (Recovery) aus der ErrorRecoveryTable basierend auf ExecutionErrorEvent.ExecutionError aus.
4. Wiederherstellung & Abarbeitung (Invariante: Current State: Recovery):
   • SM führt die mit dem Zustand Recovery konfigurierten ActionListItems aus.
   • Alternative (alt):
     • Zweig 1 [Fehler während ActionListItems-Abarbeitung]: Tritt erneut ein Fehler via PHM oder EM auf, wird die Recovery-Kaskade reentrant/rekursiv neu durchlaufen (Basis-Zustand ist nun Recovery).
     • Zweig 2 [Erfolg]: Nach vollständiger Abarbeitung öffnet SM das Interface StateMachineService wieder für reguläre RequestTransition-Aufrufe und publiziert das Event State Recovery über «Service» StateMachineNotification.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (StateMachineService):
  • Applikationen und Koordinatoren müssen auf den Return-Code kRecoveryTransitionOngoing vorbereitet sein. Anfragen dürfen nicht ungeprüft als erfolgreich angenommen werden; geeignete Retry-Mechanismen oder Fallbacks sind applikativ vorzusehen.
• Konfigurationspflichten (Manifest / ARXML):
  • Vollständige Definition der ErrorRecoveryTable: Für jeden von PHM oder EM emittierbaren ExecutionError in einer Funktionsgruppe muss eine deterministische Abbildung auf einen Zielzustand existieren. Undefinierte Fehler führen zu undefiniertem Systemverhalten.
  • Korrekte Deklaration von ActionListItems: Die in Recovery ausgeführten Aktionen müssen deterministisch terminieren, um Deadlocks zu vermeiden, da externe Transitionen währenddessen gesperrt bleiben.
• Stack- & Integrator-Implementierung:
  • Der Callback undefinedStateCallback von EM muss thread-sicher und reentrant implementiert sein.
  • SM muss sicherstellen, dass bei aufeinanderfolgenden Fehlern (Kaskadierungsfall im zweiten alt-Block) keine Endlosschleifen zwischen Fehlerzuständen entstehen (Überwachung der Recovery-Rekursionstiefe).