DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_WatchdogManager FIG-2c4b62dab85e365e 867 × 617 px 1 Release(s)

Figure 16: Initialization of the Watchdog Manager module

SHA-256 Inhalts-Fingerabdruck: 2c4b62dab85e365eb2eae49f7ab2ce076629c999577c72d17cee46d14d9f6a3b
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

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, uint16): Interner Zustandsübergang des Watchdog Managers zur Aktivierung des konfigurierten initialen Betriebsmodus (WdgM_ModeType, Mode-ID bzw. Watchdog-Modus-Parameter).
    • 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.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R4.0.3 → R4.1.3 keine inhaltliche Änderung Vorgänger: FIG-7319363ed05a61fe

Keine inhaltlichen Änderungen erkennbar.

R4.1.3 → R4.2.2 keine inhaltliche Änderung Nachfolger: FIG-6ddded2d49e63651

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

:EcuM :WdgM :WdgIf | A | After the initialization of the OS the EcuM should initialize the Watchdog Manager. | WdgM_Init(const WdgM_ConfigType*) | WdgM_SetMode(Std_ReturnType, WdgM_ModeType, uint16) | WdgIf_SetMode(Std_ReturnType, uint8, WdgIf_ModeType)

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R4.1.3 AUTOSAR_SWS_WatchdogManager S. 108 16 Figure 16: Initialization of the Watchdog Manager module