SNMP Alarms - Simple Traps Vs. Effective Multi-protocol Alarm Management

SNMP alarms are status messages sent to your SNMP Manager from your from your RTU or agent. There are two groups of alarms that an agent can send to the manager. Discrete alarms can be items such as door alarms, gear alarms and other events that have only two possible states, such as ON/OFF. The discrete alarms are "software reversible" to support both N/O and N/C alarm wiring. The analog inputs are used for tracking vital events with more than two possible states, such as temp and voltage. Each of the alarms can be assigned qualification times so that nuisance alarms can be filtered out.

A manager can receive these alarms in two forms, either by receiving autonomous traps from SNMP devices or by sending a "GET" request. Traps are messages sent by an RTU or agent, usually caused when a change of state (COS) event occurs. A get message is one that is sent from the manager to the RTU requesting status information. These types of requests can be programmed to be collected on a regular schedule rather than in the case of a COS event.

Some SNMP managers poll devices according to a set schedule, retrieving an update of all standing alarms. This can help to bring in SNMP alarms when the matching autonomous trap was not received.

A Basic SNMP Manager Can Only Manage SNMP Alarms.
A basic SNMP manager only works if you only have SNMP alarms and don't need to collect alarms from other protocols. If you try to achieve multi-protocol monitoring with a basic SNMP manager, you'll end up buying additional masters for other protocols. That means more screens to watch, more hiring, more staffing, more training, and more expense.

mib flow chart This diagram shows the movement of alarms triggered by a fault in gear, such as a generator, which is sent to the agent or RTU. The RTU translates the alarm into SNMP and then sends the alarm to the manager.

What you need to do your job well is a multi-protocol master that can bring all of your alarms into one system.

T/Mon Can Interpret SNMP Alarms - and Alarms in Over 25 Other Protocols.
T/Mon, an advanced network management platform, can receive SNMP alarms with an integrated SNMP Trap Processor software module. Unlike standard SNMP managers that can only interpret SNMP alarms, T/Mon can also receive alarm messages from over 25 other protocols, including DCP, TL1, ASCII, and more.

T/Mon Filters Critical Alarms From Unimportant Status Updates.
T/Mon combines all network alarms into one Standing Alarm window, allowing the operator to view all standing SNMP alarms at once.

T/Mon can also group alarms into windows according to user set criteria, such as just vital alarms, or alarms from single equipment types. This prevents critical SNMP alarm messages from being lost in a clutter of routine status updates.

T/Mon Notifies the Right People When a Problem Occurs.
Additional benefits of T/Mon include alarm forwarding and ascending alert. This means that SNMP and other alarm messages can be forwarded according to your personal operator schedule, sending alarms specifically to scheduled operators. SNMP alarms, as well as other alarms, can be programmed to use ascending alert. T/Mon sends alarm messages that are not responded to within a given time frame to higher-level supervisors. This assures all alarms are dealt with in a timely manner and prevents busy supervisors from being bothered by minor alarms that are easily handled by less senior staff.

If You Have an SNMP Manager, T/Mon Can Mediate Alarms to It.
T/Mon has an integrated SNMP Responder software module, allowing it to forward any alarm it collects as an SNMP trap to your SNMP manager. Now, the interface that you and your staff are already familiar with (the one that could only see SNMP alarms before) will have the complete status of your network.

With T/Mon collecting your non-SNMP alarms and forwarding them to your SNMP manager as traps, you won't have to hire a lot of staff to monitor multiple screens. You'll reduce hiring costs, training costs, payroll costs, and costs associated with missing alarms on a lot of systems.

See also:
Trap FAQ