From an operations point of view, one of the significant parts of the ISA-18.2 and IEC 62682 alarm management standards is the endorsement of alarm response procedures. An alarm response procedure, otherwise known as “Alarm Help” or “Alarm Response Manual”, is defined as guidance for response to an alarm (e.g., operator action, probable cause). It is meant to help improve the operator’s response to an alarm by reducing the time it takes to correctlydiagnose the problem and determine the appropriate corrective action.

I bet you are thinking “this seems like a good idea”.  

It is more than a good idea. As defined in ISA-18.2 and IEC-62682, it is a requirement.

“Alarm response procedures shallbe readily accessible to the operator…”

In ISA-18.2-2016, “Alarm response procedures” was added as a REQUIRED section for an alarm philosophy document. A compliant philosophy shall address the end user’s application of alarm response procedures by defining:

1. the alarms that need alarm response procedures (based on priority or class),
2. the information to be included in the alarm response procedures (e.g., cause, consequence, corrective action), and
3. the method to access the alarm response procedures (e.g., via the operator interface).

The standards also define the expected information in an alarm response procedure.

Typical Contents of an Alarm Response Procedure (ISA-18.2, IEC 62682)

1. The tagname for the alarm,
2. The tag description or alarm description,
3. The alarm type (e.g., High, Low, Change from Normal),
4. The alarm setpoint,
5. The potential causes,
6. The consequence of inaction,
7. The operator action
8. The allowable response time, and
9. The alarm class.

Control system suppliers such as ABB, Emerson, Honeywell, Rockwell, Siemens, and Yokogawa have enhanced their platforms to support this functionality. Via single click from an alarm summary list or faceplate, an alarm response procedure can be called up within the HMI. This provides the information to the operator quickly and in context.

I bet now you are thinking, “this is a good idea, but it’s going to be a lot of work.”

Not really. If you perform a thorough alarm rationalization, ALL of the information you need is being discussed and documented. If done right this can turn your alarm rationalization process into a knowledge capture process. Recording what your most experienced operators would do when an alarm occurs, and making it available for all operators to see in context within the HMI, is a fantastic way to improve operator performance.

Alarm Response Procedure displayed in PlantPAx as created by SILAlarm

In this day and age, you should not do alarm rationalization without having a plan on how you will capture the rationalization information and turn it into alarm response procedures. Tools, such as exida’s SILAlarm™, can automate the creation of alarm response procedures in the control system directly from the results of rationalization (with no additional work).

There are lots of best practices related to the composition and display of alarm response procedures, like allowing the operators to call them up when the alarm is not active (for self-training purposes), but this is the topic for another time…