Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat TodayAsynchronous transmission of data is when information is transported and sent to your RTU at irregular periods of time. Different from the polled transmission, asynchronous messages are sent only when some kind of issue needs to be reported.
The silence coming from managed devices means that everything is running smoothly. So, the problem with asynchronous transmission is that if a managed device fails or loses connectivity, your manager will not be able to know that something is wrong.
SNMP is one of the most common asynchronous protocols at remote monitoring systems. And, if you have to work with this protocol, it's critical that you know how to efficiently manage its asynchronous messages.
By making sure that your SNMP manager is able to always check the status of your RTU and remote devices, you can ensure that any important information is being delivered. So, let's explore how this can be done.
There are two ways that monitoring information can be sent from an RTU to a master station: asynchronous protocols and polled protocols. Let's take a look at the advantages and disadvantages of both methods.
Asynchronous protocols let the master station know about problems at the moment they occur. When you don't have to wait for the master to poll all the devices to get to the one that needs to report an issue, you learn about it in a timely manner.
Asynchronous alerts are sent only an error is detected. This eliminates the need to transfer status information to simply notify you that the monitoring system is still operating, which greatly improves network traffic efficiency.
If both your commercial power supply and backup fail, or if your monitoring system simply goes offline, then alerts will not be delivered at all. Keep in mind that failing equipment and network can't let you know that they are failing.
SNMP, for example, as an asynchronous protocol only sends messages when something must be reported, so there's no automatic way to know if a device is still online.
Whenever network systems generate and send asynchronous alerts, there's a potential to overburden your master station with notifications - which can cause you to miss important information.
Although over-informing may seem like less of a problem than under-informing, there's a high risk that the time to detect and react to a problem would be negatively impacted when you have a high flow of information coming in.
When the flow of notification is fully asynchronous, there's a risk of an excess of alerts being delivered, even the ones that don't represent issues (these are called nuisance alarms). This not only bombards your techs with alert messages but also saturates your network bandwidth with incoming notifications.
A master station that polls information from managed devices can usually promptly detect any equipment or network failures. If the RTU doesn't respond to a request from the master, then you might have a problem on your hands.
If your master is relying on RTUs to let it know that there's an issue, then you might assume that your faulty system is good since it didn't hear anything from the RTUs. For example if, for some reason, alerts are not reaching the destination or the managed system is unable to create an alert.
Having to poll a large number of MIB files per equipment on many different devices is a real problem. Due to this, the SNMP manager will have a long way to go before it can poll all the devices in your network. If a device fails right after being polled, there will be a long delay before it will be polled again and you can learn about the failure and be able to do something about it.
Polling many MIB files on multiple different devices also increases the amount of network traffic flowing across your network. This makes the polling process slower and your response time to a problem delayed as well.
Now that you know the pros and cons of asynchronous protocols, it's important to know how you can make sure your SNMP monitoring system is always efficient. There are some tactics you can put into place to ensure you are getting vital information in a timely manner.
A ping alarm is a signal sent from the master station to the RTU. When you want to verify that a unit is still operational, then your master sends out a ping. Just like a game of ping-pong, the RTU will send back the pong notifying you that it is functioning properly.
If you don't get an answer from the RTU, then either the request was lost or the unit is down, so you need to take corrective actions to fix the problems.
Usually, a ping is simply a manual test that you have to set up every time you need to check on the status of your RTUs. However, this feature can be automated - which is then called a ping alarm.
A ping alarm is an automatic alert sent to your master station when one of your connected devices don't respond to successive pings.
Efficient alarm monitoring equipment can be set up to send scheduled pings to a large number of devices every couple of minutes. This ensures that all your equipment is operational as it should be. If you don't get any response from a particular gear, then it is probably down and this needs to be addressed. This means that the device might need to be power cycled, it might need new cables, or it might even need to be totally replaced.
An SNNP ping is a way of receiving a heartbeat (also called keep-alive functionality) from your SNMP-enabled devices.
The SNMP devices support a ping method based on GET requests. GET messages are sent by the manager to a device in order to request a specific value. If you want to know the temperature at a remote site, for example, then your manager will send a GET request to your RTU asking for the sensor value.
This way you won't have to wait for alarms from your managed devices because if there's an issue with them, you might not get alarms at all.
Efficient SNMP managers leverage the call-and-response GET process to send an SNMP ping. You can set an automated schedule for your manager to send an SNMP GET to the device - this can be done every 5 minutes for example.
If the device responds, then it is functioning as expected. If you don't get any kind of response after a number of successive requests, then your SNMP manager will send an alarm to notify you that that device is offline.
With GET requests, you can also get a complete update of all your devices' status. Your SNMP manager will ask for information with a GET message, then the managed device will reply with a GET-RESPONSE. If you only need the data sent from the managed device then you're all set, but if you need more information then you have your manager send a GET-NEXT message. You can send GET-NEXT messages as many times as you want until you get a complete status update.
If your device fails to respond to a number of pings sent from your manager, then a ping alarm is sent to you or your techs to alert about a device failure or, at least, loss of connectivity.
After you set up your monitoring system to send pings, you will start receiving notifications of problems for each equipment being pinged. These early alerts allow you to monitor your mission-critical devices much more efficiently than you could without the ping alarm capability.
The ping alarm functionality is an essential method of protection for remote networks.
SNMP GET requests are also an important feature that allows you to work around the SNMP disadvantage of only sending you notifications when something is wrong. GET requests gives you a complete picture of what is going on so you can make the best management decisions.
If you have SNMP-enabled devices deployed, you need to use some techniques to help you ensure the efficiency of this asynchronous protocol. Ping notifications and making sure that your master station is able to periodically check on your managed devices to make sure there's no problem with connectivity are examples of these techniques.
If you want to know about some devices that feature the previous best practices, we have the right information for you. Our team of monitoring experts can help you decide which device will best fit your requirements, and if you have unique needs we can design and build a device especially for you. Contact us today and treat us as if we were your own engineering department.
Morgana Siggins
Morgana Siggins is a marketing writer, content creator, and documentation specialist at DPS Telecom. She has created over 200 blog articles and videos sharing her years of experience in the remote monitoring industry.
