I just saw this question directed to me which I'm hoping you can help me with:
I am looking for a way to be able to keep track of the bypasses that are on our DeltaV system. Something similar to to the Alarm suppressed page.
Your thoughts and ideas are appreciated.
I can think of a relatively low-tech solution. Create a new alarm priority, e.g., 'BYPASS' with an otherwise unusd priority. Set the alarm behaviour for auto-acknowledge and no audible. Set all 'bypass on' events to this alarm priority (I'm assuming that setting a bypass on does generate an alarm with LOG priority - this is normal practice). Set up a filter in Alarm List or this priority only.
Cheap-and-dirty, but should work. There is probably a more elegant solution using the Alarm List object, or possibly cloning and modifying the Suppressed Alarm display, but I'm not a programmer so don't really have much knowledge of the internals of such things.
Neil Brown.
I have customers ask me this all the time, so needless to say I have plans to develop further in the works.
The simplest way to keep track of bypasses (and by this I assume the user means equipment interlock bypasses; but why stop there, what about SIMULATE enabled?) is to use the event chronicle and process history view.
Presumabley, every bypass will be set by an operator (and never by code), and all plant areas are being recorded by the event chronicle.
Filter by Event Type = CHANGE, Category = USER, Parameter = *DISABLE*, and DESC2 = *NEW VALUE = 1*
This will give you a record of when any one has set a parameter with the name like DISABLE = 1. Interlocks are usually coded via conditions blocks which use the DISABLE parameter to control evaluation.
Cons - This is a very course query, since all parameters with a name like DISABLE might not actually represent a bypass. Also, parameters NOT like DISABLE might represent a bypass.
If the the bypass occured earlier than your query can traverse, then you won't get a baseline "what is in bypass now?" answer.
Additionally, if you have chronicles that are configured to be very small, the maximum time duration you can query against will represent a smaller time range than is ideal.
This can be remedied as follows:
1. configure chronicles to be larger (although performance becomes an issue if too large)
2. send all chronicle data to the Batch Historian (which can be larger without such a performance hit).
3. build a simple SQL client to query either the chronicle(s), or the batch historian. There are a myriad of examples of how to code SQL clients for VBscript or VBA, which means anyone can do it. This will also allow greater customization of your query, so you can get CND1/DISABLE but not NOT_A_BYPASS/DISABLE, for example.
There are a ton of other ways to achieve a rock solid management of equipment abnormal states, but unless you spec'd it during development of the automation, you will probably need to do some clever data mining either from SQL, OPC, or one of the other data sources DeltaV provides.
In reply to Youssef.El-Bahtimy:
I get asked this all the time as well. Feature request!
Yousseff, that's a brilliant way to do it. I hadn't thought of that.
In reply to Deb Colclazier:
This sounds like a good candidate for a DeltaV customer to add to the User Driven Enhancement Program (UDEP) site and to refer back to this thread.
This is a great multi-pronged approach, both retro-fitting (I assume) existing automation to broadcast abnormal conditions, and data mining to pick up the broadcasted information in a consolidated fasion.
How do we drive this into the product, minimizing the amount of effort system owners spend setting this up themselves?
DeltaV's flexibility allows for almost anything imaginable to be configured, but also allows for definition of automation constructs to become blurred if not used properly. An AI Point with an active simulation input may seem like an abnormal condition, but I have seen AI Point classes created with the intention of using the simulate input (in order to pass OPC values or other non-I/O references into the AI block). Trying to assess what is actually in simulate under this condition is problematic.
If bypasses and simulation enables can be employed in a single productized fasion, this would make it easier for the product to know out of the box where the abnormal conditions are....if you employ a simulate or bypass in any other non-productized method, then you risk being excluded from that productized feature.
In reply to Kim Van Camp:
The approach I took was as follows:
1.) Run a schedule nightly to generate a systemwide module list. I have it generate FHX's automatically (simply by turning on daily backup). The VBA schedule code running an hour after the daily backup, finds the latest file, parses the XML, and gets a list of all modules and their type (AI, ALM, PID).
2.) I can then loop through the module list and generate a report of all alarm setpoints, all bypasses, all suppressed alarms, descriptions of interlocks, and write to a file with .xls extension so it loads in Excel.
3.) I altered standard faceplates; whenever someone bypasses, they must enter a reason, who approved, their initials, etc, that logs to a web file; unbypassing removes it, so they can also see a list of currently bypassed interlocks. This is not needed for this purpose, but may be of interest.
The problem with querying event chronicle is a download can over-ride the bypass state.
The main issue with VBA is it's a bit slow looping through all system modules. This method also dumps all the setpoints out, and so, completely documents the alarm setpoints for all module types, and whether they are enabled/disabled/suppressed.
If you're curious, the way I determine module types (AI, ALM, PID, etc), is by the faceplate name for the module, as read in the FHX file. This way the VBA knows which parameters to dump to the list file -- very simple.
This solution also allows chart builder to work with ANY module type, because it can properly identify the path, because it 'knows' from the data file, whether module is ALM, PID, AI, or some other special type.
I was wondering if there is a way in VBA, to directly get the module list from DeltaV, e.g. via ODBC, etc, rather than having to parse the FHX XML file using VBA. OR a function to get the faceplate name back when passed the module name.
In reply to Frank Seipel:
Just thought I would add my support to this issue. It would be really good for Emerson to provide an out-of-the-box solution to this. Over the years we have spent many engineering hours developing techniques to monitor bypasses and simulations.
I have often considered going down the custom alarm priority for bypasses as this can be quite easily (if a little time-consumingly) retro-fitted onto a lot of systems and reports can be easy produced.
I have resisted using the event chronicle method for a lot of the reasons given here, primarily that it does not allow a ‘live’ snapshot – errors in the recording (due to downloads, corrupt event chronicle etc) will lead to incorrect reports. Also, despite the belief that bypasses should not be long-term, how far back in history would you need to be sure of capturing all of them? This could be quite slow, especially on a large system.
Ultimately, the ideal solution should be realtime and not require any manual intervention to produce useful and correct reports. Unfortunately, whatever the solution ends up being it is likely that existing systems will always have to live with the legacy of how they were configured, and it is unlikely to be a painless move to use the new functionality - be nice to have the option though!
Our current technique for monitoring is much like some of the examples above:
- we have a script that produces a list of all modules and any bypass flags within them (based on a set of customisable rules, allowing us to filter out a lot of the ‘false’ bypasses mentioned in this thread and cope with the different types used)
- using the paths generated by the script, we scan the live points via OPC to find any active bypass/simulate flags
- our ultimate control is through a separate management system that operators use to log any bypasses used and the reason. However, this relies on the operator recording it manually
The MODT.SCR file located in DVDATA\DOWNLOAD is a running talley of modules. It is text and can be read using vba very easily. It actually contains the modules and some other heading information including faceplate/detail display.
Happy parsing.
So regarding productizing, I'm wondering how much that has already been done in DeltaV Analyze or the highly-anticipated Process Analytics packages could be leveraged for this purpose. I suspect there might be a nice fit there.
Thanks Youssef, I should have just used this file instead of the FHX. Also, one other thing I'd do differently is use the VBA database functions. In other words, detail faceplates would just write updates to an MDB file or SQL server when bypass checkboxes are clicked. THEN, every night, it would scan the modules and over-write the MDB or SQL table on a schedule by scanning all modules. That way, even if you did a download, the bypass list would be correct (at least within a day), and it would be simpler to query externally. One advantage to this method is only faceplates need updates, not modules. Ideally, a separate table for alarm setpoints, enable/suppress status, and interlock bypasses would be kept. The way I have it set up there isn't really ambiguity with simulate because, with the faceplate known, I know what function block parameter to poll for the report of whether the module is in simulate. Also, on a somewhat related note, is there an update/current version of the Access DB to convert an FHX to MDB? I couldn't get this to work for v11.3 & it is somewhat related to this thread.
In reply to Phil Webb:
Can you tell me what client application you are using to read the values via OPC?