Figure 11.26: Scenario: Recover from Critical Supervision Failure in State Management

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck & Einordnung: Spezifikation des Notfall-Eskalationspfads bei einem kritischen Überwachungsfehler (Critical Supervision Failure) innerhalb des Functional Clusters State Management (SM) auf der AUTOSAR Adaptive Platform (AP).
• Architektonischer Kontext: Im Normalbetrieb meldet das Platform Health Management (PHM) erkannte Überwachungsfehler an das State Management, welches die Wiederherstellung (z. B. Prozessneustart, Funktionsgruppen-Zustandswechsel) koordiniert. Versagt das State Management selbst (hier als überwachter Prozess), bricht diese Regelschleife zusammen. Das Diagramm definiert das Fallback-Verhalten, bei dem PHM das State Management umgeht und direkt eine physische/plattformnahe Watchdog-Aktion auslöst.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Lifelines:
  • «aapFunctionalCluster» :State Management (SM): Zentraler Koordinator für Maschinen- und Funktionsgruppenzustände. Agiert hier in der Rolle einer Supervised Entity.
  • «aapFunctionalCluster» :Platform Health Management (PHM): Autonome Plattforminstanz zur Ausführung von Alive-, Deadline- und Logical-Supervision.
  • :Watchdog: Plattform-/Hardware-nahe Überwachungsentität (z. B. Watchdog-Treiber, externer SBC/PMIC-Watchdog oder Watchdog-Daemon).
• Schnittstellen & Interaktionen:
  • ReportCheckpoint(wrongCheckpointId): API-Aufruf (aus ara::phm), über den ein Thread des State Managements seinen aktuellen Fortschritts-Kontrollpunkt an PHM übermittelt.
  • «aapInformative» handleSupervisionFailure(): Interne Fehleranalyse- und Entscheidungslogik des PHM (stereotypisiert als informativ, da die genaue Implementierung herstellerspezifisch ist).
  • FireWatchdogReaction(): Interaktionsaufruf/Signal von PHM an den Watchdog zur Einleitung hardwarenaher Gegenmaßnahmen (z. B. Stoppen des Servicing, Anforderung eines Machine Resets).

3. Dynamisches Verhalten & Sequenzablauf

1. Fehler-Trigger: :State Management meldet über ReportCheckpoint(wrongCheckpointId) einen Kontrollpunkt, der der im ARXML-Modell hinterlegten Sequenz (Transition Graph der Logical Supervision) widerspricht (z. B. falscher Zweig, übersprungener Zwischenschritt oder ungültiger Zustand).
2. Fehlererkennung & interne Bewertung: :Platform Health Management detektiert die Verletzung der logischen Überwachung. Die interne Routine «aapInformative» handleSupervisionFailure() stellt fest, dass die fehlerhafte Entität das State Management selbst ist. Da SM nicht zur Behebung des eigenen Ausfalls herangezogen werden kann (Verhinderung von Zirkelschluss und Deadlock), wird der Fehler als Critical Supervision Failure klassifiziert.
3. Hardware-Eskalation: PHM triggert synchron/deterministisch FireWatchdogReaction() an :Watchdog.
4. Fehlerfolge: Der Watchdog leitet den sicheren Zustand ein (typischerweise Machine Reset, Triggern eines NMI/SBC-Shutdowns oder Fail-Silent-Übergang der Plattform).

4. Normative Relevanz & Entwickler-Hinweise

• Safety-Architektur (ISO 26262 / ASIL-D Dekomposition):
  • Das State Management ist ein Single Point of Failure für Software-Recovery-Aktionen. Entwickler müssen für SM zwingend eine Watchdog-basierte Eskalationskette im Sicherheitskonzept vorsehen.
• Konfigurationsanforderungen (Manifest / ARXML):
  • In der PlatformHealthManagementContribution muss für die dem State Management zugeordneten Supervised Entities als Fehlerreaktion eine direkte Watchdog-Aktion (WatchdogAction / Plattform-Reset) anstelle einer RecoveryNotification konfiguriert sein.
• API- & Timing-Verträge für SM-Entwickler:
  • Checkpoint-IDs in SM-Threads müssen strikt synchron zum realen Kontrollfluss aufgerufen werden. Ein Softwarefehler (Race Condition, Memory Corruption, falscher Kontrollfluss) führt ohne Vorwarnung oder Graceful Shutdown zur Watchdog-Auslösung.
• Plattform- & Treiber-Integration:
  • Die Verbindung zwischen PHM und :Watchdog muss unabhängig vom OS-Scheduling des State Managements und unabhängig von blockierenden IPC-Mechanismen (z. B. ara::com) priorisiert und blockierungsfrei ausgeführt werden.