SCADA server redundancy: FactoryTalk View SE, AVEVA System Platform, Ignition and switchover tests

SCADA server redundancy means a second server that can take over the work of the first one: the displays, the data connections to the controllers, the alarms and the history. FactoryTalk View SE, AVEVA System Platform and Ignition each do this with a primary and a secondary (or backup) running on separate computers, and each vendor documents which parts move at a switchover and which do not. Redundant servers protect only the server layer, so the network, the controllers, the virtualisation platform and the historian each need their own decision.

What can fail, and which layer covers it

The table maps each kind of failure to the layer that the vendor documents describe as covering it.

FactoryTalk View SE: redundant server pairs

In FactoryTalk View SE, HMI server redundancy is available only in network distributed applications. One computer hosts the primary HMI server and another the secondary; when the primary cannot serve clients, the clients move to the secondary and keep working. The two computers must have synchronised clocks, and the HMI server must be set to load and run its components when Windows starts.

The FactoryTalk Services Platform help lists the servers that can be made redundant: HMI servers, and data servers such as FactoryTalk Linx, OPC DA, Tag Alarm and Event, FactoryTalk Batch and OPC UA servers. The secondary cannot run on the same computer as the primary, the two must be configured identically, and once a pair is configured every client in the application uses it with no extra setup.

Two settings decide what happens after a failure:

• Switchover option. With FavorCurrent, the default for new HMI servers, the system stays on the secondary after the primary returns until a user switches over or the active server fails. With FavorPrimary, the primary takes over again as soon as it is ready.
• Keeping the pair in step. FactoryTalk View Studio can save online edits to both active and standby HMI servers and synchronise HMI memory tag values between them; the Redundancy tab also has a command to replicate the active server's project to the standby.

The FactoryTalk Directory is a separate question. If the Network Directory server is unavailable, each computer keeps a local copy of the Directory information: running clients can still read and write values, acknowledge alarms and open displays, but nobody can change the application's structure, such as adding or editing an area, a data server or an HMI server, until it returns. When the Directory and Activation server run on a PlantPAx server (PASS) in a redundant configuration, they are on the primary PASS only, and for distributed architectures the PlantPAx selection guide recommends a standalone Directory server. Rockwell's help also gives an example where the pair switched back to the primary against the "stay on secondary" setting: the primary hosted the Network Directory, a hidden FactoryTalk service counted as an extra client, and the health monitoring service picked the server with more clients.

AVEVA System Platform: redundant AppEngines and data sources

AVEVA Application Server provides redundancy in two places. AppEngine redundancy uses a primary AppEngine and a backup that the system creates when redundancy is enabled, hosted by two WinPlatforms on different computers running the same operating system. Data acquisition redundancy uses two DIObjects as data sources and a RedundantDIObject that monitors them and switches between them.

At run time the configured primary and backup become the active and standby engines, and either one can be active. They monitor each other over the redundancy message channel (RMC), which also carries message handling and data synchronisation. Each computer needs at least two network cards: one for the supervisory network and one for a dedicated Ethernet link between the pair. The store-and-forward directory settings must be the same on both WinPlatforms.

With warm redundancy, the default for new pairs, the standby engine starts and initialises alongside the active one and DI objects subscribe to both, so failover is much faster than in the legacy mode, where the standby starts only at failover. The standby takes over after the Engine Failure Timeout, 30 seconds by default, which AVEVA says may need tuning for the application. A failed active engine restarts and becomes the standby.

For trends, InTouch HMI 2026 supports a primary and a partner AVEVA Historian; when the primary fails, InTouch reads from the partner with no change to trends or scripts.

Ignition: master and backup gateways

Ignition redundancy is a two-node system: a master gateway that holds the configuration and a backup that receives it. Runtime state, such as current alarm states, is also synchronised so that the backup can take over with the master's state. The backup connects to the master over the Gateway Network, so the port must be open through any firewall between them.

• Standby activity level. A cold backup connects to OPC servers without subscribing to tag values, which avoids device load but fails over more slowly; a warm backup runs like the active node except that it does not log data or write to devices.
• Recovery mode. In Automatic mode the master takes control again when it returns; in Manual mode the backup stays active until it fails or a user requests a switchover.
• History mode. Full logs history from the backup directly and can create duplicates, because the backup cannot tell whether the master is down or only unreachable; Partial caches history and forwards only what was collected while the master was actually down.

The database is outside the redundant pair. Ignition's documentation describes failover datasource connections and notes that all history goes through Store and Forward, so it is cached while the database is unavailable. The backup gateway needs its own licence with the same modules as the master; otherwise data could be lost during a failover.

Virtualisation: high availability and fault tolerance

When the SCADA servers run as virtual machines (PlantPAx supports VMware and Nutanix AHV), the hypervisor adds its own availability options. VMware's vSphere Availability guide describes two levels:

• vSphere HA restarts the virtual machines of a failed host on other hosts in the cluster. VM Monitoring can also reboot a virtual machine when its VMware Tools heartbeats stop, and Application Monitoring can restart it when an application stops sending heartbeats, which needs VMware's SDK or an application that supports it.
• Fault Tolerance keeps a secondary virtual machine on another host in the same state as the primary at every instruction. If either host fails, the other continues with no data loss and network connections kept, and a new secondary is created.

With HA the server boots again on another host, so the SCADA application restarts. VMware describes the Fault Tolerance failover as the response to a host failure; for a virtual machine or an application that stops responding, vSphere HA offers VM Monitoring and Application Monitoring, which restart the virtual machine. The two layers can be combined with application redundancy: the PlantPAx guide sizes a virtualised system so that a three-server system with VMware HA or Fault Tolerance can still run on two servers after a failure.

Historian: buffering and redundant collectors

A switchover should not leave a gap in history. In FactoryTalk Historian SE, interface redundancy is usually paired with FactoryTalk Linx data server redundancy; the two interface nodes coordinate through a failover control file on a network share, buffering is configured on both through the PI Buffer Subsystem, and the buffer should sit on a local drive other than C. The PlantPAx guide adds that a redundant historian must be licensed for the same number of tags. Buffering, buffer limits and the Ignition and AVEVA equivalents are covered in what is a process historian.

Network and controllers

Server redundancy does not help if the only switch or the only controller fails. The PlantPAx selection guide recommends redundant power sources and separate physical cable paths for no single point of failure. PRP doubles the cabling and components and has zero recovery time inside the PRP zone; DLR recovers from a single break in the ring in 3 ms or less. PlantPAx requires the 1756-RM3 redundancy module for all ControlLogix redundancy configurations. See DLR or PRP and the ControlLogix redundancy pre-FAT checklist.

TDL project pages show these layers on Rockwell systems: at Ba Ria Gas Distribution Station the PLC-5 / RSView32 system moved to redundant ControlLogix with FactoryTalk View SE server and clients and EtherNet/IP DLR remote I/O, and at BSR four steam turbine generator systems moved from ControlNet to a redundant EtherNet/IP network and from RSView32 to FactoryTalk View SE.

What operators see during a switchover

The vendor documents describe the switchover from the client's side as follows:

• FactoryTalk View SE: clients move to the secondary and keep functioning. Rockwell describes alarm and event server redundancy, Tag Alarm and Event servers included, as automatic and transparent to clients: operators take no action and do not restart the client software. The FactoryTalk System Status Portal shows each server as Active, Standby, Failed, Transitioning and so on.
• Ignition: Vision clients reconnect to the other node and tell the user they were moved. Perspective sessions try their original gateway first and, if the backup becomes active first, open the same project and page on the backup.
• AVEVA System Platform: the standby engine becomes active after the failure timeout. AVEVA notes that scripts which read attributes right after a failover may see them still initialising, so such scripts need retry logic.

None of these documents gives a switchover time for a whole system. Measure it at FAT on the real application and record it.

Switchover tests for FAT and SAT

1. Baseline. Both servers show the expected Active and Standby states, clocks are synchronised, and the last online edits are on both servers.
2. Manual switchover. Swap roles on purpose: the Switchover command from a FactoryTalk View SE client, Ignition's Request Failover, or a forced failover in System Platform. In FactoryTalk View SE the command is ignored when the pair is set to switch back to the primary.
3. Fail the active server. Power it off, then repeat by unplugging its supervisory network. Check displays, writes to the controller, alarm states and acknowledgements on every client type.
4. Return the failed server. Confirm that the switchback setting behaves as configured, and look for hidden clients such as a Directory service on the primary.
5. Stop the FactoryTalk Directory server (Rockwell systems). Running clients should keep working; adding or editing areas and servers waits until it returns.
6. Break the historian path. Restart the active collector (the primary interface) several times, as Rockwell's Historian SE guide suggests, and check that data collection continues. Then disconnect the historian archive for a while, reconnect it and check that the buffered data arrives.
7. Fail a virtualisation host. Confirm whether the SCADA virtual machine restarts (HA) or continues (Fault Tolerance), and how the application pair reacts.
8. Restart a redundant node. For System Platform, AVEVA warns that restarting with the primary network disconnected can bind it to the RMC address; check network connections after every restart.

If firewalls sit between the servers, check which ports a FactoryTalk system needs; if a client cannot reach the servers after a switchover, start with FactoryTalk View SE client cannot connect. TDL's work on these platforms is described on the SCADA and historian and Rockwell upgrade pages.