Figure 11.22: Scenario: Manage Watchdog

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsszenario mit Interaktionsrahmen loop).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Release R23-11, Spezifikation AUTOSAR_AP_EXP_SWArchitecture, Kapitel 11 (Platform Health Management, PHM).
• Technischer Zweck: Darstellung des zyklischen Basismechanismus zur Überwachung der Plattform- und Applikationsintegrität sowie der abgeleiteten Watchdog-Bedienung. Das PHM dient als zentrale Instanz zur Bündelung aller Überwachungsergebnisse vor dem Hardware-/System-Watchdog-Trigger.

2. Komponenten, Entitäten & Schnittstellen

• «aapFunctionalCluster» :Platform Health Management:
  • Instanz des funktionalen Clusters PHM der Adaptive Platform.
  • Verantwortlich für die Aggregation und Auswertung aller konfigurierten Überwachungsarten (Alive Supervision, Deadline Supervision, Logical Supervision).
• :Watchdog:
  • Abstrahierte Zielentität (z. B. Watchdog-Daemon, OS-Watchdog-Service oder Hardware-Watchdog-Treiber).
• Aufgerufene Operationen / Schnittstellen:
  • «aapInformative» checkSupervisions(): PHM-interne synchrone Methode (Self-Call), formal durch das Stereotyp «aapInformative» als rein informatives Modellelement annotiert, zur periodischen Auswertung aller aktiven Überwachungsmetriken und Checkpoint-Zustände.
  • AliveNotification(): Ausgehender Methodenaufruf vom PHM an den Watchdog zur Bestätigung der Systemlebensfähigkeit (Watchdog Refresh / Kick).

3. Dynamisches Verhalten & Sequenzablauf

• Zyklus (loop-Block): Läuft deterministisch in einer Endlosschleife, getaktet durch die konfigurierte Zykluszeit der PHM-Hauptverarbeitungsaufgabe.

1. Zustandsevaluierung: Das PHM führt intern checkSupervisions() aus. Hierbei werden alle empfangenen Checkpoint-Meldungen, Alive-Zähler, Ausführungsreihenfolgen und Latenzzeiten der überwachten Prozesse gegen die im Manifest hinterlegten Schwellwerte validiert.
2. Watchdog-Triggern: Bei intaktem Gesamtzustand (Supervision Status: OK) setzt das PHM den Aufruf AliveNotification() an die Entität :Watchdog ab, um einen Timeout/Reset des Watchdogs zu verhindern.

• Fehlerpfad (implizit/Abbruchbedingung): Ergibt checkSupervisions() einen unzulässigen Status (z. B. Deadline-Verletzung, Alive-Counter-Diskrepanz) und greift keine rein lokale Recovery Action, wird AliveNotification() unterdrückt. Dies führt zum gezielten Ablauf des Watchdogs und initiiert den plattformweiten Hardware-/System-Reset.

4. Normative Relevanz & Entwickler-Hinweise

• Architektur-Entkopplung: Adaptive Applications dürfen den Watchdog niemals direkt bedienen. Die Watchdog-Bedienung erfolgt ausschließlich gekoppelt an die erfolgreiche Evaluierung durch das PHM.
• Timing & Konfiguration: Das Ausführungsintervall des PHM-Loops, die Supervisions-Toleranzfenster und die Hardware-Watchdog-Timeout-Periode müssen strikt aufeinander abgestimmt werden: $$\text{Watchdog-Timeout} > \text{PHM-Loop-Periode} + \text{Worst-Case Execution Time (WCET)} + \text{Jitter}$$
• Sicherheitsrelevanz (ISO 26262): checkSupervisions() bildet die funktionale Grundlage für programmablauf- und lebendigkeitsbezogene Sicherheitsziele (Safety Goals). Ein fehlerhaft konfiguriertes Überwachungsmodell im ARXML führt entweder zu unberechtigten System-Resets (False Positives) oder zum Ausbleiben der Fehlerreaktion (False Negatives).