Good Control Room Alarm Management Still a Challenge

Aug. 1, 2007
Read about how process industries resolve the issue of operator overload, human error and organizational accidents.

By Ian Nimmo

Today the process industries are facing one of their biggest challenges in decades—how to resolve the issue of operator overload, human error and organizational accidents. Some see the problem just as bad alarm management; however, the more informed will recognize alarm management as a symptom of the real problem—poor situation awareness and the unnecessary abuse of the alarm system.

The Engineering Equipment and Materials Users Association (EEMUA) has been urging the industry to get its house in order and follow some simple, but effective practices to resolve these issues. Disasters, such as the explosions at Texas City, Texas, Longford, Australia and Pembroke, U.K., have focused more attention on the issues.

But the “EEMUA 191 Alarm Systems: A Guide to Design, Management and Procurement” has been in circulation since 1999, yet companies still struggle with the problem, always looking for the silver bullet to fix it once and for all. Many companies have applied years of effort doing alarm bad-actor resolution and alarm rationalization, all to no avail.

Some have criticized the EEMUA alarm KPIs as unrealistic and hope for a change that would remove the burden of achieving them and introduce another, easier metric. But, for the most part, the whole industrialized world has accepted and used EEMUA 191.
As a result, some companies have made significant improvement in their day-to-day alarm management, but have fallen short of a working solution during abnormal situations and alarm flood conditions. They have failed, not because the EEMUA guideline do not address this issue, but because the tools available to them within the control systems are limited in this area, and the current alarm statistical analysis tools do little in the way of data mining.

Some are hoping the new revision of the EMMUA 191 document will provide a new approach, while others are looking for more clarity around dealing with the unsolved alarm flood issue. The long-awaited revised guideline is now available, and the changes highlight the gaps the end users who make up the EEMUA Association have recognized as potential shortcomings.

Few Major Changes

Bill Hollifield from PAS has been tracking the new EEMUA publication and has provided a detailed review for the ISA SP18 Alarm Management Standard committee members.The review concludes that the second edition has few significant changes and some minor ones to areas such as performance measurement, adding clarification on metrics currently in use. Interestingly, the revision now includes a “buyer’s guide” regarding important features that the tool should have.

What is new is not a “magic bullet,” or a reduction or lowering of the performance metrics or a new approach to dealing with alarm floods—only clarification and classification regarding performance levels.

The biggest new thing that the end users determined was missing and needed to be added to this revision was a whole new appendix on alarms in relationship to batch processing plants. That is not going to help the continuous processing users who have multiple units being monitored by a single operator, who has thousands of alarms and can have all his multiple units in disturbance at the same time.

For batch processing plants, however, this is good news because their needs are different from the continuous processing industries, which have more issues around notification, messaging and information delivery to remote operators. The revision addresses additional ways, other than just severity, to set alarm priorities. Among them are looking at comparing or differentiating consequences.

So has EEMUA missed the mark? I don’t believe so. I think that EEMUA was good before and is improved with this new release. So how do we address the outstanding problems? The answer lies initially in understanding that the problem being solved is not just alarm management, but situation awareness, and will require the end users to address other factors besides alarms, such as HMI and control room design.

Time to Cry Foul?

I can hear some project managers calling foul and project creep already. What most project managers have not realized is that inadequacies in the HMI, including overloading operators with visual information, poor navigation of graphics, incorrect use of color, incorrect text size, inadequate line width, out-of-context object sizes and use of full-intensity color can lead to a dependence on alarms to direct the operator to problems and to reactive problem-solving. Without fixing these issues, the alarm system will remain in high demand.

EEMUA addresses these issues around the design of the HMI or HCI (human-computer interface) in another document—EEMUA 201. It is definitely not as informative as 191 and is very shallow in some places; however, it does provide a good basis for developing a graphics style guide, interpreting the graphics and making it easier to see changes; therefore, providing good situation awareness. It focuses on the design of the HMI/HCI to encourage clarity, consistency, feedback, redundancy and robustness.

Ideally, as time goes on, the model EEMUA needs to bring out is an additional, complementary control room design guideline and a wrapper that links 191, 201 and the new document together to promote better situation awareness.

For more details on the EEMUA 201 guidelines, go to www.controlglobal.com/eemua.html