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.
History: Our team has spent months with David Black from AVEVA 2 years ago trying to understand why our Analysis Service was constantly failing. We had spent considerable time with various Engineers on our Team rewriting Analyses to make them less impactful. While this was useful in having more efficient Analyses, we did all we reasonably could at the time, yet, our Analysis Service continued to stop working sporadically.
Again, this last year, we spent considerable time working with AVEVA tech support to understand the issue. Only after some extensive troubleshooting was it made aware to us that this was a known bug with the Analysis Service.
Due to how temperamental the Analysis Service function can be, we have had to implement numerous human behavior controls including Extensive monitoring of the analysis service, manually monitoring the Analysis service when making any changes to our Asset Framework, depending on the scope of the changes we are forced to be ready to restart the Analysis service when changes are made and sometimes have to restart the service.
We have dependencies on the Analysis service now which creates value for our company in monitoring equipment, and our end users have come to depend on this, so having an Analysis Service that is this temperamental to changes in Asset Framework causes continuing and ongoing issues for us in how we use Asset Framework.
Large permission changes in Asset Framework also impacts the Analysis Service. We are hesitant to make changes to any identities and mappings we have in AF as if those permissions impact to much of the Hierarchy, it will cause our Analysis service to fail.
We spent time trying to split our Analysis service off to its own server to try to help with this issue out of desperation in trying to make it better.
This is a bug that has a very consequential impact on how we function in our use of Asset Framework and the use of Analyses.
Our overarching goal is development velocity, which is reducing the time, effort and risk in releasing changes into production.
We are running version 2.10.5.9075 and currently have approximately 410,000 analysis with over 150,000,000 events cached, running under a single instance of PI Analysis Processor. This also includes 35,000 notifications based on 55,000 event frames.
This is a highly optimized environment with zero analysis in error, 99.2% of analysis running at Rank 0, and only 0.005% not running on a periodic schedule. All of our elements are created through templates, with each template having anywhere from 50 to 50,000 elements associated. Additionally, our Element hierarchy is 10-12 layers deep and is very strict with analysis at each layer dependent on children elements’ attributes and analysis outputs.
The majority of our template check-in’s, which are performed as part of the development of the environment, causes PI Analysis Processor to clear the entirety of the cache and stop processing new events for over an hour. We find that even after events have started to process again that there are often a number of analysis that are perpetually starting of which cannot be stopped/restarted, or analysis shown to be running with periodically evaluation however nothing being written to PI Points.
Since waiting out for the cache to rebuild subscriptions leaves the environment in a potentially unknown and unhealthy state, we take the precaution of stopping PI Notifications and performing a restart of PI Analysis Processor once a check-in is performed. This requires 20mins of analysis downtime while restarting and 3-4 hours of backfills, but at least leaves us in a known clean state. If new PI Points are being created by analysis based upon the template check-in though, the start time could still be multiple hours as analysis works to build those points.
As we are continual developing and releasing changes/features to production, this significantly limits our ability to push frequent changes and slows our development cycles. Our desire would be to enable pushing daily changes without major impacts to our production environment, as well as reduce the time required by us to ensure the environment is once again stable. Currently we are only able to push changes about once a week and it requires half to a full day of monitoring the environment until we are able to re-establish our operational process using event frames and for PI Notifications to be re-enabled.