Figure 9.70: Interfaces for watchdog handling

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponenten- und Schnittstellendiagramm.
• Kontext: AUTOSAR Adaptive Platform (AP R21-11), Functional Cluster Platform Health Management (PHM).
• Technischer Zweck: Spezifikation der hardwarenahen Abstraktions- und Ansteuerungsschnittstelle (WatchdogInterface) zwischen dem daemon-basierten PHM-Core und dem plattformspezifischen Watchdog-Treiber/Subsystem zur Absicherung der Plattformintegrität (Alive-Handling und eskalierte Fehlerreaktion).

2. Komponenten, Entitäten & Schnittstellen

• «aapFunctionalCluster» Platform Health Management (daemon-based):
  • Zentraler Systemdämon der Adaptive Platform.
  • Konsument («use»-Abhängigkeit) der Watchdog-Schnittstelle. Aggregiert lokale und globale Überwachungsergebnisse (Alive-, Deadline-, Logical-Supervision sowie Health Channels).
• «aapNativeInterface, aapPlatformExtension» Platform Health Management::WatchdogInterface:
  • Native C++ Schnittstelle; deklariert als plattformspezifische Erweiterung (Platform Extension), nicht als serviceorientierte ara::com-Schnittstelle.
  • Operationen:
    • + AliveNotification(): Zyklischer Trigger-Aufruf zur Bestätigung des intakten Systemzustands ("Watchdog Petting").
    • + FireWatchdogReaction(): Synchroner Eskalationsaufruf zur sofortigen Erzwingung der im Watchdog-Subsystem hinterlegten Sicherheitsreaktion (z. B. System-Reset).
• Watchdog (UML-Komponente):
  • Implementierende Entität (Realisierungsbeziehung --▷ auf WatchdogInterface).
  • Kapselt den eigentlichen Hardware-Watchdog (interner MCU-/SoC-Watchdog oder externer System Basis Chip / SBC) bzw. den entsprechenden OS-Treiber.

3. Dynamisches Verhalten & Sequenzablauf

• Regulärer Pfad (Keep-Alive / Normalbetrieb):
  1. Supervised Entities melden Checkpoints zyklisch an den PHM-Dämon.
  2. PHM validiert den globalen Überwachungsstatus (GlobalSupervisionStatus == OK).
  3. Bei positivem Gesamtergebnis ruft der PHM-Dämon innerhalb des definierten Zeitfensters AliveNotification() auf.
  4. Die Watchdog-Komponente bedient die Hardware (Counter-Reload / Trigger-Signal).
• Fehlerpfad (Supervision Failure / Recovery Escalation):
  • Passiv: Schlägt eine Alive-/Deadline-/Logical-Supervision fehl und greift keine lokale Recovery, stellt PHM die Aufrufe von AliveNotification() ein → Hardware-Watchdog läuft ab (Timeout-Reset).
  • Aktiv: Erkennt PHM einen nicht tolerierbaren Zustand oder schlägt eine konfigurierte Recovery Action fehl, ruft PHM explizit FireWatchdogReaction() auf → die Watchdog-Komponente initiiert unverzüglich den definierten Safe-State bzw. einen Hardware-Reset ohne Abwarten des Timeouts.

4. Normative Relevanz & Entwickler-Hinweise

• BSP- & Plattform-Entwicklung:
  • WatchdogInterface muss vom Plattform-Integrator bzw. BSP-Lieferanten implementiert werden (z. B. via Linux IOCTL /dev/watchdog, POSIX-Timer oder hardwarenahe Treiber bei Safety-OS/Microkernel).
  • Die Implementierung von FireWatchdogReaction() muss zwingend reentrant, blockierungsfrei und deterministisch ausgelegt sein, da der Aufruf im Kontext kritischer Systemzustände erfolgt.
  • Für Fenster-Watchdogs (Window Watchdogs) muss die Zykluszeit des PHM-Aufrufs AliveNotification() exakt auf die konfigurierte Open-Window-Dauer der Hardware abgestimmt werden.
• Applikations-Entwickler:
  • Adaptive Applications haben keinen Zugriff auf diese Schnittstelle. Die Interaktion mit PHM erfolgt für Applikationen ausschließlich über ara::phm (Checkpoints/Health Channels) bzw. RecoveryAction.