Emerson Exchange 365

Rolling Alarms/Hour - DeltaV Operator Display and Historical Collect

Hi All,

I'm trying to figure out a way to display a rolling "Alarms/Hour" on a DeltaV Operate display and maybe historically collect this value.

I can easily query the Event Journal database "outside" of the DeltaV environment, i.e. querying the SQL database in a VBScript and store in a text file, then schedule this using Windows Task Scheduler. However, this seems a bit clunky and it doesn't appear to be easy update the value periodically without the need to manually refresh a display.

We have DeltaV Analyze, which seems to be the obvious tool, but our operators are not currently using and firstly, I'd like to just get a simple alarms/hr number displayed on a graphic that updates without the need to manually refresh i.e. reload the graphic.

Ideally, I'd like to get the number into a module, so I can add alarming, historically collect etc., but baby steps first!   

Hopefully I'm missing the point, as this seems like something that would get requested frequently!

The driver for this is to get some ownership from the operators to managed alarms proactively e.g. shelve nuisance alarms in a timely manner etc., rather than wait for a report to tell them how bad the alarms were.

Thanks in advance for any pointers.

Colin. 

• alarm
• DeltaV #DCS
• VBScript
• SQL
• VBA
• Event Journal

ccranton

• 13 Aug 2021 8:50 AM
• Cancel

3 Replies

• LaurentB

  

  • 13 Aug 2021 9:20 AM

  if you have latest dv version , have a look on new features as per example Operator Statistic Module OSM modules in the library

  • Cancel
• Matt Stoner

  

  • 13 Aug 2021 12:43 PM

  In reply to LaurentB:

  You just need to have DeltaV version 13 or 14 and the module described is located under ModuleTemplates in the AlarmManagement folder and named ALM_STATISTICS. You can find help in the module and/or in Books Online under Configuration->General Configuration->Alarms and events->Alarm statistics.
  
  This module doesn't do exactly as you need as this is more to generate numbers for ISA 18.2 Alarm KPIs but you could take this starting point and develop what you need.

  • Cancel
• Andre Dicaire

  

  • 13 Aug 2021 5:38 PM

  In reply to Matt Stoner:

  This module works with a script running in the console that writes the Alarm information to the module. Each console reports on its alarms, you should collect alarms from each console which will be based on the User and console span of control. As Matt said, you can modify the existing module to suit your needs.
  
  In Operate, the script is run based on the scheduler. In Live, there is no scheduler. I looked into this and decided to use an Alarm Banner display variable with the OnWrite script. This variable monitors a module parameter that is trigged by a DTE block to create the update events, say, every hour. To ensure the script "sees" the trigger, I set it with the DTE but clear it with the script. If the trigger lasts more than several seconds, you can flag that the event was not acted on. Maybe the console was rebooted, or a reset of the HMI was in progress. I wouldn't make this an alarm, but you might want to log an event.
  
  The Onwrite script triggers when the module parameter changes. The script can then gather the alarm information and write values to the module. the script ends by returning the current state of the parameter to the Variable, ending the script execution. During this execution, you can reset the flag. I used a reset parameter that connected to a Flip flop reset. The DTE sets the OUT and the RESET parameter resets it to false. The Script will see the change back to zero, so you simply evaluate the value of the parameter to see if this is a set or reset change.
  
  The Alarm Banner display is present on all your workstations. If you use different Alarm Banners on different consoles, you would need to add this variable and script to each display. If you use the ENV.Nodename in your parameter names, you can make the variable reference and script dynamic to the Nodename it is running in. You can then turn this into a GEM so you can more easily manage this in the system incase you want to make changes in the future.
  
  I first considered doing this from a Layout variable, but there can be more Layouts defined than Alarm Banners and one cannot use a GEM in the layout.
  
  If you prefer to use a timer, be aware that the timer is limited to about 65 seconds (this is a known issue). You can set this to 60,000 ms, and write the script to evaluate current time to see is an update should occur. Note that every time you write to a parameter, the event journal records this as a User Change. You would not want to just write values every minute from every console. I think you'd need a variable to keep track of the last "hour" and when the hour changes, you execute the parameter writes.
  
  I'm thinking that the DTE approach would allow for a module to create Scheduled triggers that all consoles can reference with OnWrite variables to create a scheduler. It may be simpler to just use a off delay timer that holds the trigger for 5 seconds. The scripts will only fire once and would not need the reset write.
  
  Hope that helps.

  Andre Dicaire

  • Cancel