Watchdog timers sit quietly inside every compliant traffic signal controller, doing nothing most of the time. That inactivity is the point. A watchdog timer is a hardware circuit that expects the controller's software to reset it on a regular, timed heartbeat. If the software hangs, crashes, or enters an infinite loop and fails to reset the timer, the watchdog fires independently and forces the system into a defined safe state. The result is a mechanism that catches software faults the software itself cannot report.
What a watchdog timer actually does
The basic circuit is straightforward. A counter decrements continuously from a preset value toward zero. The controller's main software loop writes a specific value to the watchdog register before the counter reaches zero, resetting the count. This "kicking" of the watchdog must happen within a fixed window, typically between 10 milliseconds and 500 milliseconds depending on the controller design and the applicable standard.
If the kick doesn't arrive in time, the watchdog asserts a reset or interrupt signal. In a traffic signal controller, that signal doesn't simply reboot the processor. It drives the conflict monitor into a fault condition, which removes power from the signal lamp drivers and forces all heads to flash or go dark, depending on the configured fail-safe output. No software running on the failed processor is involved in that final step. The hardware does it unconditionally.
This separation matters. A software-only timeout check can't trigger if the software has stopped. The watchdog's independence from the main CPU is what gives it value. Many modern signal controllers use a dedicated microcontroller or programmable logic device to host the watchdog function, physically separated from the main application processor.
Windowed watchdogs vs simple watchdogs
Older designs used a simple watchdog: kick it any time before the timeout, and you're fine. That approach has a flaw. Software that enters a tight loop can kick the watchdog repeatedly at high speed, satisfying the timer even though normal execution has broken down. A windowed watchdog closes that gap.
In a windowed design, the kick must arrive within a defined time window. Kick too early, and the watchdog treats that as a fault. Kick too late, and it fires the same as a simple watchdog. The software must kick the watchdog at approximately the right time in every cycle, which means a runaway tight loop or a timing anomaly both get caught. Most controllers deployed under Australian standards now use windowed implementations for this reason.
How watchdogs interact with conflict monitoring
The watchdog timer and the conflict monitor are distinct functions, but they're tightly coupled in practice. Conflict monitoring in traffic signal systems checks that signal phase outputs don't simultaneously authorise conflicting movements, such as opposing vehicle through phases or a pedestrian phase overlapping with a turning vehicle phase. The conflict monitor operates as hardware logic, not software.
When a watchdog fires, the safe-state output it asserts is typically the same signal that a conflict monitor fault would assert. Both conditions route through the same hardware interlock that cuts lamp drive power. This means the fail-safe response is consistent regardless of whether the fault originated in software timing, a processor hang, or a detected signal conflict. From a maintenance perspective, the fault log in the controller distinguishes the two causes, but the intersection behaviour at the moment of fault is the same.
This architecture directly supports fail-safe design in traffic signal systems, where every credible fault mode must resolve to a known safe output rather than an indeterminate one. The watchdog is one of the mechanisms that enforces that requirement at the hardware level, independent of software state.
Configuring watchdog timeout values
Selecting the timeout window involves a real trade-off. Set it too short, and legitimate software tasks such as communication polling, logging operations, or phase calculation may occasionally take longer than the window allows, causing spurious watchdog trips. Set it too long, and the controller runs with degraded signal outputs for an extended period before the watchdog intervenes.
Most Australian traffic signal controllers are configured with watchdog timeouts in the 100–250 millisecond range for the main processor watchdog, with a secondary watchdog on communication or I/O processors set at a different interval. The specific values must be validated against the worst-case execution time of the software's main loop under maximum load, including logging bursts and communication spikes. That analysis is typically done by the controller manufacturer and recorded in the type approval documentation held by the relevant state transport authority.
Field configuration of watchdog values is usually protected by access controls and forms part of the controller's certified parameter set. Changing the timeout without re-validating the software timing analysis invalidates the type approval, which has direct implications for liability after any fault event.
Watchdog events in maintenance practice
A watchdog trip recorded in the controller's fault log is a signal that demands investigation. It isn't a normal operating event. Isolated single watchdog trips can result from transient power glitches that affect the processor faster than the power monitor detects them. Repeated watchdog trips, or watchdog trips clustering around a specific time of day or traffic condition, indicate a software fault, a hardware degradation, or a thermal issue affecting processor performance.
Maintenance teams should treat a watchdog trip log entry the same way they'd treat a conflict monitor fault record: as a reportable event that requires a root cause check before the controller is returned to unsupervised operation. The fact that the intersection resumed normal operation after the watchdog-triggered restart doesn't mean the underlying fault is gone. It may mean the software successfully initialised from a clean state and the fault condition hasn't yet recurred.
Correlating watchdog trip timestamps with cabinet temperature logs, supply voltage records, and software version history is the practical starting point for any investigation. Controllers that log internal processor load metrics make that correlation significantly faster.
Watchdogs in newer and adaptive signal systems
Adaptive signal control architectures introduce additional watchdog considerations. A controller running adaptive algorithms has a more variable main loop execution time than one running fixed-time plans, because the optimisation calculations for live traffic conditions take longer than simple plan lookup. The watchdog timeout must accommodate that variability without being set so wide that it's ineffective.
Some deployments address this by structuring the software so that time-critical output functions and safety checks run in a dedicated real-time thread that kicks the watchdog, while the adaptive calculation runs in a lower-priority thread that cannot delay the kick. This architectural approach keeps the safety-critical path predictable and fast regardless of what the optimisation engine is computing.
As traffic signal systems take on more connected data inputs from vehicle detection, V2X feeds, and network management platforms, the software complexity increases and the importance of a well-configured watchdog increases with it. The watchdog doesn't care how sophisticated the system has become. It only cares whether the kick arrived on time.