Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA™ System Platform

Upgrade redundant pairs

  • Last UpdatedMay 14, 2025
  • 5 minute read

Important: Every redundant Application Server run-time node must be configured to use the System Management Server if data is being historized. Redundant nodes have an instance of HCAP running, which is used to synchronize tags and store-and-forward data between redundant AppEngines. With the release of System Platform 2023 R2, secure communication is required for HCAP, and thus, redundant nodes will not function without the SMS.

If the SMS is not configured, there will be data loss, as well as warnings and error messages.

You can reduce plant down time by upgrading the two partner nodes in a redundant pair, one at a time.

Platforms hosting redundant pairs may be deployed even when a partner platform is not the same software version as the Galaxy Repository (GR) platform, or is in the Software Upgrade Pending (SUP) state.

When upgrading a redundant pair, we recommend upgrading the standby partner first. This way, only one failover of the redundant engines is needed, thus minimizing the period of time in which process data is not collected. After upgrading the first node, upgrade the second as soon as possible. When only one node is upgraded, backup and failover are not available. Both nodes must be at the same software version to enable redundancy.

The following is a description of the workflow for upgrading a Galaxy Repository (GR) and one redundant pair of AppEngines (E1 and E1b) from the existing version of System Platform to System Platform 2023 R2 SP1.

  • The GR is installed on platform P0.

  • The redundant AppEngines are installed on primary platform P1 (active AppEngine E1) and backup platform P2 (standby AppEngine E1b).

  • For simplicity, this procedure assumes that each platform has only one engine.

Upgrade the GR first, next, the backup platform, and finally the primary platform.

Initial state

  • All platforms, including the GR, are deployed.

  • AppEngine E1 running on Platform P1 is the active engine.

  • AppEngine E1b running on Platform P2 is the standby engine.

Final state

  • All nodes are upgraded and deployed.

  • AppEngine E1 (Platform P1) is running as the standby engine.

  • AppEngine E1b (Platform P2) is running as the active engine.

Upgrade the GR (P0)

  1. Optional: If necessary, upload run-time changes to the GR. This saves any changes made during run time to the database.

    Caution: Any configured default values such as set points that are modified at run time will be overwritten if you upload the run-time changes.

  2. Upgrade the GR node from the current version to System Platform 2023 R2 SP1 with Application Server deployed but shut down.

    • All objects on the GR node become undeployed.

  3. Reboot when prompted.

    • System Platform 2023 R2 SP1 is now installed.

  4. Open the IDE and migrate the galaxy.

    • The galaxy database is migrated to System Platform 2023 R2 SP1.

    • The IDE shows that platforms P1 and P2 are in SUP (software upgrade pending) state.

  5. Optional: Open and migrate InTouch ViewApps.

    • InTouch ViewApps are now migrated to System Platform 2023 R2 SP1.

  6. Cascade deploy the GR node.

    • All objects on the GR node are now deployed.

Upgrade standby platform (P2)

  1. Upgrade the standby platform (P2) hosting the backup AppEngine E1b to System Platform 2023 R2 SP1. Application Server is deployed but shut down.

    • P2 and its hosted engines and objects become undeployed.

  2. Cascade deploy P2.

    • AppEngine E1 becomes undeployed but objects under E1 continue to show as deployed.

    • AppEngine E1b becomes active. Hosted objects (shown under E1) are now running under System Platform 2023 R2 SP1. Note that AppEngine E1b does NOT start from the check-pointed state of AppEngine E1, which is still running under the prior version of System Platform.

    Caution: The cascade deployment results in a brief downtime for all objects hosted by the redundant engines E1 and E1b as E1 transitions to undeployed. This downtime can last anywhere from a few seconds to a few minutes, depending on the number of objects.

    Upgrade active platform (P1)

    1. Upgrade (formerly active) platform P1 hosting the backup AppEngine E1 to System Platform 2023 R2 SP1. Application Server is deployed but shut down.

      • P1 becomes undeployed.

    2. Cascade deploy P1.

      • AppEngine E1 is deployed as part of platform P1 deployment. E1 starts as the standby AppEngine and fully syncs with active AppEngine E1b.

      • AppEngine E1b continues to run as active.

      All nodes have now been upgraded and all platforms and engines are deployed.

      • Platform P0 (GR) is deployed.

      • Platform P1 is running as backup. AppEngine E1, running on P1, is deployed - standby.

      • Platform P2 is running as primary. AppEngine E1b, running P2, is deployed - active.

      After you have upgraded to System Platform 2023 R2 SP1, you can enable CPU load balancing to improve the performance of redundant AppEngines during failover. The following table describes the behaviors associated with specific upgrade actions and states.

      Action or State

      Behavior

      Cascade deploy a Platform after upgrade

      If the upgraded platform hosts a backup redundant engine with a partner in the SUP state, then during the deploy operation, it will extract the hosted objects from the partner and deploy them along with the backup redundant engine.

      Deploy a redundant engine with a partner in the SUP state

      The deploy operation is always a Cascade Deploy.

      Multi-selection for a cascade deployment includes a redundant engine with a partner in SUP state

      The cascade deploy operation skips the redundant engine in SUP state and logs a message.

      Select a backup redundant partner engine for deployment

      The backup redundant engine extracts the hosted objects from the primary redundant engine and deploys them along with the backup redundant engine.

      The hosted objects are under the primary redundant engine on a partner platform which is in SUP state. The hosted objects will be forced to deploy with the newer software version during the deployment of the backup redundant engine.

      A dialog displays with the option to continue deployment or to cancel.

      Partner engine is deployed but not reachable or not ready to sync

      Redundant engine deployment fails.

      Partner engine has older software version

      The partner engine is detected and recognized as having an older software version. It is automatically stopped and unregistered.

      Primary engine transitions into Active – Partner not Upgraded redundancy status.

      Primary and backup partners cannot sync, but references to a redundant engine with this status—or with Active or Active – Standby not Available redundancy statuses—will resolve.

      Application Objects can be deployed to a redundant partner with Active – Partner Not Upgraded redundancy status.

      You will not be able to deploy the partner engine until you have upgraded it.

      TitleResults for “How to create a CRG?”Also Available in