Emerson Exchange 365

Alarm Acknowledge From Database to DeltaV iFix

We have an application where we use a new alarm parameter on interlock conditions to allow access to affected devices (say in a pump, if level on a tank is too high, once interlock alarm is acknowledged, operator have access to the bottoms pump to reduce the level)  The issue is that if we acknowledge the alarm parameter at the interlock level, it does not automatically acknowledge the alarm at the device level in the first place (like the Hi Hi Level in the tank that triggers the interlock).  The operator would have to remember to acknowledge both alarms. 

I understand the general alarming structure between DeltaV Operate and Control Studio, but is there a way where we can acknowledge alarms from the control studio, like sending a bit to the DeltaV Operate (to the AckAll button) to acknowledge the alarms on a control module when operator acknowledges the "NALM" at the interlock level?  Can I create an external reference looking at the "NALM" parameter of the interlock condition to force an acknowledge?   I attached a picture below to show my thought process (i know it doesn't work like that, but just trying to get the idea across)

JPC1080

• 22 Sep 2020 5:06 PM
• Cancel

2 Replies

• Andre Dicaire

  

  • 22 Sep 2020 6:44 PM

  There are many ways to work this problem. Dynamic alarm management might approach this by suppressing and unsuppressing the High Level alarm based on the Interlock alarm. The High alarm warns the Operator of a situation that needs to be addressed. If ignored, the Interlock alarm fires. At this point, the High alarm does not really matter as the prescribed action is superceded by the action to resolve the interlock alarm.
  
  You could create a Dynamic Alarm module that monitors the Interlock Alarm and it disables the High alarm when active. When the Interlock alarm clears, the High alarm is enabled. But you might want to wait until the level is below the alarm threshold so that you don't trigger the High Alarm again.
  
  For a focused action, you should do this in the control module, or in a Dynamic Alarm module, where you can do as you describe. When the Interlock alarm is active and NALM goes to 0, then set the High alarm NALM to 0. By placing this in a module, you have some tracability of changes and the code is running in one location, not on every console.
  
  If done from the console, the Ejournal gets a message that the NALM parameter was changed to 0. If done in the module, this acknowledgement has no change, but there is a message for the Interlock, and you know there is logic to also acknowledge the High alarm. The alarm should also report it's new Active/Unacknowledged state. An you could add a Log Event recording the automatic acknowledge done by the module.

  Andre Dicaire

  • Cancel
• JPC1080

  

  • 22 Sep 2020 6:53 PM

  In reply to Andre Dicaire:

  Thanks Andre! We resolved the issue by writing to the NALM parameter. We have always read from the NALM parameter, but never knew the NALM parameter was writable

  • Cancel