Q&A Session from Alarm Management Workflow Webinar (Apr.24/2013) Question Answer from Kevin Brown Can you define HAZOP and LOPA? HAZOP stands for Hazard and Operability Study. LOPA stands for Layers of Protection. The HAZOP is used to identify major process hazard or operational issues due to the process design. The LOPA is to review the safety protection layers or safeguards to mitigate against hazards in the process. What does APD stand for? APD stands for Alarm Philosophy Document. Do you do the alarm cleanup before introducing a workflow process? This is really dependant on the support for alarm management in your facility. If support is low then I suggest you start with alarm cleanup documenting all changes, costs associated with these changes and the improvement. I would also document feedback from operators and if possible demonstrating how this improvement potentially would have mitigated an alarm flood from the last 1 or 2 incidents. If there is support at your facility then introducing workflow process right away will have an immediate impact. The maintenance and operational meeting is to discuss 3 5 bad actors per week and assign responsibility to fix. The next week you can report on the improvement as listed above which reinforces that the process is working and having a significant improvement. Do you recommend tracking if employees are following their assigned workflow process? The purpose of a workflow is to minimize the effort of maintaining the alarm management system and maximize the benefit. Initially, employees may not see the value and require tracking to enforce the importance of the workflow process. The best approach is to educate the employees on the benefit of the workflow process. Is there a different process to shelve an alarm or suppress it? This really depends on your computer control system. The system will use a form of suppression to shelve the alarm. The difference between a shelved and suppressed alarm is that the shelved alarm is time
based for when it is reactivated while a suppressed alarm will need operator intervention to un-suppress the alarm. There could be a different process for shelving versus suppressing but you could also use the same process just indicate that the alarm is being shelved or suppressed. When do we use suppressed alarms? There are numerous reasons to suppress an alarm: State or mode base change Nuisance alarm Equipment outage Equipment out of service Production change Production trials Process changes The reason you suppress an alarm is to remove a nonactionable alarm from the alarm graphic. These alarms can create complacency or hide important alarms due to the noise they create. If we expect an operator to take an action for every alarm as defined in the APD then we need to remove alarms that due to the operating conditions do not require an action. The easiest way to do this is by suppressing it. Make sure that the alarm is un-suppressed when conditions are back to normal. I have a shutdown unit. How do I shelve bad value alarms at shutdown and normalize them when my unit starts? This is called state based or modal alarm suppression. My preference for these applications is to automate the suppression based on the operation such as: When pump 101 stops and flow 112 is less than 50 suppress the following bad quality alarms. Unsuppress alarm when pump 101 starts and flow 112 is greater than 60 or valve 100 is opened greater than 10% Normally it is easier to identify when to suppress alarms then it is when to un-suppress alarms because the unit is down. Be careful how you choose your state to un-suppress the alarm because if it is done too early the operator will get all the nuisance alarms while he is starting up, creating a flood condition, or if it is done too late then the operator may not get an important alarm in time to react to it. How do you define a safety-related alarm? A safety-related alarm is an alarm that could lead to an employee being injured if the issue is not resolved quickly. Examples of these are: gas leaks (H2S), liquid overflow (toxic), equipment damage, etc.
How do you identify nuisance alarms by automatic reports? Nuisance alarms are defined as alarms that continuously activate when there is no actionable response. The reports that I use to identify nuisance alarms are: Most Frequent Alarms Chattering Alarms Symptomatic Alarms You said that a stale alarm is not required because it has been standing for 24 hours, yet our rationalization determined we needed it. How do I handle that situation? The reason I said that a stale alarm (one standing greater than 24 hours) is not required because the issue the alarm identified for the operator to resolve did not occur after the time identified in the rationalization. The way I approach these alarms is to review the rationalization documentation verifying that it is still correct then review with operations why this issue was not resolved yet there was no incident. After this review I will have determined the solution which may include removing the alarm, changing the alarm setpoint, creating a new alarm or incorporating a state based alarm. You indicated there is a difference between Stale and Standing alarms how do we incorporate that difference in my plant? Was the electronic shift log book part of 's Alarm software or stand alone? The first step is to define stale and standing alarms in your APD. Then use your workflow process to deal with these alarms. Example: Stale alarms are reviewed daily by the shift supervisor and recommendations are defined to resolve them. Standing alarms are reviewed by the operator and shift supervisor at shift change, and reviewed by the operator every hour. The electronic shift log book is standalone but can also be offered as a suite (OM Pro) with the alarm management software. We have stale alarms mainly due to process conditions, for example, low level alarms in knock out drums which are always in alarm state. Operations need the alarm, so how do we handle these types of alarms? If these alarms are only required during an operational state i.e. shutdown, startup, they can be suppressed when not required. If these alarms are required to indicate to the operator the level is low in the knock out drum then I would modify the graphic instead to show this and remove the alarm. The key to solving these types of alarms (required but always in alarm state) is to understand the purpose and consider the options to resolve other than an alarm i.e. graphic changes, user alerts. If the alarm is always in an activate state then it is of no value because the operator is not responding to it so there is no layer of protection.
Can you elaborate on how to differentiate between standing and stale alarms with live examples? Which alarm out of this has the highest priority to be taken care of? As I indicated in the webinar any alarm that rings in is considered standing whereas a stale alarm is an alarm that is active for a period of time (i.e. greater than 24 hours). The point I was trying to make during the webinar is that a standing alarm becomes reportable when it exceeds a reasonable amount of time and in my opinion 24 hours it too long. The reason we want to report and review standing alarms is because they have not returned to normal and there is still the potential that there could be an incident. If an alarm can be active for greater than 24 hours without an incident then an alarm was not required, it is labeled stale and should be reviewed and possibly removed. Example: A tank has an overflow onto the flow at the 97% of the height of the tank. The alarm is set to annunciate when the level reaches 85%. The priority on this alarm is low which means there is an expectation for the alarm to return to normal within 30 minutes based on the risk metrics. When the alarm annunciates the operator chooses to reduce the rate of the flow into the tank, however this action only results in slowing the rate of increase in the tank. Eventually the tank overflows onto the floor and there is an incident. The standing alarm report would have indicated that this alarm had exceeded the 30 minutes and needed further investigation. Same example except the tank has a second overflow that drains into the sewer below the other overflow that drains onto the flow. When the alarm annunciates the operator chooses to reduce the rate of the flow into the tank, however this action only results in slowing the rate of increase in the tank. Eventually the tank overflows into the sewer and there is no reportable incident. The standing alarm report would have indicated that this alarm had exceeded the 30 minutes and needed further investigation. Based on normal operation leaving the tank to over flow to the sewer is an acceptable response. If the overflow to sewer can handle the maximum feed rate into the tank and overflowing to the sewer is acceptable then this alarm would be on the stale alarm report and require the alarm to be removed. The standing alarm has the highest priority because there is a potential for an incident. There is no opportunity for an incident on the stale alarm and that is why it has a lower priority.
How do you calculate alarm KPI and how long will it be optimum after the commissioning phase of project? The alarm KPIs need to be defined in your APD and based on ISA 18.2, EEMUA 191, API 1167 or a corporate standard. The calculation is defined within these documentations. The purpose of KPIs is to indicate where the problem areas are and if we are having a positive impact on improving them. I would be monitoring them throughout commissioning and into operation. During the commissioning phase the alarms will be tested and these need to be identified and removed from your KPI calculations. What determines the frequency of alarm rationalization, assuming no new equipment is added to the process? Besides new equipment, you need to consider having a rationalization when the control strategy or process is changed. I would use the alarm KPIs to evaluate the operations to determine if a rationalization is required. For example, if alarm count per operator per hour has been increasing over the last 30 to 60 days and this is not due to nuisance alarms then consider rationalizing that process. Another option is to pick one process unit per year and rationalize it to confirm the alarms and to keep the rationalization team trained. How can we rationalize alarms for new equipment? Is there any guideline? The challenge with rationalizing new equipment is that the operators have no operating experience on this process. That being said it is important to rationalize this equipment before it goes into service because the operators will not be familiar with it and will need these alarms to indicate issues. The process for rationalizing new equipment is the same except you will require other personnel to participate: Vendor of supplied equipment 2 operators instead of one, with experience on similar equipment and process Process design engineer We have experience rationalizing new equipment and Greenfield and are happy to discuss our process with you. Can alarm rationalization be carried out if the facility does not have an alarm philosophy document? Yes a rationalization can be held without an APD, however I would not recommend it. If you do not have an APD then you will need to define the following: Alarm definition Risk matrices Alarm types Alarm design Graphic design, as it relates to alarm
If you do not have these parameters defined prior to the rationalization then the rationalization will take longer and require re-doing parts of it as you define these parameters. These parameters will need to be incorporated into your APD once it is written. We are starting the rationalization process in our refinery. Is there any standard guideline for Deadband, Filtering and Time Delay for typical loops? The ISA 18.2 or EEMUA 191 list starting values for deadband for measurements (i.e. flow, pressure, etc). My preference is not to apply a global deadband, filtering or time delay unless it has been identified that the measurements for the process are typically noisy. I identify the alarms that require these techniques through the chattering alarm report, or if the alarm setpoint is close to the operating setpoint. The measurement and results desired will determine whether to use a deadband, filter or time delay. The University of Alberta completed a study on applying a deadband to a nuisance alarm and determined that deadband will only resolve about 20% of the problems. Due to the process and measurement you may require more than one of these techniques to resolve the issue. If there are currently no deadbands or time-off delays implemented, would you do that as a standard with all alarms in parallel with the bad actor program? No I would not apply deadbands, filtering or time delays as a standard. I would only use them for the bad actors. Trying to resolve Bad PV alarms we are thinking to increase the extended range of analogue inputs. Is there any standard concerning this parameter as a percentage of the instrument range? I am not sure what you mean by extended range. If you are suggesting increasing the engineering range on the DCS beyond the design on the instrument calibration then this will not solve your problem and will instead create inaccuracies in your measurement. BAD PV alarms in my opinion are maintenance alarms and need to be dealt with by the instrument department. When a BAD PV alarm is created due to shutting down, consider suppressing these alarms during this state. If the operation operates outside of the calibration of the instrument then consider recalibrating it based on the range (instrument-based) or purchasing an instrument for the range of the operation. If BAD PV alarms are being created due to the 4 20 ma signal dropping (noisy signal, flaw in instrument), consider adding a time delay on for the alarm.
How do you incorporate the Time delays/dead bands for a Bad PV Alarm in s Experion and TPS? Without using logics? In Experion PKS R410, we introduced the ability to configure on-delay timers and off-delay timers (along with a deadband value for chattering alarms) for controller-based alarms. See the example screenshot of a DACA block (bottom of page 9). Can you explain the relationship between Master Boundary Data (MBD) and Alarm Configuration Management (ACM)? The Alarm Configuration Management (ACM) is the master alarm database. The software application connects to the computer control system and stores the alarm settings along with the rationalization data. If you are storing the Master Boundary Data (MBD) in the limit repository the two products are integrated. You showed a Operations Logbook screenshot, how do we get the alarm data in OL? Operations logbook can gather data from different sources including alarm database for shift summary. How can we target alarms on oplimit crossing? I am not sure what you are asking. Is this output limit or operation limit? Are you looking to report on this issue or what you need to do to resolve this issue? UOP CCR alarm appears for every cycle of lock hopper filling and emptying. As per ISA18.2 this cannot be categorized as an alarm but it is difficult to convince operations as it is UOP. Firstly define alarm in the APD. Alarm: is a notification to the operator indicating a condition change requiring operator intervention. If there is no operator action then based on the definition there is no alarm. When we have an alarm system that contains alarms that do not require an operator action then we are dependent on the operator deciding if this alarm requires an action. These alarms also build complacency and distract the operator from focusing on the process. If this is a normal condition and requires a notification to the operator, consider changing this to a user alert. If this condition is a normal condition but does not require an operator action unless there is no fill or empty alarm, consider changing the alarm to indicate that the lock fill or empty did not occur as expected. Do plants with dedicated control room personnel have more success with alarm management? Success with alarm management is not based on dedicated control room personnel but a dedicated operating staff that are continuously reviewing and improving the alarm system. I have seen success with and without dedicated control room personnel.
I have a facility with thousands of alarms appearing every day. I did the AOA (Alarm Objective Analysis). On the other hand, I have PHA (Process Hazard Analysis) and SOA (System Outage Analysis) telling which alarm should be set. Are the PHA and SOA enough to consider as the alarm reference, or should I continue the alarm rationalization using AOA? If you are getting thousands of alarms per operator then yes you need to continue with the AOA. PHA and SOA are excellent for identifying risks but they do not take into account the alarms as part of a process. The AOA will identify duplicate and redundant alarms which can be removed, reducing your alarm count. The process will result in proper alarm setpoints and priorities. During the AOA you identify an alarm is not required due to no operator action, redundant or duplicate, but if it was identified in the PHA or SOA then before the alarm is removed this result will need to be reviewed again by the PHA and SOA team. This can create extra work and that s why I suggest including AOA functionality in other processes i.e. HAZOP, LOPA, PHA etc. In our last PHA (Process Hazard Analysis) revalidation study, we found a bunch of controls had been compromised. In a plant where new resources are a problem, the team decided on putting some alarm-based controls that were prioritized. How often should we redo the alarm prioritization study? The purpose of having procedures is to confirm everyone is following the requirements. The new resources need to be educated on the APD and the rationalization process prior to making any changes to the alarms. The prioritization is determined during rationalization and consider re-doing a rationalization based on: Alarm rate is increasing New equipment New control strategy Incidents are due to alarm issues If your process is not changing, the bad actors are being dealt with properly and the alarm rates are within standards then you may never require a rationalization. Operations think the alarm problem at our facility is a maintenance issue which the control team must fix. You had several slides that involve their participation. Could you suggest how I get operations more involved? This is a common issue that I have seen at numerous facilities. My experience is that when operations own the alarm issue then the facility is successful with their alarm management program. To solve this problem we first must understand the reason why they believe the alarm problem is a maintenance issue. Typically the computer control system repair is done by maintenance and so this is seen as a maintenance issue and not an operations issue. The best way to approach this is through education with training sessions and workshops. An analogy I like to use is that your car has developed a noise so you take it to your mechanic. After a quick review, he figures it will only cost about $100 to fix and will be ready when you are done work. At the end of
the day you show up at the garage to find your motor sitting on the work bench in pieces and the mechanic tells you that your car won t be ready until next week and the bill will be $4500. Would you accept this? Then why would you give maintenance the responsibility to fix the alarm problem when the purpose of an alarm is to indicate to the operator that the process or equipment operation has changed and requires an action to correct. We have held workshops and training for the sole purpose of educating different groups within a facility and would be happy to explore a solution with you. Screenshot of DACA block: