- By Lee Swindler, Rick Slaugenhaupt, Ron Carlton
- System Integration
- 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.
When alarms serve the safety system, analysis must be handled with care
By Lee Swindler, PMP, Ron Carlton, and Richard Slaugenhaupt
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.
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.
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.
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.
We want to hear from you! Please send us your comments and questions about this topic to InTechmagazine@isa.org.