• Not Answered

Running alarmsummaryutility.exe as a service

We need to set up the alarmsummaryutility.exe to run as a service, independent of any user being logged in.

We must do this in order to schedule a task to run in the wee hours of the morning.

We have not been successful in attempting to set this up. Does anyone know of a workaround to accomplish this?

 

Mark

• alarmsummaryutility standing active alarms

MPHymel

• 7 Oct 2015 8:28 PM
• Cancel

6 Replies

• Brian Crandall

  

  • 7 Oct 2015 9:38 PM

  Hello Mark,
  The alarms that the alarmsummaryutility.exe sees is a function of who is logged in to DeltaV at the time. You can create a task using Windows Task Scheduler to run daily with any configured DeltaV user, but you do have to specify a DeltaV user. If no user is specified, nothing will show up in the Alarm List. Here is a good write-up on how to configure a task.
  www.windowsnetworking.com/.../Working-Windows-Server-2008-Task-Scheduler-Part1.html
  Regards,
  Brian

  • Cancel
• PTulen

  

  • 7 Oct 2015 10:39 PM

  try creating a bat file that will login a deltav user before running the alarmsummary executable file. use hlo command to login a user (hlo.exe -user XXX -password XXX -computer XXX)
  the alarms reported will be based on area access level of the deltav user you use to login. also note that the password is exposed in readable format in batch file.

  • Cancel
• Youssef.El-Bahtimy

  

  • 8 Oct 2015 9:41 PM

  Can you speak to why you want to do this? Do you wish to snapshot the list of active or unacknowledged alarms at one moment in time? What value does this provide you?
  Would querying the alarm chronicle for alarms that went active over the last 24 hours provide more benefit to you? This can be automated in a much easier fashion and may provide more insights than a instantaneous moment.

  • Cancel
• MPHymel

  

  • 9 Oct 2015 1:40 PM

  In reply to Youssef.El-Bahtimy:

  We use a third party alarm database to track alarm metrics and manage our alarm rationalization. That system imports events either by OPC A&E are in the case of our DeltaV system we can import from the event chronicle. The problem is that over time that system looses track of when alarms clear so it begins to misreport standing alarms. They have addressed this by providing a utility to clear any standing alarms but we need to provide a list of currently active alarms for it to resolve against. Analyze will probably someday be used for this purpose, but at present we have two DCS systems and need a common database.

  • Cancel
• Andre Dicaire

  

  • 9 Oct 2015 7:07 PM

  In reply to MPHymel:

  As mentioned earlier, you require a user to be logged on with the span of control for all the areas so that the report can see all alarms. What if you simply ran this utility on each console and aggregated the lists and that would give you the data without worrying about user log on. Run the script from DeltaV Operate and this would allow you to check for conditions that ensure the data is valid, such as a valid operator is logged on, the current alarm list is complete (does not exceed some limit). You could use a write limited User account to log on, but you would also want to check that the current user is NONE in case the console is being used at the type the utility is called.
  
  Can anybody confirm if the alarmsummaryutility.exe has a maximum limit, (maybe 250?) and under what circumstances this list could be incomplete?
  
  If the summary report does not have a limit, then your challenge is still ensuring it is complete, (plant areas are suppressed, user account does not have all areas assigned, how long after logon will the list be complete...). This alarm summary utility was not created for the purpose you are envisioning, so you will need to verify carefully that it can always be trusted to contain the right and complete data. You could go from having inactive/acknowledged alarms in your report to missing Active/Acknowledged alarms. It was primarily done to facilitate an on demand report of the standing alarms on a console at a given point in time, intended to capture the current Operators alarm load.
  
  Ideally, the 3rd party application should be making an explicit check of alarms it is uncertain of. The Alarm Summary report can only confirm the alarm is currently standing. If the alarm is not in this list, is it possible the list is incomplete and the alarm is in fact still active? The way I see it, the Alarm Summary confirms if the alarm is standing (ACtive or Unacknowledged) at the time the report is run. The Event Chronicle can confirm if the alarm state has changed since the summary ran. But if an alarm ends up in the list and is identified as possibly lost, the only way to know for sure is to read the status of the alarm using the OPC DA server. Using the summary and Event Chronicle to reduce the unknown alarm states to a minimum would be prudent and reduce the amount of OPC DA confirmations, possibly to 0 if all alarm states are properly captured and read.
  
  if an alarm state in the 3rd party database matches the summary, the Event Chronicle can be queried from the time of the summary report to confirm the current state of the alarm with certainty. If an alarm is in the 3rd party database, but does not show up in the Summary list, nor in the Event chronicle is marked as "suspect", but if the summary report can possibly be incomplete, the only way to know the true state of that alarm is to read it via OPC DA. The absence of information in the summary report and the Event Chronicle may not be conclusive.
  
  Eventually, a lost alarm will be corrected when it comes active again and shows up in the normal sequence of processing. It maybe that you can simply evaluate standing alarms greater than x number of days, and confirm these with an explicit read of the Alarm STATE with OPC DA. Reading a few alarms per minute would not create any noticeable communication load on the system.

  Andre Dicaire

  • Cancel
• Kim Van Camp

  

  • 21 Oct 2015 3:33 PM

  In reply to Andre Dicaire:

  The utility is not restricted to 250 alarms as are the alarm lists visible in DeltaV Operate. I did a test in the lab and exported 809 alarms from an alarm list that was max'd out at 250 alarms. The Books-On-Line documentation for the utility can be located with a search for the phrase "saving runtime alarm information". The BOL documentation indicated the export would be a "complete" list so I'm reasonably sure there is no enforced upper limit.
  
  In the v12.3 release there was a small new (undocumented?) enhancement to this utility, the addition of a /SILENT command line switch option to eliminate the popup window in DeltaV Operate that shows where the file is being stored. Some users were reluctant to schedule the utility out of concern that this popup would be startling to the operator.
  
  I've seen other posts where users have had a bit of trouble with the command line switches for this utility. No bugs... just some finicky behavior where certain command line switches must be specified just so in order to get any results.

  • Cancel