Request Info
Alarm Monitoring Tutorial
"Alarm monitoring" is a phrase with multiple definitions. Most consumers think of a company with a 7x24 monitoring center for detecting and responding to home or business burglar alarms. In a telecom and IT context, however, alarm monitoring refers to much more (although it is involved with thieves and vandals, as well).
In an industrial telecom environment (a phone company, utility, railway, etc.), an "alarm" can be generated for a wide variety of reasons. In fact, some so-called "alarms" really aren't anything to worry about. For many companies, the routine act of opening a door will generate a low-severity "status" alarm. This is tracked largely so that a history of door entries will be available after theft or vandalism is detected.
More seriously, alarms can indicate minor equipment errors or hardware failures. These alarms trigger medium-severity "minor" alerts at the alarm monitoring center. Minor alarms frequently require a purposeful, if not emergency response. They are commonly scheduled into a regular maintenance trip to a site so that they do not interfere with daily operations (requiring extra labor time, fuel expense, and truck wear and tear).
The most serious alarms in the alarm monitoring sphere are the "major" and "critical" alarms. These alarms almost always require an immediate response, because the integrity of the network is severely at risk. Major and critical alarms are what keep network managers up at night. A company that is not prepared to deal with critical alarms at the moment they happen has little chance of maintaining its network uptime and continuing to deliver reliable services to its customers.
The severe consequences associated with missing the critical network condition point to the very high - and often underestimated - value of a good alarm monitoring system.
In this diagram, a T/Mon master station is supplying data to one of several Windows(R)-based PCs running T/GFX alarm monitoring software.
What types of gear are most commonly covered by alarm monitoring? They include:
- Telecom/transport systems (switches, routers, SONET, fiber, microwave radios)
- Power supplies (commercial AC power, battery plants, rectifiers, generators, UPS systems
- Building/facility alarms (events that can harm equipment, including intrusion, entry, open door, fire, smoke, flooding)
- Environmental levels (these aren't actually equipment, but are conditions that affect electronic equipment, including temperature & humidity)
The monitoring device architectures commonly used in alarm monitoring applications vary by company size. A very small organization may use just a single device to collect system and environmental alarms at a site and send out alerts via email and/or cell phone (voice or text message). This monitoring method is an excellent choice for small companies because no centralized server is required to collect alarms. Only a small box with a few monitoring inputs is required.
This one-box approach to alarm monitoring can be repeated at a theoretically unlimited number of sites, but it typically becomes rather ungainly and difficult to manage once a company has 10-12 sites. At this point, the concept of a centralized alarm monitoring console becomes far more valuable. Now, all collection and aggregation of alarms will be handled by computers. Only a combined, filtered, and organized list of important alarms will be displays for human operators (although even hidden alarms can still be logged for review later).
Although there are many possible RTU (remote telemetry/terminal unit) boxes to use for stand-alone alarm monitoring applications, here are a few good examples of varying capacities:
The NetGuardian LT is a very small and compact alarm monitoring device when just 1-4 alarms need to be collected. Because LT users probably have many other duties, the LT makes simple automated voice calls to one or more designated phone numbers. Upon receiving a call, a user has the option to acknowledge the alarm, indicating to the device that the alarm is known and will be dealt with.
For medium-sized sites, the NetGuardian 216 provides 16 alarm inputs. Although it can send email or text messages for monitoring similar to the NetGuardian LT, it is more commonly used to send SNMP traps back to a central master console.
For larger sites, the NetGuardian 832A includes 32 alarm inputs (with an option for 64), plus a serial terminal server and an optional network switch. At this capacity level, it is anticipated that almost all deployments will be used with a central alarm master. Still, stand-alone operation remains available on the 832A. It simply made little sense not to include a feature that already existed on other platforms.
A NetGuardian 216 G3 provides medium-capacity alarm monitoring in either stand-alone or central master (SNMP manager) configurations.
The move to a central alarm monitoring master station ("alarm master") also puts a lot more processing power into the monitoring system at a time when it's needed. An alarm monitoring system that's small enough to be monitored with alarm remotes only can be effectively monitored with simple web interfaces that are built into those devices.
Once a company's alarm monitoring needs outgrow this level, however, a more intuitive view is required. A central master console is usually a high-speed computer running highly specialized software. One use for all this power is to display alarms on a geographic map. This makes monitoring alarms much more intuitive, as even briefly trained technicians can literally see where a problem is occurring in a network.
When alarms come flooding in during an emergency (as they do during a natural disaster such as a hurricane), the ability to see which areas of a widespread network are affected is absolutely critical. A geographic map view display supports highly intuitive alarm monitoring, while a text-only view does not.
One example of a geographic map alarm display is T/GFX software. This is a Windows(R)-based software program that connects to a dedicated T/Mon server. Alarms collected by the T/Mon server are associated with graphical icons arranged by latitude & longitude. Icons blink and change color to indicate new alarms of various severities. In a few clicks, a user can "drill down" to the specific piece of equipment that has issued the alarm. Imagine how much easier it is to monitor a big network with simultaneous users moving through zoomable maps.
As you probably already see by now, there is great value for growth-oriented companies to choose alarm remotes (RTUs) that can transition from a stand-alone role to centralized-master reporting. Any RTU that can send out its own alerts (voice messages, text messages, emails, etc.) and also supports an industry-standard open protocol (the most common for alarm monitoring is SNMP) is a good choice.
The #1 Rule of Alarm Monitoring: Do not use "embedded alarm monitoring" options on your equipment. That means that the equipment manufacturer has included alarm monitoring as a "value added" feature. Unfortunately, no matter how good your equipment manufacturer may be at designing alarm monitoring functions, the fatal flaw lies in having core functions and monitoring functions residing on a single device. Imagine a case when your device failed. Now is absolutely the right time to send out a critical "device failure" alarm. Unfortunately, now is the time that it absolutely cannot send an alarm, because it has failed. Don't fall into the trap of using embedded alarm monitoring.
Case Studies of Alarm Monitoring by DPS Telecom Clients
About six months ago, a client called in to DPS with a need for alarm monitoring to keep better tabs on several remote HVAC units. These HVAC units were integrated with three cooling towers and two water pumps. This person need to monitor alarms for several key risks.
If the water level of the site dropped too low, the HVAC units would fail, causing equipment to get hot and shut down. Instead, if the water level rose too high because of a stuck valve, the company could waste a great deal of money sending tons and tons of water right down the drain. Finally, if the pumps failed, HVAC could also be severely impacted.
His two pumps rotated automatically in a 1 week on and 1 week off cycle. During transition, both were running. The alarm monitoring plan was to place a single current sensor and put it on one phase of the power, then do the same for the other pump. The sensors would be configured such that the sensors are closed when current is not flowing. These sensors would then be connected in series, such that if they both are closed they would get an alarm on their NetGuardian RTU. Each phase was 480VAC.
He also wanted to monitor alarms for low water in the towers. Initially, this was using 1 sensor for low flow, so it would be a total of 3 (3 towers). Because "too much water" also need an associated alarm point, 2 sensors were deployed per tower (total of 6 sensors to cover the 3 towers).
Another company needed an alarm monitoring system for a bank with 25 branches nationwide. The primary equipment to be monitored was contained within a single server room at each branch. The single door granting access to each room was very important to monitor, considering the amount of money in the vault that the computers controlled. Although there was value seen in monitoring individual temperatures within each server room using temperature probes, the initial phase of the project was to monitor simple ambient temperature from an on-board RTU's temperature sensor.
|
Request More Info
(simple online form) |
|
Next Page >> most related to this one |
Give Us a Call!
To find out more about this and other DPS applications, give us a call at our toll-free number and talk to one of our network specialists. They'll help you put together a perfect fit solution for your network!
RSS
