By: Allan Evora & Adam Baker
Too much SCADA alarm noise means operator apathy and missed critical alarms.
Design of alarm handling is not as high of a priority as it should be in SCADA. There is a big emphasis on points (how we integrate them, how we historize them), but insufficient attention is paid to alarm handling design.
Most of the time, alarm specifications aren’t detailed out for the designer. Alarm design criteria such as classification (alarm or event), prioritization, grouping, message formatting, and routing get little to no attention, which leads to inefficient operation and maintenance of equipment and facility.
In this three-part series, we’ll be exploring the misconceptions and mistakes made when designing SCADA alarm handling systems. We will also be discussing our recommended best practices.
Alarms vs. Events
There’s a big difference between an alarm and an event in your SCADA system. There are many different actions and data points you need to keep track of, but not all require operator corrective actions to keep things under control and running.
Whether it’s explicit (contact closure on a piece of equipment) or implicit (software determining that a value is out of acceptable range), “alarm” classification should only be used for actionable conditions.
For example, an operator can’t do anything if a solar plant’s ambient temperature is >40C, so why classify this as an alarm? (It’s probably a good idea to log that data as an event, however.)
You can resolve a blown fuse in a panel, so that should be an alarm.
Other examples of alarms include:
- Motor tripped
- Inverter fault
- Circuit breaker tripped
- Battery low
- Leak detected
- Filter high differential pressure
An event is any other piece of data you might want to know, but doesn’t have an action associated with it. You might report on this data for maintenance purposes.
- Ambient air temperature high
- Motor started
- Inverter stopped
- Circuit breaker open
- High grid frequency
- UPS battery discharging
If events shouldn’t be alarmed on…then where should they go? Events should be stored in your historian. If someone needs event information, they can access and extract pertinent data in a report.
Alarm + Event
Something can be both an event and an alarm, depending on scenario.
For example, some solar farms house inverters in shelters. Often there is a “door open” alarm on each shelter. If maintenance personnel went into a dozen shelters on any given day, an event would generate each time the door they came and left.
During the day, the “door open” action is an event. But after normal business hours, it switches to an alarm because nobody should be at the site during non-business hours. The point is, a condition can be imposed on a point to eliminate nuisance alarms.
The problem with confusing events vs. alarms is operator alarm apathy. Because hundreds of events (which require no action) can occur each day for every one critical alarm, there’s too much noise in the system for alarms to be meaningful. Eventually, a mission-critical alarm will get buried. This is a problem in both traditional SCADA systems using control room continuous HMI monitoring, and remote notification type systems. This can be even more problematic when you have a system condition that cascades and results in a “flood” of generated alarms.
Just think of how annoying junk or promotional emails are. You just start ignoring them after a while, or automatically deleting them without really looking at the contents. It’s the same with SCADA alarms that are incorrectly classified, prioritized or grouped.
Connecting Alarms to Other Systems
In today’s world, a SCADA system is not an island. It’s part of a larger enterprise system that can involve work order management and CMMS’. Differentiating between an action and event when connecting alarms to other systems is extremely important.
If your SCADA system is creating alarms that aren’t actionable, you’re creating extra work for yourself because you’re generating work orders for something that doesn’t have an action.
Why Are So Many Events Classified as Alarms?
Put simply, events are classified as alarms due to a designer/operator disconnect. Most SCADA integrators don’t fully understand or take the time to understand the system or client’s needs. This usually means events are underutilized and most everything is categorized as an alarm. Most likely no one will lose their job if they classify what should be an event as an alarm; however, if you mistakenly classify what should be an alarm as an event, it could spell disaster.
When you don’t design and implement your alarm handling systems properly, you run a much greater risk of missing crucial alarms.
Stay tuned for Smart SCADA Alarm Management Part 2: The Importance of Prioritizing Alarms and Groups and Smart SCADA Alarm Management Part 3: Best Practices.
Allan D. Evora is a leading expert in control systems integration and president of Affinity Energy with over 20 years of industry experience working in every capacity of the power automation project life cycle. With a background at Boeing Company and General Electric, Allan made the decision to establish Affinity Energy in 2002. Allan is an alumnus of Syracuse University with a B.S. in Aerospace Engineering, graduate of the NC State Energy Management program, and qualified as a Certified Measurement & Verification Professional (CMVP).
Throughout his career, Allan has demonstrated his passion for providing solutions. In 1990, he developed FIRST (Fast InfraRed Signature Technique), a preliminary design software tool used to rapidly assess rotary craft infrared signatures. In 2008, Allan was the driving force behind the development of Affinity Energy's Utilitrend; a commercially available, cloud-based utility resource trending, tracking, and reporting software.
Allan has been instrumental on large scale integration projects for utilities, universities, airports, financial institutions, medical campus utility plants, and manufacturing corporations, and has worked with SCADA systems since the early ‘90s. A passion for data acquisition, specialty networks, and custom software drives him to incorporate openness, simplicity, and integrity into every design in which he is involved.
Adam Baker is Senior Sales Executive at Affinity Energy with responsibility for providing subject matter expertise in utility-scale solar plant controls, instrumentation, and data acquisition. With 23 years of experience in automation and control, Adam’s previous companies include Rockwell Automation (Allen-Bradley), First Solar, DEPCOM Power, and GE Fanuc Automation.
Adam was instrumental in the development and deployment of three of the largest PV solar power plants in the United States, including 550 MW Topaz Solar in California, 290 MW Agua Caliente Solar in Arizona, and 550 MW Desert Sunlight in the Mojave Desert.
After a 6-year stint in controls design and architecture for the PV solar market, Adam joined Affinity Energy in 2016 and returned to sales leadership, where he has spent most of his career. Adam has a B.S. in Electrical Engineering from the University of Massachusetts, and has been active in environmental and good food movements for several years.