4 Replies Latest reply on Sep 20, 2017 6:02 PM by JJFors

    In AF, How to track the movement of an Asset over time?

    rpashula2

      I have built a "Electrical Transmission" AF Model hierarchy.

      One Element is a Transformer with Attributes pertaining to the physical geographical location of the transformer.

      The issue is that the actual transformer Asset can be retired or moved and replaced with another transformer Asset.

      We need to retrieve the time series recorded characteristics of the Asset as it moves from one location to another.

       

      For example, we track the quality of the oil within the transformer but then the transformer is moved to another location and replaced with another transformer. The oil quality Attribute history of the Transformer Element now contains information on the old asset chronologically mixed with information on the new asset. Doing a long term analysis of the Transformer's oil quality at that location would no longer make sense.

       

      Has anyone had to track the movement of an asset?

        • Re: In AF, How to track the movement of an Asset over time?
          sraposo

          Hi Raymond,

           

          I believe using versions in AF could suit your needs. This is explained under "Version Management for Equipment and Processes" in the PI System Explorer user guide:

           

          https://techsupport.osisoft.com/Downloads/File/44dba67d-6396-45fe-b6cd-29225f96b4c5

           

          Hope this helps,

          Seb

            • Re: In AF, How to track the movement of an Asset over time?
              John Messinger

              The only real problem with this is that versioning history is largely inaccessible except in the PSE GUI. Client applications can't make use of this version information to frame time series queries (only use data between effective start and end dates). It's not accessible in AF Analytics either. Depending on the nature of your analyses, you may want to consider an approach such as calculating a flag to determine if the asset is current, and the using that flag to determine whether to use data for the asset in an analysis.

               

              I am currently working with a customer tracking similar asset movements - transformers are commissioned and eventually replaced, and when we perform most long term analyses we need to determine if the equipment was in use at the time. Element versioning was of no help, we ended up using the approach I just described:

               

               

              It's not going to be perfect for every use case, but it met our requirements better than versioning could.

               

              John

              2 of 2 people found this helpful
            • Re: In AF, How to track the movement of an Asset over time?
              JJFors

              Hi Raymond, 
              My approach would  be to keep multiple AF-Trees and use references as the way of changing a XFR location.

              I'm starting with a presumption that the model your working on is a topology model for feeding a state estimator or similiar network analysis, maybe even a CIM model.  Where an element in the model is really a node in the circuit where the transformer is positioned. 

              An alternate tree in your AF would be a collection of transformer elements maybe even segmented by voltage class  and named by a key of your choice (serial number?).  In this tree would live all your active or surplus XFRs.  The Element attributes would be the name plate ratings and tags references for oil samples.  This collection would be your inventory of transformers.

               

              Now here's method to make these XFR attribute values available in other places of the model.  Make a child under each transformer element with a "Statically" named element like "XFR".  The child element  will have attributes which make reference to the Parent attributes to get the values.

              Back in the Network Model where you have a XFR Node element with transformer property requirements make a  weak child reference to the "Statically" named element.  The XFR Node attributes would then access child attributes using the "XFR.Attribute" notation.

              Changing the model location of a transformer is now changing the child reference of XFR Node element.

              Back in the Network Model where you have a XFR Node element with transformer property requirements make a  weak child reference to the "Statically" named element.  The XFR Node attributes would then access child attributes using the "XFR.Attribute" notation.

              Changing the model location of a transformer is now changing the child reference of XFR Node element.

              1 of 1 people found this helpful