Figure 11.7: Scenario: Recover by Watchdog Reset

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm zur Darstellung eines Fehlerszenarios).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Release R24-11, Dokument AUTOSAR_AP_EXP_SWArchitecture.
• Funktionaler Zweck: Visualisierung des Fehlerbehandlungs- und Eskalationspfades bei fehlgeschlagener Überwachung (Supervision Failure). Dargestellt ist das Fallback-Szenario, in dem das State Management (SM) eine vom Platform Health Management (PHM) angeforderte Wiederherstellungsaktion nicht ausführen kann (kSMCanNotHandleRecovery) und PHM die letzte funktionale Sicherheitsebene durch Auslösen eines Watchdog-Resets über das WatchdogInterface erzwingt.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lebenslinien:
  • «aapFunctionalCluster» :Platform Health Management: Zentraler Functional Cluster zur Laufzeitüberwachung (Alive-, Deadline- und Logical Supervision sowie Health Channel Monitoring) von Adaptive Applications und Plattform-Prozessen.
  • «aapFunctionalCluster» :State Management: Zentraler Functional Cluster für Zustandsübergänge (Function Groups, Machine States) und koordinierte Recovery-Aktionen auf Applikations- und Maschinenebene.
  • :WatchdogInterface: Plattformnahe Abstraktions-/Treiberschnittstelle zur Hardware-Watchdog-Ansteuerung bzw. Watchdog-Daemon-Interaktion.
• Stereotypen:
  • «aapFunctionalCluster»: Kennzeichnet standardisierte Systemdienste der AUTOSAR Adaptive Platform-Architektur.
  • «aapInformative»: Markiert architekturell informative Interaktionen bzw. interne Pseudomethoden, die keine normative 1:1-C++-API-Signatur der AUTOSAR-SWS darstellen.
• Schnittstellen & Interaktionsbeziehungen:
  • Interaktion zwischen SM und PHM über ARA-Dienste (Service-Oriented Communication via ara::com oder direkte IPC-Bindings).
  • Direkte Schnittstelle von PHM zu Hardware-/OS-Ebene über das WatchdogInterface.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung / Service Binding:
   • :State Management sendet Offer() an :Platform Health Management, um seine Schnittstelle/Bereitschaft für Recovery-Handler bereitzustellen (Service Discovery / Initialisierung).
2. Fehler-Trigger:
   • Eingehender Trigger supervisionFailed() «aapInformative» (ausgelöst durch Checkpoint-Verletzung, Timeout der Alive-Supervision, fehlerhafte Ausführungsreihenfolge oder externe Systemfehler).
3. Interne Auswertung:
   • PHM führt intern handleFailedSupervision() «aapInformative» aus, bewertet den Systemzustand und ermittelt die konfigurierte Recovery-Aktion.
4. Delegation an State Management:
   • Synchroner Methodenaufruf RecoveryHandler() von PHM an SM zur Einleitung einer softwareseitigen Fehlerbehebung (z. B. Prozessneustart, Zustandswechsel in einen Safe State oder degraded Mode).
5. Fehlgeschlagene Recovery (Negativer Rückgabewert):
   • SM antwortet mit dem Return-Code / Fehlerstatus :kSMCanNotHandleRecovery. SM signalisiert damit, dass die angeforderte Recovery-Strategie nicht anwendbar, blockiert oder fehlgeschlagen ist.
6. Eskalation / Watchdog-Reaktion:
   • PHM aktiviert den konfigurierten Eskalationspfad und ruft synchron/direkt FireWatchdogReaction() auf dem :WatchdogInterface auf. Dies führt zum Stoppen des Watchdog-Triggerns bzw. zur unmittelbaren Hard-/Firmware-Reset-Auslösung der Maschine.

4. Normative Relevanz & Entwickler-Hinweise

• Konfigurationsaspekte (ARXML / Manifest):
  • Im Execution- und Health-Management-Manifest müssen für die jeweiligen Supervisions explizite Recovery Actions definiert werden.
  • Das Eskalationsverhalten bei fehlschlagendem SM-Recovery-Handling muss deterministisch auf Hardware- bzw. Plattform-Watchdog-Aktionen abgebildet sein (WatchdogAction / PlatformHealthManagementAction).
• API-Vertrag & Fehlertoleranzzeit (FHTT / FTTI):
  • RecoveryHandler() muss innerhalb der harten Echtzeitgrenzen der ASIL-Einstufung antworten. Bei blockierendem SM oder Rückgabe von kSMCanNotHandleRecovery greift die minimale verbleibende Fehlerreaktionszeit bis zum Watchdog-Ablauf.
  • Entwickler von State-Management-Regeln müssen sicherstellen, dass kSMCanNotHandleRecovery nur als letzte Instanz gemeldet wird, da die Konsequenz der vollständige Neustart der Partition/ECU ist.
• Plattform- und Treiberintegration:
  • Das WatchdogInterface muss vom BSP-/OS-Integrator so implementiert sein, dass FireWatchdogReaction() entweder unmittelbar den Refresh-Zyklus beendet oder einen kontrollierten Reset über das WDG-Peripheral/SBC forciert.