5 Replies Latest reply on May 26, 2015 12:40 PM by pthivierge

    Dependency Tracker

    TimCarmichael

      Before I embark on a epic journey, I'd like to ask the community for help/guidance.

       

      Does anyone have a system for tracking tag dependencies? That can be PI-to-PI or source tags for PE tags.

      Today, an issue arose where a PI-to-PI tag was found to have a value of 'Scan Off'; the tag is sourced from another system where it is in turn sourced from yet another system via PI-to-PI.

      So, 'retiring' a tag on system 'C' resuts in a value of 'Scan Off' on system 'A'.

      Since there are many PI systems involved, simply doing a periodic scan is overly time consuming.

       

      I am considering writing a application that does the following:

           for each PI system

                connect to the module database

                get a list of interfaces

                for each PI to PI interface

                     find the source and destination systems

                     for each PI tag pair (source and destination tag)

                          check the current value and timestamp

                          if either tag is invalid

                               send an e-mail to the support group identifying the issue

                          if either tag is 'Scan Off'

                               send an e-mail to the support group identifying the issue

                          if both tags are valid

                               add a record to a DB identifying the source/destination system and tags

       

      Then, make a searchable interface to the DB to allow administrators to find tags that have upstream/downstream dependencies on a given tag.

       

      If you think this can be done using AF as the DB, please advsie with a possible template layout and a method to create/update elements.

        • Re: Dependency Tracker
          Eugene Lee

          Here are some thoughts about this. For the data access layer, you will probably want to use PI SDK if you want to access the MDB although this technology ison the way to deprecation. Also, do take note that interfaces that are not registered by the PI ICU are not stored in the MDB and hence will fall through your detection. Identifying destination tag will be easy since you can do this by the point source. However, identifying the source tag will be tricky since there is nothing in the point attributes that will link the source tag with the PItoPI interface instance. Therefore, you will probably need to have an algorithm that is similar to what the PItoPI interface uses for searching for source tags in the source PI Data Archive. As you know, there are a few ways to link the source tag with the destination tag such as by Tagname, Userint1 etc. Therefore, unless your company has standardized the linking using one method, you will have consider all the ways that they can be linked.

           

          Regarding dependencies between PE Tags, we do have an enhancement request and a workaround proposed. However, it is not programmatic.

          https://techsupport.osisoft.com/Troubleshooting/Enhancements/24859OSI8

          My thought would be to parse the PE expression to extract anything between single quotes and then searching for tags using this. (some searches might fail because time is also surrounded by single quotes but you can handle those exceptions)

          • Re: Dependency Tracker
            pthivierge

            Hi Tim,

             

            Scenario 1

            I have already seen such an application that was developed by a little team in a big Energy company in France.

             

            Their idea was to create a central database combined with a validation workflow.  All changes to the system must be submitted to the central database and the central database provides files to make modifications to all systems.

             

            Let's imagine a process engineer, Joe, that wants to delete few items in his Control System:

            • Joe uses the provided spreadsheet ( that is very formal) and fills the items that he wants to create/delete
            • Joe then goes on the Web Portal and pushes the spreadsheet
            • The engine analyses the "requests" and will report with possible conflicts
            • If no conflicts, Joe can then do his modifications by using the file generated by the engine.  If there is a conflict, Joe will need to adapt his request accordingly.
            • Since the engine is generating all modifications, it contains the current state of all system layers ( control systems, historians, quality control databases, etc... ).  The engine tracks reporting and formulas and can report the data flow for every value.
            • All systems are modified by the configuration provided by the engine. I.E. the engine would provide the PI Config Scripts to delete/create/modify PI Tags, a script to modify the DCS etc.

             

            --

            Scenario 2

            I have seen another application in an oil company where people created a search page for performance equations, and once you clicked on it you could see values of all its related tags. And drill down on dependent PE's.

            I think that doing the same "on-demand" logic may be possible in your situation.

             

            Your Scenario

            For the application you suggested I would think that you can omit to get the interface list, because with the points sources should have enough information already (if not this is easy to change).

            --

            List<Dictionary<string, PIPointList>> ServersTagList

             

            For each PI system

               Get a dictionary<TagName,list<pipoint>> of tags that correspond to all its PIToPI interfaces (to do that you could use the pointsources naming ex: pitopi*).  This dictionary is then added to the ServersTagList

               //i.e. var serverTags = new Dictionary<string, PIPointList>();

               // the PIPointList will contain at this point: 0 - the tag object itself

               // in the next steps, will be added other tags as we find them: i.e. 1 the source tag server A, 2 source tag server B, etc...

             

            For each item in ServersTagList

                 for each tag in dictionary

                      Check tag type (normally we already have only PItoPI Tags)

                           Get Source Tag Name from the tag configuration

                               use the TryGetValue method to get the tag from other dictionaries

                                     if you find the item, add the the Found tag () into the current tag PointList.

             

            Perform checks

             

            --

             

            One question:

            How many tags are concerned by this check?

             

            Hope this helps!

              • Re: Dependency Tracker
                TimCarmichael

                Patrice:

                 

                In a perfect world, scenario 1 would be ideal, however, since the system spans almost 100 PI servers and a few million tags total, that isn't going to happen.

                But, I asked for feedback before more eys can help find solutions.

                Whatever is decided, I will advise.

                  • Re: Dependency Tracker
                    pthivierge

                    Hello Tim,

                     

                    Please be aware that the logic I provided cannot scale to millions of tags, you'll need to split the problem in smaller chunks (you may be already aware of that, if not we can discuss it further).

                     

                    You can come back here at any time if you have more questions.

                     

                    Regards,