Emerson Exchange 365

• Not Answered

Logic for Plant Wide Priority Alarms

I am developing logic that will perform certain actions (e.g. enable an output) if a certain priority alarm is active/unacknowledged. I want the logic to apply for alarms in all areas (single DeltaV zone). Currently I have logic that uses the Operator_Station_Name/Horn (with the station in all alarm areas) to see what priority alarm is active but I am not sure this is the most reliable or effective way to perform this task.

One of my concerns is the behavior Horn value. Does it hold and maintain the first alarm priority that triggers the horn regardless of subsequent alarm or does it continuously update with each new alarm priority? For instance if I get a priority 14 alarm and a few moments later a priority 15 (with no silence of acknowledgement by the operator), does the Horn contain 14 or 15 as the final value? 

Any ideas on a better way to go about this?

• alarms
• alarm priority
• horn

JoshC

• 17 Aug 2016 12:36 PM
• Cancel

1 Reply

• Andre Dicaire

  

  • 17 Aug 2016 4:17 PM

  You have set out an interesting challenge for yourself. I'm not sure exactly what you are trying to accomplish but a brief review of the Alarm system in DeltaV might be helpful.
  
  As you know, DeltaV alarms are hosted in Control Modules running in the controller. The alarms report to each console based on Plant Area assignments to each workstation and based on the logged on user's span of control, enabling the Alarm server on each workstation to manage the alarms by priority and state. The alarm parameters are also available as runtime data for display in graphics or for reference by other control modules.
  
  The Alarm server in the workstations provides mechanisms to generate alarm lists, and the workstation "ALARM" parameters as documented in books on line can provide different views of alarms grouped by THISUSER, Plant Areas and Units. The HORN parameter is driven by the Alarm Banner's top priority alarm, and when this is a new alarm, the associated priority sound is triggered. Acknowledging the horn does not acknowledge the alarm, so the horn is not a measure of the current highest priority unacknowledged alarm.
  
  In each Module, there is also the ALARM parameter that will host the highest priority alarm currently on the module. This is an Array with the first element holding the highest priority alarm.
  
  BOL has quite a bit of information on these parameters that you should understand. Note that the console level Alarm parameters are only available to DeltaV Operate and are not available for reference in control modules.
  
  Something to consider. In v13, Emerson has released some templates for dynamic alarm suppression. This allows a group of modules and their alarms to be monitored and action taken on certain alarm combinations to minimize alarm flood conditions. By having multiple such modules, you break the problem into manageable chunks and could create supervisory type modules for more global actions.
  
  If you want to manage all alarms in the system, you could dedicate a workstation for this purpose, using the Alarm Server and workstation alarm lists to monitor process and other alarms/alerts. This workstation would have all areas assigned and would have a low priority user that can basically only view alarm data. You could create an associated module (assigned to the Pro Plus or an App Station) to "publish" information or to drive Outputs (assign this module to a controller). The workstation scripts could also be written to access an EJournal Database to query and report on alarm system activity that includes alarms that are no longer active or unacknowledged, as these will not appear in any alarm lists during run time.
  
  By using the workstation alarm server and alarm arrays, you can let the system provide you with sorted alarm information.
  
  Hope this was helpful.

  Andre Dicaire

  • Cancel