English is currently available.
SCADA & HMI DISCUSSION
Our SCADA system has about 900 configured alarms and the operators see several hundred a day. During a pump trip the alarm list fills with dozens of consequences in a few seconds, and the real cause is somewhere in the middle. Most people now acknowledge everything without reading it.
Is there an accepted way to decide what should be an alarm, how many are reasonable, and how to stop chattering and consequential alarms?
The accepted definition, used in ISA-18.2 and the EEMUA 191 guide, is that an alarm is a notification of an abnormal condition that requires a timely operator response. If there is nothing for the operator to do, it is not an alarm: make it an event in the log or a status indication on a screen.
Going through every configured alarm and writing down the cause, the consequence, the operator action and the time available is called rationalisation. Alarms that cannot be given an action are removed or downgraded. On many systems this exercise alone removes a large share of the list.
The guideline figures give you a target. For one operator, an average of about one alarm per 10 minutes (roughly 150 a day) is considered very likely to be acceptable, and about two per 10 minutes (roughly 300 a day) is the upper end of what is manageable. A flood is usually defined as more than 10 alarms in 10 minutes. Priorities should be spread so that the highest level stays rare; a commonly quoted distribution is about 80 percent low, 15 percent medium and 5 percent high.
Start by measuring. Export the alarm journal and list the ten most frequent alarms; it is normal for those few to produce a large part of the total load.
Chattering alarms are fixed with three settings. A deadband (hysteresis) means the alarm clears only after the value has moved back past the limit by a margin, for example a high level alarm at 80 percent that clears at 75 percent. An on-delay means the condition must persist for some seconds before the alarm is raised, which removes spikes and noise. An off-delay holds the alarm for a short time so it does not clear and return repeatedly.
Commonly quoted starting points for the deadband are about 5 percent of span for flow and level, 2 percent for pressure and 1 percent for temperature, adjusted afterwards for the actual signal.
For the pump trip case you need suppression logic, not more priorities. When the pump trips, low flow, low discharge pressure and the downstream level alarms are expected consequences. Configure them to be suppressed for a defined time when the trip signal is active, or condition them on the pump running status, so the operator sees one alarm: the trip. The same applies to equipment that is deliberately out of service.
Keep suppression visible and controlled. Operators should be able to see a list of what is currently suppressed or shelved, and shelved alarms should return automatically after a time limit so that nothing is silenced indefinitely.
Back to SCADA & HMI community
