Modern HMIs have nearly endless opportunities to display, organize and control alarms. However, they have been sorely outpaced by the number of outputs added to new sensors, the fantasies of engineers of what should be in alarm and poorly set up alarm systems. Let's talk a little about alarms (again).
Alarms have priorities, just like everything else in life. Which is more important for your process: a failure to start on a pump within walking distance, or a chlorine gas leak? Are some alarms things that people can check at the end of the day, or need response now?
Alarms must have a response. If you have the ability to put comments in the alarm description, please do. Which would you prefer to see at 0030 on a holiday weekend?
NAME PRIORITY GROUP COMMENT
CL2_LEAK 1 CL2 CHLORINE GAS LEAKING
CL2_LEAK 1 CL2 PPM > 2, VERIFY STAFF OUT, THEN CHECK LINES IN SCBA
Obviously, the correct answer is neither. Consider a motor bearing alarm.
NAME PRIORITY GROUP COMMENT
MTR1_B1_HI 3 INFLUENT BEARING HOT
MTR1_B1_HI 3 INFLUENT TURN OFF MOTOR, NOTIFY MAINTENANCE ON DAY SHIFT
Alarms can be filtered
If you have a real process upset, you will probably get an alarm flood. If operators can no longer read alarms because they see so many alarms, they will stop using your system. Our sites often have extra alarm displays, grouped by process. If a real problem happens, they can look one section at a time, allowing them to better respond to the situation.
Alarm groups can be disabled
Why bother showing alarms generated by equipment that is out of service? Add in some In Service (IS) / Out of Service (OoS) buttons, which disable sets at a time.
Discrete alarms may need timers
By this, I mean you can add On Delay and Off Delay timers for your discrete points. On Delay timers wait to trigger the alarm. The Off Delay will not officially clear until the input remains clear for a certain time period.
Now, you should be reasonable in this. The "on delay" for a high-level float in a bumpy tank could be 30 seconds, but 30 minutes would be silly.
Analog alarms need alarm deadbands
If you got nothing else out of this post, please use this. An "alarm's deadband" is a threshold of change that is needed in order to trigger (or clear) the alarm. Consider a 10-meter tank with an analog level sensor. If the high-level alarm is set to 9.5-meters and the tank is at 9.49-meters without alarm deadband, a simple ripple (of 0.01 m, or 0.4 inches) could knock it over the edge, back under, then back over, etc.
Not implementing these is a good way to get your team to ignore the alarm. Just note that teams who ignore one alarm will ignore other alarms.
I usually recommend alarm deadbands of 1% of the full range, unless otherwise noted. Hence, our prior system would need to go 0.1 m (or ~4 inches) to cause the alarm to come on, or off.
Alarms need review
If the system is upgraded and there is no review, you will get more and more alarms. No matter what the engineers say, you do not need (or want) every alarm on an Industry 4.0 device. A common alarm that sends someone to look will work at least 50% of the time.
If you want to know more, check out Alarm Management, which I covered in a previous TLDR; post. Another excellent book!
Comments