AVEVA Product Feedback


Add a new idea Subscribe
Status Completed
Categories Asset Framework (AF)
Created by Guest
Created on Aug 19, 2022

RELATED IDEAS

Create or Update PI Points and Reset to Template

Using PI System Explorer, it is possible to "Create or Update PI Points" in bulk across all elements or branches of elements. However, "Create or Update PI Points" resolves the substitution parameters of PI Point attributes. As a result, if you change the value of a substitution parameter that is used in the PI Point configuration, say %Description% and perform "Create or Update PI Points", the point does not update with the new value. You have to take an extra step and first reset all the PI Point attributes you want to change to the template using PI Builder. It would be good if there was an option with the bulk "Create or Update PI Points" to "Reset to Template" first.
  • ADMIN RESPONSE
    Aug 19, 2022
    This has been answered, please see previous comment. In addition, there is a separate idea to implement an indicator in PI System Explorer when an attribute doesn't match the template. Please provide your input and use case if this is applicable to you. https://feedback.osisoft.com/forums/555148/suggestions/19948495
  • Attach files
  • Guest
    Reply
    |     Aug 19, 2022
    Hi, first I wanted to let you know that you can also reset to template in PI System Explorer. Secondly, while I understand why you're asking for this feature, we must take other use cases into consideration such as the user having edited the configuration string manually. For example, you can create an element from template, then override the configuration string of a PI Point Data Reference attribute to something specific, such as a PI Point that does not adhere to the naming substitution. Now imagine you desired to make a change and update the PI Point. If we automatically reset it back to template, you would lose your previous manual configuration change to that PI Point which didn't adhere to the naming substitution.
  • Guest
    Reply
    |     Aug 19, 2022
    This behavior of resolving substitution parameters causes significant challenges when trying to deploy/migrate AF across Dev, Test, Prod servers. It essentially renders templates and substitution syntax useless if you're trying to follow a proper SDLC and keep the AF 100% in sync between Dev, Test, and Prod. It's especially dangerous when done innocently/unintentionally, which is easy for newer developers to do. And the only way to know it's happened for sure is to manually parse the exported XML. At the very least, there should be some kind of warning that clicking "Create or Update Data Reference/PI Point" will hard-code the PI Point. Additionally, there should be some kind of visual indication in System Explorer that an attribute is no longer using the template/substitution syntax. However, the real solution would be to simply leave the PI Point syntax parameterized. I see no reason to break templates and substitution syntax when "Create or Update Data Reference/PI Point" is clicked.
  • Guest
    Reply
    |     Aug 19, 2022
    The implementation of client side Known Server Table in the PI System makes it undesirable to leave the PI Point syntax parameterized. Since the Known Server Table (KST) is a client side setting, %Server% may evaluate differently per user depending on their default server setting. As you can imagine, this can lead to very confusing results. Fortunately, we implemented the ability to designate a default server per PI System and/or AF Database beginning with the AF 2018 release which mitigates this issue. In addition, when you "Create or Update Data Reference", we verify the server ID and point ID and store both in the underlying attribute configstring. This level of details is not shown in the PI System Explorer UI to improve readability for the enduser. However, if you were to "shift-click" the Settings button for an attribute, you would see all the details for that particular configuration. YOu would note it's different after you "Create or Update Data Reference". This is done to handle use cases where a user may delete a PI Point in the Data Archive and then subsequently recreate it to store the same data stream (same PI Point name, but now different ID). Users may also rename the PI Point (different PI Point name, but same ID). By instantiating the configstring via "Create or Update Data Reference", we avoid confusion and complication. Having said that, we have had many requests to improve the migration of PI System between Dev, Test, Stage and Prod. This particular request is considered to be part of that use case.