Applying alarm management

• By Bridget Fitzpatrick, Doug Metzger, Graham Nasby, Joseph S. Alford, PhD
• Automation IT

Summary

ISA-18.2 technical reports for special applications

As part of their support and guidance for using the standards they develop, ISA standards committees prepare technical reports that help automation professionals on a wide variety of topics. This article highlights three alarm management technical reports that have been published: ISA-TR18.2.4, Advanced and Enhanced Alarm Methods, ISA-TR18.2.6, Alarm Design for Batch and Discrete Processes, and ISA-TR18.2.7, Applying Alarm Management when Utilizing Packaged Systems.

The ISA-18.2 standard

In 2009, the original version of ANSI/ISA-18.2, Management of Alarm Systems for the Process Industries, was published. It was further developed with ISA18 leadership into the IEC 62682:2014 international standard, which in turn was refined into the current ANSI/ISA-18.2-2016 standard.

Known as ISA-18.2, the alarm management standard is organized around the concept of the alarm management life cycle (figure 1).

As with most published consensus standards, the content of ISA-18.2 focuses on "requirements." It does not include guidance on how to satisfy those requirements. This is where the ISA-18.2 technical reports (TRs) are helpful. The TRs give guidance on how to best implement effective alarm systems using ISA-18.2. They also provide background information and examples that explain the purposes and rationale behind the requirements outlined in ISA-18.2.

The ISA-18.2 technical reports are as follows:

• TR1: Alarm Philosophy
• TR2: Alarm Identification and Rationalization
• TR3: Basic Alarm Design
• TR4: Enhanced and Advanced Alarm Methods
• TR5: Alarm System Monitoring, Assessment, and Audit
• TR6: Alarm Systems for Batch and Discrete Processes
• TR7: Alarm Management when Utilizing Packaged Systems

An eighth technical report, TR8: Alerts, Events, Prompts, and Other Notifications, is currently under development. Four of the technical reports, TR1, TR2, TR3, and TR5, are focused around specific ISA-18.2 life-cycle work processes. The other three, TR4, TR6, and TR7, cover how to apply alarm management in a number of special applications, and are the focus of this article.

TR4: Enhanced/advanced alarms

TR4 gives guidance on how and when to use enhanced and advanced alarm methods. In ISA-18.2, alarms are broken into two categories: basic alarms and enhanced/advanced alarms. Basic alarms typically consist of a set point or a trigger value, plus on-delay, off-delay, and/or deadband, but have no additional logic associated with them. The term "enhanced/advanced alarm" is used for alarms that use special features or programming. Although both basic and enhanced/advanced alarms are discussed in ISA-18.2, enhanced/advanced alarming methods are not required in all cases, and are discussed in less detail in the standard.

In general, application of the basic alarm practices in ISA-18.2 (as well as in TRs 1, 2, 3, and 5) will improve the validity and consistency of alarm design, avoid inappropriate alarms, and establish long-term viability for most alarm systems. However, the dynamic nature of some processes and related process complexities can lead to the alarm system objectives being only partially met using basic alarm design approaches. For example:

• Alarm floods, though reduced, may still occur. Individual process events can cause multiple alarms at roughly the same time for a single underlying process event.
• A process may have other operating states in addition to the normal steady state, or it may have multiple normal operating states. This means that alarms have to be designed to accommodate multiple operating states, each of which may need different alarms and/or alarm set points.
• Basic alarm capabilities may not deliver the alarm to the person who needs to respond to it on the operating team. Enhanced methods may be needed to route an alarm to the appropriate person.

The difficulty with using enhanced and advanced alarm methods is that they do add complexity to the alarm system and can be time consuming (and consequently costly) to implement. Thus, enhanced/advanced alarms should be reserved for only those situations that truly need them. It is important to first reduce the scope of any enhanced/advanced alarming effort by using basic rationalization and basic alarm design approaches as much as possible.

TR4 provides guidance and examples on the selection, design, and implementation of enhanced/advanced alarm methods. Specific situations in a number of areas are discussed, along with solution methods and examples. Some of the topics covered by TR4 include:

Dynamic alarm attributes: Various examples are provided for where alarm attributes are automatically and dynamically changed by the control system based on the current operating state of a process. In fact, both the advanced/enhanced alarming TR4 and the batch-process oriented TR6 have multiple examples of dynamic alarm attributes.

Information linking: Information embedded in the alarm itself (e.g., tag, description, and set point) may not always be enough to help guide the operator's response. Often the appropriate guidance has already been identified during the alarm rationalization stage but not built into the primary alarm presentation. Information linking within the alarm system can be used to present additional information to an operator when an alarm is triggered.

State-based alarming: A number of methods are discussed for handling alarms during changing the plant state and operating conditions in order to minimize alarm floods or inappropriate alarms. This can occur for planned operating states, such as startup, shutdown, batch phases, and different feedstocks; or it can occur due to unplanned events, such as a compressor trip. Techniques discussed include: first-out alarming, designed suppression, state-driven alarm attribute changes, and dynamically calculated alarm set points. Figure 2 shows an example of calculated alarm set points, which is touched on in TR4 and discussed more extensively in TR6.

Dynamic cause analysis and guidance: State-based alarming can often provide appropriate alarms at the right times and help avoid nuisance alarms. But there are occasions when the customary level of operator guidance (provided by typical human-machine interface systems) can be inadequate. TR4 provides an overview of how an extra layer of logic can be added to the alarm system to dynamically analyze abnormal situations and dynamically provide recommendations to the operator on how best to respond.

Alarm routing: Sending alarms to the right person can sometimes be difficult in large or complex plants. Simply sending alarms to a central control room is not always effective, as operators could be distributed through the plant, roam on foot, or even be located offsite. TR4 provides guidance and the pros and cons of several alarm routing techniques.

Use of alerts: ISA-18.2 defines alerts as notifications that share some of the characteristics of alarms but do not meet all of the criteria of alarms (e.g., may not represent abnormal situations or may not require a timely response). TR4 provides guidance on nonalarm notifications, as it is important to understand their relation to, and distinction from, alarms.

Application to alarm management life-cycle work processes: TR4 also discusses how the use of enhanced and advanced alarming methods fits within the various alarm management life-cycle work processes. If used, enhanced/advanced alarm methods have to be integrated throughout the alarm management life cycle-including testing/training, management of change, monitoring, and audit-to preserve the investment in the alarm system and to assure continued alarm system integrity.

TR6: Batch and discrete processes

Batch processes and discrete manufacturing present several unique challenges when it comes to implementing effective alarms. TR6 provides guidance for how to design and implement effective alarms for batch and discrete processes.

The special recommended alarm practices for many batch and discrete processes become apparent when understanding how most batch processes differ from more traditional continuous processes. Most batch processes consist of a sequence of time-varying steps, often representing a mixture of manual and automated operations. The existence of multiple time-varying steps (and phases), coupled with the need to start up, shut down, and occasionally to stop, pause, hold, and sometimes even abort the process, requires a different approach for alarming. Batch processes often consist of several different unit operations, each with its own equipment. The use of packaged equipment with batch processes is also very common.

Batch processes often have special requirements for logging and recordkeeping. In addition to typical process logging, alarm records often need additional details (e.g., lot number) to facilitate alarm record sorting, undertake alarm analysis, and prepare batch lot reports.

When rationalizing and designing alarms for a batch process, alarm settings often need to be dynamic, so the control system can automatically change alarm attributes and which alarms are active, based on the current step of the batch process. Dynamically changing alarm settings can be done based on the current step, a recipe, or even time elapsed into a batch step. An example based on the system state/step is shown in table 1.

Alarm routing is commonly used in batch processes, since process operators may be out on the plant floor and not in the central control room. For complex processes, a technical services group-which may not even be located in the same building-may also need to receive alarms.

TR6 also discusses how the ISA-88 batch control standards can be helpful when implementing alarms in batch-based systems. ISA-88 has both a procedural (recipe-based) model and an equipment model, which together, provide numerous software objects to which alarms can be attached and dynamically modified. In particular, TR6 provides several examples of how alarms can be implemented in the equipment model, and then how the procedural model can be used to dynamically change alarm attributes.

How alarms are tagged, logged, and presented to an operator presents some interesting challenges with respect to batch processes. In many industries, there is a need to also associate lot numbers, time since start of batch, recipe name, and other attributes with alarm records. This can be challenging to do in some control systems. Including automated linking support in the alarm system, such as attaching such data directly to the alarm records when they are created, can greatly reduce the effort to find, for example, all "product quality" classified alarms for a particular process step in a particular batch. Also, special alarm classes may need to be configured so alarms can be sorted and/or grouped in various ways as needed.

Alarm management nuances exist for discrete processes as well. For example, it is usually not practical to alarm every defective widget when hundreds or thousands of widgets per hour are being manufactured. Therefore, for discrete processes, alarms are often generated as the result of a statistical analysis of large numbers of samples (e.g., viewing thousands of widgets manufactured on an assembly line, or tens of thousands of tablets or capsules on a pharmaceutical finishing line). So alarms are often generated based on a statistical algorithm (e.g., statistical deviation within a lot) rather than a continuous analog signal (e.g., a temperature measurement exceeding its deadband). Furthermore, the generation of a "process measurement value" (PV) for use in a discrete process alarm algorithm can, itself, be challenging, as sensors for such information can include sophisticated vision systems, robotics, and RFID chips, with part of the challenge being to export the appropriate information from such sophisticated microprocessor-based sensor systems to a plant's central alarm system. The need for any such specialized alarm algorithms should be identified in a plant's alarm philosophy, with details determined during alarm identification and rationalization life-cycle activities.

TR7: Alarm management when utilizing packaged systems

Integrating packaged systems into centralized plant automation systems is often one of the most challenging tasks faced by automation professionals. From a process design point of view, packaged systems (PS) play an important role, as they are specialized pieces of process equipment with customized control systems that are specific to their function. However, packaged systems-due to their custom nature-are often the source of many headaches when it comes to integrating them into a plant's basic process control system and into a plantwide alarm system. It is not uncommon for a packaged system to use a completely different control technology platform than the rest of the plant, often causing a multitude of system integration challenges.

Common examples of plant equipment in the process industries that use packaged systems include: chillers, compressors, turbines, furnaces, batch reactors, packaging equipment, UV disinfection systems, and sump pump controllers, just to name a few. Though each is different in its function, they share a common feature of typically using individual control systems that are different from the centralized system (e.g., distributed control system) in the plant where they are installed.

TR7 begins by defining what packaged systems are and the various pros and cons of packaged systems from a system integration perspective. The TR also establishes a set of standard terminology that can be used to clearly define the various forms of packaged system control systems. For example, the location, role, and placement of packaged system control panels, which typically include alarm information, can be implemented in many ways, and the pros and cons of various commonly used configurations are discussed.

Commonly used techniques to interface PSs into plantwide alarm systems are covered, including best practices, and, again, the pros and cons of various approaches. Frequently encountered challenges with interfacing PSs are also covered, with the goal of helping the reader avoid many of the common issues when it comes to integrating packaged systems within a plant's larger overall control system.

There are a wide variety of methods that can be used to interface a PS with a plant's alarm system (and a plant's overall control system). There are also several ways to apply the ISA-18.2 alarm management life cycle to packaged systems. TR7 provides a framework of how to effectively cover packaged system alarms within a facility's alarm philosophy. The TR then discusses the unique details of packaged systems one by one, and how this in turn relates back to the alarm philosophy, complete with examples.

The text of TR7 includes a discussion of how using packaged systems impacts each of the work processes of the ISA-18.2 alarm management life cycle. The design-oriented alarm management work processes of identification, rationalization, detailed design, and implementation are covered first. The TR has a step-by-step method of how to develop packaged systems alarms, which includes leveraging the knowledge and expertise of the packaged system vendor, as well as the needs of the end user. Specific emphasis is put on resolving alarm management issues during the design process, rather than waiting until fabrication or commissioning of packaged systems.

The TR then covers some of the more operations-oriented aspects of alarm management, namely operation, maintenance, and alarm system performance monitoring and assessment. A strong emphasis is put on how changes to the alarm system with respect to packaged systems and packaged system interfacing must be made carefully as part of a management of change process. Making changes with packaged systems can sometimes be difficult because of warranty and commercial considerations, so the TR gives advice for project leaders about talking to vendors and end users about the benefits of applying alarm management to packaged systems. Lastly, the TR7 technical report provides guidance on how to audit alarm management processes when packaged systems are involved.

Helpful guidance

Every process facility is different, so there is no "one size fits all" approach to doing alarm system design. For plants that make use of complex processes, batch processes, discrete manufacturing, or packaged equipment, the ISA-18.2 technical reports provide helpful guidance on how to best implement and maintain effective alarms.

Further reading

The ISA-18.2 alarm management standard and supporting technical reports are available at www.isa.org/standards. ISA members may view the standard and TRs online at no cost as part of their ISA membership benefits.

• Facebook
• Twitter
• Linked In