Using a Hardware or Software Watchdog in a Real-Time Application

In real-time applications, deterministically responding to failures or system events is sometimes necessary. If a critical component of a motion control system fails, keeping the motor running might risk the safety of both the equipment and operators. While shutting down the equipment as quickly as possible might be the best solution, not every failure needs to be handled in this manner. When a network connection between an embedded data-logging application and a host machine fails, it is possible to continue running the real-time application and log to a disk until the network connection is reestablished.

This document discusses inactivity watchdogs and network watchdogs. Watchdogs are utilities that monitor for specific system events and failures. These utilities can be either software or hardware, where available. The watchdog waits until a specific event occurs and executes a preconfigured action. There are two implementations of the watchdog, the inactivity watchdog and the network watchdog. The inactivity watchdog uses a continuously incrementing counter. When this counter reaches some terminal count, it executes the expiration action. The network watchdog checks the system for network disturbances and responds to a connection failure.

Inactivity Watchdog

Several PXI controllers have hardware watchdogs that can be configured programmatically to respond to system inactivity. The PXI Hardware Watchdog has a timeout period that you can configure. The watchdog uses a built-in counter to count up to that defined timeout. When the watchdog reaches the terminal count, it executes the predefined expiration action. To prevent the watchdog from timing out, the application can reset the watchdog count. The monitoring of the application is called whacking the dog, which essentially resets the counter/timer on the PXI controller. As long as your application is running, it can reset the count. If your application stops running, the watchdog counts up to its timeout value and then carries out the expiration action. Available expiration actions include setting a trigger, generating an occurrence that another application can respond to, and rebooting the PXI controller. LabVIEW RT ships with an example of the PXI Watchdog. From the LabVIEW dialog box, click the Find Examples button. Click the Browse tab and select the Directory Structure option. The RT Watchdog (PXI).llb is located in the Real-Time directory. You also can find the PXI Watchdog example VI in the LabVIEW 6.1\examples\Real-Time directory.

When hardware capability is unavailable, you can configure a Counter/Timer device to behave like the built-in PXI watchdog counter. You also can toggle a hardware digital line. By monitoring this count value from a separate application, you can respond to inactivity in the necessary way. If you use software watchdogs, inactivity can trigger the following actions: resetting the PXI controller, setting an occurrence in software, and activating a PXI back plane trigger. One example of this solution is using the shared memory on the RT Series DAQ boards. With this solution, you either can shut down the host application when the embedded application becomes inactive, or vice versa.

Network Watchdog

Some RT Series hardware, such as the FP-2000, have a built-in network monitor. If you enable the network watchdog and the FieldPoint Ethernet module loses communication with all hosts or clients over the network, the FieldPoint Ethernet module sets the output channels to predefined values corresponding to the watchdog state. You can configure these watchdogs to output a certain value when a network failure is detected. Refer to the link below for more information about how to use network watchdogs in FP-2000 to guard against network failures.

If no built-in network watchdog is available, you can create one programmatically. For example, if TCP/IP is the communication protocol between the host machine and target applications, you can monitor for network disconnect errors and timeouts. In these situations, you might want to change the behavior of the system. For example, you might want to log to a file until the network connection is reestablished.

While many communication issues occur between the host and the target machine, many real-time applications include one other important communication path. Many real-time applications separate time-critical tasks into a separate VI, and communicate with this thread using specific protocols such as RT FIFOs. You can use the API of the RT FIFOs to detect a failure in this communication path or in one of the participants. For example, you can check if the RT FIFO is unexpectedly empty or if you are overwriting data. Appropriate expiration actions for this kind of failure include shutting down entirely until communication is re-established, providing a kill switch, returning to a known state (home), and continuing as usual. Refer to the link below for more information about RT FIFOs.

See Also:
Guarding Against Network Failures: How to Configure the Network Watchdog Timer for Your FieldPoint Ethernet Module
Real-Time FIFO for Deterministic Data Transfer Between VIs.

Reader Comments | Submit a comment »