Failing to establish and document best practices is a recipe for disaster. In order to get consistent results you have to create guidelines for performing alarm rationalization. For example, a project-specific alarm philosophy, including a methodology and rules for setting alarms, an alarm review to build commitment and consolidate training, as well as an audit process to ensure that the philosophy is consistently applied. These guidelines will clearly define the criteria for legitimate alarms and setting of their priorities. These are the backbone of an “Alarm Philosophy” document, which acts as a corporate standard to guide your entire organization’s alarm management initiatives.
Blunder #5: Cutting Resource Corners
It is disturbingly common for companies to try and exclude the most important resource from rationalization meetings: the Panel Operator. Panel Operators are the end user and the primary stakeholder in alarm optimization. If you exclude the Panel Operator from the rationalization process, the project will fail.
The following reality is based on unpleasant site experience. Instrument Technicians, Automation Engineers, Process Engineers, and Field Operators are not Panel operators. Please pay attention; the only person who can be the “Panel Operator” is an experienced Panel Operator. This person fights alarms and unit problems day-in and day-out and his knowledge becomes very valuable during the rationalization process.
Alarm Rationalization is the process of applying operational experience to alarm system design. Although operators are the most important participants in this process, they cannot carry this burden alone. Without a facilitator who is familiar with Alarm Rationalization, your rationalization project will take longer than it should, yield poor results, and have to be repeated.
Finally, Alarm Rationalization requires an engineering review prior to implementation. This is required to ensure results are consistent with Hazard and Operability Studies (HAZOP) and Safety Integrity Level (SIL) studies. The “Process”, “Unit”, or “Contact” engineer plays this role.
Blunder #6: Establishing the Easieerst or Cheapest Connection
Collecting alarm data in an optimal fashion is system specific. The easiest way is often not the best way. Be sure to answer the following questions:
- Does the analysis package need to present information to the operator in real-time or are existing alarm visualization tools adequate to manage plant upsets?
- Is the plant hierarchy represented consistently and intuitively within the Control System and the Alarm Management System?
- Is redundant alarm data collection required to meet regulatory or corporate policy compliance?
- Are all required events such as “Return to Normal”, “Operator Actions”, and “System Messages” included in the chosen connection method?
- Are all required fields available in the data? Can priorities be distinguished? Can audible and suppressed alarms be distinguished? Can set point changes be discerned from output changes? Can absolute alarms be separated from deviation alarms? If gaps exist, what other sub-system(s) can be referenced to close them?
- Are basic alarm and event archiving and analysis adequate to meet my objectives, or do I need to establish a connection with the control system configuration database?
- How likely is the connection strategy to function with Control System upgrades?
- How much maintenance is required to keep the system running?
- Does one option provide advantages over another and vice-versa? Should more than one connection be used for each area?
- Do I only want to view this data at the plant level, or would corporate comparisons between sites benefit my operations?
Don’t restrict connectivity to legacy strategies if they do not meet current needs. What worked in the past may no longer be the best solution. However, do not make things unnecessarily complex. Decide what you want to accomplish and then choose the simplest method that meets all of your needs. If the collection strategy becomes overly complex then it will be hard to maintain, and ultimately your entire alarm management strategy will suffer.
Blunder #7: Failing to Automate
Good technology makes life easier. Its purpose is to relieve people of dangerous, repetitive tasks, freeing them to intervene when the automated system requires guidance. When intervention is required, software should make problem assessment and diagnosis easy so as to free the user’s time to fix the problem.
Although task accountability is necessary for successful Alarm Management, staff is more likely to use reliable technologies that are available on demand to make their jobs easier.
Blunder #8: Only Tracking Alarms
People often mistakenly fail to track all of the data required. Only tracking alarms is not enough! Alarm rationalization requires more than one type of data. For example, when an alarm occurs you need to know if an operator actually responded to it. Tracking operator actions is an effective way to identify control problems, automation opportunities, and audit the effectiveness of your alarm strategy. If the operator did not respond, there is a good chance that the alarm is a nuisance alarm. Examine the ratio of operator actions to audible process alarms in order to identify poor alarm strategies. The de-facto standard “every alarm requires operator intervention” demands this ratio exceed one.
Other data to track consists of operator actions, including controller setpoint, mode changes, and system errors. If a controller’s mode or output is repeatedly changed it is a clear sign the loop needs fixing. If action data is coupled with controller performance data, an understanding of the loop’s problems can be quickly diagnosed saving time. If a controller’s setpoint is frequently changed and the controller has no supervisory control, then the Automation engineer must ask “why not?” Installing new automation strategies can free the operator to focus on pushing limits rather than maintaining process stability. In addition, process variable history is important for determining some deadband alarm settings, or for performing the engineering reviews prior to implementation.