Skip to Main Content
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.

Status No Status
Categories Administration
Created by GaryYegiazaryan
Created on Nov 16, 2022

PI Vision should connect to all collective members in case a collective member is unavailable

Currently, PI Vision connects to a single collective member based on the priorities set in the AFSDK KST (known server table).

However, if that collective member becomes unavailable due to an issue (pairchss crashing, network etc etc), the PI vision display returns no data.

There is no way for a client to troubleshoot this because PI vision is going to connect to PI server based on the web server's priorities.

My proposal is that PI vision connects to all collective members and returns data from whichever one responds first. It should only return no data when:

  1. none of the collective members are available

  2. there is actually no data




  • Attach files
  • Matthew Del Bonta
    Reply
    |
    Jan 25, 2023

    This is a common sense enhancement that is critical for many clients. It provides value and stability to users operations.

  • Shawn McNabb
    Reply
    |
    Jan 24, 2023

    A related issue is that clients are also responsible for fanning the source data to each member of a collective and keeping the members synchronized. It is entirely possible for the same PIVision screen to present completely different views at the same time simply because under the covers the users are connected to different collective members.
    It should be up to the collective to guarantee each of its members contain the same set of data and thus will present the exact same view no matter which member is referenced. So the proposal makes sense, but also needs to guarantee that whatever member responds does so with complete and identical set of data as would be returned from any other of the members if they were available.

  • GaryYegiazaryan
    Reply
    |
    Nov 16, 2022

    This should likely be an update to the AFSDK rather than PI vision. This would increase the robustness of client connection to the PI system.

    From a client point of view, they should not care which collective member the data is being returned from. All they care about is that data is being returned.