At the intersection of alarms and safety systems

When alarms serve the safety system, analysis must be handled with care

By Lee Swindler, PMP, Ron Carlton, and Richard Slaugenhaupt

Systems Integration Main

It is not difficult to find resources related to safety instrumented systems (SISs) or alarm management, but discussions relating the two and considering their overlap are rarer. In fact, one could conclude that the two are not related at all, especially when companies address them at different times or with different personnel.

In a greenfield plant or process unit design, the hazard and operability (HAZOP) study is usually very early in the project-well before any concrete is poured or pipes are welded. Major hazards identified often trigger some equipment redesign. When the HAZOP is finished, a layer of protection analysis (LOPA) may be warranted to determine if a SIS is required (figure 1). When the automation systems are finalized later, attention turns to alarm rationalization.

An entirely new team of people, perhaps far removed from the HAZOP and LOPA efforts, may address rationalization. If a company is disciplined and fastidious about documentation, it is simple for the rationalization team to incorporate the results of the safety analysis, but this is not always the case. This is unfortunate, because details of the safety analysis play a substantial part in defining how the alarm rationalization process incorporates safeguards and independent protection layers (IPLs).

The most important layer of protection in any process is effective process control. Short of an outright mechanical failure, operations within normal boundaries produce few, if any, incidents. But no basic process control system (BPCS) can handle every possible disruption, and there will always be some process upsets.

The alarm system tells operators about disruptions that the BPCS cannot adequately handle automatically. An operator response is then required to fix or mitigate the problem before it escalates to the point where the SIS has to act. By definition, every alarm has an associated operator response, and the operator needs to know the appropriate action.

Sys Integ Jan-Feb fig 1
Figure 1. For most companies, the design of a safety system moves through distinct phases, each building on the previous effort. For this process to work correctly, each team must document its work thoroughly.

Scope limitations

It is logical to perform a HAZOP before construction has proceeded too far. For many companies, hazard analysis is tedious. A group spends many days hammering it out and might not want to extend the effort with discussions about alarm rationalization at this stage. Moreover, the automation system design may not be far enough along to make such a discussion practical. This is not a problem if the results are thoroughly documented, but poor documentation can cause significant problems for subsequent design efforts.

The HAZOP analysis identifies hazards in the process and determines the likelihood of a particular event actually happening. The LOPA considers ways to prevent the incident, or at least mitigate the result, with a preference for multiple layers of protection to prevent escalation to a full catastrophe. A LOPA study typically comes after the HAZOP, assuming a company uses it as its safety integrity level (SIL) assessment method. This is when IPLs are identified, including those defined as operator actions triggered by alarms. If the HAZOP team produced thorough documentation, this effort should be straightforward.

Operator actions as layers of protection

When the LOPA team concludes that a particular operator action can eliminate or reduce a hazard identified in the HAZOP, an alarm may be defined as an IPL within the safety system strategy. As a result, that alarm is included in SIL calculations associated with the design of the SIS. SIL calculations can take credit from the alarm's presence and may permit less drastic action in subsequent layers, as long as the operator appropriately addresses the situation.

For example, an interlock in a subsequent layer, which would have required a SIL 2-rated system, may only require a SIL 1 level of protection to achieve the same overall effectiveness when combined with the alarm. Of course, if the alarm does not cause the operator to take the designated action, the IPL fails, and the incident escalates until it encounters the next layer of protection.

With all this in mind, it is clear that key information from these studies has to survive multiple team handoffs and be implemented properly to achieve the correct alarm response to a hazard. At each handoff and time lag, gaps can form in the chain and interfere with the desired outcome.

Once it reaches rationalization

Later-possibly much later-after the other teams have done their work, the company will form an alarm rationalization team with a goal of determining the optimal set of alarms to include in the system. The idea is straightforward: deliver the right alarm to the right operator at the right time with the right importance and with the right guidance to correct or mitigate an undesirable situation. It sounds simple, but a team can become quickly intimidated by the scale and complexity of the challenge.

The alarm rationalization team is supposed to review and evaluate the operation of the plant or unit, determine the undesirable things that might occur, and subsequently determine which associated alarms are appropriate under the criteria set forth in the alarm philosophy document. The team may create a preliminary design that includes the priority, set point, and other alarm attributes. An effective team might process more than a hundred alarms each day from a total of about 10,000, so the process is often long and tedious.

Most of the time, there are many more general process alarms than alarms related to safety conditions. So, within the massive undertaking of alarm rationalization, the team is supposed to give special consideration to perhaps 15 percent of the total. Any alarm intended to function as an IPL should be included as a given. There is no question about the validity of these alarms, because they have already been figured into a broader safety strategy and definitely need to be there. Further, they must be implemented in a way that supports the intent defined in the safety analysis.

This raises two questions: Will the rationalization team members fully understand the importance of those alarms, and will they select the best way to design the alarm to achieve the mitigation results previously envisioned?

First, the rationalization team should not be forced to determine the difference between normal alarms and those that are truly critical. The critical ones should be clearly defined and documented by the hazards analysis, and their treatment should be defined in the alarm philosophy document. When done well, the documentation should leave no doubt which alarms are intended to be IPLs. If the documentation is insufficient, there is a chance that an alarm will not be treated appropriately or be missed entirely.

Second, the HAZOP team probably will not specify how the alarm should be implemented, given the limited information available during that phase of the analysis. The rationalization team will have to review the hazard and determine what event triggers an alarm and what series of actions the operator should perform within the necessary time window to mitigate the situation.

Sys Integ Jan-Feb fig 2
Figure 2. An experienced consultant provides continuity, so all elements are completed appropriately. 

Not for the fainthearted

A team cannot be expected to review every hazard, and also to design the mitigation solution through layers of protection and alarming. Though ideal, it is impractical for most companies. In reality, it is common for each team-HAZOP, LOPA, alarm rationalization, implementation-to function independently, probably at different times and with different people (figure 2). There will be multiple handoffs from stage to stage. With effective documentation, these handoffs do not become points where knowledge is lost.

Because we are focusing on alarm rationalization, let's look at how this process works when dealing with safety-related alarms, many of which qualify as IPLs and figure into the larger SIS calculations. Alarm rationalization is a long and complex process, thoroughly documented in ANSI/ISA-18.2, Management of Alarm Systems for the Process Industries (figure 3). Many elements factor into the discussion, particularly when working with the safety-oriented alarms designed to perform as IPLs. The alarm rationalization team has to understand the methodology followed by earlier teams to recognize the hazards and generate the alarm requirements. Few companies have enough people with the depth of skill, experience, and time to do this-so outside assistance is often required.

Sys Integ Jan-Feb fig 3
Figure 3. ISA-18.2 outlines the entire life cycle for a given alarm.

Because any alarm, by definition, has to have an associated operator action, all alarms require workflow management. Operators need to know alarm responses from memory, or at least be able to retrieve them very quickly. Anyone auditing the system will likely quiz operators to make sure they can respond correctly and promptly. This means those individuals need to be trained. This is especially true for safety alarms where there is probably a very stringent time-of-response requirement. These alarms require the correct response within a specified time, or the opportunity to slow or stop escalation of the problem will be lost.

Consequently, anyone on the alarm rationalization team must bring a variety of skills and a thorough understanding of all the implications of the team's actions. The relationship between the BPCS and alarms within the SIS calculations is complex. Not all alarms recommended to help mitigate SIS-related hazards qualify as IPLs, so determining where credit is taken requires a deep understanding of these mechanisms.

If alarms being brought into the safety system are not implemented correctly, the IPL loses its validity, along with any credit in the larger SIS calculations. This often happens on a practical basis, whether anyone recognizes it or not. If the alarm is not implemented correctly, there may be excessive demand placed on the SIS, causing it to not have the intended availability to mitigate the hazard.

Alarm rationalization requires an engineering review before implementation, so alarms can be identified correctly, with each resulting alarm providing the protection required to fulfill the HAZOP, IPL, and the associated SIL calculations. Of course, this element of alarm rationalization is only one facet of a larger process. Most companies cannot pull it off single handedly, given the complexity and risk associated with the effort, but outside consultants are available to assist.

To understand the interplay of all these elements, everyone involved needs extensive process industry experience. Facilities and process units often handle very dangerous products with serious potential hazards. Handling them well requires discipline to avoid conditions that could cause an incident. Team facilitators, whether employees or consultants, must make sure all participants in the chain of analysis, design, and implementation know what is required to meet safety expectations.

Outside consultants, as neutral participants, can increase the likelihood of staying on track and avoiding internal squabbles. They also bring experience from dozens of projects-more than the range of experience possible for someone working for one company or plant.

 subscribe now jpeg

Fast Forward

  • The safety instrumented system and operator alarms interact but are usually developed by different people at different times.
  • ANSI/ISA-18.2 is a very helpful tool if it is applied appropriately.
  • Operator alarms that are intended to function as independent protection layers must be planned and implemented carefully.

About the Authors   

Lee Swindler, PMP, is a program manager at MAVERICK Technologies and has 30 years of automation industry experience. He is a TÜV Certified Functional Safety Engineer.

Ron Carlton, a a consultant for MAVERICK Technologies with 30 years of petrochemical industry experience, is responsible for work processes and philosophy development in alarm management.

Rick Slaugenhaupt, a consultant for MAVERICK Technologies, has more than 34 years of industrial controls experience.

Good documentation practices
By Joe Alford, InTech Editorial Advisory Board Member

Good documentation practices facilitate the management of projects as they progress from initial specifications to final system implementation. Good documentation is critical; often different aspects of a project are handled at different times and by different resource groups. The potential for missed, forgotten, or misinterpreted verbal communication is great. In all the documents discussed, it is important to note the rationale for the decisions. Many decisions are compromises, and it is important to capture their justification.

Selected documentation topics relevant to this article include functional requirements (FRs), system design, formal change control, alarm philosophy/rationalization, and system testing/commissioning.

Functional requirements: A validated system requires FRs documentation, and it is a best practice for all systems. This document is the complete list of project, system, infrastructure, and product requirements from the various project stakeholders. It is used to help select system vendors and in driving system design and testing.

System design: The design part of a project is driven by functional requirements and must be documented. It usually includes a multitude of documents, all the way down to detailed piping and instrumentation drawings. Design shows, for example, whether a separate SIS is included, LOPA information, interfaces with other plant computers, and where alarms will be generated.

Formal change control: Almost all major plant projects experience significant changes as the project progresses (e.g., a failure modes and effects analysis often results in significant plant or system redesign to reduce unacceptable risks from the original design). It is important for an organization to have a management of change procedure to drive activities associated with, for example, plant design changes, including the requirement to update relevant documentation. This enables late project activities, such as alarm rationalization, to draw on “up-to-date” design and other documents in determining what alarms to implement and what their attributes should be.

Alarm philosophy/rationalization: The requirements of alarm management are described in the national standard ANSI/ISA-18.2. This includes the need for an alarm philosophy document—which, in turn, describes the requirements for the various alarm management life-cycle activities, including rationalization. Alarm rationalization can be a daunting task with several attributes needing specification for sometimes many thousands of plant alarms. Many of these attribute values can best be determined with the help of documents from previously completed project activities, such as functional specifications, system design, and documentation generated as part of change control.

System testing/commissioning: Testing is largely driven by functional requirements (i.e., the primary purpose of testing is to show that FRs have been met). Testing includes verification that alarms work as intended, which requires that alarms are implemented in accordance with the results of alarm rationalization, which, in turn, depends on the results of previous project activities. For example, ANSI/ISA-18.2 notes that plants can designate some classes of alarms as “highly managed,” because they have special administrative (e.g., reporting) requirements. Any alarms designated as “highly managed” will typically be determined from documentation of previously completed project activities like HAZOP reviews.

Reader Feedback

We want to hear from you! Please send us your comments and questions about this topic to