• Not Answered

"Alarm Management" application in DeltaV Explorer doesn't show alarm limits for all modules - why?

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:

 

9 Replies

  • 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:

    The difference has to do with how the alarm assignment was created. When you use the 'Assign Alarm' function in the function block context menu in control studio, it gives you a dialog to configure the function block based parameters related to the alarm that you have chosen to configure, and shows you what the values are for the limits. If you just use the 'Add' function in the context menu of the alarm palette, the binding to the appropriate alarm limit parameters still exists, it is just not presented.
    The moral is, use the assign alarm function for all standard type alarms and the add function for non-standard types.
  • In reply to Youssef.El-Bahtimy:

    So . . . once such a module exists - with alarms created by "Add Alarm" from the alarm list - is there any way to restore them so the LIM setting can be collected by SAM?
    What if the modules are created by "copies" (start from existing) or from a library module template? Do the parents pass on this defect to their children?
  • John,
     
    The System Alarm Management application, SAM for short, has a print to xml file option that allows you to easily extract information about every alarm for a selected node, area, unit or module.  It’s one directional however; SAM has no ability to read an XM file of the same format.  To remedy this, a new V13 bulk edit template is coming that provides true bi-directional alarm importing and exporting.
     
     
     
    There are a number of standard analog alarms (LO_ALM, LO_LO_ALM, HI_ALM, HI_HI_ALM, DV_HI_ALM, DV_LO_ALM) that are supported within certain function blocks such as the AI, PID and ALM module.  These standard alarms are the ones you see limits for in SAM.   The remaining so called custom alarms are a different matter.  In a function block you are free to perform any calculations you wish to determine an alarm’s active condition and wire it up as the input to an alarm with any name you wish.  You can identify the alarm’s active state determination parameter in SAM or in the alarm’s property dialog as shown below.  For custom alarms, SAM is unable to trace back through the logic of the control module to find the various analog limits that may have been considered in the calculation of the active state. Thus the limit is blank in SAM and likewise grayed out in a custom alarm’s properties dialog.  Custom alarms are very powerful and flexible, but come at the price of not being able to populate their limits, on/off delays and hysteresis from a simple tabular presentation such as SAM.
     
    This alarm FAIL_ALM is based on an input condition DC1/FAIL_ACTIVE.
     
    Regards,
    Kim
       
     
  • In reply to Kim Van Camp:

    Looks like we have both an interim solution from and longer-term application improvement that is in the works by @Kim Van Vamp. Wow, combine that with the expertise and enthusiasm of and the last 50 minutes has been pretty darn exciting!

    Best Regards,

    Rachelle McWright: Business Development Manager, Dynamic Simulation: U.S. Gulf Coast

  • In reply to Kim Van Camp:

    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:

    John, what you are seeing is based on the method used to create the alarm. For the ALM function blocks, the alarm was created as a non-standard alarm. For the others, the Assignment feature was used. If you were to click on the ALM and use Assign Alarm, the mapping to the limit parameter would be displayed.

    Exporting the module, you'll probably see LIMATTR="" when not defined as a standard alarm and LIMATTR="ALM1/LO_LO_LIM" if it was.

    As Kim said, if you don't tell control studio and SAM up front that it is a standard alarm, it won't assume that the alarm you've created is configured in a standard way. You could have an alarm tied to a custom composite parameter called ALM1/LO_LO_ACT, but control studio and SAM can't assume ALM1/LO_LO_LIM exists or is in fact the LO_LO_LIM.

    How to correct it? The configuration of the alarm itself needs to be changed. Surely, instances of a class or template will inherit the configuration when created or changed (in the case of classes). I'm not sure you can bulk edit your way through it in the case of template instances. Ultimately, a configuration change that will require downloads is needed.
  • In reply to Youssef.El-Bahtimy:

    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?

  • In reply to John Rezabek:

    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.