Dear all,
At "Exchange" this year Kim Van Camp showed us the "System Alarm Management" application in DeltaV Explorer, which I hadn't utilized before. When I got home I tried it on our system, and I'm confused by what I'm seeing. For many modules, I can see all the alarms and setpoints for those alarms. But for some modules I don't see any setpoints. It's the same as I see in "Control Studio" but it seems just as random. There are alarm limits configured for the parameters in question, but they are invisible in "System Alarm Management" and also in Control Studio.
Has anyone seen this before? Any suggestions regarding what I might do to make these visible in both applications? (I have tried uploading the modules - doesn't change anything). For what it's worth, these modules were developed in version 3 or 4, and migrated through successive revisions to what is now version 11.3.1.
Assuming it could be refreshed with the actual alarm settings, this database would be useful to export - but I don't see any options for "export as CSV", for example. Is anyone exporting this data from DeltaV in this format?
Here are some screen captures:
Here is a thread describing 'exporting' from the SAM.
http://community.emerson.com/process/emerson-exchange/operateandmanage/deltav/f/50/p/4078/8757#8757
You basically print to xml.
In reply to Youssef.El-Bahtimy:
In reply to Kim Van Camp:
Best Regards,
Rachelle McWright: Business Development Manager, Dynamic Simulation: U.S. Gulf Coast
Kim - I get the "empty" limits for parameters like ALM1/LO_LO_ACT . . .
The phenomenon is consistent - the "Alarm Properties" dialog is grayed out, and the alarm list (table) in control studio is blank.
The parameter "ALM1/LOLO_LIM" has a number in it, though. We have modules referencing the AI block alarms that behave the same way.
In reply to John Rezabek:
Yousseff - allow me to check my understanding. So, it's like the database recognizes the connection to a "standard" function block when one uses the "assign alarm" from a function block context menu, but when I point to the very same parameter in the very same function block using "add alarm" from the "Alarm View" table, the database assumes it's just another random user-created custom parameter, like we all might be renaming calc blocks "AI1" or "ALM1" and naming custom parameters "LO_LO_ACT", etc.
I think I might have some user input for the UDEP. This phenomenon is widespread in our system and has likely been there for 15 years, as systems engineers were blithely unaware of this (undocumented?) "feature". Seems to me the database should be smart enough to see the alarm limits regardless of how an alarm was configured, no?
John,
I wouldn't say the difference is undocumented. The following two articles from version 7.3 (circa 2004) describe configuration of standard alarms vs. custom alarms
http://www3.emersonprocess.com/systems/support/bol73/Theory/html/alarm_configuration.htm
http://www3.emersonprocess.com/systems/support/bol73/Theory/html/custom_alarms.htm
Configuring a standard alarm involves more than pointing to a parameter path; it is invoked in the context of a function block, regardless of its name, and thus has assurances that the parameter association is definite and immutable.
The scenario I describe regarding a misinterpretation of the limits associated with a alarm parameter due to block/composite rename may not seem likely, but I would hesitate to have the system misrepresent the alarm limit in SAM based on the text name of the parameter supplied to the custom alarm configuration routine, which is why it does not attempt to do so.
I would say the UDEP feature you describe would be a 'Convert to Standard Alarm' option or even a dialog when creating custom alarms that says 'A Standard Alarm parameter has been identified. Do you wish to create a standard alarm instead?', either case requiring further input.
It is unfortunate that the subtle differences between the standard and custom alarm configuration was overlooked in the configuration legacy you describe, and that alarm rationalization using a spreadsheet of unidentified limits will be significantly more difficult.
Perhaps for the alarm detection blocks you have configured as custom alarms, a bulk export based on you site standards (e.g. for all modules bulk export the ALM1/HI_LIM, ALM1/LO_LIM, etc., then filter out rows that return no values because they have no ALM1 blocks) would help fill in the gaps.