I am in the process of rolling out PlantWeb Alerts in an integrated DeltaV-AMS environment. We are currently monitoring over 4000 devices. I am looking for other users to share experiences and best practices for managing the device configurations, DeltaV Alert configurations and the alerts themselves. I have a lot of things to share and a lot left to learn.
Jay I have a lot of experience with this. I was on the Whiting, Indiana project. My personal email is tat8r@aol.com. I have a document that BP used for configuring alerts and such I would be happy to discuss some of the things we did on site there. Thanks, Tater
I've got experience setting up alerts and templates for a large two zone greenfield system, and I'm also currently dealing with managing alerts in a migration from Provox I/O (with DeltaV controllers) to CHARMs. I'd be interested in sharing and learning.
In reply to Tom Grusendorf:
I will start with one of the things that I see as a problem going forward. How do we effectively manage the alert conditions and priorities that are associated with each device?
We found out very quickly that the default Alarm Condition values were developed by someone that had never been in a real plant. We have developed our own Device Templates in the DeltaV library for each device type and revision. At the I/O channel or CHARM level, we use the "Copy Library Data" option to load our standard template. However, once that is done, it seems there is no way to propagate changes to the Device Template down to the channels that used that template. There is not even a good way to keep track of which templates were used on each device. There is also no way to know whether or not any changes have been made at the channel level that makes that device different than the standard Device Template.
If I decide to change the standard Device Template for a particular device type and revision, I have to
I have about 1200 Rosemount 3151 Rev 7 transmitters. If I decide to change that template, I have to find, change and download 1200 I/O channels!
We decided to use the Type and Sub-Type fields in the Naming Reference area on the General tab of the Device Properties dialog. In the Device Template, we put the name of the template in the "Type" field and the last date the template was modified in the "Sub Type" field. These values get written to the individual Device Properties when the library data is copied. We have developed some bulk exports that include these fields. From the bulk export data, we can identify which templates were used on which channels.
Comments? Suggestions? Any better ideas?
In reply to Jay Colclazier:
Jay,
We've experienced the same thing trying to manage device templates. We had set up some initial device templates and applied them to a few hundred transmitters, but soon realized that changes were required to the template which necessitated re-applying the template to every channel and downloading. I like your idea of putting the last modified date in the sub type field. Another problem we ran into was that copying the library data to a transmitter would overwrite the hardware alarm priorities from the template, so if we had manually adjusted the priority of some transmitters, we had to be sure to note it and set it back after applying the template. I don't have any better ideas than what you've already come up with.
We've also spent some time dealing with alarm conditions which cause duplicated alarms. For example 'Analog Output Saturated' which generates both a device alert and a PV_BAD alarm because it sets the signal status to BAD (the DeltaV HART Capabilities whitepaper says this should set the status to Uncertain, but this doesn't appear to be the case).
How have you dealt with alarm rationalization for device alerts? The easiest approach seems to be to rationalize the PV_BAD alarm and send it to the operator station (under the assumption that any condition that actually affects the PV would trigger a PV_BAD alarm), but not rationalize the device alerts and just set them to a priority which only appears on the maintenance station.