AVEVA™ PI System™ Feedback Portal

Welcome to our new feedback site!


We created this site to hear your enhancement ideas, suggestions and feedback about AVEVA products and services. All of the feedback you share here is monitored and reviewed by the AVEVA product managers.

To start, take a look at the ideas in the list below and VOTE for your favorite ideas submitted by other users. POST your own idea if it hasn’t been suggested yet. Include COMMENTS and share relevant business case details that will help our product team get more information on the suggestion. Please note that your ideas and comments are visible to all other users.


This page is for feedback specifically for AVEVA PI System. For links to our other feedback portals, please see the tab RESOURCES below.

Add a new idea Subscribe
Status No Status
Product AVEVA™ PI Server
Categories Asset Framework (AF)
Created by Guest
Created on Aug 19, 2022

RELATED IDEAS

Allow modification of System Enumeration Type

Although it is not advisable to modify the "System" digital state on a PI Server it is permissable as per the documentation on a "Minimal" basis. In AF the matching "System" Enumeration set is "hard coded" and allows no modification at all. This provides not only an inconsistancy in approach from OSIsoft, but also an Inconsistancy in values received from AF and from PI when the "System" digital state has been modified. These inconsistancies leed to people questioning the validity of the data and the products being used to display it. The "System" enumeration should be held in the AFEnumeraiton tables in the PFID database rather than hardcoded.
  • Attach files
  • Guest
    Reply
    |     Aug 19, 2022
    Can you provide some examples of what changes you may have made to the System Digital State Set? Can you also provide the rationale behind changing these System Digital State Set? What problems were you trying to solve by doing do?
  • Guest
    Reply
    |     Aug 19, 2022
    Take for example writing a digital state to an analogue, some older interfaces we have write a digital state of error when data is faulty. You can't add another digital state set to an analogue so it has to be system and an additional state is added or and existing one is modified.   At the end of the day you allow modifications to system on the PI server, it is in your documentation, so why would you not allow AF to match?   Can you explain the rationale in the inconsistencies between products in the OSIsoft product line up? Why allow it in PI but not in AF even if it is not actively encouraged, you should allow the user to be able to display the same value on both applications.
  • Guest
    Reply
    |     Aug 19, 2022
    In response to Matt Inglis, "Take for example writing a digital state..." One of the reasons why we currently don't allow editing the AF System State Set is because within a single AF database, you can have PI Point Data References to multiple PI Data Archives.  If you can imagine Attribute1 -> \\PIServer1\sinusoid and Attribute2 -> \\PIServer2\sinusoid.  Thus within AF we would need to handle multiple Digital State Sets with potentially the same name.  This causes a lot of complexity.   Having said that, I understand the issue you're experiencing and will keep it in mind for possible future enhancement.
  • Rick_Davin_3.0
    Reply
    |     Aug 19, 2022
    My company needs something like this as well. We have custom SYSTEM state code 2 with text of "No Limit". When an engineer is reviewing limits, its far friendlier to see "No Limit" rather than "Bad Input", "Calc Failed", or "Invalid Float", none of which have meaningful context to the engineer and actually tend to raise anxiety. But let them see a "No Limit" and they remain calm.