Optimize your Nonprofit with Pipeline Scada Alarm Management

How to create outlook signature

so welcome to the webinar alarm management 101 or alarm management Basics everything you wanted to know about alarm management but we're afraid to ask my name is Todd staer I'm director of alarm management here at EXA and we're broadcasting live from the Sellersville Sound Garden studios so I am involved with alarm management here at exoda as well as part of the ISA committee on alarm management Isa 18.2 and helped develop one of the standards that we'll talk about on alarm management so first a little bit about exoda we're a global company that's focused on process safety cyber security and alarm management we are a leader in the certification of products and people for safety systems and safety technology and we have a suite of software for safety instruments system design to address All Phases of the safety life cycle and as part of that we include our alarm management software called s alarm so what are we going to talk about today we're going to talk about alarm management but in a different style than most of our typical presentations or typical presentations that you would probably see we're going to do it in a question and answer format so we'll walk through some typical questions and talk about the best practices that relate to each one so we'll look at things like what's the purpose of an alarm how do we determine when an alarm is needed how do we determine when alarms are redundant how do we set up a good alarm limit things like that so the format will be a question and the answer let's start with a a bit of a grounding about why alarm management is important so a question quiz question related to the role of the operator so the question is what role in today's society analyzes information diagnoses situations predicts outcomes and takes action to deliver value your choices is it an airline pilot a medical doctor an operator who are all of the above well since we're talking about alarm management and operator you probably guessed that the answer here is all of the above part of the idea is to get you to see that similar to an airline pilot or a flight controller operators get a lot of information a lot of data that they need to make quick decisions about and those decisions have significant impact one of the best tools for the operator to help them make those quick decisions and to make them correctly is the alarm system in the control system and that's what we want to talk about management of the alarms in the alarm system so how does alarm management affect the operator's performance well if we think about what an alarm is ideally for if the process is being controlled effectively by the the DCS then the process stays in the normal operating range if something happens the process may start to deviate and go into the abnormal area and then ideally an alarm would be generated and the purpose of that alarm is to let the operator know that there's an abnormal situation present to help them figure out what's wrong and to guide them to take the appropriate corrective action the idea is that when they take the Cor ctive action the process turns around and heads back to the normal operating area if the operator does not respond or responds incorrectly then the process may continue to deviate continue to go away from normal operating conditions resulting in a process shutdown perhaps activation of a safety instrumented system or some other type of consequence so there's a one forone correspondence between between the creation of the alarm and the need for the operator to respond to prevent something from happening now if your control system if your alarm system summary screens look like this where you have tons of alarms displayed constantly then something's wrong that one for one correspondence the operator responds and the process corrects itself is obviously not working in this scenario so what does that do and what does that mean to the operator that's the source of a lot of problems we'll call them the alarm management villains and they include just flat out giving the operator too many alarms whether it's on average kind of steady state or after an upset we'll call that an alarm flood another typical problem is when the operator gets hit with nuisance alarms this is the idea of alarms that are occurring that don't actually need to be responded to so they break that one for one cause consequence correlation cause operator needs to respond or consequence in this case the operator is either responding and the process is not correcting or The Operators may be not even responding and nothing's happening so the purpose of the alarm is not working in that scenario and then alarms that either don't have a response as we said or alarms where the priority is not meaningful if these situations are present in your alarm system that is going to diminish the ability of the alarm system to Be an Effective tool for the operator and it's going to make it harder for them to do their job it's going to make it harder for them to make those quick decisions and to make them correctly so the alarm system can be a supporter of the operator when it's uh def defined and managed correctly and appropriately but when it's not performing well it actually hurts the operator's performance so thinking about what alarm management is overall then we can Define it as the process by which alarms are engineered monitored and managed to ensure safe and reliable operations and really the goal of alarm man management is to improve the situation awareness of the operator so they can prevent those consequences they can prevent the trip of the sis they can prevent damage to equipment uh and situation awareness is really the ability for the operator to totally be in touch with the process and understand what is happening and to kind of be able to predict what will happen so they can ideally take proactive measures even before the alarm terms occur but the idea is they are in touch with the process enough to know what's happening so now let's talk about what are the most important industry standards and guidelines not too much time on this but there are a couple of Standards one that was created in the US Isa 18.2 first created in 2009 that led to the creation of an international version called IEC 626 82 which came out in 2014 and then after that the the ISA 18.2 standard was just uh recently re-released and updated uh in March those are the two main standards that govern process industry customers throughout the world there's also a guideline document called amua 191 which was created in the UK in response to a major accident that they had there which was an alarm management problem which contains a lot of good information on best practices for alarms uh so between those three bodies of knowledge those are the the most important collections of alarm information now the ISA standard is supplemented by some technical reports a standard typically tells you what you need to do the requirements per se but not how to do it so the technical reports go into more detail about applications and examples of how you might do things so that coupled with the standard gives you a good compendium of alarm management knowledge so okay let's start with a test test your knowledge on alarms we're going to look at a couple of different scenarios and I want you to take a piece of paper and a pen and write down your answer to these question questions we won't uh go over them now we'll go over them later at the end of the webinar and we'll see how you did and whether your answer changes based on what we learn and what we talk about so the first scenarios that we want to look at are operators are alerted to an abnormally high level in a tank that could result in a spillover or process shut down without direct operator intervention second one operator wants to be not IED when a water tank level is low enough for them to restart some wells that have been shut down so we want to know of those two scenarios which ones should be alarmed A or B perhaps both of them or perhaps neither so take a second and write down for yourself what you believe the best answer is and then we'll move on to the next set of scenarios so in this one we have a couple of different ones piece of equipment was shut down by the operator from the face plate that's the first one that's a b a piece of equipment has shut down and requires operator attention that's B so the question is again is a an alarm is B an alarm are both alarm scenarios or is neither an alarm scenario so take a second and write down your answer to that question you will turn to that later in the webinar so now let's talk about what an alarm actually is or what it's supposed to be as defined in the ISA and IEC standards same definition an alarm is supposed to be an audible Andor visual means of indicating to the operator I have the word operator underlined to emphasize that the operator is the target audience for the alarm system so all of the information that goes through the alarm system and and is presented to the operator must be understandable and actionable by the operator where it doesn't belong in the alarm system next an alarm needs to indicate an equipment malfunction process deviation or other abnormal condition and I've highlighted the words abnormal condition to emphasize that an alarm is supposed to be used to mean that something is wrong something unexpected has happened and then last but not least it requires a timely response and I don't mean acknowledging the alarm or silencing the horn they don't count in this case response I mean something that is going to correct the process abnormality that's going to drive the process back to the normal operating range so that would be something like turning on a backup pump opening or closing valves something like that now one other way to think about alarms is it's just one form of communication to the operator of an event that has occurred in your process or in your process control system so one of the important things to understand or to focus on when we're looking at all the different notif ifications that the operators get is to make sure we can clearly differentiate which ones are alarms and which ones are not so the definition of an alarm helps there another way to to help differentiate is to use this Matrix that we see here which basically has you ask kind of two questions related to a notification does it require action from the operator or is it just for informational purposes and then is the event that it's providing notification of is it an abnormal or is it an expected event based on that we can classify or categorize alarms and make and we want to make sure that during the creation of our alarm system or the setup of our alarm system that we're making sure that alarms are reserved truly for conditions that just meet this one box here of the Matrix so operator action is required and it's an abnormal situation so why are there so many alarms configured in a typical control system it's a common question um which leads to many of the problems that we see so how did we get to the situation that we're in part of the problem is in the olden days of panel board control there was a lot thought put into what points should be an an alarm and that was because there was limited real estate on the walls for the alarms and there was actually a real cost to wiring them up the fast forward to the modern DCS and alarms are essentially now free they don't cost anything they're in software and a typical DCS an analog point will have a high high high low low low rate of change deviation PV bad there can be you know 8 to 10 different alarm possibilities for just a single sensor and if you don't put thought into which ones you really need you can end up enabling you know all of them or four of them or two of them and part of the the problem that we have or the problems that we do have arises from the fact that we don't put thought into what alarms we really need we look at what's available and either enable them all or enable whichever ones we think might be useful without putting in the same kind of thought process that we did in the past where we thought about what is the real purpose of this alarm what is it there for and what is the operator going to do that thought process is actually a key part of what we call alarm r ization which is the key to figuring out which alarms you actually need so now that we know what an alarm is and how the operator is supposed to deal with them how many alarms can an operator realistically deal with now first we have to remember that operators their sole job is not to respond to alarms in fact they would prefer getting no alarms that would be ideal alarms are supposed to be an infrequent notification that something is wrong and to draw their attention so if they spend all of their time responding to the two alarms that would not be good they would not have time to optimize the production or the the uh the operation itself so let's take a look at the process for an operator to respond to an alarm what does it consist of you can think of it as three different steps the first step is the operator needs to detect that the alarm actually exists so this relies heavily on the design of the human machine interface alarm horns alarm beacons so the idea is when an alarm comes in that it immediately can draw the operator's attention second step is diagnosing what the problem is and figuring out what the cause and what the operator needs to do what's the corrective action and then third step is to perform that corrective action to respond to the alarm to open the valve or to turn on the pump so those three pieces make up the operator's response time so the question is if you thought about a 10minute time period how many true alarms that an operator needs to respond to can an operator realistically deal with do you think in 10 minutes so take a moment to think about that while you're thinking about it uh make sure you consider not just alarms that can be quickly addressed from a face plate in the the DCS but also scenarios where the operator may need to call an outside operator or walk out into the plant to find the final control element so if the corrective AC or the final element can't be um manipulated from the control room it's going to take a lot more time for the operator to respond probably on the order of minutes so that's why the standards based on human factor studies recommend no more than one to two alarms per 10 minutes and if you think about that detect diagnose respond uh scenario that seems to make sense as a San now if you cons continue with thinking about 10 minutes and one to two alarms is what the operator can reasonably deal with a long term or steady state what can they deal with um short term on a burst after an unplanned event that's what we call an alarm flood so essentially overloading the operator temporarily with with too many alarms the standards recommend there that you you try and limit it to no more than 10 alarms in that 10minute time period or else you're going to start to overwhelm the operator and what happens when you overwhelm the operator well you can see down here in this table that the likelihood of them making a mistake either responding incorrectly to the alarm or not doing it in time or not noticing the alarm that the likelihood of them responding incorrectly goes up dramatically in that stressful upset scenario so that's one of the main reasons why we want to uh prevent alarm floods from occurring so now that we've talked about how many alarms an operator can get how do we figure out which ones they actually need try and minimize the alarms they actually get so how do we determine when which alarms are needed and which alarms are not I mentioned earlier or I hinted earlier at something called The Alarm rationalization process that's really the key for where you determine what alarms you actually need and it's a multi-step process that consists of checking the validity of the alarm and we'll look at that in a second assessing the consequence if the operator doesn't respond looking at the the cause and the corrective action looking at how much time the operator has to respond and those are the typically the the key things that one looks at to determine whether the alarm is valid or not whether the alarm is really going to be necessary whether it really has a purpose and then the rest of the rationalization process includes steps like determining the priority of the alarm assigning the classification reviewing the alarm limit setting attributes like dead band and onoff delay and then last uh assessing whether there's any scenarios where the alarm needs to be suppressed or have a different limit or priority and that's done in a team setting and the exit tool called sill alarm is a tool that will guide you through the rationalization process prompt you to make all those decisions and document your results and then push that information back into your control system so how do we determine then whether the alarm is valid or not well what we have to work with is the definition of an alarm so let's take that definition and create some criteria to judge our s against and we can come up with a couple of questions that we can apply kind of as a a go noo criteria the first one would be does the alarm that we're looking at indicate a malfunction deviation or abnormal condition there's that abnormal condition phrase again you have to answer yes to this question if you can't answer yes then the point is not an alarm second question does it require a timely operator action in order to avoid defined consequences again if you can't answer yes to this question it really should not be an alarm continuing is it unique or there other alarms that might be better indicators of the root cause so these are some of the other criteria that can be applied to determine whether an alarm is valid and needed and that's just a quick check so now let's take that knowledge and apply it to a real life scenario and the real life scenario is the design and operation of a typical sump pump this comes from an actual drawing for a a project where the the definition of how it should work was that there were high and low level alarms defined at 85% and 10% respectively and the pump the sum pump was to be automated to turn off on when it reaches the high level alarm 85% and turn off when it reaches the the low level alarm at 10% so if we apply what we just talked about or what we just learned and think about the high alarm that's defined at 85% and run it through our criteria first criteria is does it indicate an abnormal condition and the answer would be no not as it currently constructed the level is going to increase enough that the pump is going to need to turn on that's the way it's designed to work second does it require a timely operator action and the answer is no the operator doesn't have to do anything the pump is is turning on automatically the way this is designed so that would indicate that the high alarm is really not required it's not a valid alarm so now let's continue with the rest of the rationalization process that helps us understand whether we need an alarm or not it's called The Alarm objective analysis and we look at four different things first being what is the likely cause of the alarm we want to make sure that the alarm is an unexpected event not expected and we want to make sure that we're looking at the root cause so when we look at uh a low flow alarm we want to know the root cause not the cause being cause of a lowf flow alarm being low flow which I've seen on projects as opposed to uh a clogged filter or clogged strainer something like that that's more along the line of the root cause that we're looking for next look at the consequence and for this we want the the direct consequence what's going to happen if the operator doesn't respond let's assume every other layer protection every other Safeguard in the plant is going to work the way it's supposed to to so what only would happen if the operator doesn't respond in this scenario that we have here this picture the consequence of the operator not responding would be the trip of the safety system then we want to document what the corrective action is and of course we're looking at something other than acknowledging the alarm we're talking about opening a valve turning on a pump things like that and then last ideally we want to document how the operator can connect confirm that the alarm is real particularly if the operators have been subjected to nuisance alarms where they don't trust the alarm system we want to provide them with additional information so they can help make the decision that in this case this is an important alarm and I need to respond to it now when we go through this analysis if we can't come up with a consequence of what's going to happen or the only consequence is another alarm then we don't need that alarm similarly if we can't Define what the corrective action is for the operator to take it's also not an alarm so the objective analysis in addition to the validity check helps us again refine what points should be an alarm and which should not so now let's go back to our Su pump example we eliminated the original high level alarm at 85% but if we just left it at that and moved on we'd be doing a a disservice to the situation because there really still is an undesirable situation a scenario that we want to avoid a hazardous scenario there is the potential for one there so what is that undesirable situation well if the Su pump doesn't work where it gets overloaded can't keep up with demand then the sump will overflow and spill out so that is a potential hazardous scenario so if we created an alarm for that what would the operator action be well they would need to go out and check what's happening whether there's a malfunction with the pump or you know something like that or a failure and then what would the consequence be if the operator doesn't respond what would be a spill uh the some pump would overflow and depending upon what's in it that could have minor to significant environmental consequences so what we've just determined is that we actually need a high high alarm here that would basically indicate that the Su pump is not working so something where the limit is greater than 85% so let's say 90 or 95% something in there uh that indicates some pump is not working or not able to keep up with demand and this is a real life situation so let's look at an example of where that rationalization makes a difference and caused a problem so in this chemical plant they were transferring reagent into a neutralization area and that pump developed a significant leak which filled up the sump it also caused a lack of reagent flow to the neutralization area which upset that whole entire process and made the operator scramble to figure out what was going on and to address that now the operator did receive a high and a high high level alarm for the sump but they ignored them and they ended up overflowing the sump as we talked about and dumping 10,000 gallons in the environment there now they regularly ignored the highlevel alarm on the sump because as we just talked about it was actually used as the set point to start the pump so if we look at the failure modes for this the operator did not understand that the cause of the upset in the neutralization area was actually not in the neutralization area it was some somewhere else but one of the major problems in this scenario is rationalization was not performed correctly the fact that that high level alarm was still there the one that we had eliminated meant that the operator ignored it because every time it goes off that's just indication that the pump is starting it's not an alarm so the operator developed a culture that he could ignore all the alarms coming from the Sun pump well that was true for the high level alarm but not for the high high uh so when that occurred and they ignored them as well that led to the problem so incorrect application of alarming and alarm rationalization led to a 10,000g spill in this case so then how do we take that further and determine when alarms are redundant so for example when is it okay to have both a high and a high high alarm in the past we might have configured a high high alarm with the idea that if the operator misses the high alarm then the high high would be the backup it would be the the catch off where and hopefully you're kind of seeing that that's not a produ or good way to set up your alarm system so what we want to do is analyze for each alarm each potential alarm high and high high in this case what is the cause of the alarm what is the consequence what is the corrective action the operator response and something needs to be different between the two alarms for those three criteria if nothing is different if they're the same for the high and the high high high alarm then you have duplicate alarms and you don't need both of them so let's look at a little bit more of one of the criteria here which was the opera response needing to be different in kind or degree let's dive into that a little bit more so if we look at this tank example and you're the operator um and you're going to get high level and high high level alarms and the question is what do you do uh for this tank the only thing you have control over is the manual valve so what would the operator response be when they get the first high level alarm it might be to reduce the flow through that manual valve so close it partially but what if that doesn't work and the level continues to rise reaching the high high level point now what does the operator do well they would stop the flow entirely close off that valve completely so that shows an example of where the response is different in kind or degree between those two examples in one case we're reducing in the other case we're totally shutting off the flow so now how do we Define a useful limit for an alarm an alarm set point well if we think about the operational scenario that we saw earlier hopefully the DCS is keeping control the process and keeping your process variables let's say your pressure in your normal operating envelope or your normal operating range but let's say it loses control and the pressure starts to increase there's some value that we don't want the pressure to get to where the consequence will occur what is that point that's the consequence threshold so we need to know what that that value is we need to know what that consequence threshold is to be able to set the alarm limit so let's say for pressure for a vessel the consequence of high pressure will be a relief valve opening so the consequence threshold would be the set point for the relief valve and what do we do with that information well that represents the value of the process that we don't want the the pressure to get to so we want to set our alarm limit in reference to that consequence threshold and if we know the rate of change of the process we can set an alarm limit that gives the operator suff time to respond effectively before the increase in pressure to reach the consequence threshold so the the takeaway is alarm limits are set in relation to consequence barriers or constraints design constraints that you have so in this case it was a pressure relief valve setting it could be a safety instrumented system setting it could be an interlock setting it could be a maximum design pressure it could be a mechanical Integrity limit so there are many different design constraints and you need to know what they are because that's what you're looking at to set the alarm limit now you can't just set the alarm limit and walk walk away because if you don't look at other attributes like hysteresis or deadband you're going to end up with nuisance alarms and what deadband does is there's typically uh signal noise in your process variables so let's say we set our alarm limit at 60 PSI and our pressure fluctuates while every time it goes up above 60 it generates an alarm and then that's say just because of the fluctuation on the next scan of the DCS it drops below and then it goes above and then drops below well we'll end up with four different alarm instances or four different alarm events just because of the fluctuation in the process variable and that's a a chattering alarm so that's a nuisance to the operator by configuring a dead band we make it so that the alarm needs to clear a certain Gap uh before it would actually be cleared cleared or or would be eliminated from the screen for the operator so that essentially Smooths out a chattering alarm and takes it from a multi-alarm event to a single alarm eliminating chattering so a little bit more about how deadband works if you had a a situation where you had a pressure um gauge that was scaled from zero to 100 PSI and your high alarm limit was set at 90 with a deadband of 2% the alarm would be triggered any as soon as or any time the pressure goes above 90 and then it would not clear or return to normal until the pressure dropped below 88 and any fluctuations between 90 and 88 would not result in any additional alarms so that's essentially how we get rid of chattering alarms in addition to deadband there's parameters such as on delay and off delay which can also smooth out that chattering but from a a Time based point of view rather than from a value based point of view and part of the reason why that's this deadband is important is because it um influences when the alarm will uh clear I mean you could here's an example of an alarm summary display from a DCS where it shows both the alarm limit and the live value so the operator could actually see the live value be less limit less than the high limit and say how come it hasn't cleared yet and it would be because of that dead band and if it wasn't said appropriately they might it might be a stale alarm and and I've actually seen some scenarios where operators will go in and change the dead man temporarily to zero to clear out that alarm and then change it back so that it disappears from the screen once it's cleared so okay moving on to the next question how do you let the operator know which alarm to respond to first or how do they know well we're going to primarily focus on the the HMI the human machine interface that's going to draw their attention and hopefully give them the information that they need to know as to which which situation is most critical that they need to respond to first and if you look on this screen you can see one set of visual images and if you look for certain alarms that are kind of difficult to see compared to this screen where you can see that the alarms really stand out they really jump off the page so that the operator can clearly see them and that's the the goal that's the idea that's the way you should design so the coloring and the priority and the visibility within the human machine interface should correlate to how important or critical the event is or the alarm and what the best practice is is that you only use um yellows and reds and abnormal colors for alarms everything else normal states would not be those bright colors to draw the operator's attention because we want it we want to make it very easy to the operator to differentiate when there's an alarm there now the color of the alarm usually is connected to its priority and what is the priority that's actually what the operator needs needs to key off of or should be able to key off of to know which alarm do I respond to first now if you have a system where you only ever have one alarm at a time guess what doesn't matter what the priority is but if you're like 99.5% of the rest of the process plants you get multip alarms at the same time and the idea is the operator needs to have some way of knowing which arm is more critical to the the plant to the business to the process if they can only respond to one at a time which one do they pick and that's what priority is used to guide them for so we need to come up with some way how the heck do you assign the priority of the alarm typically by looking at the severity of the consequences you know essentially what would occur if the operator didn't respond and how much time the operator has to respond and the idea is the combination of that is what determines what the priority is so in this example if an alarm had this significant financial consequence we assess how bad its consequences as part of rationalization and we estimate its amount of time to respond time available that would indicate that the alarm should be a critical priority so the operator would know that whenever that alarm whenever a critical priority alarm occurs there are significant potential consequences behind that including not only a uh significant financial but the possibility if you look up here in this cell that one of their colleagues could get hurt or killed so there's a relation to from the priority to the significance from a business point of view for them to respond to that alarm so how do we then let the operator know what action they should take when the alarm occurs this is particularly important for plants that have a lot of new operators or turnover for uh operators the ISA standard defines something called an alarm response procedure and the idea is the operator can access that and look at that to know how they should act or respond when the alarm occurs what type of information should be in that uh procedure well it should in include the the name of the alarm the set point and then information like what's the potential cause of the alarm what's the consequence what's the action they're supposed to take how much time do they have to respond so information that will truly help them know how to respond to the alarm and the good news if you want to call it that is those are the same things that we talk about during alarm rationalization if you remember the discussion about alarm objective analysis what's the cause what's the consequence what's the corrective action we need to document and talk about that information during rationalization so if we do that then we can farm that information or leverage that information and turn it into alarm response procedures and we can actually do that very easily with our C alarm tool here's an example of where the the rationalization information can directly populate an alarm help face plate in the DCs so how do we then manage alarms that are special for those of you out there like my friend Charly that focus on safety how do we know which alarms are safety related or safety important well that's through a process called alarm classification and class classification is basically used to group alarms that have common sets of requirements for how they're treated so just like passengers are treated differently in first class and economy class you know certainly the amount of seating you have the number of free drinks that you get is very different so not all alarms are created equally uh some alarms for example those that have safety potential consequences you might want to test more frequently than your average process alarm or make sure that the management of change process is much more rigorous the last thing you want is somebody to disable a safety alarm and you have an accident or somebody gets hurt so the way to help prevent that is to identify which alarms have these different characteristics by defining these classifications so common ones here are related to say now both the ISA and the IEC standard Define a special super class of alarms called highly managed alarms and this is an identification of one or more classes that you've defined that requires whole set of special requirements extra special treatment like safety alarms safety alarms is typically a good good example of what a highly managed alarm would be and the standards define specific requirements for what you must do in the management of those alarms whether it's how you test them how frequently you test them how you document that the training for The Operators on how they know what to do um periodic testing and benchmarking the whole idea is that you're treating those alarms with a lot more rigor um because of how important they are so for example if we look at an analyzer shed the alarm that essentially tells you that you shouldn't go in there we really want that to work because the last thing we want to do is to have that alarm not work and somebody goes in there and and they're killed so that's an example of a safety alarm and that's why we have these extra special requirements in place for those types of alarms to make sure that they'll work when they need to so now the next question how do we make sure alarms occur only when they are needed well we can apply a couple of different techniques one of which falls under the category of advanced alarming uh we can talk about a concept called suppression which means we actually hide the alarm from the operator we don't present it to them under certain situations situations when we know that the alarm is not relevant so there's a couple of different ways to implement that so one application example would be for example we have a pump and we have alarms on the outlet pressure or the discharge pressure or perhaps on the outlet flow now we have a low discharge pressure alarm and of course that's going to go off anytime the pump stop stops so that alarm is not useful in that scenario that would be a nuisance alarm so we would want to do something special to prevent that low discharge pressure from enunciating anomalously so we could do that two different ways we could set up a a state base suppression where we look at whether the pump is running and and use that to suppress the uh load discharge pressure or we can just change the criteria for when the the pressure the low pressure alarm goes off and look at more than just the actual pressure reading the pressure measurement itself but also look at the status of the pump running as part of that alarm expression so it's kind of like it goes from uh the pressure must be less than 20 psi to the pressure must be less than 20 20 psi and the pump must be running so we change the expression for when the alarm is generated and we've made it smarter so that it will only occur when it's providing useful information so that's one example another example relates to um flooding of alarms to the operator after an equipment trip like a compressor where we're going to end up with a whole bunch of alarms that are kind of triggered as a as an effect an after effect of the compressor tripping so we can define a way to suppress the alarms first by detecting or looking for what might trigger the compressor trip or how we would know that the compressor is tripped and then we can set up logic to say when that happens when we detect that in the control system here's the set of alarms that need to be suppressed and as part of the review and identification process there we'd want to make sure that the alarms truly could be suppressed and that there was no safety implications being overshadowed by that okay so now we're we're coming to the end we're coming to the wrapup portion now we're going to go back to the the uh the quiz questions that we looked at earlier so this is the final exam for this webinar so let's look at the the questions that we saw earlier and talk about what the correct answer is so and hopefully you've learned something along the way in this webinar that helps solidify your understanding and thinking and and coming up with the correct answer as well so the question was which scenarios should be alarmed scenario a operators are alerted to abnormally high level in scenario B the operator wants to be notified is it uh one or the other both or neither and the answer in this case is a so operators are alerted to an abnormally high level in a tank and the reason why it's a is if we read the description and it and this is kind of a lesson learned that if we can take the alarm and truly document from a narrative point of view what it's supposed to do kind of in this fashion it can become pretty clear whether it should be an alarm or not so that's one of the things that you want to try and do to help you make that decision and of course in this case it is an abnormal situation there's a consequence that's going to occur if the operator doesn't respond so it meets all of our criteria now B not quite so sure given that uh the description that we have here it looks almost like a a prompt to the operator to tell them to to do something something that's kind of a normal thing so it doesn't look like it meets the criteria for being an alarm at least based on this description so next scenarios piece of equipment was shut down by the operator from the face plate and a notification that it is provided that it has stopped second one piece of equipment has shut down and requires operator attention to find the problem and restart the equipment is it A B C or D in this case the answer is B if we look at scenario a that's essentially an alarm being generated when the operator does something and does it successfully so it sounds kind of crazy when you look at it from that point of view and obviously shouldn't be an alarm but I bet if you're in a plant right now and you walk out to your control room you will find some alarms that are just like that that occur when the operator does something and gets the response that they want actually so it's a very relevant example now in scenario B we need the operator to go and figure out what's happening and and restart the equipment so that's clearly an alarm bonus question which scenario should be alarmed in this case a a plc's memory support battery is low and needs to be changed B power has failed to a PLC and will result in a plant shutdown if power is not restored before the backup batteries run down so is it A B C or D this one is a little bit trickier the answer here is B but it really depends on what the operator's action would be for scenario a clearly if you read the description for B there's a eminent consequence that requires the operator to do something so that's pretty clearly an alarm if we look at a that doesn't necessarily look like it meets the criteria for being an alarm but it really depends on what would the operator be responsible to do in that case if there's on the operator's part then it's really just for informational purposes on the other hand if the operator is the one that's responsible for notifying maintenance or creating a maintenance work order then it is is a valid alarm so it really depends on what the operator's response would be and actually your alarm philosophy toward how operators deal with diagnostic alarms so that kind of wraps up our session for today I say thank you very much for attending and tuning in appreciate your uh support and hopefully you found this an enjoyable webinar if you did I would um encourage you to go to the exit website where we have a a whole bunch of other webinars that have been recorded from previous times there's a series on alarm management as well as on various other topics so please feel free to check them out and if you have any questions or comments on what we talked about my email address is there at the the bottom so on that note I'll say uh thank you very much for attending and we hope that you'll join another webinar in the future and have a good day