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
Created by sahilp
Created on Aug 2, 2023

Ua Server force failover / improve failover logic

Let me preface this by saying that I know it is a workaround for a non-compliance with the OPC UA specifications. The point is that the situation described below is unfortunately all too common and the workaround is needed.


It often happens that the SCADA vendor installs two seperate ua servers, but does not correctly configure the redundancy (either through lack of skill, or other problems) and so the server URI array, and the Service Level nodes are not populated in the proper way and the adapter (and connectors) are not aware that a failover is needed, nor where to failover to.


The URI array problem is solved in the latest (1 Aug 2023) version of the ua adapter, but we still need a mechanism to either force a failover, or even better for the adapter to figure out that the connected server is not working in the proper way and should try to fail over.


Manual failover could be initiated by pushing a JSON at the adapter REST API.


Automatic failover could be based on the fact that the adapter knows very well exactly how many values have changed in the subscription. If there are zero value changes (or less than N) within T minutes, then failover. With the N and T being user configurable parameters. I am not sure if it is equivalent, but the data source IO Rate could also be watched and if below a certain threshold then failover. This would be less easy for the user to configure because the IO Rate is not super transparent (to me at least).


Another (possibly harder to implement) failover logic could be based on the adapter watching a node which is expected to change frequently. e.g. if there is a PLC upstream of the ua server, then it could be configured to send out a saw tooth wave, and if the adapter sees the saw tooth not updating anymore, then failover.

  • Attach files
  • Guest
    Reply
    |
    Aug 9, 2023

    Maybe introduce a way to ignore the supported redundancy mode of the server (RedundancySuppport nodeID) and just proceed with a normal default connection to the backupendpointURL parameter when primary server is disconnected?

    Otherwise it seems its not possible to use non-transparent server failover with RedundancySupport value being 0 despite the secondary server being automatically used when restarting Adapter with primary server disabled