Blunder 3: skipping benchmarking. Benchmarking is vital to any serious improvement initiative. If you don’t measure your current performance, you won’t be able to accurately determine your progress. The first step is to keep track of alarm rates for several weeks in order to get a baseline measurement. Once that’s done, assess how your plant’s current alarm levels measure up to industry standards (Figure 2).To get a quick snapshot of where your plant ranks according to 191:99 “Alarm Systems — A Guide to Design, Management and Procurement” by the EEMUA, Matrikon has posted an automated calculator on its website (www.matrikon.com/plantperformance).
When you have finished benchmarking, you can start identifying opportunities for improvement. Following are the key questions in order of importance you need to answer when performing this assessment.
- Is the dynamic (real-time) alarm load acceptable for all operators?
- Does the dynamic alarm prioritization meet industry standards?
- What are the troublesome tags on the system during steady-state operation?
How about during start-up and shutdown? Was there any particularly
troublesome phase of your operation that lit the board?
- How does the configured-DCS alarm count compare to the EEMUA standards?
(How many alarms per tag during start-up, shutdown, steady-state?)
- What does the configured-alarm distribution look like compared to the
Blunder 4: stop philosophizing — get it done! Failing to establish and document best practices is a recipe for disaster — you need to create guidelines for alarm rationalization. Documentation should include: rules for setting alarms, plans for alarm reviews to build commitment and consolidate training, and an audit process to ensure that the rules are consistently applied. These guidelines will clearly define the criteria for legitimate alarms and setting of their priorities. They 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 corners. Disturbingly, companies often exclude their best resource — the panel operator — from rationalization meetings. Panel operators are the end user and the primary stakeholder in alarm optimization. If you exclude the panel operator from the rationalization process, your 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. Sometimes, foremen, who were once panel operators, can serve in their place, but their experience may not be current.
Please pay attention: the best candidate for the meeting is the person who fights alarms and unit problems day-in and day-out. This knowledge is irreplaceable 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 necessary 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. In addition, if this project is part and parcel of the roll-out of a new process, include “technical experts” in your review process. These experts may be equipment vendors. As with all projects, a safety review is recommended after the project is completed to identify any unplanned changes that typically occur in the heat of battle.
Blunder 6: find a system that works with your alarm philosophy. 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 collection of redundant alarm data 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 archiving of alarms and events and analysis adequate to meet objectives, or do I need to establish a connection with the control system configuration database?
- How flexible is the connection strategy? Will it survive control system upgrades?
- How much maintenance is required to keep the system running (reliability)?
- 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 these data at the plant level, or would corporate comparisons between sites benefit my operations?
Don’t rely on legacy strategies if they do not meet current needs. What worked in the past may no longer be the best solution. However, don’t 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.