LabVIEW Real-Time Watchdog Timer Overview

Overview

The watchdog timer available in LabVIEW Real-Time Module is a tool to ensure stability and reliability of your real-time system. 
 

Software required to utilize these functions is LabVIEW and LabVIEW Real-Time Module. Note that there is also a watchdog that is available on the FPGA that functions similarly, but this document will focus on the Real-Time watchdog timer. 

Contents

What is a Watchdog Timer?

When designing embedded systems, stability and reliability are key. Watchdog timers are a useful tool that can watch your application and take over in case of an error condition in the program. The watchdog timer is a hardware timer that interfaces with the embedded application that can detect and respond to software failures.  

Watchdog timers work by constantly resetting a hardware timer from your application. If the hardware timer ever expires, it will cause a set of predetermined actions to take place. This functionality is shown in Figures 1 and 2 below:

Figure 1. Normal System Operation

 

Figure 2. Watchdog Functionality During Application Hang

 

Potential causes for the watchdog timer to not be reset are a crash or hang in your program. If the loop that contains the watchdog is being starved for processor time by another process, it won’t be able to reset the hardware timer. This will cause the timer to expire and trigger the pre-determined fail-safe condition to occur. 

 

Why Should I Use It?

Embedded systems typically require lengthy amounts of uptime and reliability. Imagine a real-time system deployed in a difficult to access location on an oil rig. The system measures vibration and temperature readings and communicates the data over the network back to a host PC. If the system becomes unresponsive over the network due to a crash or hang in the software, the only way to recover it is to physically access it and manually reset or power cycle the chassis. The controller may take a long time to access and reset, losing a lot of data. With the watchdog enabled, the system can recover automatically when the error occurs with only a short delay in the data lost and the uptime of your system.

 

How Can I Use It?

Figure 3. LabVIEW RT Watchdog Palette

 

The LabVIEW Real-Time module includes a palette that contains the watchdog VIs. This is the palette used to configure and reset the watchdog timer. The VIs that are contained in this palette are the following:

  • Watchdog Configure VI

Watchdog Configure is called at the beginning of your application to define the timeout of the timer and the actions that will be taken when the timer expires.

  • Watchdog Whack VI

Watchdog Whack is used to reset the timer. This will be called in a while loop in your application to periodically reset the hardware timer. If this VI doesn’t get called again within the timeout value passed to the Watchdog Configure VI, the configured actions will occur.

  • Watchdog Clear VI

The Watchdog Clear VI is called at the close of your application and resets the watchdog hardware and closes the watchdog session.

  • Advanced Watchdog Palette

The Advanced Watchdog palette contains the building blocks that the other VIs are made of. These don’t need to be explicitly used in most circumstances but would be if your application requires more intricate interaction with the watchdog timer.

 

An example of how to use the watchdog timer is included in the LabVIEW Real-Time Module in the example finder under Toolkits and Modules >> Real-Time >> General >> Watchdog – RT Engine.lvproj.

A standard LabVIEW Real-Time application is divided into deterministic and non-deterministic tasks. It’s suggested to have your watchdog configured and interacted with in a non-deterministic task. If the watchdog VIs are included in a deterministic task, they can cause jitter and impact the performance of your application. Another consideration is to interact with the watchdog in a low priority task. Imagine a system in which the highest priority task is taking too much time to run and starving all the lower priority tasks, preventing them from running. If the watchdog is included in that high priority task, the timer will be continually reset as expected, and the system won’t realize it’s in an error state and will continue operating in that incorrect state. The best practice in this scenario is to ensure that your watchdog VIs are being called from a low priority task to ensure that the watchdog will catch any process starvation in the application.

 

What are my Configuration Options?

With the Watchdog Configure VI, there are a variety of actions that can be configured to be taken when the watchdog timer expires. Figure 4 shows the different configurable options that the watchdog timer offers. The full explanation on each option can be found in the LabVIEW help. The options for actions are a reboot of the controller, restart of the LabVIEW code, generating an occurrence within LabVIEW, and triggering a PXI line. Check the manual for your specific PXI/PXIe controller to see what trigger lines are available for use.

Figure 4. LabVIEW Real-Time Watchdog Configuration Options

 

When selecting a timeout value for your watchdog timer, you must take various considerations into account. The appropriate range of timeout values depends on the specific performance characteristics and uptime 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 uptime requirements. This balance will vary based on your application and is a decision that you must make in the design phase of your embedded application.

 

Using Watchdog Timers in Applications

When integrating a watchdog timer into a larger application, the most important consideration to make is where you are calling the watchdog VIs from. Watchdog VIs should never be called from a deterministic loop. They do not run deterministically, so they may increase the jitter in the high priority loop. An illustration of how to call the watchdog VIs can be found in Figure 5. This is especially important when using newer PXIe controllers, starting with the PXIe-8861. Due to the process by which these controllers interact with the hardware watchdog timer, it can introduce a large amount of jitter if included in deterministic loops. For best performance, include the watchdog timer VIs only in non-deterministic loops.

Figure 5. Example of Deterministic and Non-Deterministic Tasks with Watchdog

 

An example of using the watchdog timer in a more complex application can be found in the template projects in LabVIEW. From the splash page, click Create Project. If you have the Real-Time module installed, an option under Sample Projects will be Real-Time. Select the LabVIEW Real-Time Control sample project. This sample project uses multiple loops to handle different processes. One of these processes is RT Loop - Watchdog.vi. Explore RT Main.vi and RT Loop - Watchdog.vi to see how they interact and work together to keep the application running smoothly, even in the case of a crash or hang.

Was this information helpful?

Yes

No