Pipeline scada alarm management in IT architecture documentation

How to create outlook signature

one welcome to this session on delta v system alarms management solutions my name is kim vancamp i am the product manager for delta v responsible for the alarm features in delta v i am also a member of the isa 18.2 committee and a member of the industry review council for the 191 standard joining me we have mr todd stopper and i'm the uh business development manager for alarm management for exeter as well as the product manager for a tool called cell alarm and i'm also on the isa 18.2 committee with kim in the demonstration you're going to see today we're going to be describing to you a work process which is represented by the diagram center the blue boxes this work process comes from the isa 18.2 alarm standard and so we'll step this uh process through using a real alarm as an example to the left and right of this work process you see the various tools that will be used uh during the work process uh cell alarm and master alarm database and rationalization tool set uh we'll be looking at delta v version 11 uh in its alarm help feature and also for monitoring and assessment we'll be using the delta v analyze products there these products uh fit into the architecture as you see here the sill alarm up tool is generally installed on a plant land layer not on the delta v control network which is represented in the center and lower half of the diagram it's all to be the analytic tool is typically installed on the delta v system on an application station as you see delta v alarm help is a capability to present the information about an alarm to an operator and that would be presented on the workstations on the delta v system also represented in the center of the diagram we'll also be touching on the core elements of the delta v system during the demo including the engineering environment for delta v now for the demo what we're going to look at is a small process area representing a solvent tank with a couple of inlet flows and an outlet flow with the filter and what we're concerned about is a high level alarm lic 500 and then what we're going to show in this video is the tools and techniques for how we would deal with one alarm as it goes through the alarm management life cycle so we're going to look at how we can review and analyze alarm system performance following the monitoring and assessment stage in the life cycle including identifying problem alarms nuisance alarms or in this case a chattering alarm then we're going to load the alarm system configuration for that particular alarm into our master alarm database which is the sill alarm tool then we'll execute rationalization for that alarm following the customer's alarm philosophy document when we complete rationalization we'll make sure that the proposed changes are approved by our management of change board following our moc process documented in our philosophy document then we'll implement the new alarm settings in the delta v system and then last but not least we'll create alarm response procedures for the operator to help them know how to respond to this alarm when it occurs okay now we're switching from the presentation slides to an actual demonstration and we're going to begin with delta v analyze so i will proceed to the start menu here and in the start menu for delta v analyze you'll see that there's actually two different links to web pages one is to the delta v analyze administrative page and the others to the delta v analyze page during this brief demo we'll not be visiting the administration page but what it is used for is to set up delta v analyze for such things as definition of shifts and scheduling of alarm statistics reports so let's go ahead and take a look at the delta v analyze webpage okay we've arrived at the overview page which is the starting page this particular page is used to do month-to-month comparisons of trends in terms of the alarms events and user actions i'll be focusing on alarms today there's a number of columns missing here because this small system that we're demoing on today is on my laptop pc not connected to a real delta v system i am going to briefly show you what the data looks like for this page for a real delta v system and to do that i'm going to actually change from the name of my laptop computer to a name of a fictional uh company the data's real but tulsa oil is a fictional company here you'll see what the data can look like month to month and here we have a situation where month to month the customer is getting an improvement in the number of alarms that is they're coming down uh month to month except for when they get to may and things pop up a little bit now the way delta v analyze works in general is point and click so i'm going to click on that column hitting for you and we'll go from a month-to-month view to a specific month in this case we're looking at the month of may and here we see the alarms for the month of may presented in terms of which units are creating the most alarms it's possible to sort by something other than unit count one can sort by time and i've just reformatted the x-axis label so you could see the entire month one column at a time so this is basically the way that delta v analyze works all these pages are pre-engineered by emerson you don't need to build these pages they just out of the box work this way for example one could focus on the critical alarms drill in or using the breadcrumbs come back perhaps focus on a particular unit and then again using the bread crumbs come back so let's get back to the main demo that we're doing for you today and for that i'm going to switch back to the overview page and select the data that came out of this small laptop system we're using for the demo go there one of the things that's important about alarm analytics is to be able to see the information not only for an entire system but to be able to focus in on a particular operator's position and for that we use this feature here in the center where i can select not just all areas but a particular name in this case utilities that corresponds to the delta v areas assigned to the utilities operator and here we can see uh that there are alarms being created in these three areas right here now rather than say month to month i'm going to focus in on a particular point of time last month to do that i'm going to use bookmarks and you'll see that i have a bookmark here called utility alarms in the last 31 days so i'm going to focus in on that these relative bookmarks are really useful because one can set them up uh and then just day-to-day reuse them and not have to worry about re-specifying a date range so we're looking at the alarms that are coming out of this part of the plant including that solvent area that todd showed you in the diagram you'll notice that i've got a number of critical alarms here coming out of this area called kvc you'll notice also with delta v analyze that the tip tools that give you a lot of information when you hover over a pie chart or a column in this case i've hovered over that column in the red area which is the critical area alarm level 15 and delta v and you'll see that there were 45 critical alarms if i wanted to um drill in a little bit to a given area i can do that such as this kvc area and we see that all of the critical alarms are actually coming out of this control loop lic 500 i'd like to understand a little bit more about that guy so what i'm going to do is look at this thing not by count but look at this by time and here we see that uh on the uh 27th of the month is the first time i saw these critical alarms and then uh more recently here there were some critical alarms on the uh the 17th and 18th here i'm going to focus back in this october date where the critical alarms were try to understand that with a single click on that day column now i'm looking at the same information only now the resolution is hour by hour midnight and so forth until we get to 8 am and we start to see the alarms going up so this is one way to to look at them i'm going to focus on this lic 500 in particular by selecting that module and so you can start to get into some module details again again these module details can be sorted not only by count but by time and you see a similar view here only for a particular module you may have noticed these horizontal lines across the diagram these correspond to the incoming alarm rates and at the 10 o'clock to 11 o'clock hour the incoming alarm rate uh was actually in excess of not only the acceptable level but was actually in excess of the manageable level these are by default and delta v analyze the amua levels although you could set those using that administrative page to a different set of names and alarm rate bands corresponding to your alarm philosophy document one thing about this high alarm is i noticed that on this particular day it activated 27 times the shortest time being just a two second activation and the average being two minutes i suspect that this alarm is actually shattering i'm also concerned that this alarm is even critical knowing that solvent area i wouldn't have expected it to be have been prioritized quite that high so we're going to focus on the lic 500 module now before i leave delta analytes i want to show you one other page and that is the alarm statistics page the r statistics page serves really a different purpose than the previous things i showed you the previous examples of drilling down were really all about analytics and trying to understand what's going on with your alarms this dashboard here really represents a measure of the health of the alarm system overall so for i'm looking at just a day here but for any given date range one can look at what is the distribution of alarm priorities down here one can look at the key performance indicators that you would typically find in your philosophy documents such as average alarm rate peak alarm rate average time to acknowledge those type of measurements as well as a distribution of alarm incoming rates what percentage of the time were the alarms coming in at what was an acceptable rate versus a managing demanding or even unacceptable rate or whatever labels you choose to give to your alarm ring fans in addition to looking at these statistics these kpis as a dashboard one can actually create an excel report which i'll do now for you the advantage of creating an excel report on demand from this screen is you can really filter into the areas the in the data ranges that you're most interested in for purposes of periodic reporting you would probably take this report that i'm showing you here and not running on demand from this screen but rather you would probably just go ahead and just schedule it on that administrative page to run automatically at the end of every day week or month uh whatever is your preference so here we're looking at this alarm statistics report that i've created on demand and you'll see that we've got a date range we've got a scope in terms of the areas covered we have all of our key performance indicators that could be compared to your velocity document a little profile of the alarm timeline uh the distributions which are part of your metrics and then you get into a top 20 alarm sources list now this particular tiny demo system that we're using today just has a handful of alarms that i manually created so you're not seeing a whole lot here but what you are seeing here is that this lip 500 or this solvent tag has activated 91 times on that date an average of four per hour which is quite a bit also further down we have a top 20 modules with the shortest average activation time which i use to identify chattering and fleeting alarms and you'll see that this alarm has at the top of that list now what does this list look like for a real delta v system let me go ahead and just show you an example of that i'm looking at that same system we were looking at online a minute ago now we're looking at nearly a month's worth of data that was given to me up for the system and you'll see that we have an average alarm rate of 16 per hour there was a flood there was a peak 10-minute period where there were 207 alarms in a 10-minute interval you've got a profile for this particular customer's data and you'll notice that on one particular date here they really had a problem in the sense that they had a lot of alarms these alarm priorities here are the names that were given in the delta v system to the alarm priorities there's no need with delta v analyzed to configure these uh the delta the analyzed products made to work with both of the analyzing it already knows how to look up and report whatever the alarm priority names are in the system here's a distribution for this particular customer and i would say this customer is not in horrible shape they certainly don't meet the profile that one might want to have for the incoming alarm rate targets six percent of the time they're at an unacceptable level but i've seen systems that are much much worse than this also notice here in their top 20 alarm sources that if they were to take the top one two three four five six seven the top eight alarms and address the alarms that are coming from those top eight modules creating those alarms they would have eliminated a full fifty percent of all the alarms coming into this system and that's a very typical thing where just a few alarms will create uh the majority of the alarms also in their 20 list of shortest average activation times you'll see that at the top of the list we have one particular alarm that activated 12 times for a total sum of 11 seconds not even being on average one second on so clearly that's an example of a shattering or a fleeting alarm to complete the report we have these modules that are uh the arms that are on the greatest length of time that is these are scale alarms probably indicative of an alarm that is not appropriate for a given process state that would suggest something that we need to be addressed in rationalization to do some state-based alarming there we also see alarms that are most frequently suppressed by the operators alarms that have actually been disabled perhaps by a supervisor indicating maybe alarms that should have been taken out of service altogether and then our profile of the highest date so we're going to leave this now and in fact we're going to actually leave delta v analyze at this point and we're going to focus on that lic 500 and continue continue the demo that we had started for you so going to uh delta v uh explore this is the heart of the engineering environment for delta v that uh area kvc was throwing the most alarms and within that you see there is this lic 500 module i recall that the high alarm was actually the one that was generating uh most frequently i expect that it might be shattering so i'm going to just take a look at its properties and there's a couple things here that strike me about this alarm first of all it's got an 80 limit which is i know the default for a high alarm chances are this alarm has never really been given close attention to determine a proper limit there's been no functional classification assigned which would have happened during rationalization so i know this alarm was not rationalized there's been no alarm help provided to the operators and it's got a a criticality that's high priority that's higher than what i think might be appropriate um also under advanced settings we'll see that there's no shelving going on here this thing has the the uh delta v default of 999 days here so i i suspect that we're not doing shelving with this alarm if it is a chattering alarm that would suggest that maybe the hysteresis on delay and off the label properly set let me just take a quick look at those and as i look here i see that the hysteresis for this high alarm was set at the default of half percent which may not be enough for a level loop such as we have here we also have zero seconds of off delay and zero seconds of on delay so this a particular alarm could indeed be a chattering alarm so uh the next step is to actually have this uh alarm of this module be rationalized so let's go ahead and begin that part of the work process rationalization by getting this modules information out of this engineering environment and over into the syllable arm environment so to do that i'm going to use a standard feature of delta v which is an export feature using bulk edit so i have highlighted the particular module i want to export and i could just as easily have exported the whole area or for that matter all the control strategies across the system but i'm going to be very focused in this demo highlight there and do a file export user defined i'm going to step through here to actually select all of the alarms within the or all of the modules in this case it's just one module now we're asked for a format specification file this is a template for actually doing the book export to know which fields to bulk export i'm going to browse and you'll see here that we have a series of these format files that have been specifically designed for use with cell alarm i'm going to select this one that relates to process alarms as opposed to hardware alarms or device alarms i'll open that now that we have a format file then the next step is to actually create a data file one doesn't exist so i'm going to give it a name i'll call it lic 500 so that it'll be easy to spot them and get into the rationalization process click on the next step and click on the uh export here and we'll see that we've actually had a successful export so what we're doing here basically is bringing in the alarm modeling the engineering environment of delta v bringing it over into the uh rationalization environment so i think at this point here i'm about ready to turn over control to todd such that he can carry through with the balance of the demonstration for you here so let me just turn control over to todd okay thank you ken while we're getting lined up here i just wanted to say the the delta v analyze tool is great at creating actionable results that we can take care of here during the rationalization process today what we're going to focus on is the chattering alarm that was identified in analyze but certainly many of those other issues that you pinpointed in analyze we could address through the rationalization process as well so here's the cell alarm tool that's going to act as our master alarm database as well as guide us through the rationalization process the first thing we want to do is check to make sure that the settings in our tool match the rule set that's defined in the customer's alarm philosophy document so one of the critical things we want to look at is the prioritization scheme that's defined in the tool and make sure it matches so here we can see we have five four priorities defined log advisory warning and critical corresponding to the defaults in delta v where log is not presented to the operator so that matches up let's also look at the descriptions of consequences and impacts and philosophy defines a consequence matrix of four columns by three different impact categories with personnel environmental and financial and that matches up and we can see here that there's individual editable descriptions for each box in that matrix and that does also correspond to what's in the philosophy document so let's make sure the prioritization grid is completed and for that matrix of four different potential consequence severities and four different operator urgency levels we have assigned the associated priority for each cell and yes that does match up with what's in the philosophy document so we should be good to go from a alarm prioritization and now for this particular customer this particular philosophy they've decided that system and instrument diagnostic alarms should not be presented as alarms to the operator they should instead be treated as alerts and presented and modified or sent to the maintenance department they'll be available for the operators to see but they'll be segregated that information will be segregated from the alarm information so we're going to define three different priorities of alerts critical warning and advisory these would probably correspond to priority numbers four five and six in a delta v system so that's set up next we want to look and make sure that the classifications are defined to match up with what's in the philosophy document we've got six different classifications defined we could add or subtract from that to match up and that does and last but not least since since kim said that he suspected this was a chattering alarm we want to review the recommendations for alarm dead bands and on off delays and we can see here that the defaults have been entered and they correspond with what's in the alarm philosophy document as well so looks like we're ready to begin we'll close the settings and call up our master alarm database and i can see we have 180 alarms in that database right now and if i scroll through that list i don't see the lic alarm that kim mentioned so it must not be in here so we will import it into this database so we'll click on the export import alarms select and browse for that file and there i see it he put it on his desktop so that's got the alarm information for lic 500. so we'll select that and we have a couple of prompts to enter save my project i do want this information to be loaded now i need to think about do we want all of the alarm conditions from this control module even the ones that are not enabled i don't think so i think we just want to rationalize the existing enabled alarm conditions so that's all we're going to bring in next it asks me whether it wants to do a one-for-one comparison between what we're importing versus what's in the database to look for alarms that are missing and we don't want to do that in this case because we're only importing from one control module alarms from one control module not the whole entire configuration so we'll skip that comparison and proceed with the import process it's asking me to define the name of a change log file it creates a change log every time it does an import so now let's look at the results the change list shows me that there were no modifications made to the alarms that were already in the database which is what i would expect but let's click on the additions tab and we see that it has added the new tag lic 500 and it's brought in three new alarms a pv bad a low and a high so we should have added three alarms to our master alarm database so let's close our import and we'll look and we see in the top heading that the number of alarms in the database has increased by three now it's up to 183 so let's find the lic 500 we could scroll through but if this was a big database that would make it hard to find and hard to work on so let's actually filter it so let's set a filter to say show me the alarms that are only from lic 500 and i really like to use this filter during rationalization because it allows me to segregate alarms by logical groupings because then i can apply the results from one alarm to many other alarms and that helps me get through the rationalization process as quickly as possible i can actually copy the results from the rationalization results from one alarm to another so being able to filter really helps me understand what i'm looking at so in this case we we have our three alarms i'm going to select the high alarm and begin the rationalization process it's going to guide me through step by step and first what i see is the information that's been brought in from delta v such as the engineering range it's 0 to 100 looks like it's 100 foot tank this is actually a pid loop so that's good to know the next i'll move on and it's given me an opportunity to record any safety implications to this alarm so i'm going to look at the lopa analysis the layer protection analysis and the hazops that were done for this plant in particular for this unit and i do see that this alarm was actually identified as a safeguard and a hazard so i'm going to record that information so that we have a cross reference so that we can always go back and understand where this alarm came from and what its significance is so we've got that recorded next we're going to move on to determine whether this alarm is really legitimate or not by first addressing what is the potential consequence for this alarm the tank uh if it if the operator does not respond to this alarm the tank will overflow the solvent tank will overflow and that will result in a chemical release so we're going to record that consequence and then as part of this rationalization process this is a a multi-functional team that's involved in recording this information and making these decisions so we have one of our best operators involved and he's helped us determine or document what the likely causes would be for this particular alarm so we're going to take that information and document that as part of the rationalization process he's also told us how he would respond to this alarm the corrective actions that he would take so we're going to record that information and you can see this is kind of a knowledge capture process documenting what your best operator would do in response to an alarm so in addition to accomplishing rationalization we're also doing knowledge capture and then he's also told us how he would confirm that the alarm is legitimate and troubleshoot and determine what the actual situation is so we'll record that information so now we've got everything and based on what we see it's got significant consequences we've defined what the operator's supposed to do so yes this is a legitimate alarm so it's supposed to be there now kim mentioned that there was no alarm help defined so we want to check the box so that's created and what that'll do is take this information for cause consequence corrective action confirmation all this good information that our best operator helped define and we'll allow that to be transferred to delta v and then populate the alarm help screens so every operator no matter what shift when this alarm occurs they'll be able to see what the best operator would have done in response to that alarm so i think that's tremendous operational value so now let's look at prioritizing this alarm we are going to assess the consequences in the area of personnel first in the event that the alarm has not responded to and the tank overflows and there are people in the area at all times so this could result in some injuries so we'll do our assessment using these descriptions that essentially came from the alarm philosophy document from the consequence matrix our experienced operator said they would expect that they would have about five to fifteen minutes to respond we enter that information in our prioritization matrix says that this alarm should be a warning priority which is interesting because in the delta v system this is set as critical priority so kim's questioning of whether it really should be critical was legitimate based on this analysis that we've done of the consequences the potential consequences and the amount of time the operator has to respond i would say that this alarm should not be critical but should be warning instead so now let's move on to the classification step and this alarm comes from a hazop and impacts personnel safety so we're going to select those classifications classification allows us to group alarms together that have common requirements for testing training and moc so this will make it really easy to find alarms like this one that come from a hazop or impact personnel safety uh and probably we'll want to make sure that they're highlighted in our testing plans to make sure that this alarm is tested at a pretty good frequency every 12 months or so next we want to look at the alarm limit and i can see that right now it's set at 80 in the delta v system which i know is probably the default for this control module and now the tank is ranged zero to a hundred so it'll overflow ing to these drawings when the tank level reaches a hundred so that is the consequence threshold that we need to be concerned with now for this we know that when the inlet valve is open the max rate of change is going to be 0.5 feet per minute as a standard we want to make sure that the operators have at least 15 minutes to respond so if we know this so based on the fact that we know this process dynamic information we've calculated that the alarm limit might probably might better be set at 92.5 so we're going to copy that value and enter that into our selected set point now what we want to do is document the rationale for why we set the alarm limit where we did so we'll document that we are allowing for a 15 minute response which will help us then in the future if anybody ever questions this alarm limit or we need to determine whether it's still correct now we understand why it was set where it was and maybe we'll find that process conditions have changed we've got new equipment in there that yes in fact maybe this limit should change but now we know for sure why it is where it is now let's look at the dead bands and alarm on off delays and kim had mentioned that this was a chattering alarm and i can see that it is a level and the dead band is set to 0.5 which i know is the default but that's a little low for level devices so our alarm philosophy says that we can make the dead band up to five percent so i'm going to change it based on the fact that we were having problems with this alarm we're going to change the deadman to 5 we can also implement an on and off delay of up to 60 seconds i'm going to implement 60 for off delay not comfortable with that high of a value for on delay so i'm only going to make it 15. next we'll move on to suppression now we've decided and then in this and it's documented in our philosophy that we want to provide the operators with the ability to manually suppress alarms manually suppress alarms that are nuisances also known as shelving this is much preferable to allowing them to enable and disable arms because when they show that the alarm will disappear temporarily but it'll come back so it's never lost track of so we want to implement shelving for this particular alarm the default in delta v is 999 days so we're going to eliminate that and we're going to allow the operator to show this alarm for five minutes at a time also i know that this particular unit has problems with alarms when the equipment is out of service when the solvent tank is out of service and many of the other alarms in this unit are actually suppressed during that state now this is a pretty critical alarm because it was identified in a has hazop so i don't feel that it can be suppressed when the equipment is offline like the other alarms in fact i think we should keep this alarm it's actually pretty important because i know the tank when you when the tank is offline it should actually be empty so we're going to set this alarm to have a different alarm limit when the tank is offline something low like five feet which will let us know if for some reason the tank is starting to fill when we believe that it should be offline which would mean we've we've lost kind of isolation to the process next we can record the team that took part in the rationalization process representing all the different disciplines here in our plant and in this case now we'll change the status of this alarm so we can keep track of where it is in the process we're going to make it say that it's pending approval and that we fixed a chattering alarm that was identified in our 11 21 11 report so that's now recorded it's pending approval because we still need to go through our moc board on our moc process to make sure that these changes are authorized but now let's let's rationalize the pv bad alarm this is a diagnostic alarm so let's just jump right to the prioritization tab because that's what we need to do for this alarm and ing to our philosophy we've said that diagnostic alarms should be routed directly to the maintenance folks and not presented in summaries with other alarms so that means we're going to prioritize these differently we're going to manually set their priority as dictated in the philosophy to the alert priority screen scheme that we saw and we're going to set the alert priority equal to the highest priority from that tag which in this case is warning and we're going to document that it's per our alarm philosophy document so now we have completed the the prioritization of this diagnostic alarm we'll again go to our change log tab and change its status to indicate that it's ready for review now we go back to our alarm list and at this point we would probably go through the moc process to say this is an alarm that was identified as a nuisance alarm we've gone through the rationalization process the priority is going to change the limits going to change we've defined the operator actions so the moc team has reviewed it and approved it and authorized these changes so let's change the status of these alarms from pending approval to approval it'll pop up a message and say so we can say approved by mock midi we can kind of keep track of the status of our alarms and we can say that we can see that its approval has changed from pending approval to approved and we've reported that it's gone through that all the steps now that we've completed that we want to export this alarm information so we can send it back to kim so we can export to delta v i know this is a version 11 system so we'll select that we can export all different kinds of alarms we can rationalize all data sources in the delta v system but in this case we're only after process alarms and in particular as part of the moc review process they said we're only authorized to make these particular configuration changes so we want to make sure that the only alarms that are affected here are going to be these from lic 500 so we're only going to export those alarms not all the other alarms are in the database so to ensure that happens let's keep our filter by tag and also we will filter based on the approval status because we just went through this rationalization process and these alarms are approved so now we're going to export these alarms so they can be sent to kim to implement in the delta v system so i'm going to set a file name that he can find hit the save button and that should generate a txt file and there it is a little difficult to interpret without our fmt files to know what information goes in each column but looks like we're all ready so i'll let kim know that he can pick up the process and take the rationalization results and bring them back into the delta v system that so that he can fix the alarm issues that delta v analyze discovered thank you todd at this point here we have a approval and uh everything is ready to go so i'm going to return to the delta v engineering environment and import that set of approved changes so file import user defined format and browse to that fmt file which is going to take and interpret that txt file so i've selected that now with that formula file selected i'm going to browse and see that here is the file with the rationalized settings open that up and proceed to import it and we have a successful importer let's just first of all make sure that we can see what the changes are in the delta v engineering environment so i'm going to again take a look at this uh lic 500 here take a look uh i'll take a look at the high alarm we will now see that it's got a new priority established which is a warning priority we see the limits 92.5 there's a functional classification the alarm help has been enabled we can see that there's now a suppression or shelving timeout of five minutes allowed so operators can temporarily set the alarm aside and all of the knowledge that was captured from the senior operator during the rationalization process is now available to every operator in the alarm help system here including confirmation corrective action cause time to respond and then consequence of inaction so it looks like we're good in terms of alarm help in terms of the alarm conditioning there were some decisions made in rationalization to use some uh settings there so let's just see if they came through here we have the high alarm hysteresis which was formerly a half percent a little a little uh low for a level loop and here we put five percent in and i see that there is a uh high alarm uh off delay of 60 seconds and a high uh alarm has a on delay of 15 seconds so it appears that everything is uh completely successfully transferred into delta v at this point i'm going to take this module and download it and we'll take a look at the results in the uh so our module is downloaded uh in the delta v system alarm help is actually downloaded separately that allows alarm help to be maintained without having to actually do any downloads to control modules which is important to some delta be a user so we're going to go to the alarm help system here and we're going to download that across the system such that it's available at any operator position and that was also successful so now we've moved the changes from an engineering environment to the operating environment let's take a quick look at that here we have the um lyc 500 and i'm going to go ahead and actually cause an alarm to take place by taking this set point moving it up beyond that limit in this particular simulation we have this set point tied back to the input at this point we will see an alarm but you will recall that there is an on delay that's been established in 15 seconds while we're waiting for that let's go ahead and look at the detail display and look at the help that's available for that high alarm back here we have our alarm sounding silence the horn also notice that there's an indication in context that there's help for this high alarm which is this little blue circle with the question mark and again here is the help now if you are a user that does not have delta version 11 you're using an earlier version all of this information you're seeing here uh can be put uh using cell alarm into a pdf file where the file name actually has the tag name as part of the file name and it's very easy and our delta v folks can help you to create a button on the space flight here where you could click on that let me acknowledge that alarm click on a button that would take you right to a window that would pop up with a pdf file that's been nicely laid out for presentation of alarm help for a free version 11 customer so i think at this point here we've actually completed the cycle and so let's go ahead and end our simulation here our demonstration and move to the conclusion of the presentation with some summary slides here okay thanks kim so as we saw we were able to identify a poorly performing alarm actually a chattering alarm using delta v analyze and then take that alarm through the whole alarm management life cycle the work process a consistent rigorous work process with checks and balances to make sure that only authorized changes are being made and then are implemented within the system so we were able to load the alarm configuration into our master alarm database using delta v bulk edit standard capability and so alarm then we rationalized the alarms using still alarm export that information first did a review and authorization process using moc then we export the information so that it can be implemented in delta v and then last but not least create alarm response procedures using the alarm help subsystem for the operator so we identified a poorly performing alarm corrected it got the operations team involved in making it and recording the information on how that alarm should be responded to and then made that information available online to the operators so thank you very much for your attention if you'd like to learn more please feel free to contact kim or myself at the email addresses listed below