Hi,
My company has Delta V 10.3 since a couple of years. Right now we have a major interest in taking advantage of system flexibilty on alarm management. I'm trying to create a tag that will allow me to monitor the current number of active alarms in my system and go back in time to see the value of this number at any moment in the past. This will allow me to identify alarm flooding / alarm banner saturation since my current Delta V Analize version is no capable of this.
The problem is that I don't know how to create a reference to this number so I can link it to a control module and from there to data historization. One of the default operating pictures shows this number using the following reference: DVSYS.THISUSER/ALMCNT.F_CV, but I've tried this and doesn't work. I know from Books On-Line that THISUSER is acknowledged by DV as a control module in the default AREA_A, so I've tried to change the reference to: DVSYS.THISUSER/ALMCNT.CV , but it seems like ALMCNT is not a valid module parameter.
I'm also trying to the same with current suppressed alarms number, but I guess the logic is just the same.
Thanks a lot in advance for any help.
In the past, I have used the diagnostic parameter for the event chronicle records written rate (open diagnostics and browse to Journal subsystem of chronicle node) to identify when alarm flooding occurs. This parameter can be read by a control module or historized separately.
This is better than an alarm count as it indicates potential network issues or other unalarmed abnormal events.
Make sure your chronicle is assigned every area.
Youssef El-Bahtimy | Systems Integration Technologist PROCONEX | 103 Enterprise Drive | Royersford, PA 19468 USA Proconex Office: 610 495 2970 | Cell: 267 275 7513 Youssef.El-Bahtimy@ProconexDirect.com
In reply to Youssef.El-Bahtimy:
Turns out records written rate is no longer available. Scratch my suggestion.
By the way THISUSER information is only available through iFix and is only pertinent to the interactively logged in user. It does not referenc the alarm subsystem of the node without that user context, and therefore cannot be read in the controller.
Thank you.
Our system is in such a way that that a single operator is needed (there are no zones or sub-unit segregation) and therefore the same active alarms are seen on every station and for every logged user having the appropiate lock permit. This eliminates any problem caused by using THISUSER information.
Is there anything like an alarm counter available to be read in a control module?
Regardless of you particular usage, the alarm framework is such that it is reliant on the DeltaV application user scope, and is thus not available via OPC or by persistent reference in the controller.
You have a couple of options:
1. Write scripting within Operate VBA to read the THISUSER values periodically, and write them to a control module parameter via the frsreadvalue and frswritevalue functions. This scripting would need to be placed in a persistent graphic object such as a schedule, toolbar, alarm banner, user.fxg, or SIglobals.fxg. The scripting would only run when Operate is running, however.
2. Write SQL queries against the chronicle database to determine, for a single point in time, to find latest *distinct* instance of all alarms becoming active before that point, then subquery each instance to find if a complimentary inactive or disabled event occured before the point in time. This will likely be a very expensive query, and dependant on the size and retention of you chronicle, may not yeild alarms which have been active for very long durations.
You may want to consider DeltaV Analyze because when you say "go back in time", this is sometimes difficult and controller resource intensive to do on top of the issues Youssef has described for Workstation and logged in User.
www2.emersonprocess.com/.../PDS_DeltaV_Analyze.pdf
Regards,
Matt
In reply to Matt Stoner:
Yeah, I agree with using Analyze, but SMAQLL states his version of Analyze won't do this....Maybe SMAQLL could be more specific about what version he's using and what he has encountered.
Youssef makes a couple of good suggestions. I would keep it simple and go with a basic script in the Alarm Banner to write the alarm count value to a Control module and then you can historize this like any other parameter.
The alarm summary parameters are based on the alarm count after any filtering applied at the console. So you should also consider any enabled filtering and report this as well so there is context to the alarm count you are recording.
As for mining data from the Even Chronicle, Analyze will give you the best tools for that. Consider upgrading it rather than spending time building your own queries that may not actually work as expected...
Andre Dicaire
Thank you guys for your responses.
Right now I would take the VBA scripting option. My only problem with this is that I'm not sure about what Youssef means when he says that: "scripting would need to be placed in a persistent graphic object such as a schedule, toolbar, alarm banner, user.fxg, or SIglobals.fxg"....
Specially, What do you mean with "persistent"?
As far as I know, I can do the scripting in then same standard graphic that now is showing me the alarm count with the THISUSER information, which I mentioned before that can be used in my context.
The scripting will work whenever Operate is running. In my case this is 100% of the time since Operate is running in at least one of the operator stations and/or engineering station (pro plus) all the time.
Am I right?
Thank you guys for your responses. Right now I would take the VBA scripting option. My only problem with this is that I'm not sure about what Youssef means when he says that: "scripting would need to be placed in a persistent graphic object such as a schedule, toolbar, alarm banner, user.fxg, or SIglobals.fxg".... Specially, What do you mean with "persistent"? As far as I know, I can do the scripting in then same standard graphic that now is showing me the alarm count with the THISUSER information, which I mentioned before that can be used in my context. The scripting will work whenever Operate is running. In my case this is 100% of the time since Operate is running in at least one of the operator stations and/or engineering station (pro plus) all the time. Am I right?
In reply to Brian Atkinson:
If you have multiple operator stations running Operate, make sure not to hit the same parameter from each one running the Operate script. If the alarm scope of each workstation is different (with different alarm counts), consider sending the counts to different parameters or different modules that segregate the alarm count of one workstation (alarm scope) versus another. If the alarm scopes are not different, just minimize the unnecessary writes to the parameter from multiple workstation, unless of course you want unintended redundancy for this feature.
Since the alarm information is user/node based, ensure some user is always logged in by using the DeltaV Autologin / DeltaV Screensaver features.
All right. I'll be making my attempt next week. I'll come back to tell you my results. Once again thank you all.
In reply to SMAQLL:
Thank you guys, with your help I did really good on this matter. I see now that I need to get used to Delta V subroutines and functions to fully exploit all the potential of the system.