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 General
Created by GaryYegiazaryan
Created on Jul 25, 2023

PI Adapter High Availability Resilience

Problem Summary:

The client failover service for PI adapter is not highly available. If the client failover service node is unavailable, then the PI adapter instances that it manages will lose failover functionality. This is further exacerbated if the primary PI adapter node goes down as well. In this case the secondary PI adapter will stay in its last current state of backup until human intervention (role override on the secondary PI adapter node).


Client failover service does not need to be redundant if the PI adapter pairs that it manages are smart enough to communicate with each other in the case the failover service goes down. In the unique case of the primary PI adapter and client failover service becoming unavailable, then the secondary will automatically take over.

This potential solution allows for self-healing without human intervention at remote sites.

Below is a potential workaround (not tested). If it works, then we would like to see it incorporated into PI adapters.

  1. Client failover service goes down.

  2. primary PI adapter goes down.

  3. secondary is in a backup state.

  4. outside service/script hosted on secondary periodically checks the health of the primary, and client failover service (this can be a simple ping).

  5. if both primary, and Client failover service are down, then the secondary assumes primary state with a role override command:


  • Attach files
  • Matthew Del Bonta
    Jul 26, 2023

    This is a great idea and will fill a gap in the Client Failover Server operation.