Using Watchdog Hardware to Recover from Embedded Software Failures (Real-Time Module)

LabVIEW 2017 Real-Time Module Help

Edition Date: March 2017

Part Number: 370622R-01

»View Product Info
Download Help (Windows Only)

Many embedded real-time systems need to be self-reliant. It is often impractical to wait for someone to restart an embedded system if a software failure occurs. Therefore, the embedded system itself must be able to detect a failure condition and execute a graceful recovery procedure. To detect and recover from software failures, many embedded systems contain a built-in hardware timer known as a watchdog timer or a dead man's switch. You can use a watchdog timer to ensure that an embedded software process continues to execute normally and to initiate a recovery procedure if the software becomes unresponsive.

Understanding the Hardware-Software Interface

A watchdog timer is a hardware counter that interfaces with the embedded software application to detect and recover from software failures. During normal operation, the software application initiates the hardware timer to count down from a specific number at a known increment and defines the action to take if the timer reaches zero. After the application starts the watchdog timer, it periodically resets the timer to ensure that the timer never reaches zero, as shown in the illustration below:

If a software failure prevents the application from resetting the timer, the timeout eventually expires because the hardware counter is independent of the software and thus continues to count down until it reaches zero. When the watchdog timer expires, the hardware triggers the recovery procedure, as shown in the illustration below:

RT Series PXI, CompactRIO, and Compact FieldPoint controllers contain built-in watchdog timer hardware that you can access using the RT Watchdog VIs. Use the Watchdog Configure VI to set a timeout for the watchdog timer, and to specify the action(s) to perform if the timeout expires. Use the Watchdog Whack VI to periodically reset the counter before the timeout expires.

Note  Because the Real-Time Watchdog VIs depend on the specific hardware features common to RT Series PXI, CompactRIO, and Compact FieldPoint controllers, NI does not recommend using the Real-Time Watchdog VIs to interface with third-party watchdog hardware.

Choosing an Appropriate Timeout Setting

The appropriate range of timeout values depends on the specific performance characteristics and up-time requirements of the embedded application. You must set the timeout long enough so that it does not expire due to acceptable levels of system jitter. However, you must set the timeout short enough so that the system can recover from failure quickly enough to meet system up-time requirements.

Using the Advanced Watchdog VIs

The high-level Watchdog VIs, Watchdog Configure, Watchdog Whack, and Watchdog Clear, are built from the low-level Advanced Watchdog VIs. If you cannot meet your application requirements using the high-level Watchdog VIs, you can use the Advanced Watchdog VIs to implement custom watchdog applications.

Creating Multiple Watchdog Objects

You can create multiple watchdog objects with separate properties using either the Watchdog Configure VI or the Advanced Watchdog VIs. Multiple watchdog objects might be useful for applications that include distinct states of operation with different timing characteristics. For example, if you implement a state machine architecture with states A and B, you can use a watchdog object with a timeout value of 5 seconds in state A and another watchdog object with a timeout value of 10 seconds in state B.

However, because RT targets typically contain only one hardware watchdog timer, you can use only one watchdog object at a time. After using a watchdog object, you must use the Watchdog Clear VI or the Advanced Watchdog VIs to close the current watchdog object before you can use another watchdog object.

WAS THIS ARTICLE HELPFUL?

Not Helpful