Protect Yourself from Unseen RTU Failures with Keep-Alive Pings

Remote monitoring is a surefire way to make sure that the equipment you have at your unmanned sites is in good, working, order. It reduces truck rolls, saves you time and money, and can even extend the life of your equipment.

But, there is a piece to this puzzle that is easy to overlook. Its not enough to just have monitoring equipment at your site. Your equipment sends alarms to your RTUs or manager when something goes wrong. But what happens when your equipment is down and unable to send an alarm? To your RTU or manager, a downed unit and a unit with no alarms look virtually the same.

A device that does not return a ping to the manager
is considered offline, causing the manager to trigger an alarm."

How to detect when an RTU has failed

You can't only wait for asynchronous alarm messages from your RTU. If it fails, you might just be waiting forever. You to send some kind of proactive request from your manager and listen for a response. This can take a few different forms:

1. ICMP Ping
2. SNMP "Ping" (GET)
3. Polled protocol (ex. DCP)

With any of these methods, the logic is the same. After some number of failed pings (usually 3-5), your master will generate an alarm telling you that the device is offline. But how do you choose one of these methods?

How to choose a ping/poll type:

You could use a typical ICMP ping. That's an IP-based signal sent from one device to another. If the target device receives the "ping" from the source device, it will (if configured to do so) respond to confirm that it is active and connected to the network. It's a nice, simple way of confirming that a device is online.

The problem with ICMP pings is that they operate on a fairly superficial layer. If you've worked with IP networks for a while, you've surely run across a situation where a device is "frozen" but can still respond to pings. In cases like this, a simple ping just isn't complex enough to be a good test of actual device status.

SNMP devices in your network support a more reliable ping method based on GET requests. As you'll recall, an SNMP GET message is sent by the manager to a device to request a specific value. If you want to know the temperature reading at a remote site right now, your manager will send a GET request to the local SNMP RTU to demand the sensor value.

What you need is a monitoring device that doesn't just wait for alarms, but instead requests status updates from your gear. An "SNMP ping" is a method of achieving "heartbeat" or "keep-alive" functionality with SNMP communications.

A smart SNMP RTU or manager can take advantage of the call-and-response GET mechanic to send a kind of "SNMP ping". On a automated schedule (one every 3 minutes, for example), your device will send an SNMP GET to the device. If the device responds, all is well. If no response is received after a few successive requests, your manager can conclude that the device is offline and an alarm must be reported.

It may not be realistic for you if you already have an extensive collection of SNMP RTUs, but you can choose a polled protocol like DCP if you're starting from scratch. A polled protocol has keep-alive functional baked in, because RTUs do not send asynchronous messages at all. Instead, the master asks the RTU for alarms every few seconds.

Don't ignore the value of NC ("Normally Closed") alarm wiring

The same keep-alive principal works at a smaller scale when you're wiring your alarms to your RTU. You should always favor NC alarm wiring when possible. That way, a broken wire opens the circuit and triggers an alarm. With NO wiring ("Normally Open"), a broken wire will appear to be "ALL CLEAR" forever.

Call DPS at 1-800-693-0351 to discuss equipment that includes the SNMP ping function.