Figure 9.1: Initialization of the Watchdog Manager module

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck: Spezifikation des standardisierten Start- und Initialisierungsablaufs des Watchdog Managers (WdgM) während der ECU-Startup-Phase (EcuM-Init-Sequenz nach OS-Start).
• Architektur-Einordnung:
  • System Services Layer: EcuM (ECU State Manager, Steuerungsinstanz des Bootstraps) und WdgM (Überwachung von Alive-, Deadline- und Logical-Program-Flows).
  • Device Driver Abstraction Layer: WdgIf (Watchdog Interface, Abstraktionsschicht zur hardwareunabhängigen Adressierung interner/externer Watchdog-Treiber).

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte Instanzen (Lifelines):
  • :EcuM – ECU State Manager (Aufrufer der BSW-Initialisierungsphase).
  • :WdgM – Watchdog Manager (zentrales BSW-Modul zur Software-Überwachung).
  • :WdgIf – Watchdog Interface (Routing- und Abstraktionsmodul für Hardware-Watchdogs).
• Schnittstellen & Datentypen:
  • WdgM_Init(const WdgM_ConfigType* ConfigPtr): Synchroner API-Call zur Initialisierung des WdgM mit post-build-fähigem Konfigurationsdatensatz (WdgM_ConfigType).
  • WdgM_SetMode(Std_ReturnType, WdgM_ModeType): Interner Zustandsübergang des Watchdog Managers zur Aktivierung des konfigurierten initialen Betriebsmodus (WdgM_ModeType).
  • WdgIf_SetMode(Std_ReturnType, uint8 DeviceIndex, WdgIf_ModeType WdgMode): Synchrone Weiterleitung des Moduswechsels an das Watchdog Interface für den jeweiligen Watchdog-Kanal (DeviceIndex, z. B. interner MCU-Watchdog oder externer SBC-Watchdog).
• Beziehungen:
  • Strict top-down Kontrollfluss ohne Callbacks; hierarchische Abhängigkeit EcuM → WdgM → WdgIf → (Wdg-Treiber).

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger / Voraussetzung:
   • Ausführung explizit nach der Initialisierung und dem Start des Betriebssystems (OS). Der EcuM ruft im Post-OS-Task bzw. der Phase Startup II den WdgM auf.
2. Synchroner Initialisierungsaufruf:
   • EcuM sendet synchron WdgM_Init(&WdgM_Config).
3. Modus-Initialisierung (Self-Invocation):
   • Innerhalb des Kontexts von WdgM_Init triggert der WdgM intern WdgM_SetMode(...), um den in der Konfiguration definierten Initialmodus (WdgMInitialMode) einzunehmen.
4. Hardware-Triggerung über Abstraktionsschicht:
   • WdgM ruft für alle zugewiesenen Watchdog-Instanzen synchron WdgIf_SetMode(DeviceIndex, WdgMode) auf, um Hardware-Watchdogs in den korrespondierenden Target-Mode (z. B. WDGIF_SLOW_MODE oder WDGIF_FAST_MODE) zu versetzen.
5. Return-Pfade:
   • WdgIf_SetMode quittiert den Moduswechsel synchron an WdgM.
   • Nach internem Abschluss des Moduswechsels terminiert die interne Initialisierungssequenz.
   • WdgM_Init kehrt synchron ohne Rückgabewert (void) zum EcuM zurück.

4. Normative Relevanz & Entwickler-Hinweise

• Initialisierungsreihenfolge & OS-Abhängigkeit:
  • Der Aufruf darf erst erfolgen, wenn das OS läuft, da WdgM auf Betriebssystem-Mechanismen (z. B. OS-Counter für Deadline Supervision, globale Interrupt-Sperren, Task-Scheduling für WdgM_MainFunction) angewiesen ist.
  • Eine Initialisierung in Phase Startup I (Pre-OS) führt zu undefiniertem Verhalten oder DET-Fehlern.
• Konfigurationsaspekte (WdgMConfigSet):
  • WdgMInitialMode muss zwingend auf einen gültigen Modus referenzieren.
  • Für jeden im Initialmodus aktiven Watchdog muss im WdgIf ein korrespondierender WdgIfDevice konfiguriert sein.
• Laufzeit- & Blockierungsverhalten:
  • WdgIf_SetMode propagiert den Moduswechsel direkt an den MCAL-Treiber (Wdg_SetMode). Dauert die Hardware-Umschaltung (z. B. SPI-Kommunikation bei externem SBC-Watchdog) blockierend an, verlängert dies die Ausführungszeit von WdgM_Init direkt im Bootstrapping-Kontext des EcuM.
• Fehlerbehandlung:
  • Schlägt WdgIf_SetMode fehl (E_NOT_OK), verbleibt der WdgM im Fehlerstatus (WDGM_GLOBAL_STATUS_DEACTIVATED bzw. fehlerhafte Initialisierung), meldet gegebenenfalls einen DET-Eintrag (WDGM_E_PARAM_CONFIG / WDGM_E_SET_MODE) und verhindert die spätere Aktivierung der Überwachungsentitäten.