I remember it like it was yesterday. I was standing in the control room of one of the biggest life sciences organizations in the world and their central cooling plant had been down for three hours...
And the shocking thing is we all were just finding out about it... Why was this? How could a site that arguably employed some of the most qualified BAS professionals (and paid them handsomely I might add) be three hours behind knowing their central cooling plant was down?
The culprit my friends was out of control alarming. And this problem is very real.
I've been to countless sites that have 20, 30, sometimes even 50 thousand unacknowledged alarms.
It seems that in the world of BAS we are losing the battle against nuance alarms and our solution of highlighting all the alarms and deleting them, hoping that we will be able to keep up this time is similar to how drug addicts and alcoholics try again and again only to fail because they are trying to do the same thing and expecting a different result.
Is that a bit harsh? Did that shock you?
I hope so!
The reality is there is so much time wasted troubleshooting, designing increased capacity, and chasing ghosts in the system! So many of these issues could be resolved if we could simply put a strategy around alarming.
If you've been reading my articles for any amount of time then you know I have no love for plug and play, boilerplate specifications. I realize that they have their place but I also realize that they are notoriously weak and do nothing to help deal with this "alarm fatigue" problem.
What is "alarm fatigue" you ask? Alarm fatigue is where you have so many alarms that you become overwhelmed and simply give up on using the alarms as part of your facility management strategy.
So how can we solve this issue? First, we need to understand the cause of the problem
What causes out of control alarms
In order to solve any problem, you need to get to the root cause. If you don't then you will always be fighting the symptoms of the problem and not the core issue.
Over the years my experience working on projects has shown me that there are three main causes of "alarm fatigue". These are:
- Bad specifications
- No Point standards
- No clear alarm segmentation strategy
Bad specifications
Specifications that simply say "control system shall be alarmed" or the slightly more specific "control system's points shall be alarmed" do nothing to help solve this problem. If anything these specifications are what cause the problem in the first place.
After all, when every alarm has the same level of importance, none of them have importance.
No Point standards
But specifiers can only specify what they have guidance to specify. That's why I am so adamant about the need for BAS standards in my article "BAS Expert shares his 13 tips". When the owner gives absolutely no direction to the design engineer, the design engineer has no choice but to be very broad in his or her design.
No clear alarm segmentation strategy
Even if you do get a list of what points should be alarmed you need to take it one step further to make sure the alarms get to the right person at the right time. Otherwise these alarms will end up being lost in the noise of filter alarms and flappy end-switches.
But as you can imagine, this is also something that is rarely being done!
Resolving these issues
As I mentioned there are three issues that cause alarm fatigue (Bad specifications, No Point standards, and No clear alarm segmentation strategy). But how do you address each issue?
No clear alarm segmentation strategy
As you may have noticed, I flipped the order of the "alarm strategy" issues. This was a very deliberate action.
Before you create point standards and specifications you need to have a strategy for alarm segmentation. If you are new creating an alarm strategy here is what I recommend.
You will need to create three categories. Now each BAS will do this differently. Some BAS will call these categories "priority levels", some will use the term "severity". But regardless of what they are called, you will need to create "buckets" that these alarms go into.
My recommendation is that you create critical, high, and normal. Now you may be wondering why would you not create a "low" level. It's simple rather. If something is a low priority the likelihood of an overworked BAS department getting to the low alarms is about as high as me winning the Powerball.
Now to the levels.
Critical will be for critical alarms (Central plant failures, critical air handler failures) the rule of thumb is if these can affect multiple sub-systems then you should consider them critical.
High will be for alarms that will have a determinantal affect to the system. if you are getting no flow on a VAV box then that is a high alarm.
Normal alarms are for things that indicate failures that will not keep the whole system from working but will significantly degrade the system. An example of this would be no temperature change across a VAV heating coil. This won't keep the VAV box from supplying air but it will keep it from heating the space.
No Point standards
Now that you have a list of priorities you will need to create standards around your points. You will list out what points will be alarmed and at what priority level. You may want to add what department or role the individual alarms get sent to.
Bad specifications
Now things get really easy. If you've gotten to this point all you need to do is to copy the information you created in the previous steps and copy them into the specification. Bada bang, bada boom! There you go!
Conclusion
So there you have it. If you've followed what I just taught you and you've implemented it then congratulations. You've just helped one more site deal with the issue of alarm fatigue. That's what I love about the field of BAS. Where else can you have such an immediate impact on the things you work on?
Now it's your turn. I'd love to hear how you deal with alarm overwhelm. Let me know in the comment section below!
Conclusion
