Figure 10.14: Use case Recover from Critical Supervision Failure

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Use-Case-Diagramm (Anwendungsfalldiagramm) unter Verwendung des AUTOSAR Adaptive Platform (AP) UML-Profils («aapUseCase», «aapParticipates»).
• Architektur-Kontext: Funktional verortet im Cluster Platform Health Management (PHM) innerhalb der AUTOSAR Adaptive Platform. Das Diagramm spezifiziert die Eskalations- und Recovery-Strategie auf Plattformebene, wenn eine Funktions- oder Prozessüberwachung irreversibel scheitert und das System in einen sicheren Zustand zurückgeführt werden muss.

2. Komponenten, Entitäten & Schnittstellen

• Systemgrenzen (Boundaries):
  • Adaptive Platform: Äußere Architekturgrenze der POSIX-basierten AUTOSAR-Laufzeitumgebung.
  • Platform Health Management: Funktionale Clustergrenze von PHM, zuständig für Alive-, Deadline-, Logical-Supervision sowie Health Channels.
• Anwendungsfälle («aapUseCase»):
  • Recover from Critical Supervision Failure: Übergeordneter Anwendungsfall. Kapselt die Behandlung eines als nicht lokal behebbar eingestuften Überwachungsfehlers.
  • Fire Watchdog Reaction: Untergeordneter, gekapselter Anwendungsfall zur Triggerung einer definierten Watchdog-Reaktion (z. B. Reset, Interrupt oder Übergang in einen sicheren Zustand).
• Akteure (Actors):
  • Watchdog (Paket Actors): Repräsentiert die Watchdog-Entität (externer Hardware-Watchdog, SoC-interner Watchdog oder Safety-Companion-Controller/Classic AUTOSAR Core).
• Beziehungen:
  • «include» (Gerichtete Abhängigkeit von Recover from Critical Supervision Failure auf Fire Watchdog Reaction): Erzwingt, dass die Ausführung des Recovery-Anwendungsfalls zwingend die Auslösung der Watchdog-Reaktion umfasst.
  • «aapParticipates» (Assoziation zwischen Watchdog und Fire Watchdog Reaction): Bindet den Akteur aktiv in die Durchführung der Watchdog-Reaktion ein.

3. Dynamisches Verhalten & Sequenzablauf

1. Triggering / Fehlerklassifikation: PHM detektiert über seine Überwachungsmechanismen (Alive Supervision, Deadline Supervision, Logical Supervision via Checkpoint-Graph oder Health Channel Action) einen Fehlerzustand, dessen konfigurierte Recovery-Aktion als systemsicherheitskritisch definiert ist.
2. Eskalation: Lokale Mechanismen (z. B. Prozess-Neustart via Execution Management ara::exec) werden übersprungen oder sind bereits fehlgeschlagen. Der Use Case Recover from Critical Supervision Failure wird aktiv.
3. Execution der Watchdog-Reaktion:
   • Inklusionsaufruf: PHM führt den Use Case Fire Watchdog Reaction aus.
   • Interaktionspfad mit dem Watchdog:
     • Passiver Pfad (Watchdog Starvation / De-servicing): PHM stellt das zyklische Triggern (Ticking/Petting) des Watchdog-Treibers (z. B. via POSIX-Device /dev/watchdog oder SPI-Kommunikation zum System Basis Chip) ein. Nach Ablauf des Watchdog-Timeout-Fensters löst die Hardware die konfigurierte Reaktion (z. B. Reset) aus.
     • Aktiver Pfad (Direct Reaction Trigger): Sofern hardwareseitig und treiberisch unterstützt, sendet PHM ein sofortiges Reaktions- oder Reset-Kommando an die Watchdog-Peripherie.
4. Endzustand: Die Watchdog-Reaktion führt das System in einen definierten sicheren Zustand über (z. B. Hardware-/Machine-Reset, Fail-Silent / Safe State gemäß ISO 26262).

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationsaspekte (ARXML):
  • Überwachungsfehler müssen in der PHM-Konfiguration explizit auf eine RecoveryAction mit Watchdog-Reaktions-Eskalation (Fire Watchdog Reaction) gemappt werden (SupervisionEntity, HealthChannelAction).
  • Die Watchdog-Timeout-Konfiguration muss gewährleisten, dass die Zeit bis zur Auslösung der Watchdog-Reaktion innerhalb des zulässigen Fault Tolerant Time Interval (FTTI) liegt.