Figure 11.22: Scenario: Critical Supervision Failure in Execution Management

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Sequence Diagram).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), spezifiziert im Dokument AUTOSAR_AP_EXP_SWArchitecture (Kapitel Platform Health Management / Execution Management).
• Technischer Zweck: Darstellung des Fehler-Eskalationspfads bei einem fatalen internen Kontrollflussfehler (Logical Supervision Failure) innerhalb des Execution Managements (EM). Da das EM die zentrale Instanz für Prozesslebenszyklen und Zustandswechsel darstellt, kann ein Ausfall des EM nicht softwareseitig über EM-interne Recovery-Mechanismen (z. B. Prozess-Restart) behoben werden, sondern erzwingt die direkte Auslösung einer hardwarenahen Watchdog-Reaktion durch das Platform Health Management (PHM).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / Lifelines:
  • «aapFunctionalCluster» :Execution Management Funktionaler Plattform-Cluster der Adaptive Platform. Dient hier als Supervised Entity (SE) für die Sicherheitsüberwachung.
  • «aapFunctionalCluster» :Platform Health Management Funktionaler Plattform-Cluster für die Laufzeitüberwachung (Alive-, Deadline-, Logical Supervision sowie Health Channels) und Ausführung konfigurierter Recovery Actions.
  • :Watchdog Plattform-/Hardware-Watchdog-Instanz (Watchdog Driver / Hardware-Entität), zuständig für den System-Reset bzw. den Übergang in den Safe State bei Ausbleiben des zyklischen Servicings oder explizitem Fehler-Trigger.
• Schnittstellen & Interaktionspunkte:
  • ReportCheckpoint(wrongCheckpointId): Aufruf der PHM-Client-API durch das EM zur Meldung eines erreichten Checkpoints im Rahmen der Kontrollflussüberwachung.
  • handleSupervisionFailure(): Cluster-interne Methode des PHM zur Auswertung des Überwachungsstatus und Transition der internen Supervision State Machine.
  • FireWatchdogReaction(): Hardwarenahe Steuerungsschnittstelle des PHM zur Watchdog-Entität zur unmittelbaren Fehlereskalation.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger / Checkpoint-Meldung: Das Execution Management führt Programmcode aus und meldet via ReportCheckpoint(wrongCheckpointId) einen Checkpoint an das PHM.
2. Fehleridentifikation (Logical Supervision): Gemäß annotiertem Hinweis (Example for a cause of a failed supervision [...]) entspricht die übermittelte wrongCheckpointId einer ungültigen Transition innerhalb des im PHM konfigurierten Kontrollflussgraphen (Transition Fault).
3. Interne Fehlerbehandlung: Das PHM verarbeitet den Regelverstoß über handleSupervisionFailure(). Die Supervision State Machine der betroffenen Entität wechselt in den Zustand EXPIRED bzw. FAILED.
4. Watchdog-Reaktion (Eskalation): Da die fehlerhafte Entität das EM selbst ist, greift die dafür im Manifest konfigurierte Recovery Action: Das PHM ruft synchron FireWatchdogReaction() auf. Der Watchdog unterbindet das Servicing bzw. triggert unmittelbar einen Reset/Safe State der Machine.

4. Normative Relevanz & Entwickler-Hinweise

• **ARXML-Konfiguration (Execution Management & PHM Manifest):**
  • Checkpoints innerhalb des EM müssen als Logical Supervision im PlatformHealthManagementContribution-Modell exakt gegen den spezifizierten Kontrollflussgraphen (SupervisionCheckpoint, SupervisionTransition) abgebildet sein.
  • Für Supervised Entities des EM darf als Recovery Action keine gewöhnliche Prozess-Neustart-Aktion (RecoveryAction via EM) hinterlegt werden (Zirkelschluss/Deadlock-Gefahr), sondern zwingend eine WatchdogAction (Hardware-Reset / Fail-Safe Transition).
• ASIL-D-Dekomposition & Unabhängigkeit: PHM und Watchdog müssen räumlich und zeitlich unabhängig vom EM agieren (Freiheit von Rückwirkungen / Freedom from Interference gem. ISO 26262), damit ein Speicher- oder Kontrollflussfehler im EM das PHM nicht korrumpiert oder das Auslösen der Watchdog-Reaktion blockiert.
• API-Verhalten & Laufzeit: ReportCheckpoint ist non-blocking und deterministisch auszulegen. Tritt ein Fehler auf, muss die Latenz zwischen Erkennung (handleSupervisionFailure) und Abschaltung (FireWatchdogReaction) innerhalb der definierten Fault Tolerant Time Interval (FTTI) des Gesamtsystems liegen.