JAN-FEB 2018

Issue link:

Contents of this Issue


Page 22 of 53

INTECH JANUARY/FEBRUARY 2018 23 SYSTEM INTEGRATION Scope limitations It is logical to perform a HAZOP before construc- tion 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 au - tomation system design may not be far enough along to make such a discussion practical. This is not a problem if the results are thoroughly docu - mented, but poor documentation can cause sig- nificant problems for subsequent design efforts. The HAZOP analysis identifies hazards in the process and determines the likelihood of a par- ticular event actually happening. The LOPA con- siders 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 docu- mentation, this effort should be straightforward. Operator actions as layers of protection When the LOPA team concludes that a particu- lar 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 ac tion in subsequent layers, as long as the op- erator appropriately addresses the situation. For example, an interlock in a subsequent lay- er, which would have required a SIL 2-rated sys- tem, 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 designat- ed 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 infor- mation 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 in- clude 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 of ten long and tedious. Most of the time, there are many more gen- eral 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 per- cent 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 rationaliza - tion team members fully understand the impor- tance of those alarms, and will they select the FAST FORWARD l The safety instrumented system and operator alarms interact, but are usually developed by different people at different times. l ANSI/ISA-18.2 is a very helpful tool if it is applied appropriately. l Operator alarms that are intended to function as independent protection layers must be planned and implemented carefully. HAZOP • Identify hazards • Judge severity • Estimate likelihood LOPA • Review HAZOP • Identify new hazards • Create IPLs • Recommend alarms Alarm rationalization • Design alarms • Design workflows • Integrate with SIS 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.

Articles in this issue

Archives of this issue

view archives of InTech - JAN-FEB 2018