Emerson Exchange 365

• Not Answered

Alarm Horn Retrigger

I am trying to see what the best approach is to retrigger the alarm horn after the operator has silenced it. As of now when an alarm comes in the operator hits the "up arrow" key, which we have a key macro to silence horn. Sometimes the alarm will go awhile before they even ack the alarm. So I was trying to figure out a way if they ignore this that after a period of time the horn will retrigger and go back off. I was looking at maybe a scheduler. I have tried it in a module just for that particular alarm by ack it through the code, and also disenabling it then reenalbing it but I am not sure that would be the correct way. I was looking for maybe a global way to do it. Anyone ever do anything like this?

Bill Sayers

• 6 Mar 2016 8:02 PM
• Cancel

9 Replies

• dave_marshall

  

  • 7 Mar 2016 1:55 PM

  Hi Bill,
  
  I have implemented this type of action at a customer site. In my approach, I built a composite that has as an input the parameter that you would alarm off of and as an output a parameter that the alarm is triggered from. Inside the composite I had the re-triggering timer logic. When the alarm is to be re-triggered, it drops the output for a scan and then re-sets it.
  
  The other method that I experimented with was using an Action block to set the .NALM field of the actual alarm to 0. The NALM field is the "New Unacknowledged" indicator for the alarm, and this would effectively re-trigger alarm as well.
  
  I looked through my notes to see why I went the first method I mentioned instead of the second, but I couldn't find a reason. I may have had an issue being able to write to the .NALM field in an Action block.
  
  Dave

  • Cancel
• Andre Dicaire

  

  • 7 Mar 2016 4:08 PM

  Caution: Although there may be value to retriggering the Alarm Horn, the first thing to do is identify if the alarm system is adequate. If alarms are properly designed, and operators trained, there should be little or no need to retrigger alarms. If the system is not performing properly due to too many alarms without consequence and Operator actions defined, adding additional Horn activations may simply contribute to more dysfunction within the handling of alarms. The challenge is to correctly identify those situations where a horn activation is warranted. Is this something the Operators are asking for? If not, would adding this capability accomplish anything, other than a periodic activation of the Horn Silence button?
  
  That said, are you wanting to remind the operator that there are unacknowledged alarms? Or are you trying to add logic to retrigger standing alarms to remind an operator that the alarm has not been cleared?
  
  Using HORN.F_CV
  
  Since the alarm horn sounds with each alarm that enters the Alarm List (If the alarm does not set the horn, is it really an alarm? and if you want this, the alarm should be auto acknowledged), then the only time you would need this feature is when there have been no new alarms for a period of time. So the pseudo code logic might be "
  
  IF (TopPriorityAlarm is Unacknowledge) and (Time since last Horn > X seconds) Then,
  Set the Horn parameter based on the Priority of the top unacknowledged alarm,
  Reset TimeSinceLastHorn
  endif
  
  The ALARMS parameter provides access to the Alarm List in a console, and the Time In value (TIN) may be useful. You may have to add an action in your macro key that resets the time since last horn parameter, and you may want to check the horn is actually active so Operators don't "learn" to reset this timer with habitual activation of the acknowledge button.
  
  The HORN.F_CV holds an integer that reflects the Alarm priority that set the HORN. Writing this value to 0 silences the HORN. Writing the appropriate number to the HORN.F_CV would set that priority sound. However, DeltaV documentation warns about manipulating this parameter from anywhere but the Alarm Banner. You are already doing so with a Macro Key script. I would recommend that you fully test the HORN parameter behavior to understand what values are written normally and what you should use if you do decide to affect this parameter.
  
  Note that this method does not affect the state of the alarms, so there would not be any record in the Event Chronicle that the Horn was reactivated. The downside is the Horn goes off but without a clear reason for the horn, it will become a nuisance.
  
  Using NALM:
  If the highest priority alarm is an acknowledged alarm, you could choose to write to the NALM, which would record an event as the alarm state would change. This would retrigger the Horn and require the Operator to re-acknowledge the alarm, and would record these events in the Journal. The alarm in the left most field of the Alarm Banner would change to Unacknowledged state. When there are no unacknowledged alarms, the highest priority Acknowledged alarm moves to the ALARM[1] position. If its TIN is > than X, you could reset its NALM. I'm not convinced this would be useful.
  
  Since we don't really know what the under lying issue you are trying to resolve, adding more alarm horn activations or retriggering alarms simply based on operator horn activity would not be my first choice. I encourage you to get input from your Operators as to what they need to improve their performance. Usually, the solution is a better performing alarm system, not more horn activations for no apparent reason.

  Andre Dicaire

  • Cancel
• Bill Sayers

  

  • 7 Mar 2016 8:36 PM

  In reply to Andre Dicaire:

  Thank you both for the replies. Andre you are correct, to me there is more of an underlying problem. Our operators seem to get in the habit of just hitting the macro key and ignoring the current alarm. So that unacknowledged alarm could go for awhile and not be noticed. As you stated I did notice that DeltaV does not recommend changing that state other than the alarm banner. I also did notice as you had mention if you change the NALM it does record in the event log, which I didn't really like doing, also disenabling and enabling does the same thing. I tried looking into the ISA 18 standard but didn't really see anything about this other than it mentioned something about retriggering. To me this will be a challenge and not sure how to present that challenge to the requesters. Thanks again!

  • Cancel
• Former Member

  

  • 8 Mar 2016 7:38 AM

  In reply to Bill Sayers:

  Bill, to be brutally honest, the behaviour of the operator to just silence the alarm is in contradiction to what most would suggest is good operator practice. I've had the same issue at my site, and it resulted in a demonstration that when an alarm is acknowledged or silenced, if there is a resulting incident/plant trip and NO action by the operator, then the operator was liable for disciplinary action and possible legal prosecution. That soon had them on board (especially after a few of them were held to account for poor operating practices).
  
  If the operators are getting frustrated with the number of alarms (and the response is to just silence them) then I would suggest the long and sometimes painful task of an alarm rationalisation project. We are 2 years into ours and you would be surprised how differently the operators view what should happen in response to an alarm compared to the engineers. Sometimes, the operators think an alarm is useless when in fact its a precursor to something more significant. That kind of thing helps to focus on operator training too as it can show up the short-comings in training material, procedures, etc. I know the HSE in the UK are getting quite hot on compliance to EEMUA191 so from my perspective its a no brainer. It's also one of the site KPI's so it gets focus from senior managers too.

  • Cancel
• Ben Bishop

  

  • 8 Mar 2016 2:20 PM

  In reply to Former Member:

  A full alarm rationalization lifecycle process is best, but if you need somewhere manageable to start then DeltaV Analyze is a great tool. It is a "zero configuration" tool that plugs into your Event Chronicle. It gives you a web browser based portal to view alarm statistics. Which 10 alarms are activated then silenced immediately (nuisance perhaps)? Which 10 alarms are activated most frequently (chattering)? You can potentially make significant progress looking at these "Top 10" lists and adjust DeltaV alarm parameters such as on/off delays and hysteresis. Determining if a process condition is actually an alarm is a more involved and time-consuming process, but in the end will make your operators pay close attention next time the horn sounds.

  • Cancel
• Andre Dicaire

  

  • 8 Mar 2016 2:56 PM

  In reply to Ben Bishop:

  And, if you have a Guardian Support Contract, you can submit your Event Chronicle for a free report. That would be a great way to start, and see the value of Analyze. But be careful, you will probably want to buy it after you get this report...

  Andre Dicaire

  • Cancel
• scottjturner

  

  • 9 Mar 2016 5:59 AM

  Really good posts guys. I agree with the thoughts that the alarm system may not be set up as well as it could be. Alarms should allow the operator to respond to an abnormal condition before it escalates. If he or she does not respond and it does not escalate then maybe it should be an alert and not an alarm?

  • Cancel
• Bill Thackston

  

  • 9 Mar 2016 12:21 PM

  There is also an excellent primer on ISA 18.2, which you can find here: https://www.isa.org/store/alarm-management-a-comprehensive-guide-second-edition/116298.  You may not have registered Colin's statement about being two years into an alarm rationalization process.  This is not unusual and seems daunting, but the long term payoff is worth the effort.  As Ben suggests, the "Top 10" lists from DeltaV Analyze will show the low-hanging fruit.  In similar projects, I have managed to reduce the alarm rate about 80% by addressing the top 10 most frequent alarms, all of which turned out to be nuisance alarms.

  • Cancel
• Former Member

  

  • 9 Mar 2016 1:25 PM

  In reply to Bill Thackston:

  And don't be surprised by how many of your alarms will be down to "instrumentation" errors, broken/poorly performing equipment, and poor operating schemes. One of our biggest hurdles was getting the operators to run the plant correctly. Some operators even ran controllers with setpoints = to the alarm limit! At first you will get considerable pushback to any alarm changes, or telling people to run the plant correctly, but if you point out that getting the alarms right can improve efficiency, reduce downtime, reduce costs, reduce stress, and most of all keep people safe then you should get buy-in from most people.

  • Cancel