Managing Alarms

Technology is good, so more technology must be better. Right? Wrong. More is not always better. The advent of the microprocessor and the proliferation of the modern distributed control system (DCS) made it easy to alarm something…everything, in fact…at little or no cost. As a result, many facilities today have an overwhelming number of notifications daily, leading to frustrating, s...

By Jeanine Katzel February 1, 2007

Sidebars: Attributes of a ‘good’ alarm message Online resources: Standards, benchmarks, best practices

Technology is good, so more technology must be better. Right?

Wrong. More is not always better. The advent of the microprocessor and the proliferation of the modern distributed control system (DCS) made it easy to alarm something…everything, in fact…at little or no cost. As a result, many facilities today have an overwhelming number of notifications daily, leading to frustrating, sometimes confusing, and occasionally tragic situations.

“Everyone knows alarm management is important, but somehow it rarely seems to be important enough to justify projects in the plant,” observes Todd Stauffer, PCS7 marketing manager, Siemens Energy & Automation. Recent events exposing the consequences of bad alarm management—among them the explosion at the BP refinery in Texas City in March 2005 that killed 15 and injured 170—may be changing that attitude, however. (View a report about the event, attributed in part to alarms that were not fully functional, by visiting the video room on the U.S. Chemical Safety and Hazard Investigation Board Website, .)

This and other such incidents have prompted personnel at many plants to re-think alarm management programs and look at what has led to the overwhelming number of alarms, learn about and adopt best practices, and promote standards development. The renewed interest has led companies to consider and incorporate benchmarks such as the Engineering Equipment and Materials Users’ Association’s (EEMUA) Publication 191; “Alarm Systems: A Guide to Design, Management and Procurement,” called by many the de facto alarm management standard. Notes Tim Donaldson, director of marketing at Iconics, ‘Alarm distribution, tag frequency/chattering, cross-correlations, operator response time and operator changes by interval are among reporting metrics that are part of EEMUA and provide valuable information to improve plant operations.” In addition, end-users and vendors alike are supporting such standards development as ISA’s SP-18.02, Management of Alarm Systems for the Process Industries. (See accompanying section, “Standards, benchmarks, best practices” for more on these guidelines.)

Getting started

Most industries experience far more alarms than are considered good practice. The EEMUA figures are recommended benchmarks from Publication 191 (1999), ‘Alarm Systems: A Guide to Design, Management and Procurement.

Among the more obvious questions raised about alarm management is why so many? Stauffer explains it this way: “In the analog days, alarms were hard-wired. They had to be deliberately designed and installed. There was a real cost to each one—about $1,000 an alarm—so they were done carefully. With the modern DCS, alarms are essentially free, so plants tended to enable every alarm they possibly could.”

Indeed, today’s operator too often faces near-constant alarm flurries. The average, recommends EEMUA’s Publication 191, should be 1 every 10 minutes, or not more than 144 a day. Most industries report significantly higher alarm levels, ranging from 5-9 per 10 min. interval (see comparison chart). David Gaertner, director of alarm management services for Invensys Process Systems, recalls one facility where five operators experienced some 5 million alarms in a six-month start-up period. “One device alarmed 550,000 times. It ran for months and still didn’t drive someone crazy enough to go and shut it down.”

Past practice has been to put in an alarm whether or not you were sure it was needed. The latest paradigm in alarm design, however, is to configure an alarm only when operator action is required. This philosophy, which reflects a fundamental change in system design practices and operator interaction, is included in the draft of ISA SP18. It defines an alarm as “an audible and/or visible means of indicating to the operator an equipment malfunction, process deviation, or abnormal condition requiring a response.” Following a practice that says ‘configure only when action is required’ lets the operator know that when an alarm sounds or flashes, he needs to act.

Measure for measure

If one piece of advice for managing alarms recurs more than any other, it is: “Don’t do anything unless you have a tool (typically software) to measure with.” The words, from Nick Sands, co-chair of ISA’s SP-18.00.02 alarm management standards committee, and process control technology manager for the chemical solutions enterprise at DuPont, emphasize the necessity for monitoring. “A monitoring system must tell us what state alarms are in,” Sands explains. “How many are in maintenance? How many are highest priority? How many are related to safety? It also needs to tell you how your system is performing. Is it meeting your goals, following your philosophy?”

A good alarm system requires a guiding document to tact as its foundation. ISA’s SP-18.02, Management of Alarm Systems for the Process Industries, proposes a holistic approach based on a lifecycle model that includes a defining philosophy, training, monitoring, and auditing.

Adds Keith Jones, senior product manager, visualization products, Wonderware, “Many industries, such as pharmaceuticals and food and beverage, are already required to maintain a database of materials or ingredients. This information can be useful for alarm analysis as well. We can implement a series of real-time components to visualize where alarm problems might be. For example, simple histograms of alarm frequencies can be drawn. Various levels of alarm reports can be created providing data for managers as well as executives.”

Two basic parts of every alarm management program, says Invensys’ Gaertner, should be: “a good analysis tool that identifies which devices are creating the most alarms; and a good work process to bring personnel and resources together to eradicate the problems. The analysis tool helps you understand where the problems are. It can help determine the most frequent alarms, the chattering alarms, the nuisance alarms. It helps us see where and when alarms occur, so that we can do a root cause analysis to see why there are floods and re-prioritize the alarms. A lot of plants have all their alarms set at high priority. That’s not acceptable. The distribution typically should be to limit 5% of all alarms to priority #1, 15% to priority #2, and 80% to priority #3. Then the operator can respond to those that are really important.”

Nonetheless, cautions Mark McTavish, director of alarm management solutions and global training at Matrikon, “Remember that software is a tool you use, not a solution in itself. Alarms should be the exception, highlighting things that are going out of bounds. Successful alarm management programs help plants reach that point. They help engineers manage their plants on a daily basis, achieving tighter quality control and higher productivity because they have fewer unplanned shutdowns.”

An ‘operator-centric’ function

Even having a good alarm system and a mechanism to monitor and analyze its performance is not enough, however. They need a philosophy, a guiding document that forms the foundation for the overall alarm system, stresses ISA SP18 co-chair Sands. In developing the standard, “We are focusing not only on the rationalization of alarms,” says Sands, “but on the whole lifecycle of alarms, including training, modifications, benchmarking, periodic monitoring against the processes that are in place. We want to take a holistic approach to alarm management, modeled in some ways after ISA 84.00.01, Functional Safety: Safety Instrumented Systems for the Process Industry Sector . (See alarm management life cycle model graphic.)

That approach includes the need to consider the operator. Most people underestimate the importance of operator participation, notes Matrikon’s McTavish. “Alarm management is ‘operator-centric.’ Engineers find it hard to understand operator problems unless they have actually sat in the operator’s chair and experienced alarm management. They think they know what an operator needs, but often they don’t.”

Presenting information to the operator properly through the HMI is a critical aspect of alarm management. Says Wonderware’s Jones, “Alarms need to be filtered so that only the right ones reach the operators. Software provides the tools they need to configure those parameters easily, but consistency and acknowledgement of response are important, too.”

The message that notifies an operator of an alarm must make clear what’s needed. For example, says Siemens’ Stauffer, “When a process control engineer configures a system, he may label the physical device according to the ISA tag ID or loop ID: LIC-120 might be an alarm. But that’s not the way an operator typically refers to that piece of equipment. He sees it as ‘the level controller for tank XYZ’. If the message communicates the wrong information to the operator, it will create a problem. The operator is the target audience, not the process engineer. The operator is the one who responds. The message needs to be one he will understand—immediately!”

Adds Eddie Habibi, founder and CEO of PAS, ‘Operator effectiveness, which significantly impacts plant reliability and profitability, goes far beyond improving the alarm management system. Investing in operators is as important as investing in advanced process controls. One can’t have effective operators without proper human factors. A competent operator knows the process; has good interpersonal and communication skills; and stays alert on the job by practicing good life habits. Before the DCS,” he goes on, “the operator had a physical layout of the process, showing at a glance all piping and instrumentation. With the introduction of computer-based monitoring, hundreds of P&IDs were replicated into computer systems with little thought going into the design of the operator interface. When we went from analog systems and physical layouts of the control board to digital systems with screen interfaces, the operator lost the big picture.”

The operator also needs to be educated about the process, stresses Habibi. “Too often, we overlook training. What are the operating principles behind a pump or a compressor? An airline pilot receives countless hours of training. He must be experienced before he is allowed to take responsibility for so many lives. A chemical plant operator might have as many, or more, lives in his hands, yet he typically receives a couple of months of training, then learns on the job. We need to pay more attention to upgrading the competency of the plant operator.”

Paying the price

Good alarm management costs time and money. But bad alarm management does as well, leading to lost production and jeopardizing human life. Although initiating an alarm management program, or reviewing and revamping one, can be daunting, volumes of information are available to help establish and achieve alarm management goals.

The most important factors are to set a goal and take action. Matrikon’s McTavish says a system should provide timely, unrepetitive alarms relevant to the situation to assist the operator in diagnosing the problem and determining a successful course of action. ‘The objective is to maintain the plant in a safe, reliable working condition so that it can make a quality product. In the end, the goal is to be financially lucrative. If a plant fails to accomplish that, then its existence is in question.”

Alarm management is a process, not a project, summarizes Invensys’ Gaertner. “It is like safety in the plant. It is ongoing. You are never done. We’ve learned the high cost of low performance, and plants are not willing to pay anymore. The price is way too high.”

Author Information

Jeanine Katzel is senior editor at Control Engineering magazine. Contact her at .

Attributes of a ‘good’ alarm message

Among the best practices encouraged in the EEMUA benchmarks document is the clear, consistent presentation of information in an alarm message. Each display screen should:

Clearly identify the condition that occurred;

Use terms familiar to the operator;

Use consistent abbreviations from a standard site dictionary of abbreviations;

Have a consistent message structure;

Not rely on learning tags names or numbers; and

Have been checked for usability during plant operations

Information drawn from EEMUA Publication 191 (1999), “Alarm Systems: A Guide to Design, Management and Procurement.”

Online resources:

Abnormal Situation Management Consortium;

Alarm Management Handbook, A Comprehensive Guide by Bill Hollifield and Eddie Habibi, PAS (ISBN 0-9778969-0-0);

Chemical Safety Board;

Engineering Equipment and Materials Users’ Association, EEMUA Publication 191, “Alarm Systems: A Guide to Design, Management and Procurement,”

Instrumentation, Systems, and Automation Society standards;

Standards, benchmarks, best practices

Best practices for alarm management have been sparse. Primary within the industry right now is EEMUA Publication 191 (1999). “Alarm Systems: A Guide to Design, Management and Procurement.” It provides guidance on developing an alarm system philosophy, system design and function, optimizing the operation of existing systems, and specifying a new system. The document was developed and written by industry practitioners, in association with the U.S. Abnormal Situation Management Consortium (ASM), a Honeywell-led research and development group.

For more details on these best practices, visit the EEMUA and ASM Consortium Websites at

The standards-making body of ISA, the Instrumentation, Systems, and Automation Society (

The goal, says Nick Sands, committee co-chair, is to develop a consensus standard that will also be an ANSI standard. “Work on the standard began in earnest in October 2003,” notes Sands. “We have a couple of members from S84 [Functional Safety: Safety Instrumented Systems for the Process Industry Sector] and from SP101 [Human-machine interfaces] on our committee to ensure that what we do is consistent with what’s in those standards. At this point, we’ve completed a second draft, but some revision still needs to be done. We expect to have a draft for ballot by summer 2007.” An optimistic goal, he adds, would have the standard in place by end of this year.

If you have an interest in participating in the development of the ISA standard or have input to offer, e-mail co-chairs Nick Sands ( or Donald Dunn ( For more on standards, visit the ISA Website at