• Not Answered

How to make LSAVTR LSDVTR tags searchable in DeltaV Live?

Good day!

As you know, CSLS has limitation on creating maximum 16 SIS modules and only module names are searchable through DeltaV Live not Function Blocks.

In my case, Operation team is looking for a way to search SIS AI, DI, DO tags (function blocks or at least LSAVTR or LSDVTR) via HMI. Any solution?

Let us build success,

Zohaib Jahan

15 Replies

  • How do they want to use those? If it's just for something like easy trending, one solution is to create "shadow" modules in standard DeltaV modules that contain the tag names you want. For a given analog, you could use an AALM module with an external reference parameter looking at the LSAI.

    - Bryce H. Elliott, P.E.

  • , your statement is incorrect, any parameter within a DeltaV SIS Control Module can be directly assigned to any graphic in DeltaV Live.

    On top of that, Alarm Groups help creating objects within the DeltaV SIS Control Module, so you can customize Alarms, Alarm Help, Description, Primary Graphic, Face Plate call outs, trending, etc; for devices and SIFs within the Control Module.
  • In reply to Bryce Elliott:

    , Alarm Groups has replaced the need for the so called "Shadow modules"
  • In reply to Tadeu Batista:

    How does this work with multiple AIs? The faceplates in Operate use AI1 as the function block name, and I can only use that function block name once per module. We typically name the LSAI function blocks after their transmitters, with some modification to make the name unique from the I/O point itself. I can't find a way in Control Studio to point it at a specific block, and when I set up the faceplate and detail just now, it threw errors in Operate, which is what I expected.

    - Bryce H. Elliott, P.E.

  • In reply to Bryce Elliott:

    ,
    Alarm Groups is available from v14.LTS on.
    There's no limit of Alarm Groups per Control Module, you can have one Alarm Group per LSAI FB. Each Alarm Group will have its own TAG, description, Faceplate, Primary Graphic, etc, from the call out in DeltaV Live, you'll have to consider the Alarm Group TAG, not the Control Module tag.
  • Zohaib.  Just to be clear, the SIS Modules are not necessarily created as individual SIFs.  One SIS module can hold multiple SIF's.  You can build the system with each SIF in its own module, but you will be limited to 16 SIS modules in the CSLS. With Up to 48 Outputs you might have applications with more than 16 SIFs in a Logic solver, and that would be resolved with multiple SIFs per SIS Module.

    earlier versions of DeltaV SIS did not have the Alarm Group feature, and the solution was to build shadow modules in the SZ (or M-series) controller to abstract the LSAI and LSDI blocks to the DCS with a dedicated "module Tag" and associated alarms. So although the SIS Module data was available to the consoles and trends, everything was relative to the SIS module name.  The Shadow tags allowed each LSAI block to be treated as an independent AI Module.

    Alarm Groups were added, I think in v13, to provide this signal granularity and avoid the need for the Shadow Modules, as Tadeu explains.  Since a SIF can include multiple AI blocks, the Alarm Group may not necessarily represent the SIF.  It is intended to bring clarity to alarms and display the related AI to the operator.  

    The Alarm Groups will be searchable in the Live Search tool like all other modules.

    Bryce brings up a good point.  I've created an SIS Module with a single SIF with three LSAI blocks and associated Alarm blocks.  These must all be named uniquely in the SIS Module.  I then created three Alarm Groups each with an LSAI and an LSALM block assigned to the Alarm Group.    I have assigned the same FP and DT displays and have a display GEM for my LSAI blocks.  

    After Download, the OPC Watchit browser shows only the Alarm Group tags with no subordinate references or alarms:

    However, the Watchit utility and OPC Watchit both return a value for PI-101A/LSAI1/OUT.CV

    Live Search now finds there three Alarm Groups:

    But since my FP and DT displays are built around LSAI1 and LSALM1ALM, they only work with the PI-101A.  Also, the GEM for displaying an LSAI will only work with the PI-101A.

    I admit I've never used this feature before.  So I don't know what I am missing here. It may be that we need to create a number of items, such as an AI_LSAI1_FP, AI_LSAI3_FP and associated DT and GEMs that will work with various block names.  Not sure.  I guess for the GEM, we can specify the FB name, and add logic to adjust Alarm name information to create a flexible GEM that works with various blocks.  SImilarly, an FP could be made to read the suffix and adjust block name references to the appropriate block.  I don't know.  Or maybe there is an alias table for the Alarm Groups that I did not find.

    Anyone have any insight on this?  Or are we still using Shadow modules in the SZ controller so all the LSAI alarm Groups are abstracted to a common structure that uses one set of FP, DT and GEMs. (or Dynamos)?

    Andre Dicaire

  • In reply to Andre Dicaire:

    Andre Dicaire (ADicaire)

    If you create an Alarm Group, an namely differently from the LSFB you have in the Control Module, 

    Then you will have them as two separate entities within the Control Module, and is is how the OPC client will see them.

    But if the Alarm Group name matches the LSFB, in this case a Composite LSFB, or in the case of the request, it could be the case for a single LSAI:

    Then the OPC client will find all the objects inside the same entity.

    When an alarm is created within the Control Module, using a parameter from an FB associated to an Alarm Group, the alarm will be automatically associated to the Alarm Group, if there's no association, the Alarm Group column stays blank, and that particular alarm will be associated with the Control Module.

    One thing that is not clear to me, is why the suggestion for using the LSALM FB?

  • In reply to Tadeu Batista:

    Tadeu,  Thanks for the response.  The OPC item was a lost leader.  It was an observation that naming the Alarm Group a unique tag does not result in a browsable path, but as I indicated, the Tag and contained blocks do work if you enter the path explicitly.

    I see that in your AG configuration dialog, there are Block/Param assignments.   So I created an Embedded block and added the LSAI1 block to this embedded block.  I named this embedded block PI-101A and defined an Alarm Group by the same name:

    Now I have a browsable path to three separate LDAI1 blocks that fit the expected references in my FP, DT, and GEM designs, which all reference LSAI1.  

    There are two key design requirements here for the Alarm Group to replace the Shadow module behavior:

    1. The LSAI or LSDI block must be contained within an Embedded/Composite block so that the FB names can be consistent with the Display objects.
    2. The Alarm Group must be named the same as the Embedded/Composite block, creating the new Tag/FB path in the DeltaV Name space.  If the Alarm group above was called BOB, then the valid path to my Embedded block would be BOB/PI-101A/LSDAI1.  

    WIth the LSAI1 inside the Embdded block called PI-101A, and the Alarm Group also named PI-101A, there are two valid paths to the LSAI1 parameters:

    AG_TEST/PI-101A/LSAI1/PV.CV  (SIS Module path to the Embedded Block called PI-101A)

    PI-101A/LSAI1/PV.CV ( Alarm Group Path, but only because Alarm Group has same name as Embedded Block)

    There is still one issue though.  If I have three Alarm Groups for three pressure signals, and I want to create three Low Pressure alarms, these cannot have the same Alarm Name in the SIS module.  I added the LS1ALM block to the PI-101A Embedded Block and Assigned the Alarm in the SIS module.  I also have to Assign the LSALM block to the Alarm Group to have the alarm linked to that group.  If I had created an boolean alarm parameter in the embedded block, and linked an alarm to that, it would have automatically been part of the Alarm Group of the Block. 

    So if we add alarms, they must still be uniquely named at the SIS module level.  They can be assigned to the Alarm Group by making sure their Parameter field links to a block that is explicitly assigned to the Alarm Group.   But since the Alarm names must be unique per module, this will break typical Detail Display alarm references, but the FP alarm summary will work fine.  GEM's could have Custom Alarm Names to allow the GEM to link to the right Alarm.

    Does that sum it up correctly.  I could not find these details in BOL.  If it is documented, could some one please point the rest of us in the right direction.

    As for why I had the LSALM block, i wanted to add a low alarm and the LSAI does not have alarm assignments.  Using the LSALM allows a Limit Parameter to be associated with the Alarm as a field, which makes the limit accessible through the Alarm Path.  It is also available via the LSALM block path. I had the LSAI and LSALM at the root level of the SIS module not knowing they must be in a composite or embedded block to create the familiar Tag/FB/PV.CV path structure.

    Andre Dicaire

  • In reply to Bryce Elliott:

    Two reasons:
    1- easy access to tends like for DCS control modules
    2- searching analog voter blocks with trip Setpoints, bypass status

    Let us build success,

    Zohaib Jahan

  • In reply to Tadeu Batista:

    How to connect alarm groups with LSAVTR Faceplates?

    Let us build success,

    Zohaib Jahan

  • In reply to Tadeu Batista:

    As I started directly from latest v14.3.1 so don't know about shadow modules but I'm surprised to know about Alarm Group. Emerson training (7305, 7409) didn't include these things.

    Anyways, thanks for introducing it. I'll definitely look into it.

    Let us build success,

    Zohaib Jahan

  • In reply to Andre Dicaire:

    Tadeu and Andre:
    I appreciate if you can briefly tell how to create the Alarm Groups as I didn't see this block in DeltaV 14.3.1

    Let us build success,

    Zohaib Jahan

  • In reply to Zohaib Jahan:

    It's not a block. If you have an SIS module open in Control Studio, one of the buttons on the top menu will say something like, "Alarm Groups Configuration." I haven't been able to use these in Live, just Operate, so I'm not sure how well Live uses the faceplates and details when those are assigned.

    - Bryce H. Elliott, P.E.

  • In reply to Bryce Elliott:

    Zohaib, My previous posts should give you mostly what you need. The challenge is to create an Alarm group that behaves and works with existing display constructs, such as FP, DT and GEMs. What I found is that you need to structure your SIS Module into embedded/Composite blocks. I'd recommend refining the design into composite blocks so that you can implement consistent designs.

    Your FP, DT and GEMs will be based on SIS blocks located in an SIS Module. For instance, if you have an LSAVTR based FP,, this FP Works with an SIS Module that contains LSAVTR1 block. The module will have other blocks, but this FP is looking for SISMOD_NAME/LSAVTR1/.... paths. It also looks for the SISMOD_NAME/DESCR.CV and other module level parameters as well as the module alarms.

    An Alarm Group is a named object that has assigned blocks, such that you can reference the assigned block references using the Alarm Group Name instead of the SIS Module name. That is easy. Create an Alarm Group from the Menu option "Alarm Groups", name it, give it a description, assign the FP and DT file names and assign blocks to the group. Any alarms built based on the assigned blocks will also report with the Alarm Block, rather than the SIS module.

    Done right? No. Maybe. Your FP, DT and GEMS are designed with specific block names. So if the SIS module has two LSAVTR, only one of them can have LSAVTR1. So if you create a group called PI-101A, and assign LSAVTR1, the FP will work, but if you have PI-101B with LSAVTR2 assigned, the FP will not find PI-101B/LSAVTR1/ and links will be invalid. Alarms will be assigned to the Alarm Groups based on block assignments.

    What I found above is that if you encapsulate the Alarm Group related block in an Embedded block, you can name this block with the Alarm Group name (or vice versa). In this block you can have one LSAVTR1 block defined, along with any other appropriate logic. You can now create multiple Embedded blocks and each has exactly one LSAVTR1 named block. Now your FP, DT and GEMS will all work with the Alarm Group Tag because all these tags will have the LSAVTR1 block name.

    Create an Embedded Block called PI-101A (or whatever name you want).
    Place your LS Block and other logic in this Embedded block and name it to the FP block name. i.e. LSAVTR1.
    Create your alarms in the SIS module to reference the alarm trigger from this Block.
    Create your Alarm Group and name it the same as the embedded block , i.e. PI-101A.
    In the Alarm Group, assign the Embedded Block by the same name and define the FP, DT display names, as well as the Process display for direct alarm access, same as you would for a module.

    Once you have refined and defined this Embedded block to provide you with all the desired functionality for the alarm group, convert this to a Composite so you can use it over and over, and manage these instances from the composite template in the library and ensure consistent design in your system.

    This allows you to create multiple alarm groups in an SIS module based on the same LS FB type.

    Because you are using a defined FP, i.e LSAVTR_FP, this faceplate has a similarly named Trend file called LSAVTR_FP.PHVE that works with LSAVTR1 blocks.

    Since an SIS module can host multiple SIF's, it is possible to have multiple LSAVTR blocks related to different SIF's. To use Alarm Groups on each of these, I have concluded you do need to build a block if you are to use Alarm Groups across your system without building custom FP, DT and GEMs to align with FB names, when there are more than one block in an SIS module.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Thanks, Andre! I'm going to try this.

    - Bryce H. Elliott, P.E.