SCADA Redundancy and Failover: Designing for Availability, Not Magic

Buying a redundant SCADA system is easy; operating one that actually fails over when needed is not. Redundancy moves the failure point somewhere else, and every architecture has a different one.

The Common Topologies

• Redundant servers (active/passive): two SCADA servers share state; the standby takes over on heartbeat loss. Watch for split-brain behavior - both servers thinking the other is dead.
• Redundant communications: dual paths to the field (separate switches, rings, or links). This protects the network but not the servers.
• Redundant data acquisition: RTUs or gateways with dual uplinks, or two gateways publishing to the platform. Choose one source of truth for historians to avoid duplicate values.
• Geographic or cloud DR: a standby environment elsewhere, warm or cold. Slowest to activate; best for disasters, not routine faults.

The Parts People Forget

• Redundancy applies to every layer: power, licensing servers, time sources, engineering workstations, and the database behind the historian.
• Failover must be tested. Pull the primary server's power during a shift change and watch what operators see. Annual scheduled failover tests are the industry norm for a reason.
• Alarm and event history must survive failover - a standby that loses the last five minutes of alarms is not redundant.

Honest Sizing

Ask what failure the redundancy actually covers. If the risk is a crashed server, active/passive with tested failover solves it. If the risk is the site losing connectivity or power, redundancy belongs at the network and power layers instead. Matching the architecture to the actual failure scenario is the whole job.