A watchdog timer, often called WDT, is a hardware or hardware-assisted timer used to detect software execution failures. The ECU software must service the watchdog within a defined time window. If the expected service does not occur, the watchdog triggers a defined fault response, often a microcontroller reset.

The basic idea is simple. Healthy software regularly proves to the watchdog that execution is progressing as expected. If software gets stuck, enters an unexpected state or fails to execute the required service operation, the watchdog timer reaches its timeout condition.

An ECU controls functions such as engine management, braking, steering, battery management, body functions and ADAS features. Software failure inside these systems needs controlled detection and recovery mechanisms.

The exact relationship depends on the MCU watchdog architecture, prescaler, counter width, clock source and configuration. Always use the target MCU reference manual for the exact timing calculation.

A basic watchdog might allow service at any time before timeout. A window watchdog adds an additional timing rule. Software must service the watchdog inside an allowed time window.

Engineers often use the phrase “kick” or “feed” the watchdog to describe the watchdog service operation. The software performs a hardware-specific operation to prevent the watchdog from reaching its timeout condition.

A watchdog is more useful when the mechanism that detects a software failure has sufficient independence from the software path being monitored. The level of independence required depends on the ECU safety concept and hardware architecture.

Watchdog monitoring is one element of a broader functional-safety architecture. It does not prove that all ECU software is correct. The safety design defines what faults need detection, how quickly they need detection and what reaction follows detection.

In an AUTOSAR Classic ECU, watchdog functionality typically involves configured basic software components and the microcontroller watchdog hardware. The exact module configuration depends on the project and supplier implementation.

An RTOS provides task scheduling, timing and synchronization. A watchdog strategy needs to verify meaningful execution rather than blindly refreshing the watchdog from a high-frequency task.

A simplified example shows the basic idea. Real automotive software often uses a dedicated watchdog driver, supervisor or operating-system mechanism rather than directly accessing registers from application code.

void MainTask(void)
{
    read_sensors();

    execute_control_logic();

    update_outputs();

    if (software_supervision_ok())
    {
        watchdog_service();
    }
}

A watchdog timer provides an important hardware-assisted mechanism for detecting selected software execution failures inside an automotive ECU. The core operation is simple: software follows the required execution path, supervision confirms healthy operation and the watchdog receives a valid service operation.

When software stops progressing or violates the configured watchdog timing, the hardware detects the fault and triggers the defined reaction. In many systems, this reaction is an MCU reset followed by startup and fault analysis.

For automotive engineers, the important part is the complete chain: software supervision, watchdog configuration, timing, hardware response, reset-cause information, fault injection and recovery verification.