Figure 11.24: Scenario: Recover from Critical Supervision Failure in Execution Management

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck: Spezifikation des sicherheitskritischen Fehlereskalations- und Wiederherstellungspfades (Recovery Path) innerhalb der AUTOSAR Adaptive Platform (AP), wenn das zentrale Execution Management (EM) selbst von einem kritischen Überwachungsfehler (Critical Supervision Failure) betroffen ist.
• Architektur-Einordnung: Im regulären Fehlerfall meldet das Platform Health Management (PHM) Fehler an das EM, damit dieses fehlerhafte Prozesse beendet oder neu startet. Versagt jedoch das EM selbst (z. B. Deadlock, Speicherfehler, korrumpierter Kontrollfluss), entfällt die reguläre Prozessmanagement-Instanz. Das Diagramm modelliert den deterministischen Fallback auf den Watchdog, um das Gesamtsystem in einen definierten sicheren Zustand (Safe State via Reset) zurückzuführen.

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • «aapFunctionalCluster» :Execution Management: Instanz des funktionalen Clusters für Lebenszyklus-, Prozess- und Zustandssteuerung der Adaptive Platform. Agiert hier als fehlerhafte, überwachte Entität (Supervised Entity).
  • «aapFunctionalCluster» :Platform Health Management: Instanz des funktionalen Clusters für Plattformgesundheit und Überwachung (Alive-, Deadline- und Logical Supervision).
  • :Watchdog: Plattform- bzw. Hardware-Watchdog (Treiber/Daemon bzw. hardwarenahe Watchdog-Interface-Instanz), autonom gegenüber dem POSIX-Prozessraum des EM.
• Stereotypen:
  • «aapFunctionalCluster»: Kennzeichnet standardisierte Architekturbausteine der AUTOSAR Adaptive Platform.
  • «aapInformative»: Markiert interne, nicht-normativ vorgeschriebene Implementierungsdetails bzw. Verhaltensschritte.
• Schnittstellen & Methodenaufrufe:
  • ReportCheckpoint(wrongCheckpointId): Standardisierter synchroner/asynchroner API-Aufruf (gemäß ara::phm) von einer Supervised Entity an das PHM zur Meldung eines erreichten Kontrollpunkts.
  • «aapInformative» handleSupervisionFailure(): PHM-interne Auswerteroutine zur Bestimmung der konfigurierten Fehlerreaktion (Recovery Action).
  • FireWatchdogReaction(): Direkter Steueraufruf an die Watchdog-Entität zur Auslösung der konfigurierten Hardware- bzw. Eskalationsreaktion (Reset/Safe State Trigger).
• Diagramm-Annotation:
  • Stereotype/Notiz: "Example for a cause of a failed supervision (wrong checkpoint reported for a logical supervision)." Veranschaulicht die Fehlerursache: Verletzung des zulässigen Kontrollflussgraphen innerhalb der Logical Supervision.

3. Dynamisches Verhalten & Sequenzablauf

1. Fehlertrigger (Kontrollflussverletzung):
   • Das Execution Management durchläuft einen Programmpfad und meldet via ReportCheckpoint(...) einen Kontrollpunkt.
   • Der übergebene Identifikator wrongCheckpointId entspricht nicht der im ARXML-Modell definierten Transition der logischen Überwachung (Logical Supervision Graph Violation).
2. Lokale Fehlerverarbeitung im PHM:
   • PHM erkennt die Transition-Verletzung und führt die interne Routine «aapInformative» handleSupervisionFailure() aus.
   • Das Regelwerk stellt fest, dass der Verursacher das Execution Management selbst ist. Ein Standard-Recovery-Pfad (Prozess-Kill/-Restart via EM oder Zustandswechsel via State Management) ist ausgeschlossen, da die ausführende Instanz korrumpiert ist.
3. Eskalation an den Watchdog:
   • PHM ruft unverzüglich FireWatchdogReaction() auf.
   • Die Watchdog-Instanz stoppt das Triggern des Hardware-Watchdogs oder leitet unmittelbar einen Plattform-/MCU-Reset ein.

4. Normative Relevanz & Entwickler-Hinweise

• Eskalationshierarchie & Recovery-Konfiguration:
  • Entwickler dürfen für Supervised Entities des EM keine Recovery Actions konfigurieren, die auf EM-Dienste (wie Prozessneustart) rekurrieren.
  • Für kritische Überwachungsfehler im EM ist im Manifest zwingend eine Watchdog-Eskalationsaktion (Watchdog Action / Hardware-Reset) zu hinterlegen.
• API-Vertrag (ara::phm):
  • ReportCheckpoint: Gehört zur normativen C++-API (ara::phm::SupervisedEntity::ReportCheckpoint).
  • handleSupervisionFailure: Ist rein informativ («aapInformative»). Stack-Hersteller können die interne Fehlerkorrelations-Pipeline proprietär optimieren.
  • FireWatchdogReaction: Repräsentiert die Interaktion mit dem Watchdog Driver/Daemon (WdgM/Wdg-Interface).
• Safety & Unabhängigkeit (ISO 26262):
  • Der Pfad PHM -> Watchdog muss frei von Rückwärtseffekten (Freedom from Interference, FFI) und Blockaden durch das EM implementiert sein.
  • Der Watchdog-Pfad muss auch dann voll funktionsfähig bleiben, wenn der Execution-Management-Prozess vollständig blockiert oder dessen IPC-Kanäle ausgelastet sind.