6 Replies Latest reply on Jul 1, 2015 4:56 PM by kdoyle01

    Dynamically creating Element Attributes from Template Table Lookup DRs

    kdoyle01

      I am creating an AF structure for electrical Substations and their corresponding Feeders.  Ultimately, I need to be able to reference PI Tags associated with the Feeders.  Each Substation has one or more Feeders.

       

      In the Element Template I am using for Substations, I would like to reference the Feeders' names as Attributes of the Substation Elements.  But, because the quantity of Feeders varies from one Substation to the next, I'm not sure how to do so.  Does AF provide a mechanism within Templates for referencing/cycling through multiple values (that are returned from Lookup Table DRs) and creating an Attribute for each value using a 'For Each' like process?  I.E., as a varying number of child Attributes (Feeder Names) under a 'Feeders'  parent Attribute (similar to 'Objects' in a 'Collection' relationship).

       

      I am already using Table Lookup DRs to populate the Substation Elements' Attributes for static (pre-known) quantities of meta-data and PI tag names.  I'd like to simlarly use Lookup Table DRs to dynamically create the attributes for each sub's (1 or more) Feeder Names and their associated set of PI tags.

       

      Use of the PIPoint Array DR may somehow be applicable here.  But, I am unaware of how to dynamically create the child attributes from wihtin a Template.

       

      Is this possible?

       

      Here's a rough hierarchical layout example of the structure to which I am refering:

       

      SUBSTATION A

           FEEDER 1

                PI TagName i

                PI TagName ii

                PI TagName iii

           FEEDER 2

                PI TagName i

                PI TagName ii

                PI TagName iii

       

      SUBSTATION B

           FEEDER 1

                PI TagName i

                PI TagName ii

                PI TagName iii

       

      SUBSTATION C

           FEEDER 1

                PI TagName i

                PI TagName ii

                PI TagName iii

           FEEDER 2

                PI TagName i

                PI TagName ii

                PI TagName iii

           FEEDER 3

                PI TagName i

                PI TagName ii

                PI TagName iii

        • Re: Dynamically creating Element Attributes from Template Table Lookup DRs
          skwan

          I'm not aware of a way of doing this without programming.  Are you open to developing your own app?

           

          Perhaps some clever user like Rhys Kirk or Roger Palmen or Rick Davin know of a way

           

          --

          Steve Kwan

          • Re: Dynamically creating Element Attributes from Template Table Lookup DRs
            Rhys Kirk

            I might not be following what you want 100% but it sounds to me like you are trying to denormalise your structure into the single substation Element Template.

             

            Regardless, there may be a workaround in AF 2.7 onwards that doesn't need code...

            If your Feeder template was updated to include a "Name" attribute which was using the StringBuilder with a config of %Element% then you could do something like the following:

            • Create a "Feeders" Attribute in your Substation and below that add a number of child AF Attributes (the maximum you would typically expect for a substation).

             

            • Each one of those child Attributes is named with an index number, e.g. Feeder1, using the StringBuilder again but with the config '.\Elements[@Template=FeederTemplate][1]|Name' where the index number [1] is replaced with [2] etc for however many Feeders you pre-create.

             

            • Create instances of the Element Template, then run a one-time activity (could be a script) to "Hide" those AF Attributes that don't resolve (hide = check the Excluded property when instantiated).

             

            • You would need to repeat the process for each piece of data you want lifting from a feeder to the Substation.

             

            Apart from that you would have to use some code. I've wondered about having a Dynamic Data Reference that will check if its host Element is "dirty", if so then run some code to dynamically add/remove AF Attributes below based on its config (similar to what you describe). With this approach your Element Template will hold the rules but when being created the Data Reference executes the rules.

              • Re: Dynamically creating Element Attributes from Template Table Lookup DRs
                kdoyle01

                Thanks Rhys.  I think you (and Stephen and Roger) have confirmed my suspicions as to what I can and cannot do, vis-a-vis, unknown quantities of child elements and attributes for templates.

                My intent is to 'black box' the process of creating new Substation Elements; to simplify creation of new Substation Elements by AF Admins as much as practical.  Especially when there are a significant number of substations to add, each of which would have large and varying numbers of Feeders.

                 

                When time allows, I may pursue creating an app that would do this (as Stephen mentioned).  Of course, Roger's thoughts on using Excel/AF Builder to manipulate the structure may be suitable for 'packaging' into a list of tasks when the PI AF Admin needs to add new substation Elements.

                 

                Thanks you!

              • Re: Dynamically creating Element Attributes from Template Table Lookup DRs
                Roger Palmen

                I think the best solution mainly depends on the process to create and maintain your asset model. In most cases, power users are able enough to build some logic in Excel to create the desired AF structure. Using the AFbuilder the AFModel is then created and/or updated quite easily.

                The advantage of this is that power users can create and maintain the AFmodel with some limited knowledge of PI AF and PI Builder. Typically no programming (read: AFSDK) required.

                 

                To date i have not found a way to use the PI Point Arrays (open to suggestions though)

                 

                Hope this helps!