Issuu

EDITORIAL Who is Your Alarm Management Champion? Katherine Persac Executive Editor

Who is the alarm management champion at your site? Normally, operations is the alarm owner, but an operations person may not be the alarm management champion. A lot of alarm management projects go really well and for the first few weeks after the contractor leaves the site, your metrics are really good. Then, you add a new piece of equipment. Who does the alarm management for it? What system does it belong to and who knows the operating limits for the new piece of equipment? After a year of adding equipment and no one taking responsibility for the alarm management, your operators are getting more alarms. And two years later? Your plant manager thinks that alarm management was a waste of money. This is why itâ€™s so important for someone at the site to take on the role of alarm management champion, and it should be well advertised. They should be known to everyone in controls, operations and all of the other alarm or boundary owners. Itâ€™s amazing how much difference one person can make. Do you have what it takes to be the champion at your site?

CONTENTS PROCESS SYSTEMS MAGAZINE | WINTER 2017

Features 04

Editorial - Katherine Persac

Can You Prevent Alarm Floods?

13 19 23 24 26 30

A Look at Why the “Seven Steps” May Not Deliver Desired Results Leveraging Procedural Automation Alarm Management Meets SIS When Converting Your DCS, Don’t Forget Your Alarm Management System Ten Important Questions to Ask Before Starting an Alarm Management Project Intern Spotlight - Rationale for Alarm Rationalization

Process Systems Magazine © Winter 2017, Published and Copyrighted 2017 by ProSys, Inc., Baton Rouge, LA 70816. All rights reserved. Permission to reproduce part or all of this issue must be secured in wri�ng from the publisher. Complementary subscrip�ons are at the discre�on of the publisher and may be cancelled or modiﬁed at any �me. We assume no liability for the content of this issue and all points and ideas are strictly that of the writers involved and not that of the publisher, publishing company, prin�ng company or editors.

Can You Prevent Alarm Floods with Native Functions in the Control System? Missy Jones

The only way to answer this question is to examine what exactly an alarm flood is and what causes an alarm flood. Then, examine whether these events can be prevented using functions that are native to a typical control system.

What is an alarm flood?

ISA 18.2 defines an alarm flood as follows: • “condition during which alarm rate is greater than the operator can effectively manage (i.e. more than 10 alarms per 10 minutes)” Alarm floods are determined by using the number of alarms annunciated to the operator in each 10- minute interval: • Alarm flood begins when the alarm count in any 10-minute interval is more than 10 • Alarm flood ends when the alarm count in any 10-minute interval is less than 5 Alarm floods can be described using four different metrics: • Alarm flood count – the number of alarm floods occurring in a specified interval of time • Duration – the length of the flood condition in minutes (or hours) • Alarm count – the total number of alarms that occurred during the flood period • Peak alarm rate – the highest number of alarms that occurred in a single 10-minute interval Overall, the percentage of time any alarm system should be in a flood condition should be less than ~1%. A typical example of an alarm flood may be: • Compressor Lube Oil pump trips (1 alarm) • Low & Low Low Lube Oil Pressure (6 alarm for triplicated instrumentation) • Auxiliary Lube Oil pump is started (1 alarms) • Aux pump fails (1 alarm) • Compressor trips on Low Lube Oil pressure (5 – 10 alarms) • Compressor Low Suction pressure alarms, Compressor Low Discharge pressure alarms, Compressor Low flow alarms, more trip conditions met, auxiliary system alarms (seal gas, buffer gas, etc.), KO drum level alarms, … (>50 alarms) • Alarms generated by process conditions upstream and downstream of the compressor (20 alarms)

When do alarm floods occur?

When first starting an Alarm Management initiative, many facilities are running in what can be considered a “flood” condition at all times, i.e. the normal rate (or steady state) of alarms that are presented to the operator in the control room exceed 10 alarms in 10 minutes. During times of upset, the alarm rates exceed even flood conditions, rendering the alarm system useless. The first step in an Alarm Management initiative is to complete Alarm Rationalization. This step involves the reengineering of alarms such that each and every alarm has a defined operator response and meets all of the criteria for a good alarm as set forth in the Alarm Philosophy Document. An important criterion for a good alarm is that it should be relevant. This means that the alarm should only occur during process conditions that require the alarm to allow the operator to respond and prevent unwanted consequences. An example of an alarm that is not relevant would be a compressor low discharge pressure alarm when the compressor is shut down. This alarm is only relevant when the compressor is running. It is therefore important to consider not only static, but also dynamic alarm rationalization. • Static Alarm Rationalization considers the need for an alarm during “normal” operating conditions, e.g. the unit is running. • Dynamic Alarm Rationalization considers the need for an alarm during all operating conditions, e.g. Startup, Recirculation, Running, Shutdown, etc. Static Alarm Rationalization results in the reduction of alarms during steady state operating conditions, but does not significantly reduce the number of alarms during upset conditions. As such, alarm floods are still very likely to occur. Dynamic Alarm Rationalization specifically addresses the need for alarm suppression during operating conditions that make the alarm irrelevant. This reduces the number of alarm floods that occur.

Why is it important to eliminate alarm floods?

The biggest danger associated with alarm floods is the possibility of missing a critical alarm. The likelihood of missing important alarms is increased with the number of alarms occurring in the flood. When tens or hundreds of alarms are occurring in rapid succession, the operator may not even see a particular alarm before it scrolls off his alarm summary display. At times like this, the operator tends to ignore the alarm summary as it becomes more of a hindrance than a helpful tool.

Control System Functionality to Prevent Alarm Floods

Modern control systems include tools for improving alarm functionality. But is it possible to prevent alarm floods using these tools?

Simple Alarm Reduction Tools

Most control systems include basic tools for reducing certain nuisance alarm conditions. These capabilities are usually simple to configure and, when properly applied, can reduce a lot of alarm noise. These nuisance alarms can add to alarm floods even when the upset conditions are not related. Alarm Deadband Alarm deadband is defined as the change in signal from the alarm setpoint to clear the alarm. See the Figure 1 below:

Figure 1: Alarm Deadband Configuring a deadband prevents nuisance chattering alarms when the variable’s process variable (PV) may be operating close to the alarm setpoint. The alarm stays in the Active state until the PV has cleared the deadband. On many systems, alarm deadband can be configured as either a percentage of the variable’s total span or as an absolute value in engineering units. While the deadband is simple to use and configure and reduces nuisance chattering alarms, it can only be applied to analog values.

Alarm Delay

Alarm delay can typically be configured in two ways: • On-delay: The delay time between alarm activation and alarm annunciation. Figure 2 shows the results of having a configured On-delay of 10 seconds. The first three occurrences of the alarm are not annunciated to the operator. Only once the alarm has been in the active state for a continuous period of more than 10 seconds, is the alarm annunciated. This prevents annunciating alarms which may be fleeting in nature and clear before the operator can take any corrective action.

Figure 2: Alarm On-Delay

Our last project came in behind schedule and over budget. The next project is even bigger. It’s going to be a monster unless we do things differently.

IT’S IMPOSSIBLE

It’s time for Project Certainty. Emerson’s transformational approach to capital project execution provides a fresh, new look at projects so that you meet your original budget and schedule targets. Using a combination of innovative products and services, Emerson provides a path to reduce complexity, eliminate cost, and accommodate late changes. Reset design, engineering, and project management to make your project more predictable and reliable. Learn more at www.emerson.com/project-certainty. The Emerson logo is a trademark and service mark of Emerson Electric Co. © 2017 Emerson Electric Co.

• Off-delay: The delay time between alarm deactivation and the alarm clearing. Figure 3 shows the results of having a configured Off-delay of 30 seconds. The alarm is not cleared from the operator’s alarm summary until it is inactive for a continuous period of 30 seconds. This prevents the reannunciation of the alarm after only a very brief period out of alarm condition.

Figure 3: Alarm Off-Delay

Alarm Suppression Tools

Many control systems include some form of alarm suppression tools. These can vary in complexity and effectiveness.

Alarm Shelving

While alarm shelving is a very useful tool for temporarily getting rid of nuisance alarms, it really does not directly reduce the number of alarms contributing to alarm floods. Alarm shelving typically relies on operator intervention after an alarm has occurred to remove the alarm from the alarm summary for a defined period of time. While this may prevent a nuisance alarm from occurring during an upset condition, the two events are not related and the reduction in alarm during the flood is purely coincidental. As such, alarm shelving is not considered a tool for reducing alarm floods.

Advanced Alarm Handling and Suppression

Dynamic Alarm Suppression is an advanced alarm handling technique that prevents an alarm from annunciating to the operator when plant operating conditions make the alarm irrelevant, e.g. low pump discharge flow when the pump is intentionally not running. Dynamic Alarm Suppression can be as simple as the one-to-one relationships (pump stop, low flow) or can be complex relationships based on multiple operating conditions dynamically suppressing many alarms. Dynamic Alarm Suppression is the most effective tool for reducing alarm floods. But do control systems have Dynamic Alarm Suppression capability?

Simple Dynamic Alarm Suppression

Simple Dynamic Alarm suppression techniques are useful in preventing alarms based on well-defined operating conditions of a single piece of equipment. For example, when a pump is not running, there is no need to have a low flow alarm on the pump discharge. This type of alarm suppression is usually based on the evaluation of only a few process variables that evaluate to either a true or false state.

Complex Dynamic Alarm Suppression – State Detection

The suppression of alarms dynamically based on the detection of the current operating state of a unit is more complex than the simple DAS described above. This form of DAS uses State Detection Algorithms to determine an operating state for a unit or piece of equipment and changes alarm attributes for each state to ensure all alarms presented to the operator are relevant. A State Detection Algorithm (SDA) is a logic driven process that is used to determine the current operating state of a plant, unit or piece of equipment. The algorithm may use the value of process variables (analog or digital), defined constants, deadbands and delays to accurately predict the current operating state, often employing voting logic. For example, to determine if a compressor is running, a simple algorithm may look at:

Figure 4: State Detection Algorithm This would just be one part of the algorithm, with different variables being evaluated to determine other cases such as “Lube oil only”, “Shutdown”, etc. When the SDA evaluates a certain operating condition (Running, Shutdown, Circulation, Decoking, etc.), alarms which are not relevant during that mode of operation are suppressed. The actual suppression may be done using different alarm attributes, depending on the capabilities if the control system (e.g. change to a non-audible alarm priority, set a suppression bit, disable the alarms, etc.) For the Dynamic Alarm Suppression to be effective, the following functionality is required: • The SDA needs to be assessed at a fast-enough rate to prevent the alarms from occurring, i.e. the alarm should not be presented to the operator on the alarm summary display and then be removed after a period. The ability to evaluate state changes at a fast-enough rate depends on the processing capability and resource requirements of the control system. • The system should have a form of deadband built in such that the evaluated operating state does not toggle between two states unnecessarily. • The system should have the capability of determining the appropriate operating state in the event of signal failures and communication faults. • The system should handle a situation when more than one operating situation evaluates to true • There should be the ability for an operator to override the evaluated state to a more secure state (i.e. all alarms enabled) if necessary. • There should be visible indication to the operator of the current evaluated state and the current modifications to the alarms in the state. • The system should not necessarily use the same criteria to evaluate a state as true and false. An additional benefit of a Dynamic Alarm System is to enable alarms in an operating state such that the alarms do not occur unless the alarm condition is valid. For example, if the state of a compressor changes from the “lube oil only “case to the “running” case, the low pressure and temperature alarms on the suction and discharge should only be re-enabled once the process values have cleared any low alarm conditions. This prevents a flood of alarms from occurring during state transitions.

Conclusion

Most control systems can prevent certain nuisance alarms by using built in functionality that is simple to configure and apply. However, for more complex alarm flood suppression techniques, such as Dynamic Alarm Suppression using State Detection Algorithms, most control systems do not have a fully integrated, easy to configure, effective tool. Organizations that have implemented advanced alarm flood suppression techniques are using customized logic or third party applications to achieve the desired results.

11 continued...

A Look at why the “Seven Steps to a Highly Effective Alarm System” may not deliver the Results you Need

Tom Nolan

This is a look at why the “Seven Steps to a Highly Effective Alarm System” as proposed in “The Alarm Management Handbook” will probably not deliver the true meaningful alarm system performance that you need for safety and loss protection. Step 1 proposes to Develop, Adopt and Maintain an Alarm Philosophy, which is good advice. If you have alarms, you should have an alarm philosophy, but don’t create your philosophy alone. Acquire help from alarm management experts that are able to guide you through the process and help tailor your philosophy to your specific needs. The rest of the alarm management program is dependent on and audited against the alarm philosophy. The folks at ProSys know how long term decisions in the alarm philosophy will affect the entire life cycle of the alarm management program and can facilitate the development of a successful alarm philosophy. Choose to begin this journey with folks who have been down this road successfully many times. Step 2 is to Collect Data and Benchmark Your System. Benchmarking is a great idea, but do not make the mistake of thinking that this is a numbers game. While it is good to know where you started, good alarm management relies on the quality of the alarms. Data needs to be carefully considered, and the process state in which the data is collected needs to be understood. High alarm rates during changes in the state of the plant such as start up, upsets and shut down are indicating that a dynamic rationalization is called for. Benchmarking only the running state of the plant will not give the full story. In the running state, the alarms may not appear to be a problem over time, but 70 % of incidents occur in startup and shut down situations. This is where the alarm system is needed the most and has the poorest performance without dynamic management. Bottom line, up and running data cannot determine serious problems of managing alarms throughout start up, shut down or during a serious upset. For example, Navy pilots critique

each landing on an aircraft carrier, even the ones that go well. This is worth it because a bad landing on an aircraft carrier can cause a lot of damage. In your case, a bad landing for your plant has the potential to cause a lot more damage. Make sure that when the plant comes down, hard or soft, you study the landing. You will probably see a need for dynamic alarm management through these transitions. Step 3 is to Perform â€œBad Actorâ€? Alarm Resolution. This can often turn into a game of Whack-a-mole. Remember that all alarms need to be rationalized, and receiving alarms is not a bad thing. If alarms are coming in at a high frequency and are legitimate alarms, that is a good thing. The high alarm loading may indicate the need for process improvements, instrumentation improvements or operating discipline issues, but the alarm itself may be doing its job just fine. If they are not legitimate alarms, they should be eliminated through rationalization. If they meet the criteria of a good alarm, they need to be there. Never think that this is about removing alarms. Throughout the alarm management process, there will probably be alarms that are removed because they are not indicating an abnormal situation, are not actionable, are duplicates, etc. For a quality alarm system, attention needs to be given to what alarms need to be there. This process may lead to adding alarms as well as taking them out. It is not about getting more or less alarms, but about getting the right alarms. Study PHA, LOPA and other documents to know what needs to be alarmed is being alarmed. When done properly, the process can also identify risks. In the process of determining the required response time from the operator to set the alarm priority, it is unrealistic to think that the operator will be able to act quickly enough to mitigate the undesired consequence. This points out an opportunity that can be taken for automatic action in the DCS. With that said, stopping after steps 1-3 is not a good idea, even if you do see some reduction in the alarm loading. Again, this is not a numbers game. Numbers can indicate a problem, but they cannot indicate if there is no problem. Focus on the quality of the alarm system. If the alarm is in the DCS, it needs to meet the criteria of an alarm. It indicates an abnormal situation that will cause an undesirable consequence which then requires operator action to mitigate it. A bad quality alarm that does not come in often and is unfamiliar to operations can cause big problems in an upset situation. This was identified as a factor in Three Mile Island. The root cause of an alarm may be something wrong in the process that needs action, poor operating discipline, instrumentation issues or a bad quality alarm (which should not be there, is not configured correctly or needs dynamic management). Alarms are telling the process owner something. By fixing things at the root cause level, avoid the Whack-a-mole game and create a safer and more profitable process.

Step 4 is to Perform Alarm Documentation and Rationalization (D&R). This is the only real way to insure the quality of your alarm system. The ProSys team has significant process, process control and alarm rationalization experience that dates back to the very beginning of alarm rationalization. Alarms are an emotional subject with plant personnel. ProSys brings objective criteria and process knowledge to an alarm rationalization. Assembling a team of operators and engineers and leading them through the causes, consequences and required actions of alarms, leads to consensus and by in on the validity of an alarm. Skeptics that enter the process leave as proponents after they see and participate in the process knowing that the alarm system will inform operations when an action is required and with the proper priority while not overwhelming them with an alarm flood. Using the team’s process knowledge to add dynamic management and shelving to the rationalization process is key to achieving ISA 18.2 levels of performance when they are most needed in startups, shutdowns and upset conditions. Step 5 is to Implement Alarm Audit and Enforcement Technology. This needs to be done in a way that is effective and is not a significant manpower burden. AgileOps Master Control System Database provides complete documentation of the approved alarm system and configured values. The auto-discovery feature can automatically detect changes to audit the existing system. The database contains not only the standard configuration data but also the systems and cases used for dynamic management as well as the process boundaries. It provides a complete and auditable database of the approved configuration against the running system. Step 6 is to Implement Real Time Alarm Management. The performance that your alarm system needs to provide is that laid out in ISA 18.2. To achieve ISA 18.2 level performance, a static rationalization alone is not adequate. Dynamic alarm management is not just nice to have. Doing this as a separate step from Step 4 just wastes time and money. A better approach is to ask the “When?” question when during your alarm rationalization. Ignoring Dynamic Behavior will not deliver the needed performance. An ASM Consortium finding with a study of 37 consoles for 90 months of data overall found that for Static Rationalization – “peak alarm rate is not closely correlated with the degree of rationalization” Zapata and Andow – HUG 2008 – Highlights from the ASM Consortium.

If you think about it, it is no surprise. A static rationalization optimized for the running state will undoubtedly produce alarm floods, even if it is done well when the plant is out of the normal running state. Why, even if it is done well? An alarm is for an abnormal situation. What is normal is dependent on the process state the facility is in. For example, a low temperature in the bottom of a distillation tower is abnormal while in the running state. It has undesirable consequences and action must be taken. This is a perfectly legitimate alarm. If the plant is down for maintenance or just starting up, a low temperature in the bottom of the tower is not abnormal, and there is nothing that anyone needs to take action on. It is not a valid alarm when the facility is in this state because the bottom of the tower is cool as it should be. A static rationalization done for the running case has to bring in all alarms even when they are not valid, meaning that there is nothing abnormal and no actions need to be taken. In a down for maintenance state, the low tower bottoms temperature along with the other alarms that should not be in are now filling the alarm screen. This makes it more diďŹƒcult to see and respond to alarms which are legitimate and at a time when there are more people than usual out in the process area. Many of these folks may just be there for the shutdown and do not have as much knowledge to keep themselves safe in the plant as the normal operating crew. It is a bad combination. In terms of risk reduction, the dynamic management of alarms provides a process state by state rationalization that optimizes the alarms when they are needed most during upsets, shut downs and startups. Step 7 is to Control and Maintain Your Improved System. Processes will always change with time, condition and feed stock. Instrumentation will fail, be added and removed. Many things will affect the alarm system over time. Monitoring performance is needed to make sure that hard won improvements do not degrade over time. Conclusion Over the years, we have learned that alarm management is not a numbers game. One alarm that comes in at a bad time and creates confusion that leads to a wrong decision can have devastating consequences. If the alarm is in the DCS, it should meet the criteria of a legitimate alarm. The quality of the alarm is most important, and alarms needs to be rationalized.

When you put plant safety first — you’ll last. Get Safety Certified!

hy would you trust anyone other than the developer of the renowned, OSHA-endorsed ISA84 standard to teach you how to keep your plant safe? Our hands-on safety certificate programs give you the knowledge you need to improve the safety of your industrial processes, and give you a chance to prove your expertise. • Certificate 1: ISA84 Safety Instrumented Systems Fundamentals Specialist • Certificate 2: ISA84 Safety Integrity Level Selection Specialist • Certificate 3: ISA84 Safety Integrity Level Verification Specialist Earn all 3, and you’ll be designated an ISA84 SIS Expert!

Visit www.isa.org/safetycertificate or call +1 (919) 549-8411 to register.

Leveraging Procedural Automation John Veldhuis, ProSys

Many chemical and refining companies are leveraging Procedural Automation (also referred to as State Based Control) effectively on operating units and this is becoming more widespread as demands for better product transitions, handling of unit upsets and increased reliability in production facilities increases. Further to drive consistency and leveraging Procedural Automation, the ISA is releasing a new guideline “ISA106, Procedure Automation for Continuous Process Operations” which will be of interest to companies looking to benefit from their automation assets. By automating what were previously manual procedures and incorporating them into the control system, the following improvements can be made: • Reduction in time to execute the procedure • Elimination of mistakes or omitted steps when carrying out the procedure • Improved outcome consistency and equipment reliability by using best practices • Operations can focus on critical/high value units when upsets occur

Typical execution time reduction is between 5-30%. The value of eﬃciency and reliability gains are dependent on the specific process and need to be evaluated on a Unit basis. In Larry O’Brien’s September 2010 ARC paper titled “Why We Need a Better Approach to Procedural Automation”, he states the following: “In demand-limited industries like refining, the overarching objective is to improve utilization. This cannot be achieved without reducing unplanned downtime. Research shows that the largest reason for unscheduled downtime is operational or human error. This accounts for approximately 42 percent of the unscheduled shutdowns in the process industries. Of that 42 percent, 14 percent is directly related to procedural error. When researching the role of operators in the Refinery of the Future, several major operating companies concluded that they could address this by empowering a higher level of perspective on the entire production operation, one that enables flawless intervention by exception and relieves operators of manual tasks, freeing time for operators to perform more value-added activities.”¹ Specific improvements cited by our customers include reduction of incidents, faster start-ups and shutdowns, time saved using “safe park”, catalyst regeneration consistency and increased speed, faster and more

consistent transitions, and conversion of disparate operations into Standard Work. Incidents on Start-Up or Shutdown: Typical reduction opportunities are reflected in the comments of Scott Ostrowski and Kelly Kheim of ExxonMobil Chemicals: “A disproportionate percentage of process safety incidents have occurred during transient operations, which include those conducted infrequently such as startups or shutdowns as well as abnormal or emergency events. A typical refining or petrochemical facility will spend less than 10% of its time in transient operations — yet 50+% of process safety incidents occur during these operations”.² Process Knowledge: Additional benefits can be in the capturing of process knowledge and capturing that within the state based control. This is illustrated by Tom Nolan in his joint paper entitled “ State Based Control and the Value Delivered from the Initial Design Through the Operating Life of the Facility”, AIChE, 2016. “Loss of process knowledge through attrition is often an issue for those facilities that do not have a high level of automation or state based control. A large percentage of the work force is nearing retirement age. Within the next five years, about 20% of the workforce could retire.”…. “ This knowledge transfer has to happen before the experienced personnel retire.”³

Safe Park: Some customers have developed safe park states that allow a unit to idle in place at a safe, recycling, or reduced operational state for a short time. This gives operators time to return an upstream or downstream operation to its normal operation instead of shutting down the operation under control. Considerable time and intermediate product can generally be saved. Catalyst Preparation or Regeneration: Catalyst preparation or regeneration is frequently very demanding. We have automated very complex preparations and regenerations to improve catalyst consistency and to reduce the time these take. One unit alone reduced its catalyst regeneration time by 15% while simultaneously improving catalyst consistency. Transitions: A significant percentage of our customer’s requests for Procedural Automation derive from application to Units that operate in multiple modes or for different products for which transition material needs to be minimized. In these cases Procedural Automation is often coupled with sophisticated APC, non-linear, or model-based control systems. Simpler systems can be managed with transition tables. Customers typically report 10-18% reductions in transition times. Perhaps most importantly the best practice in these transitions is followed every time, simplifying the application of Standard Work (to use the Toyota nomenclature). A typical customer here is an ethylene furnace or other

system that has a regular cycle of decoking or unit cycle. Impact on Equipment Reliability: A significant percentage of equipment failures are related to operating outside the equipment’s intended design envelope, so-called “self-inflicted” equipment failure. Some of these excursions derive from inadequate procedure compliance, either because operators are very busy with more important matters, or because they are unaware of the equipment’s design limitations. In either case Procedural Automation can easily enforce design limits. Customers often overlook these benefits when considering Procedural Automation, but later report gains that cannot otherwise be explained. Identifying companies that have good experience with your specific control system, your production units and specializing in state based control implementation will be key to success. References 1. Why We Need a Better Approach to Procedural Automation, Larry O’Brien [page 6] 2. Tame Your Transient Operations, Scott W. Ostrowski and Kelly K. Keim, ExxonMobil Chemical Company 3. State Based Control and the Value Delivered, Tom Nolan, ProSys

Alarm Management Meets SIS Alarm Requirements How many alarms must be configured per the SIS Standard (ISA-84 Part 1) for an SIF? Zero How many alarms must be configured per the AM Standard (ISA-18.2) for an SIF? Zero How many alarms are necessary for an SIF to correctly perform its function? Zero

Pre-alarm – What makes sense? Pre-alarm before an SIS impending trip? True – This gives the operator an opportunity to prevent the trip, keeping the plant running and reducing the demand frequency on the SIF. Pre-alarm should always be on the BPCS control or indicator tag rather than the SIS transmitters? False – Choice of where to put the prealarm is up to the facility, and it’s a good idea to document this in the Alarm Philosophy. Each transmitter in a voting arrangement should alarm individually? False – Are we trying to keep our plants operating safely or do we just throw multiple alarms at the operator? SIS and BPCS transmitter disagreements among redundant SIS transmitters should be alarmed? True – With this alarm in place, there is no need for a pre-alarm on more than one transmitter.

Introdu

Most plants focus on meeting the alarm managem proper approach is taken in configuring the BPCS, system. SIS is addressed based on the requirements not address alarming related to SIS events. ProSys management philosophy is only effective when taken

Unified Alarm

s SIS

Dr. James Henry - Associate Professor, Lamar University

uction

ment requirements laid out in ISA 18.2. Even if the there is one area that is sorely neglected, the SIS laid out in ISA 84. Unfortunately, this standard does s contends that a successfully implemented alarm n as a holistic view of the BPCS and SIS systems.

ming Scheme

Trip – What makes sense? First out alarm indicating the reason for a trip? True – There is no better way to announce to the operator that a trip has been initiated. Alarm SIS valve moving to trip position? False – Going to the trip position is the expected response to an SIS trip – better, provide a failed to trip alarm, which makes noise if the valve doesn’t work as expected.

Bypass – What makes sense? Alarm board operator initiated SIS bypass? False – Although a common practice, this alarm adds little or nothing to the integrity of the system: “Hey Joe/Mary/Sam, you just pressed a button!” Alarm field operator initiated SIS bypass? True – This may come as a surprise to the console operator, so it’s not a bad thing to annunciate. If a bypass is in place, trip point alarm on the SIS transmitter? False – Why give the operator an alarm that isn’t reliable or won’t be believed? Find an alternative monitoring plan. Re-alarm on SIS Bypass? Neutral – Bypass and shift changeover procedures exist, but do we follow them 100%? This is a facility decision. If used, realarm shortly after shift change.

www.ProSys.com

When Converting Your DCS, Don’t Forget Your Alarm Management System! Earlier this year, one of ProSys’ clients completed the converting of its tank farm, upgrading from a Honeywell TDC® DCS to a Honeywell Experion PKS®. With thousands of I/O converted from the original DCS arrangement of “tag.parameter” to the newer DCS format of “tag.block.parameter” and all other connection settings equally and meticulously accounted for, it took an extensive effort both from the client’s staff and from the consulting companies that assisted with the network configuration, HMI graphics assembly, and general project management needs. Right before operator training commenced on the new DCS, ProSys upgraded the client’s installation of Dynamic Configuration Software to its more flexible, DCS-neutral alarm management platform, AgileOps. With the company’s specialized insights and expert knowledge of the inner workings of both DCS platforms, the seemingly-gargantuan task of upgrading the entire alarm management system, was successfully completed with relative ease overall. The alarm management system maintained rationalization records from that LCN for ~2,000 alarms of which ~80 had dynamic settings across ~40 process systems. The new DCS was recognizing/instantiating an additional ~15,000+. I would be remiss though to say it went off without a hitch, and with that client expecting ProSys to help them out for future alarm management system conversions on their remaining LCNs, there are a few things my coworkers and I, along with any other potential clients, should be aware of for such a procedure. First, one must ask, are there any pending gaps in the client’s original alarm management records? A project’s execution is only as strong as its foundation. For full team confidence, it helps to ensure that all alarm boundaries properly define such fields as their Cause(s), Consequence(s), Action(s), Time to Respond, and Severity for the board operator to get a complete idea of how to respond when the associated alarm annunciates. If there are actions items remaining from the original work, it is reassuring to have them closed out. If an alarm is deemed to be dynamically managed, it is crucial to have the appropriate timers indicated accordingly. In short, with incomplete records, delays emerge in completing the implementation, and if the client does not prepare time in the whole conversion schedule to address such delays, it can consequently impede our progress. Second, as the consulting company assisting on the conversion, have we received the latest information? Two months before arriving to the site, ProSys had received Honeywell Experion® configuration files in .XML format and assurances by the firm charged with configuring the new I/O scheme that they were not expected to be changed any further. So, we ran our .XML-file-reader program and generated the list of loaded and configured alarms, and then we prepared to migrate the alarm information accordingly. However, after completing AutoDiscovery in AgileOps and then reviewing the Honeywell® configuration, I learned that some alarms that had supposedly been “loaded”, had not for various reasons, leaving me scrambling a bit at the last minute to reconcile alarm information. Thus, the next time I do this, I advise that we get an additional configuration update right before we go to site to avoid this re-work. Third, are all alarm types from all relevant alarm sources properly defined? While our .XML program read in and recognized potential alarms directly built in the Control Builder program, I had to reconcile points at the last minute built using the Profit Blending and Movement (PBM) software, used particularly for inventory and storage operations like the tank farm we converted. You should account for alarms from all sources. With these three major takeaways, I’m fully ready to get to the next alarm management system conversion. So if there are any questions or interested participants, let us at ProSys know! Stephen Reilly

My operators have poor visibility to potential issues. They need to view, process, and make informed decisions - clearly and quickly.

YOU CAN DO THAT Improve operations performance. Operator performance can impact plant safety and process availability. Emerson sets your operators up for success by using best-of-class technology, proven processes, and an understanding of human limitations and strengths. The DeltaV distributed control system can help reduce operator stress, limit human error, and provide intuitive data to run your plant more efficiently. Better visibility â€“ better performance. Learn more at www.emerson.com/operationsperformance/.

The Emerson logo is a trademark and a service mark of Emerson Electric Co. ÂŠ 2017 Emerson Electric Co.

Ten Important Questions to Ask Before Darwin Logerot, Stephen Reilly “By failing to prepare, you are preparing to fail.” – Benjamin Franklin The need for managing alarms in an industrial plant stems from advances in control systems technology and resulting increasing sophistication/complexity of systems. With increasing controls complexity comes increasing numbers of configurable alarms. Alarms system design is typically not considered an integral part of the unit design philosophy, and as a result, many more alarms are active in most plants than are necessary. Operators’ time is sometimes, especially in upset conditions, consumed with answering a flood of alarms rather than dealing with the upset condition and returning the plant to normal operation or at least a safe state. As a result, many plants are implementing alarm management in one form or another. So for proper preparation, here are some basic questions to ponder before embarking on an alarm management project.

1. Why should I do it? Perhaps a more appropriate question is “Can I afford NOT to do it?” Recent trends in the refining and chemical industry are aimed at doing more with less. Fewer operators with a wider range of responsibility for each operator is becoming commonplace. In addition, there has also been a trend toward increasingly complex and sophisticated control systems. This brings with it a tendency toward more points and a resulting increase in configured alarms. Fewer operators coupled with more alarms produces information overload. The important information—the alarm the operator really needs to see—is easily buried. In addition, Process Safety Management (PSM) dictates that industrial facilities handling highly hazardous chemicals be designed in accordance with accepted industry standards and with “recognized and generally accepted good engineering practices”. Alarm management is gaining widespread acceptance; ISA Standard 18.2 has been updated and is widely in use. In some cases, this now carries the weight of a regulatory requirement. In some facilities, PSM managers are taking responsibility for alarm management, taking over from the control group and operations managers.

2. What will be the scope of my project? Some may attempt to embark upon a project that just covers the top “bad actor” alarms. Cover the worst ones this month, the next bad batch next month, etc. The thinking here is to get the most bang for the buck and not to try to tackle a large project, especially if manpower is limited. But, this line of thinking misses an essential point, that is, that the alarm system is an integral part of the control system, which itself is an integral part of the chemical process as a whole. Taking a holistic approach to alarm management will result in a more effective project. This approach evaluates each and every alarm in a unit, considering the alarm configuration, the control system, and the chemical process as parts of a unified whole. In this line of thinking, how the alarm system affects the process (and its operators) and vice versa are taken into consideration. In effect, this becomes an alarm design project as opposed to simply alarm management.

3. Can I do it alone, and if not, with whom should I work? The short answer here is probably not. If your facility is like most, the staff is at or near the point of overload; any new project, especially one as labor intensive as a complete alarm management review, cannot be handled with existing staff levels. In addition, if the primary team members are not well-versed in the principles of alarm management, then the project may not ever get off the ground. It is usually in the best interest of the facility to plan to hire a qualified alarm management consultant. Otherwise, the results may not be worth the cost of the project. You do however need to have an alarm management champion or champions at the site and they need to take over when the consultant leaves for day to day tasks.

Starting an Alarm Management Project In considering who the consultant should review the work with, a multidisciplinary alarm management team will be most effective in achieving optimum results. Representatives from operations, control engineering, and process engineering are essential. In addition, technical specialists from other areas, such as maintenance, mechanical engineering, electrical, instrumentation, etc., should be available for consultation as needed. Another important team member is the project leader / facilitator, an experienced alarm management professional. The project leader should be a degreed Chemical Engineer, someone who has a good, broad understanding of chemical and refining processes. All team members need not be present at all times during the rationalization meetings. As a minimum, the project leader and operations representative(s) should be full-time team members; the others can be part-time participants.

4. Do I understand what’s going on behind the scenes, among other technical considerations? When an alarm rationalization is conducted, revisions and suggestions are made and agreed-upon at the generic, basic level, but without the understanding of how such alarm properties as a trip point or priority are specifically configured within the control system, the results will fail to be implemented and get off the ground! Whoever becomes the project leader should be able to answer some detailed questions. How many alarm types are configured in the control system? How is each alarm type defined? Which alarm properties can be (directly) modified on the spot, and which ones require a planned system restart to properly load the changes? Once that’s known, it will also help to be aware upfront of where your potential changes might be restricted or denied. Are any interlocks tied directly to alarm active statuses or trip points? Are any alarms referenced as PHA safeguards or LOPA IPLs in plant documentation that would require extensive approval to change?

5. Should my alarm configuration be static? Is the chemical process static? If not, the alarm configuration shouldn’t be either! This is probably the number one problem with existing alarm configurations in refineries and chemical plants today. The alarms are designed for a running unit, operating at or near steady state. But, how does the process start up or shut down? What happens during normal transitions? How about regenerations? Furnace decoking? Alternate unit feeds and/or products? A well-designed alarm system will consider each of the above scenarios and will include some form of dynamic management that is capable of changing alarm settings as it detects a new operating state. Transition management between operating states is also a key element of a well-conceived and designed configuration. For instance, when the state selector detects that the unit has reached its run state, if ALL process alarms are enable instantaneously, then a flood of useless alarms may result—all process parameters may not have cleared their alarm limits. If you’ve performed a static rationalization, all is not lost however. The design can be reviewed and dynamic alarm logic can be added. Bottom line is this: don’t expect a static alarm configuration to perform well for a plant that is by no means static!

6. How will I manage alarm disabling? What happens when an alarm is meaningless or becomes a nuisance? A bad switch or transmitter can cause the alarm to sound unnecessarily. Or, the transmitter is correct, but the process condition does not indicate a true problem (equipment may be down or bypassed). Or worse, the alarm can sound repeatedly, creating a nuisance distraction for the operator. Too often, problem alarms are easily disabled by the operator and then are forgotten. The result is that the root cause of the problem is not addressed, and the alarm will not be available when it is really needed. A better solution is to allow operators to shelve alarms, using a software tool designed for this purpose. The shelving tool will temporarily disable problem alarms but will not allow them to be forgotten. Shelved alarms are kept on an easily retrievable list, and periodic reminders and reports can be configured.

7. What effect will alarm management have on operating culture? This answer depends significantly on the current operating culture. In some plants, there may be a culture of “operating by alarm”. That is, few operating adjustments are made unless an alarm sounds. Still others may have so many alarms sounding that most of them are ignored. In a plant such as either of these, the operating culture may need to experience a shift. After a sound alarm management project is executed and the system is installed and activated, the plant will usually experience a significant drop in the number of annunciated alarms. As a result, operators used to waiting for alarms to make process moves will need to pay closer attention to plant conditions. Those who are accustomed to ignoring most alarms they receive will need to change that practice as well. The alarms that are annunciated will usually indicate plant conditions that do require attention. Ignoring alarms will no longer be a viable option. If in your plant the operators are attentive to the process, usually make proper adjustments before alarm conditions are reached, and respond promptly when an alarm is received, then little culture change will be necessary. Of course, most operating plants are between the extremes indicated by the examples above. The amount of culture adjustment necessary will vary with each location and unit. What is important to note is that after alarm management, prompt response to all annunciated alarms will be needed. Also, this prompt response will be better facilitated by a welldesigned alarm configuration.

8. How will I maintain the integrity of my alarm configuration? Unauthorized changes can adversely affect performance of even a well-designed alarm configuration. For this reason, a good audit and enforcement tool is essential. Such a tool will regularly review alarm settings against approved values and will report discrepancies. If the user desires, it will also enforce important alarm settings back to their approved values.

In addition, alarm configuration impacts should be included in the site’s Management of Change program. Any time the plant is revised, the alarm system should be revised accordingly. If this is not done, then the advantages gained in the initial alarm management project could easily be lost. Another consideration is the potential blending of alarm management efforts into a unit’s PHA revalidations. Some of the questions that the alarm management team asks itself are similar if not exactly the same as those asked by the PHA team. What are the potential causes of a deviation that triggers an alarm? What are the consequences of inaction? What action is expected to correct the problem? And, process alarms are often listed as safeguards in the PHA documentation. Problems can arise if the alarm management team decides that a particular alarm isn’t needed, but the PHA team included it in their documentation.

10. How will I measure success? There are a number of metrics available that are generally accepted as measurement tools for alarm management projects. Number of alarms received per unit time, peak alarm rates, and alarm flood analysis are all important measurements of success of any alarm management effort. There are a number of software tools on the market to aid a plant in developing these key statistics. But, there are some caveats that should be applied to any analysis based on metrics. First, an absolute metric alone is not a valid measurement of an alarm system’s performance. Application of an absolute metric can be inaccurate, because this method generally ignores site-to-site and unit-to-unit differences. The more important validation of success is the before vs. after picture for a unit. How much improvement did I gain from the effort? Also, the truly important metrics are very diﬃcult to measure. How many, or what percentage, of the alarms received were relevant to the operator? Conversely, how many could have been ignored without consequence? Were any important process deviations missed? In other words, how many alarms were needed but not sounded? These answers can only be obtained from operator interviews or some other manual data gathering effort. Also, metrics must never be used as a basis to compromise an alarm management process. If at the end of a well-designed, rational process, the results should violate some pre-established metric limits, then it is more appropriate to re-evaluate the metric or consider reallocation of operator responsibilities. There is an important distinction between a standard of measure used to assess the final results of a process and a justification to compromise that process. With these questions confidently answered, your alarm rationalization project is all set! Your preparation will have served you well, minimizing the efforts needed to backtrack or clarify specifics, leaving a more-thansatisfactory experience for all involved.

9. Is the completion of my project the end of my alarm management effort? In a word, no. Alarm management is not defined by the beginning and end of a single project but can and should be an ongoing effort in any plant. When the initial project is done, there will inevitably be some adjustment required. The initial alarm configuration is seldom the final optimum, and continuous improvement opportunities will always be present.

INTERN SPOTLIGHT - CHRISTIAN WALSH

Rationale for Alarm Rationalization Bad value alarms, shutdown-state alarms, several alarms to indicate one event – more information is better, right? Not quite. Before beginning my internship with ProSys, I thought that annunciating more alarms would be better for operations by providing redundancy, clarity, or multiple ways of checking each possible instrument. It was a tempting thought but I soon learned that was not the case. It is more appropriate to say that smaller amounts of carefully chosen information are better than simply more information. For alarms, this is done through alarm rationalization and dynamic alarm management. It’s useful for understanding alarm rationalization to consider alarms occurring in abnormal, unexpected situations instead of normal situations. For example, a typically hot process stream falling to a low temperature during a regular run state would certainly be unexpected and should receive an appropriate alarm. But why should that same stream give a low temperature alarm during startup if it starts from a cool temperature? According to the CSB, 70% of process incidents occur during startup or shutdown which demonstrates that effective dynamic alarm management is essential for plant safety and performance. Unnecessary alarms can also cause alarm floods and make it diﬃcult or misleading for operators to identify the true problems occurring. Alarm rationalization addresses this issue by eliminating alarms for normal, expected situations and leaving alarms for truly abnormal situations which in turn improves operator knowledgeability and allows plants to meet ISA 18.2 standards.

My internship with ProSys has allowed me to contribute to alarm management projects for clients seeking to implement dynamic alarm management. One major piece of work I did was to create the HMI graphics for operating consoles which display the case logic diagrams that govern which alarms are enabled in the different operating cases. I then linked shapes in the diagrams to data points in the control system such that suﬃcient instrument values would illuminate the operating case in the diagram, allowing the operator to see the logic-determined operating state and understand which alarms are enabled. The final alarm database and my graphics were successfully implemented near the end of my term. Towards the end of my internship, I contributed to the front-end design efforts of a new alarm rationalization project. I helped divide a swath of the facility into systems with unique case logic, draft the logic, and select the instruments that would be used to determine cases in the logic. This required an understanding of the process and the equipment for the system breakout as well as the careful inspection of P&IDs to find appropriate instruments. This experience introduced me to an important niche of process control, provided motivating examples of why alarm management is essential to safe and effective operation, and allowed me to make real contributions to a successfully implemented project. I am grateful to have had this opportunity and for the support from the engineers around me.

4954 Space Center Drive, San Antonio, TX 78218 210.804.0390 â€¢ www.shweiki.com