Figure 2: Sequence of watchdog initialization, setting trigger condition and mode switching.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck: Spezifikation des Lebenszyklus und Interaktionsmusters des AUTOSAR Watchdog-Stacks (Classic Platform, System- und Abstraktionsschicht bis MCAL).
• Funktionale Einordnung: Zeigt die Entkopplung von Initialisierung (Boot-/Startup-Phase via EcuM), zyklischer Überwachung/Trigger-Verlängerung (WdgM an Wdg via WdgIf) und Betriebsmodi-Umschaltung (WDGIF_OFF_MODE, WDGIF_SLOW_MODE, WDGIF_FAST_MODE).

2. Komponenten, Entitäten & Schnittstellen

• Akteure / BSW-Module (Stereotyp «module»):
  • EcuM (ECU State Manager, System Services): Übernimmt die hardwarenahe Grundinitialisierung im Boot-Pfad.
  • WdgM (Watchdog Manager, System Services): Führt die logische Überwachung (Alive-, Deadline-, Logical Supervision) durch und steuert das Trigger-Budget.
  • WdgIf (Watchdog Interface, ECU Abstraction Layer): Bietet eine einheitliche Abstraktionsschicht für interne (Microcontroller-interne) und externe (z. B. SPI-basierte SBC-) Watchdogs.
  • Wdg (Watchdog Driver, MCAL): Hardware-spezifischer Treiber zur Ansteuerung des physischen Watchdogs.
• Schnittstellen & Parameter-Signaturen:
  • Wdg_Init(const Wdg_ConfigType* ConfigPtr): Synchroner Treiber-Initialisierungsaufruf (Post-Build-Konfigurationszeiger).
  • WdgIf_SetTriggerCondition(uint8 DeviceIndex, uint16 Timeout): Übergibt den Ziel-Watchdog (DeviceIndex) und das Timeout-Intervall in Millisekunden.
  • Wdg_SetTriggerCondition(uint16 Timeout): Treiber-spezifischer Hardware-Trigger ohne Geräteindex.
  • WdgIf_SetMode(uint8 DeviceIndex, WdgIf_ModeType WdgMode): Modus-Anforderung an das Interface; Rückgabetyp: Std_ReturnType (im Diagramm als Parameterfeld typisiert).
  • Wdg_SetMode(WdgIf_ModeType WdgMode): Treiber-spezifische Umschaltung des Hardware-Modus; Rückgabetyp: Std_ReturnType.
• Kardinalitäten & Abbildung:
  • WdgIf multiplexiert 1..n Watchdog-Instanzen (Wdg) über den Parameter DeviceIndex (uint8).
  • WdgM greift modular auf 1..n Watchdogs ausschließlich über WdgIf zu.
  • EcuM initialisiert den Treiber direkt (typischerweise in DriverInitListOne oder DriverInitListTwo).

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierungsphase (Startup):
   • Synchroner Aufruf: EcuM ruft Wdg_Init(const Wdg_ConfigType*) direkt auf dem MCAL-Treiber Wdg auf.
   • Der Treiber initialisiert die Register, setzt die Hardware in den konfigurierten Default-Modus (in der Regel WDGIF_SLOW_MODE) und kehrt synchron zu EcuM zurück.
2. Watchdog-Servicing / Trigger-Bedingung setzen (Runtime / Cyclic Task):
   • Auslöser: WdgM evaluiert zyklisch den globalen Überwachungsstatus (Supervision Entities).
   • Pfad: WdgM ruft synchron WdgIf_SetTriggerCondition(DeviceIndex, Timeout) auf.
   • Demultiplexing: WdgIf ermittelt anhand des DeviceIndex die zuständige Treiber-API und ruft Wdg_SetTriggerCondition(Timeout) auf.
   • Wirkung: Hardware-Timer/Trigger-Window wird auf das spezifizierte Intervall aufgefrischt. Synchroner Kontrollfluss kehrt über WdgIf zu WdgM zurück.
3. Modusumschaltung (Mode Switching):
   • Auslöser: Änderung des Betriebszustands (z. B. Übergang in Shutdown/Sleep oder High-Frequency Task-Monitoring).
   • Pfad: WdgM ruft WdgIf_SetMode(DeviceIndex, WdgMode) auf.
   • Routing: WdgIf delegiert an Wdg_SetMode(WdgMode).
   • Rückmeldung: Wdg quittiert synchron mit Std_ReturnType (E_OK oder E_NOT_OK). Der Status propagiert synchron über WdgIf zurück an WdgM.

4. Normative Relevanz & Entwickler-Hinweise

• Treiber-Implementierung (Wdg):
  • Wdg_SetTriggerCondition und Wdg_SetMode müssen reentrant bezüglich verschiedener Instanzen sein, dürfen aber für dieselbe Instanz nicht überlappend ausgeführt werden.
  • Wenn die zugrundeliegende Watchdog-Hardware die Deaktivierung (WDGIF_OFF_MODE) hardwaretechnisch sperrt (z. B. Window-Watchdog im Safety-Lock), muss Wdg_SetMode(WDGIF_OFF_MODE) zwingend mit E_NOT_OK fehlschlagen und den aktuellen Modus unverändert beibehalten.
• Interface-Konfiguration (WdgIf):
  • Kann als statische Inline-Funktion/Makro generiert werden (Zero-Overhead-Optimierung), wenn im Gesamtsystem genau ein Watchdog (WdgIfNumWatchdogs == 1) konfiguriert ist (DeviceIndex = 0). Bei Multi-Watchdog-Setups (> 1) erfolgt das Dispatching tabellenbasiert über Funktionszeiger.
• Systemintegration (EcuM / WdgM):
  • Reihenfolge-Abhängigkeit: Wdg_Init erfolgt vor dem Start des OS und vor WdgM_Init. Bis zum Start des WdgM läuft der Watchdog im hardware-definierten Timeout-Fenster; EcuM bzw. der BSW-Boot-Pfad muss sicherstellen, dass WdgM_Init und der erste Aufruf von WdgIf_SetTriggerCondition vor Ablauf des initialen Hardware-Timeouts erfolgen (Vermeidung von Early-Boot-Resets).
• Synchrones API-Modell: Alle Schnittstellen sind blockierend/synchron ohne Callbacks; zeitintensive externe Watchdog-Treiber (z. B. via SPI) müssen im Treiber blockierende SPI-Sync-Transfers nutzen oder dürfen das Watchdog-Trigger-Timing nicht überdehnen.