There's an old saying you're probably familiar with: 'you have to walk before you can run.' Or maybe it isn't an old saying, maybe it's something you saw printed on vintage stock. Either way, it is certainly true. It's true in life, and it's true when setting up a system to monitor your remote stations.
That's why, before you start running your monitoring network, you should take an SNMPWalk.
An SNMPWalk is how you get a list of everything in your SNMP-protocol network that might be queried, and how you test the effectiveness of each agent's response.
In short, it's how you make sure things work. You can do this before you use your SNMP system in real scenarios, and you can do this to troubleshoot if anything goes wrong.
The SNMPWalk is more than walking around the car kicking tires: it's doing a full-scale test of every situation, every condition, and every sudden stop your equipment might take. It's a full picture of how your SNMP devices communicate information. It's a walk that enables you to run.
To start with, it's important to understand what SNMP means. Simple Network Management Protocol - or "SNMP" - is a protocol two computers use to communicate with each other. It's the language in which packets of information are sent back and forth.
Your SNMP-based monitoring system is made up of multiple devices, including a network of RTUs and master stations. All of these are addressed by their Object Identifier (OID). The OID is a long string of numbers that incorporate SNMP, the manufacturer, and other information.
The whole system is set up for these devices to talk to each other. They talk to each other using 5 different types of information.
(Note: an "SNMP manager" is essentially the central master server; an agent is the RTU or other remote device.)
How does this work in practice? Well, let's pretend that OIDs for a system are 1.1 and 1.2 (in real life, they are each much longer, but we can simplify). 1.1 and 1.2 are both unique items within single SNMP agents. They both represent individual discrete inputs on a remote monitoring device.
The master might send a 'GET' message to 1.1 to find out how things are going, and when it finds out that temperatures are climbing a little high (1.1 is a temperature reading), will send a 'GET-Next' message. 1.2 sends back that the battery is drained more than usual (1.2 is a battery voltage). Now, we're beginning to get a clear picture of an overworked system.
It's possible that the master can send a 'SET' message to slow down a turbine which is overworking and raising the temperature. That way, without anyone getting involved, your system solved a problem.
Easy, right? That's the way it should run. But it only does so if you take the time to do an SNMPWalk initially.
Before you install your system, you need to do a full evaluation of everything that needs to be monitored. You have to know how many RTU points you'll need. Then, when you're installing, you must test all of your RTUs.
An SNMPWalk helps you obtain a full (or partial) list of variables. This will show you what your system is capable of reporting and help you build the logic around its parameters. It will help you determine how to set up which messages, and how they should be sent.
In doing this, you will set up a library of MIBs. A Management Information Base is a file that tells the manager what information one agent can (and cannot) send and receive. In our example above, 1.1 and 1.2 could send information about their stations, but they probably can't receive a 'SET' message. They don't control that.
So, the MIB and a verifying SNMPWalk help you determine all the logic of your SNMP network. Your master knows that if it gets a 'Trap' notification from 1.1, it needs to send a 'GET' message to 1.2. If that 'GET-Response' comes out looking bad, it can send a 'SET' message to 1.3 to take action. That's for you and your partner to program. But you won't know that without an SNMPWalk leading to a library of MIBs.
Of course. If something went wrong during your install, an SNMPWalk can help you find the glitch. An SNMPWalk and RTU troubleshooting can help you understand where there is a miscommunication or a disconnection, and you can adjust the logic with what you have learned. This way, your devices will communicate effectively.
The biggest fear for any remote equipment failure is leading to a shutdown. That means money is lost, manpower hours are eaten up, and probably resulting in angry customers. It might mean regulatory fines and even lawsuits. It could even mean lost lives.
So, you want to keep your devices working effectively, and that means having a monitoring system that works throughout your system. That means having your masters and agents be able to communicate. And, that will require an SNMPWalk to be able to fully set the parameters of communication.
This is complicated, which is why you want a partner who can help you during installation and implementation. After all, no one learns to walk on their own. The right partner can get you- - and keep you- - up and running.
DPS Telecom has the experience and expertise to help companies monitor what matters most - including working with SNMP. Our technicians can work help you with SNMP troubleshooting and ensuring you have the best equipment. Reach out and get a quote today!
Image courtesy Shutterstock