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 TodayMore and more companies are moving to automatic monitoring systems that free operators from looking at screens 24x7. These intelligent monitoring systems allow multiple different industries to have more efficiency - by doing more with fewer resources.
If you have remote sites with mission-critical equipment to maintain, then purchasing a competent network monitoring system is a smart idea. These systems allow you to remotely interact with your devices. They're designed to send notifications when an alarm or faulty condition happens (or is about to happen), allowing you to respond to these conditions before they affect your network.
As a trusted remote monitoring systems manufacturer, we build our devices with best practices for alarm management in mind. Our central master station, the T/Mon LNX, is no exception. Designed and built with powerful alarming features, it will let you acknowledge and react to any event in a timely manner.
Knowing what to expect when purchasing a remote monitoring solution is key to prepare yourself to have full visibility over your network. So, let's dive into T/Mon's alarming features and best practices to get the most out of them.
If you already have or are planning to invest in a T/Mon master station, it's important for you to know exactly how this device can help you manage your remote network. So, let's take a look at some capabilities of the T/Mon.
All alarm conditions require attention. However, some of them are more critical than others. That's why T/Mon master station has an alarm priority scheme.
How you prioritize and sort your alarms is up to your unique scenario, and as you see fit. Most of the times clients sort them out based on safety and then on the potential economic effects.
Imagine, for example, that you are responsible for managing a medical campus central energy plant. If the batteries for your backup power supply is low, then that's considered a high priority alarm. This is because if commercial power fails and you don't have a backup power supply, then this will be a huge safety issue for patients in this medical facility.
In order to keep higher priority alarms well visible and on top of your mind, T/Mon's graphical interface (the GFX) will give you important alarm handling capabilities. You can configure it to display your remote sites in a map, and you can drill down to images of your devices in a rack. So, when an alarm happens, points in your map will blink and the image of your rack will show you exactly where the problem is.
Your alarms can be color-coded to indicate severity, so when a change of condition happens the point in your map will blink in a determined color according to what you've set. This way, you can quickly see what your highest priority and critical alarms are.
Derived alarms (also called soft alarms) are alarms created through user-defined formulas that coordinate inputs from many alarm points and apply logical operators to them. In other words, derived alarms are alarms created used software logic.
One example of derived alarm logic is the combination of a low battery plus a broken generator. Either condition might not be considered a critical alarm if happens by itself, but together they are a high priority alarm.
Derived alarms are very beneficial because they allow you to keep an eye on different combinations of scenarios. You don't have to manually scan your monitoring screens to find out what's going on in your network. If you configure your derived alarms, your T/Mon will know what to look for and it will keep track of these events for you.
Similar to derived alarms, derived controls will apply a set of rules to incoming events in order to control complex automatic responses to problems. With this feature, complex and intelligent responses to emergencies can be completely automated.
There are two types of derived controls:
Filtering nuisance alarms are a very important but underutilized tool in many remote monitoring systems. Common scenarios where nuisance alarm management can be useful include:
Scenarios like these could result in recurring alarms that an operator can't fix. The T/Mon gives you the ability to suppress alarms either proactively or according to a specific condition, which reduces the number of nuisance alarms in your system. This ultimately means less frustration for your team and minimized risks of missing real alarms.
Since, most likely, not everyone in your company is trained to deal with your remote monitoring systems, it doesn't make sense to notify everybody when an alarm happens. T/Mon allows notifications to be sent to the specific team that can provide the corrective action to fix the condition that created the alarm.
T/Mon has the ability to send notifications through text messages, email, or even phone calls. So each specific group can be reached at any time of the day (depending on how severe the alarm is) and can react in a timely manner.
For example, if your generator fails to start when the commercial power goes down, then it will determine the technician on duty and send him an alert. If the event happens after hours, then you can tell T/Mon to send a text or phone call to the on-call tech.
Also, in the T/Mon, you can configure escalation lists of technicians that will receive notification alerts. So, if T/Mon doesn't receive a response or there's no acknowledgment of the alarm condition after a set period of time, then it will send a notification to the next technician in the list and so on - until someone recognizes the alarm.
As an effective tool to keep remote equipment and processes running effectively, reliably, and safely, the T/Mon has the alarm prioritization, derived alarms and controls, nuisance alarm filtering and escalation lists capabilities.
Having a central master station that has efficient alarming features is a great first step to full visibility over your remote sites. However, you need to know how to use them and learn important best practices when handling your network's alarm notifications.
Whether you are using T/Mon or not, here are some best practices to keep in mind:
A common (and bad) practice that many network operators end up doing is to acknowledge all alarms when there's a large flood of notifications coming in. Instead of looking at each alarm individually, they end up hitting the "acknowledge all" button.
It's important to avoid doing this because you might miss a high priority alarm that is buried within this long list of other alarms.
One way to handle this is making sure your alarm management system is able to filter and sort alarms for you. This can be done by having different screens for each type of alarm priority or even disabling the acknowledge all feature for critical alarms.
For remote monitoring systems, events not always will be the same thing as alarms.
Alarms are conditions that need actionable actions, such as high-temperature notification or device failure. Events, on the other hand, are relevant pieces of information that don't ask for corrective actions, such as ambient air temperature within thresholds. Usually, events are still stored for later analysis and for maintenance purposes.
Most often than not, hundreds of events can happen every day for each critical alarm. And, the more notifications for events your remote monitoring systems send you, the more apathetic you and your team will become.
So, if you don't disable notification for events (or configure nuisance alarm filtering), there will be way too many alerts requiring your attention. This usually increases the chances of you missing an important notification.
As I've said before, technicians should only be notified of alarms on a "need to know" basis. Keep in mind that receiving alerts about equipment or processes that you have no responsibility for is a fast way to create apathy towards alarm notifications coming in.
There's no need to send out notifications to all maintenance staff if determined people are trained to only deal with certain types of alerts. This is distracting, inefficient, and can possibly be a threat to your network as it can result in missed critical alarms if there are too many nuisance alerts.
Organizing your team and your network is fundamental to defining alarm groups. Are there conditions that need to be sent to anyone other than technicians? If an alarm happens outside of normal business hours, who will be on call in which days?
The escalation feature I've talked about goes hand-in-hand with organizing your alarm notifications. If a designated person doesn't acknowledge an alert within a set period of time, then the alert gets escalated to a higher-level team in your company to ensure the problem will be dealt with.
Each technician in your team should take responsibility for their actions (or lack of action) regarding the acknowledgment and reaction to alarms.
Many companies became our clients after they missed a critical alarm in their old remote monitoring system that didn't have the capability of setting up individual login credentials for each tech. We hear way too many horror stories where a high priority alarm was missed and the tech responsible for it was never identified.
Our master station follows the industry's best practice of ensuring technician responsibility through individual, unique user logins that require strong passwords. You won't use a generic user ID for everybody in your team.
In addition, T/Mon logs and stores all alerts and the associated actions made by each determined tech. This way, you can see who is acknowledging an alarm, who sent out control commands, or even who is opening and closing the doors at your remote sites.
All actionable conditions in your network require attention, but some of them will need more attention than others. A common (but dangerous) situation is when a high priority alert is pushed down the list of alarms in your master station by lower priority conditions.
If you are not careful, as you work from the top to the bottom of the list, the critical alarm might be left unattended for hours.
In order to efficiently take care of network alerts, your remote monitoring system needs an alarm priority setting. This way, you can prioritize your alarms based on network safety, and then on potential economic effects.
Your alarm master station should feature not only a user-friendly interface with priority alarm configuration. Also, it should display graphical representations of your remote sites and color-coded alerts to bring your team's attention to what's going on with your network.
Unfortunately, not every remote monitoring system is made the same. Not every central master station will be able to give the visibility features you need for a more efficient network. Poorly designed and built monitoring devices will put your remote sites at risk and affect your revenue.
We've been manufacturing remote monitoring solutions for more than 30 years, so we understand how important the visibility over your network is for your bottom line. That's why our goal is to custom design remote monitoring devices that will make your life easier.
All of our products - RTUs, the T/Mon LNX, and etc - can be custom modified to attend all your requirements while still having powerful alarm handling features to protect your network at all times. Talk to us today and tell us what you need.
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.
