Skip to Main Content
AVEVA™ PI System™ Feedback Portal

Welcome to our 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.

Status No status
Created by Guest
Created on Aug 20, 2022

Safeguard against multiple analyses writing to the same PI Point

Safeguard against multiple analyses writing to the same PI Point. Currently it is possible to configure more than one analysis to write to the same PI point. This is a problem since it often goes undetected until someone looks at the data and sees unpredictable results. The road to finding which analyses is usually long and tedious. In my opinion, one improvement would be to either: 1. Safeguard so that it is impossible to configure the system so that more than one analysis cannot write to the same PI Point or 2. develop a mechanism which warns about this configuration (if OSIsoft deems this behavior valid and an acceptable use case)
  • Attach files
  • Guest
    Reply
    |
    Aug 20, 2022
    Unfortunately this is quite difficult to do. The Data Archive doesn't keep track of the exact application that is writing to a PI Point. As such, you can create two applications that write to the same PI Point currently. To complicate matter, the same service (PI Analysis Service) is writing to all the output PI Points from all the analyses so the Data Archive certainly cannot differentiate one from the other. Any prevention of these configuration errors would need to be done elsewhere.