The “independence” of the built-in watchdog in MCUs is typically reflected in its hardware isolation from core processing units (such as CPUs and buses), for example, having independent clock sources, counters, and reset logic. This ensures that even if the CPU becomes unresponsive due to software bugs or hardware failures, the built-in watchdog can still trigger a reset, covering some scenarios of IP failure, which is common in ASIL B and other mid-low safety level scenarios. However, in high safety level scenarios like ASIL D, the advantages of a system-level external watchdog become apparent—it is not only independent of the MCU but can also operate independently of the entire main control system’s power and clock domains. For instance, if the MCU experiences power supply issues due to a failure in the internal power management unit, the built-in watchdog may also fail, while the external watchdog (usually powered by an independent power source) can detect this “systemic failure” and implement a more thorough shutdown or reset, which is a concrete manifestation of the ISO 26262 principle of “avoiding common cause failures.” In simple terms, the built-in watchdog is for “MCU self-protection,” while the external watchdog is for “system-level monitoring.” The two are often not mutually exclusive but form a “dual protection” in high safety architectures, especially in automotive electronics and industrial control, where this layered design can significantly enhance diagnostic coverage (DC) and single point failure metric (SPFM). Friends in the chip industry may be more concerned about how much the independence of the built-in watchdog is “isolated to which layer” (for example, whether it shares a clock with the phase-locked loop), as this directly affects its weight in functional safety assessments.
The following content is based on industry standards, vendor documentation, and authoritative technical materials:
1. Core Technical Principles of Watchdogs
1.1 Classification and Mechanism of Watchdogs
- Independent Watchdog (IWDG):
Taking the STM32 series as an example, the IWDG uses a low-speed RC oscillator (LSI, 30-60kHz) that is independent of the system clock, allowing it to function even if the main clock fails. Its core is a 12-bit decrementing counter that triggers a system reset after a timeout. For example, the IWDG of the STM32H7 supports hardware watchdog mode, which automatically starts after power-up and cannot be disabled by software.
Source: STMicroelectronics official document “STM32H7 Functional Safety Manual”
- Window Watchdog (WWDG):
Based on the system clock (PCLK1), it requires the feeding operation to be completed within a specific time window. For example, the WWDG of the STM32F4 allows feeding the watchdog when the counter value is between 0x40 and 0x7F; exceeding this window results in a reset. Its Early Wakeup Interrupt (EWI) function can trigger an interrupt before a reset, used for critical data preservation.
Source: STMicroelectronics application note “AN4686: STM32 Watchdog Configuration Guide”
1.2 Technical Details of Independence Design
- Clock Isolation: The watchdog module of NXP S32K1xx uses a clock source independent of the phase-locked loop (PLL) to avoid watchdog failure due to PLL faults.
Source: NXP technical document “S32K1xx MCU Reference Manual”
- Power Isolation: The safety watchdog of Infineon AURIX TC3xx series is powered by an independent power domain, ensuring operation even if the main power supply is abnormal.
Source: Infineon application note “AURIX CPU and Safety Watchdog Design Guide”
2. Specific Requirements of Functional Safety Standards
2.1 Core Principles of ISO 26262
- Layered Protection: ISO 26262 Part 5 requires ASIL D level systems to adopt a “dual watchdog architecture,” i.e., built-in watchdog (MCU self-monitoring) + external watchdog (system-level monitoring). For example, in automotive electronics, the external watchdog must be independent of the MCU’s power, clock, and communication bus to avoid common cause failures.
Source: ISO 26262:2018 “Road Vehicles Functional Safety” Part 5
- Diagnostic Coverage (DC):
• The diagnostic coverage of the built-in watchdog for internal MCU faults is typically 60-80% (e.g., program runaway).
• The external watchdog can increase the diagnostic coverage of system-level faults (e.g., power fluctuations, bus errors) to over 99%.
Source: AUTOSAR specification “MCAL Wdg Driver Technical Document”
2.2 Fault Handling Mechanism
• Watchdog management in the AUTOSAR architecture:
In AUTOSAR CP, the WdgM module monitors program flow through Checkpoints. If an anomaly is detected (e.g., deadline timeout), it can trigger the external watchdog reset via WdgIf. For example, when a software task fails to refresh the watchdog within the specified time, WdgM sends a timeout signal to the hardware watchdog.
Source: AUTOSAR standard “MCAL WdgM Module Specification”
3. Vendor Implementations and Typical Architectures
3.1 Built-in Watchdogs of Automotive MCUs
- Infineon AURIX TC397:
Integrates two independent watchdogs (WDT1 and WDT2) that monitor CPU1 and CPU2, respectively. WDT1 can be configured in window mode, requiring feeding operations to be completed within a specific cycle; WDT2 supports both hardware reset and software interrupt responses.
Source: Infineon “AURIX TC397 Functional Safety Manual”
- NXP S32K3:
The watchdog module supports programmable timeout periods (0.5ms-16s) and can be configured via registers to reset only specific CPU cores or the entire system.
Source: NXP “S32K3 Series MCU Data Sheet”
3.2 Typical Solutions for External Watchdogs
- TI TPS3828:
An industrial-grade external watchdog chip that supports independent power inputs (VDD and VCC) and can monitor the MCU’s supply voltage (e.g., under-voltage, over-voltage), triggering a system reset via the RESET pin. Its timeout can be configured using external resistors and capacitors (10ms-100s).
Source: TI application note “TPS3828 Watchdog Design Guide”
- MAXIM MAX706:
A watchdog chip with voltage monitoring that triggers a reset when VCC falls below a threshold (e.g., 4.65V) and supports manual reset input (MR pin). In DSP systems, software feeding can be achieved via the WDI pin.
Source: Maxim Integrated “MAX706 Data Sheet”
4. Application Scenarios and Design Considerations
4.1 High Safety Requirements in Automotive Electronics
- Autonomous Driving Domain Controller:
The Huawei MDC 610 adopts an “MCU+FPGA” architecture, where the MCU (e.g., AURIX TC397) has a built-in watchdog monitoring software tasks, and the FPGA uses an external watchdog (e.g., TI TPS3828) to monitor the entire system’s power and communication status, ensuring compliance with ASIL D level.
Source: China Automotive Technology and Research Center, Tsinghua University, Huawei “Automotive Intelligent Driving Technology White Paper”
- Battery Management System (BMS):
In Infineon’s BMS solution, the TLE9879 controller’s built-in watchdog monitors the cell balancing algorithm, while the external watchdog (e.g., STMicroelectronics STM32G4) monitors the battery pack’s voltage and temperature sensor data, forming dual protection.
Source: Infineon “BMS Functional Safety Design Guide”
4.2 Reliability Design in Industrial Control
- PLC Systems:
The Siemens S7-1500 PLC’s CPU module integrates a watchdog while also monitoring the communication bus (PROFINET) status through an external module (e.g., ET 200SP watchdog module) to prevent system loss of control due to bus interruptions.
Source: Siemens “S7-1500 System Manual”
- Motor Drive:
In TI’s C2000 DSP solution, the brake function of the ePWM module interacts with the external watchdog. When overcurrent or overheating is detected, the watchdog triggers the ePWM module to shut down PWM output, protecting power devices.
Source: TI “C2000 Motor Control Application Note”
5. Authoritative Standards and Industry Norms
5.1 ISO 26262:2018
• Part 5: Chapter 9 “Hardware design metrics” specifies the contribution calculation method of the watchdog to SPFM (single point failure metric).
• Part 6: Chapter 10 “Software unit verification” requires that watchdog-related code must pass MC/DC (Modified Condition Decision Coverage) testing.
Source: ISO 26262:2018 official text
5.2 IEC 61508
• Part 5 “Deterministic safety-related systems” requires that the diagnostic coverage of the watchdog must reach over 90% (SIL 3 level).
Source: IEC 61508:2010 “Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems”
5.3 AUTOSAR
• The “MCAL Wdg Driver Specification” defines the interface standards between the watchdog driver and upper-layer software (WdgM), including feeding functions (Wdg_DriverRefresh) and status query functions (Wdg_DriverGetStatus).
Source: AUTOSAR Release 4.4.0
6. Conclusion
The design of watchdogs must adhere to the principles of “layered protection and independent isolation”:
- Low safety levels (ASIL B): Relying solely on the built-in watchdog of the MCU, such as the IWDG of STM32, to achieve basic protection through an independent clock source.
- High safety levels (ASIL D): Must adopt a “built-in + external” dual watchdog approach, such as Infineon AURIX paired with TI TPS3828, to meet ISO 26262’s requirements for avoiding common cause failures.
- Verification methods: Use HIL (Hardware-in-the-Loop) testing tools (e.g., ETAS ES680) to simulate watchdog timeout scenarios and verify the correctness of reset logic.
Note: The above content is synthesized from vendor technical documents, industry standards, and academic papers; specific implementation details should refer to official materials.