Alarm rationalisation: how to cut a list nobody reads

Every alarm list starts small and grows the same way: something went wrong, somebody asked why there was no alarm for it, and one was added.

Nobody ever asks the reverse question, so the list only goes one direction, and after a few years the operator has learned that the correct response to the alarm banner is to acknowledge it and carry on.

The three tests

Rationalisation is one meeting, one condition at a time, asking three questions.

• Is there an action? What should the operator do, specifically, when this appears? If the answer is 'be aware', it is not an alarm.
• Is the action different? If the response is the same as the response to three other alarms that always arrive together, you have one alarm and three symptoms.
• Is there time? If the consequence has already happened by the time it announces, the alarm is a notification of an event, not a prompt to act.

Most of the reduction comes from the first test. A large share of a typical list is conditions somebody wanted recorded, which is a job for the event log.

Priority, from consequence and time

Priority is not importance. It is the product of how bad the consequence is and how long the operator has to prevent it.

A condition with a severe consequence and two hours to act is lower priority than a moderate consequence with thirty seconds, because priority exists to order what an operator does in the next minute.

Assigning it any other way, particularly by which department shouted loudest, produces a list where the highest priority alarms are the ones nobody needs to act on quickly.

Write down the response

ISA-18.2 asks for the operator action to be recorded against each alarm, and this is the part that gets dropped for time.

It should not be. An alarm whose documented response is a blank field is an alarm that failed the first test and nobody noticed. Filling the field is the test.

The master alarm database

One record per alarm, holding the tag, the condition, the limit, the deadband, the delay, the priority, the message, the consequence and the response. That record is the authority, and the configuration in the HMI is generated from it or checked against it.

Without one, the alarm design lives in the HMI project file, which means it is only knowable by opening a piece of software, and it drifts the first time somebody adjusts a limit on a night shift.

The settings that stop chatter

Two parameters remove most nuisance alarms and both are usually left at zero.

Deadband. How far back the value must come before the alarm clears. Without it, a value sitting on the limit raises and clears every scan. Two to five percent of span is a normal starting point, and it should be asymmetric: alarm on the way up at the limit, clear on the way down at the limit minus the deadband.

On delay. How long the condition must hold before it is announced. A few seconds removes every transient that would have cleared itself.

Setting these two on an existing system, before touching anything else, typically removes a large fraction of the alarm count without a single rationalisation meeting. It is the cheapest improvement available and it is nearly always available.

Doing it in bulk

Rationalisation stalls on effort. Forty analogue tags, four limits each, is one hundred and sixty records to type, and it does not get done.

The practical answer is to generate the obvious ones from the tag table, as a percentage of engineering span, with priorities escalating outward, and then rationalise the generated list rather than a blank page. Arguing with a draft is much faster than authoring one, and it is the same list at the end.

The HMI builder in LADX does exactly this: pick the tags, set the limits as a percentage of span, preview what would be created, and skip anything already defined.