[EE365 DeltaV Group] Limiting Alarm Suppression by the Operator to Lower Priority Alarms

Does anybody know a relatively simple (i.e., no custom VBA programming) way of restricting operator alarm suppression (using the OPSUP parameter) to lower alarm priorities.  The system is running DeltaV 11 and has the following priorities set up:
15: EMERGENCY
14: CRITICAL
13: WARNING
11: ADVISORY
3: LOG
which I think is reasonably standard.
 
I would like to restrict operator suppression (‘alarm shelving’) to ADVISORY alarms only, or perhaps ADVISORY and WARNING.  This would need to apply to the tick boxes on detail displays and to the right-click pull-down menu on the Alarm List display.
 
Thanks in advance,
 
Neil Brown
 
 

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

8 Replies

  • One option would be to use alarm suppression timeout when configuring alarms that are higher than priority type warning. Timeout value of 0s would remove the operator's ability to suppress the alm. other than that - I'm curious to know if this is possible to customize through usermanager & field security.
  • Thanks Ashwini.  I should have thought of that...  I tested it and it works fine.  Quite a lot of configuration and download though, but should be relatively easy via bulk edit.  I think my client will want to use ENAB for dynamic alarm suppression and OPSUP for manual shelving.   This mechanism would allow ANY alarm to be prevented from being suppressed – which is useful, as whether or not ‘shelving’ is allowed may not always align with alarm priority.  My only concern now is how to prevent the alarm horn sounding again when suppression is removed and the alarm is still active.  This seems a design flaw to me...
     
    Best regards,
     
    Neil Brown
     
  • In reply to neilrbrown:

    The alarm will come back as Active/Acknowledged when alarm suppression is removed if the alarm is still in an active state and no horn will sound so you should be fine. I'm fairly confident this hasn't changed and this is the way v12 and v13 work (no system to test in v11).

    There isn't a way to globally do this as the ActiveX controls for suppression can't be modified. The parameter security won't work because it has nothing to do with the priority (LO_ALM could be Critical on one module while another has it as Advisory). The only way to get this to semi do what you want (not exactly the same) is to put the Timeout to 0 as Ashwini suggests.
  • Thanks, Matt.  My client’s system is v11 and I have a v11 test system here and I’m 100% sure that, when OPSUP is cleared for an alarm that is still active, the horn sounds again.  The same is true if the alarm is suppressed by setting  ENAB to FALSE; the horn sounds if ENAB is returned to TRUE for an alarm that is still active.   I suspect this is either a design or coding error and may well be corrected in v12 and beyond.  I have been experimenting with a much simplified mechanism for dynamic alarm suppression (for relatively simple state-based alarming and consequential alarm suppression applications) and I have had to put in logic that delays removing the suppression (or re-enabling the alarm) until the alarm condition has cleared.  My client wants to reserve the OPSUP mechanism for operator-initiated suppression; thus (for v11 at least) ENAB needs to be used for dynamic suppression.  Actually I like Ashwani’s suggestion as it is just a subset of the overall question of if/when do operator-initiated suppressions get removed automatically.  Alarms where operator suppression is not permitted simply have the timeout period set to zero.  I would rather the automatic removal of suppressions were capable of being scheduled though – e.g., at shift change time.  Any ideas here?
     
    Best regards,
     
    Neil Brown
     
  • In reply to neilrbrown:

    Yeah I understand the Conditional Alarm enables on the blocks (LO_LO_ENAB, LO_ENAB, etc) and the Alarm Enable itself (LO_LO_ALM.ENAB) because it is essentially turning it off. The suppression leaves the alarm alone so it should remain active, You have me curious now as I didn't think this had changed. Have to look harder for a v11 system.

    Sounds like they need to see some of the v13 features as they have alot of great things and specifically in Alarm Management area.

    We actually did a paper a couple years ago at Emerson Exchange on that very topic, the suppression would only be good for the rest of the shift. The paper was titled "3-4922 Ready-to-apply Configured DeltaV Alarm Management Solutions" from the Denver 2015 Exchange.
  • I've just implemented just as you want for a client on v13, but it does require a bit if simple VB in pcsd detail displays and removal of the alarm shelve option from all ActiveX alarm controls as mentioned above.

    The solution allowed suppression of certain priority alarms to certain users only.

    Your requirement is simpler but the principle could be applied.

    We only went the VBA route after determining alternative approaches were inappropriate.
  • Thanks.  However I’m very reluctant to go anywhere near VB  and I’m sure my client will be too.  I think I have a workable solution – thanks to Ashwini earlier – so will run with that.  I’d still like to know if and how to stop the horn sounding again if suppression is removed for an alarm that is still active.
     
    Neil Brown
     
  • In reply to IntuitiveNeil:

    Is there any white paper on this approach? This is what I am trying to figure out how to do.