Redundancy

Overview

EnvisionSCADA redundancy provides a two-node high-availability setup with a Primary node and a Standby node.

1) Purpose and architecture

The Primary node is the active server that runs the project and is the authoritative source of configuration and historian data.

The Standby node is the passive server that stays synchronized with the Primary and is ready to take over automatically.

The redundancy mechanism continuously determines which node is Primary and which is Standby, keeps configuration and runtime state aligned, keeps historian data aligned, and performs automatic failover if the partner becomes unreachable.

2) What must be configured

Redundancy relies on having two participants configured consistently on both nodes.

• Participant 1: IP address, port
• Participant 2: IP address, port

The IP addresses must be valid and must match the actual network interfaces of the servers.

Each server must match exactly one of the participant IP addresses so the server can identify whether it is Participant 1 or Participant 2.

Both nodes must run the same EnvisionSCADA build/version.

The nodes must be able to reach each other over HTTPS on the configured ports.

Any firewall rules must allow the required traffic between the two nodes.

Each participant may optionally be given a second IP address on a separate network, using the Participant 1 IP Address (LAN 2) and Participant 2 IP Address (LAN 2) fields. LAN 1 (the primary Participant IP Address) carries all redundancy traffic; LAN 2 is a standby path that is used automatically only when the partner cannot be reached on LAN 1. Leave the LAN 2 fields empty for a single-network setup.

Both networks use the same participant port. A node is still recognized as the same participant when only one of its two LAN addresses is reachable, so a single failed cable or switch on one network no longer interrupts synchronization or forces a role change. The partner is treated as offline only when it cannot be reached on either network.

When HTTPS certificates are used on the synchronization channel, include both LAN IP addresses of each node in that node's certificate Subject Alternative Name (SAN). This lets the partner certificate validate on either network, so the fallback path keeps working after a LAN 1 outage. The Certificate Generator page provides an IP Address (LAN 2) field for issuing a certificate with both IP addresses in the SAN.

3) How roles are determined (Primary vs Standby)

At runtime, each node continuously exchanges status information with its partner and assigns roles.

If the partner is reachable, the system ensures that one node is Primary and the other is Standby.

If the partner is not reachable, the local node will promote itself to Primary to keep the system running.

When both nodes start and neither is yet established as Primary, the system selects Primary based on which side appears to have the most up-to-date historian progress.

If both appear equal or empty, the system uses startup timing to settle on one Primary and one Standby.

The goal is a stable pair with exactly one Primary and automatic continuity if one side disappears.

4) Normal operating behavior

In a healthy steady state, the Primary operates the project normally, serves configuration and state updates to the Standby, and receives any historian records that the Standby forwards.

In a healthy steady state, the Standby keeps its configuration aligned with the Primary, keeps historian data aligned, and maintains a small local standby historian buffer that is continuously emptied toward the Primary.

5) Synchronization model (What is synchronized)

Redundancy synchronization covers project configuration and runtime state, plus historian data.

The Standby keeps aligned with the Primary for project configuration, schedules, events configuration, alarms configuration, variables and local variables, and alarm counters with related runtime counters and state.

Configuration and runtime synchronization uses a baseline import when required and incremental updates thereafter.

The Standby keeps historian tables aligned with the Primary for Historic Data, Historic Alarms, and Historic Events.

Historian synchronization uses Backfill, where the Primary sends missing historian ranges to the Standby when it is behind, and Forefill, where the Standby forwards buffered historian rows to the Primary and then deletes them locally before syncing them back.

Project-level operations
Import Project, New Project, and the Git operations Pull & Import to DB and Restore replace the project on the Primary. The Standby receives the new project with its next baseline. Until then it keeps the previous project, so a takeover in that period starts the previous project on the new Primary.

After one of these operations on a redundant pair, restart EnvisionSCADA on the Standby node, for example by recycling its application pool in IIS Manager or by restarting the Standby server. The Standby takes a baseline on startup and returns to Synced with the new project.

6) Standby synchronization states

The Standby typically moves through Baselining, Syncing, and Synced states.

During Baselining, the Standby requests a full project baseline from the Primary, imports it, and uses this process on first sync, after role changes, or if the system detects a baseline mismatch.

During Syncing, the Standby requests incremental changes from the Primary and applies them until it catches up.

During Synced, the Standby is fully aligned with the Primary and only small periodic updates may occur.

If problems occur, the Standby can enter an Error condition.

7) Health rules and conditions that prevent redundancy

Redundancy requires both nodes to be compatible and correctly configured.

If the nodes run different EnvisionSCADA versions, redundancy is considered invalid and synchronization does not proceed normally. Ensure both nodes are deployed from the same build.

If both nodes are configured in such a way that they identify as the same participant, redundancy cannot operate correctly. Ensure each server matches only its own configured participant IP.

If the partner cannot be reached, the remaining node goes Primary to keep service available. When the partner returns, the system stabilizes back into a Primary and Standby pair.

8) Historian data handling in detail (Backfill and Forefill)

If the Standby is behind the Primary in historian progress, the Standby requests missing segments from the Primary and stores these records in its local historian database.

To protect disk space on the Standby, backfill is automatically paused or limited if the Standby historian buffer grows beyond a configured maximum. This ensures the Standby database remains small and does not grow uncontrollably.

The Standby periodically takes a limited batch of the oldest buffered historian rows, sends them to the Primary, and deletes the sent rows locally after the Primary confirms processing.

This keeps the Standby buffer small and ensures the Primary remains the long-term historian store.

If a node becomes Primary during failover or switchover, it may still have historian rows in its local standby buffer. The new Primary drains those remaining rows into its normal historian ingestion path until caught up. This is designed to avoid losing buffered historian records during role transitions.

9) Planned switchover behavior (Controlled role change)

The system supports a controlled switchover mechanism where the Primary can request a role change, the Standby promotes to Primary, and the original Primary yields to Standby.

This is used for planned maintenance where the active role needs to move to the other node with minimal disruption.

Exact operational steps depend on how the deployment exposes switchover request to operators, but the redundancy mechanism supports it.

10) What integrators should monitor

For commissioning, acceptance testing, and ongoing support, verify redundancy status and counters intended for HMI and diagnostic display, including role, sync state, baseline and change tracking, historian progress, and buffer counts.

• Exactly one Primary and one Standby
• Standby reaches and remains Synced in steady state
• Baseline identifiers match and do not oscillate
• Historian last ID indicators converge over time
• Standby buffered historian row counts remain low (forefill working)
• No persistent error state related to version mismatch or participant identity

11) Commissioning checklist

Use this as an integrator checklist during commissioning and acceptance testing.

12) Securing the synchronization channel (Redundancy Shared Secret)

The Redundancy Shared Secret authenticates the synchronization channel between the Primary and Standby nodes. When it is set, every redundancy request must carry a valid signature derived from the secret, so only a node that holds the same secret can request a baseline, exchange synchronization data, or forward values.

Configure the secret on each node in the redundancy settings on the Parameters page. Enter the same value on both nodes. Redundancy must be disabled to change the secret.

The secret is stored encrypted on each node and is never sent to the partner or included in a project export, so it must be entered separately on both nodes.

When the Redundancy Shared Secret is left empty, the nodes authenticate the synchronization channel by source IP address only. Set the secret on both nodes to require authenticated synchronization.

To change or remove the secret, disable redundancy, update the value on both nodes or select Clear stored secret to remove it, then enable redundancy again.

13) SYSTEM Variables: Redundancy

The following SYSTEM variables expose redundancy status, participant configuration, synchronization state, baseline tracking, historian progress, and forefill buffer counts.