This post was authored by Leila Myers, a consulting engineer with Yokogawa.

Although distributed control system (DCS) selection is one of the most important steps in the design of a new or upgraded process plant, some users now consider such a system a commodity and give its selection far less thought than it merits. The result is a generic control system that provides little more than the most basic control functions. This is a huge opportunity lost, because a control system that is optimized for a given application using relevant ISA standards is far more effective over its long life span.

One very practical element of this selection and configuration process is alarm management. In spite of dozens of articles and even whole books on the topic, this aspect of control system design is often ignored until the new DCS is installed and running—and driving the plant operators crazy trying to deal with a multitude of problems. Alarm management then becomes a matter of trying to squelch the noisiest problem, instead of the result of a carefully thought out strategy.

The far better approach is using the ANSI/ISA-18.2-2009 standard for alarm management as a practical guideline early in the DCS selection and specification stage. This may seem like an obvious approach, but in the real world it is far rarer than one would imagine. System integrators and companies providing control platforms do not always do a good job of showing users how to get the most out of the opportunity early in the design process, the best time to implement an alarm management strategy.

Most DCS platforms have a basic framework for the first line of alarm interface for control room operators, but that is far from what users need to build a systematic approach that supports a safe plant with effective operators. To fill that gap, a committee of experienced users, engineers, system integrators, and DCS suppliers developed the ANSI/ISA-18.2 standard with the primary goal of making process industries safer. This goal can be accomplished by implementing an alarm management system that emphasizes what is important to the operator and eliminates what is distracting and time consuming. ANSI/ISA-18.2 describes the alarm management process in terms of a life-cycle model (figure 1).

Figure 1. Alarm management is not a static process, and it needs to be adjusted to match changes in the process and other new operational practices. Regular audits coupled with change management procedures help avoid undocumented modifications made by operators that can have potentially serious consequences.

The life-cycle concept as expressed here creates a dynamic system, not a static one. As situations and needs change, the alarm management strategy can also change to stay current. Changes are administered with appropriate documentation and training to ensure that all involved benefit. After some years, the overall approach may have evolved a great deal, but all the information is retained in the system, so it is clear how and why modifications were made.

There are many DCSs running plants today that were implemented years ago with no alarm management life-cycle concept in place. Such systems usually started up with little or no strategy for alarm management beyond an attempt to make the most aggravating problems go away, so operators could get their work done.

Typically, many more alarms than needed were included in the initial installation, and over the ensuing years, system alarm configurations were changed without any tracking or recording. In addition, many advisory messages were included that were not really alarms, because operators could not or did not need to take any actions in response. The most annoying problems were squelched for the sake of the operators’ sanity, but the DCS was rarely systematically cleaned up. And as DCSs added more functionality, alarm management often became even more problematic.

A blessing and a curse

As DCS platforms gained sophistication, it became much easier for system architects to add alarming functions in far more areas. As a result, some DCS function blocks were given the ability to generate tens of alarms by default. Users had to disable some of these alarms, not always an easy process. As a result, there are many nuisance, duplicate, and unnecessary alarms in the existing systems that need to be investigated and possibly deleted—too many alarms only distract and stress operators, possibly causing them to miss important problems.

With this problematic history in mind, how should a company planning a DCS upgrade or new installation approach the situation to avoid these problems and ensure the most effective outcome? The ANSI/ISA-18.2 standard (with its associated technical reports 1 through 6) provides best practices, requirements, and guidelines that can improve the implementation from the start.

With increasing retirements among experienced operators and reduced employee head counts, many end-user companies no longer have in-house support systems, but DCS suppliers and system integrators can step in with the support and knowledge to make the new or existing DCS a safer system based on ANSI/ISA-18.2.

A step-by-step process

ANSI/ISA-18.2 helps avoid the problems of alarm management as an afterthought. It is a systematic approach for an effective strategy that works hand-in-hand with the larger process control and safety systems. Here are some of the key steps of the process, outlined in the standard, that DCS suppliers and system integrators can support:

1. Help the user develop an alarm philosophy document as required by ANSI/ISA-18.2. This document explains how the alarm management process is handled consistently within the facility, including roles and responsibilities of personnel involved with alarm management.

2. Form a cross-functional team at the site for alarm rationalization. Members should include operators and all the personnel involved in various life-cycle stages of alarm management. The team also needs to be involved in testing and approval of the alarm implementation within the system.

3. Educate the team about the alarm capabilities of the particular automation platform being used. Most process hazard analysis reports, which are used as the starting point for alarm identification, only specify alarm set points. They do not identify which function block in the control system should be built with alarms, or what other alarm attributes should be activated on each function block. Implementing control loops within the DCS often involves multiple function blocks between the measurement input and the output to the manipulated variable. Avoid duplicating alarms in the function blocks. Figure 2 shows an example of various alarms that can be associated with a single control loop within the DCS and how alarms can quickly and unnecessarily multiply.


4. Educate the team about how alarm settings in the system interact and are affected by the human-machine interface (HMI) design selections and facility security requirements. (ISA101, currently under development, can help.) The different alarm priority levels and their presentation to the operators should follow the HMI style guide for the site. The alarm philosophy and HMI philosophy documents should describe the assignment of alarm annunciation and acknowledgement functions to various HMI displays, consoles, and control rooms depending on operator tasks and realm of control.

5. Develop an alarm system requirements specifications document to describe how the alarm philosophy requirements are implemented within the specific automation system platform.

6. Document the alarm rationalization results in an electronic master database that can be sorted and manipulated to facilitate the rationalization process. For example, it often helps to sort the instrumentation by unit operations or by operator realm of control to complete rationalization in manageable blocks. It also helps to group similar instrumentation and associated function blocks together to address similar alarm types at once. The rationalization process should eliminate all extraneous items, leaving only the alarms that the operator can do something about.

There are other alarm rationalization tasks that need the special knowledge of the DCS supplier or system integrator:

  • How to handle instrument failure alarms consistently: Where should the alarm appear and how should it affect the controllers?
  • How to handle system hardware problem alarms: Who should receive the alarms and where?
  • How to handle alarms from any third-party packaged system connected to the DCS: If a compressor skid or some other equipment device with its own control system should fail or lose communication, what should be done?
  • How to select and designate effects (color, sound, symbol) of priority selections within the system: Alarm priorities should be based on the consequence and the required response time, as recommended by ANSI/ISA-18.2, not on the available choices in any control system platform.
  • What operator overrides to allow: When can operators suppress or shelve alarms, and what are the effects? (See figure 3.)


Figure 3. There can be many conditions where it is appropriate for operators to suppress or shelve specific alarms. But deciding exactly where and when such a practice is permitted needs to be handled carefully and rationally in the context of the overall management strategy.


7. Provide enhanced alarming mechanisms within the control system to reduce alarm flooding. Both static and dynamic suppression techniques are available in most DCSs. The team should be advised of the capabilities and the effect of implementing these techniques.

8. Advise the end user to incorporate alarm changes in the management of change procedure for the facility. The procedure should consider various alarm attributes in the control system that might not be apparent to the operator.

9. Make sure that the alarm and event logs in the system are saved in the history and can be retrieved easily. Moreover, be sure to collect statistics about the number and types of alarms. Based on ANSI/ISA-18.2 requirements, the facility should monitor the performance of the alarm system and deal with problem alarms regularly. An alarm reporting package can be provided to analyze the results, as illustrated in figure 4.

Figure 4. Analyzing alarm data points is a way to improve the process and the alarm management system. Relevant data needs to be available, and the control system should have intuitive tools for performing statistical analysis.

10. Provide a mechanism to track and document all changes to the control system database regarding alarm attributes. Provide a means of comparing the current status with the saved and rationalized master alarm database.

11. Set up a periodic audit plan for the alarm management system. Evaluate how well the philosophy is being implemented and the changes required to optimize the process.

These points are merely highlights of what ANSI/ISA-18.2 covers, but they should give you a sense of the breadth of the discussion. Within ANSI/ISA-18.2, you will find the collective wisdom and experience of a large group of industry experts who have worked together to create a way for you to be more successful.

If you are actively engaged in a new DCS project or a major upgrade, there may be pressure from management to speed up progress and get the new system installed and operating as quickly as possible. Such a mindset is shortsighted if it comes at the expense of the kind of planning necessary to ensure an effective alarm management implementation.

Following a standard, such as ANSI/ISA-18.2, can actually speed up the process. You will not have to backtrack to complete elements that could have been done more effectively in a more sensible order. Time spent in planning following ANSI/ISA-18.2 can help you avoid problems during startup, ensure smoother plant operations, and result in a more successful project

About the Author
Leila Myers is a consulting engineer with Yokogawa’s global strategic marketing group, USMK, in Dallas, Tex. and has worked on the asvanced decision support strategy. Myers has more than 30 years of experience planning, implementing, and commissioning automation projects at various industries, such as oil and gas, chemicals, polymers, energy, food, and water treatment. Previously, she has been with Honeywell, Amoco/BP, and Vista Chemical Company. Myers has a B.S. and M.S. in chemical engineering from Ohio State University.

A version of this article also was published at InTech magazine

Pin It on Pinterest