Determine alarm activation point (limit). Set limits far enough away from the consequence threshold that the operator has adequate time to respond but not so close to normal operating conditions that regular process variation triggers alarms.
A common mistake in creating alarms is to configure limits based on rules of thumb relative to the engineering range of the process variable — for example, configuring the limits for High-High, High, Low and Low-Low as 90%, 80%, 20% and 10% of range, respectively. This ignores the time the operator has to respond, the process variable's rate of change, the consequence threshold and process deadtime.
Verify other alarm-related settings and attributes. An alarm ideally should go off only once per event. Use deadband and on/off delays to reduce the number of times an alarm triggers for a single abnormal condition.
Proper application of deadband and alarm delays can minimize chattering alarms and also prevent problems during control system installation and commissioning.
Assess the need for special handling. Document the states, conditions, phases or products where the alarm limit or priority should differ from "normal" or the alarm should be suppressed (Figure 2). This ensures any alarm presented to the operator always is relevant.
Record results in a master alarm database (MADB), which can range from a user-developed spreadsheet to a commercially available tool designed for the purpose. An effective tool can maximize efficiency by speeding completion of the overall process, saving money and reducing the time commitment of key personnel. It also helps produce consistent results from the first alarm reviewed to the last, even if team members change and the order of alarms reviewed varies.
A well-equipped rationalization team each day can complete 20 to 30 process tags (alarm sources) or more, representing 100 to 200 alarms. So, the choice of rationalization tool/MADB is important. Whether developed in-house or purchased, it should reduce dependence upon team member personality and training with mechanisms to enforce consistent review, apply philosophy criteria (priority setting as an example), facilitate management of change, allow similar alarms to be rationalized in mass and, ideally, enable efficient two-way exchange of alarm configuration data with the process control system.
MAKE RESULTS AVAILABLE
Alarms are only effective if operators know how to properly respond to them. So, provide operators with the information documented during rationalization (particularly the cause, consequence, corrective action, confirmation and time to respond). Such "alarm response procedures" can be used for operator training and integrated into the HMI to give operators on-line access, resulting in a quicker and more consistent response.
Ideally, a control system faceplate should offer direct access to appropriate alarm response procedures. Figure 3 shows a setup in which a click on the help icon adjacent to the alarm opened the alarm help window.
Run any alarm configuration changes captured during the rationalization process through the management-of-change process before approving their implementation. The level of review may differ depending upon the type of change and the alarm's classification. For example, adjusting the limit of a safety-critical alarm may require a more-thorough review and approval process than altering the deadband of a typical process alarm. Update the MADB to reflect any changes made in the alarm system configuration so they are kept in sync.