What a Redundant PLC Actually Protects — and How to Commission One

What a redundant PLC actually promises

A hot-standby PLC pair is two CPUs running the same program, one primary and one standby, joined by a dedicated synchronization link. The primary controls the process. The standby does nothing to the outputs but keeps a live copy of program logic and data so it can take over within a scan or two if the primary fails.

The promise is narrow and worth stating plainly: if the primary CPU dies, control continues without a process bump and without operator action. That is it. Redundancy at the CPU does not protect against a failed I/O module, a cut network segment, a logic bug, a wrong setpoint, or a field device fault. Those failures hit both CPUs equally, or hit the shared parts that sit outside the redundant pair. Commissioning a redundant PLC is mostly about proving the one thing it promises works, and being honest about the many things it does not cover.

Common implementations you will meet: Rockwell ControlLogix/GuardLogix redundancy with a pair of 1756-RM2 modules linked by fiber, Siemens S7-400H and S7-1500R/H, and Schneider Quantum Hot Standby and M580 HSBY. The vendor names differ but the commissioning concerns are the same.

The three states of the pair

Every redundant pair has three conditions you must be able to read at a glance, ideally on the HMI and not just in the programming software:

Synchronized (redundant): both CPUs healthy, standby fully crossloaded and tracking the primary. This is the only state where a switchover is bumpless. Full protection.
Disqualified (standby not ready): primary running alone. The standby is powered but not synchronized — mid-crossload, a firmware mismatch, a failed sync link, or a fault it has not recovered from. Control is fine but there is no backup. This state is dangerous precisely because the process looks normal.
No primary / both faulted: the process is down or running on frozen outputs. Rare, but the failure mode you plan the alarm response around.

The single most useful redundancy tag on the SCADA is not "primary CPU = A/B." It is "pair synchronized: yes/no." A pair that quietly drops to disqualified and runs for three weeks unsynchronized has silently thrown away the redundancy you paid for. Alarm on loss of synchronization, and make that alarm one an operator cannot shelve away and forget.

How synchronization works, and why scan time grows

The standby stays current by receiving a copy of the primary's data table over the sync link, typically at the end of every scan (or every few scans for large data sets, depending on the platform). This crossload is not free. The primary must pause to package and send state, so a redundant program almost always has a longer, and more variable, scan time than the same program on a simplex CPU.

Watch for this during commissioning:

Measure scan time with the pair synchronized, not just with the standby off. The synchronized number is the real one.
Large arrays, big UDTs, and message-heavy logic inflate crossload time. If scan time is marginal, reducing the redundant data footprint helps more than optimizing rungs.
A scan time that jumps only when synchronized points straight at crossload load. Some platforms let you exclude specific tags from the crossload — use it for data that does not need to survive a switchover (diagnostics, scratch pads).
Set your SCADA poll rate and any scan-time watchdog against the synchronized scan time plus margin, or you will get watchdog faults the first time the pair syncs under load.

What triggers a switchover

Know exactly what will and will not hand control to the standby, because operators will ask and because half of switchover surprises come from a wrong mental model here:

Primary CPU hardware fault or power loss — the classic case, and the one redundancy is built for. Bumpless when synchronized.
Primary major fault (program fault) — a divide-by-zero or array-index fault that halts the primary. Here is the trap: the standby is running the same program, so it usually faults on the same rung a scan later. Redundancy does not protect against logic bugs. Do not count on it to.
Loss of the primary's I/O or network connection — platform-dependent. Some redundancy systems switch over when the primary loses its I/O path; others do not, because the standby has no guarantee its path is any better. Know your platform's behavior and test it.
Manual switchover command — from the programming software or an HMI control. Essential for planned maintenance: you swap to the standby, service the (now offline) former primary, and swap back.
Firmware or program download — most platforms let you update the standby, switch to it, then update the former primary, achieving a firmware change with no process stop. Rehearse this before you need it.

Bumpless is only as good as the shared parts

"Bumpless" means outputs do not glitch when control moves between CPUs — the standby already holds the current output image, so it drives the same values the primary was driving. But the redundant CPU pair is only one link in the chain. Everything the pair shares is a single point of failure that no CPU redundancy will save you from:

I/O. If the two CPUs reach field I/O through a single remote I/O adapter, that adapter is a single point of failure. Truly redundant designs need redundant I/O paths (dual adapters, ring networks) or they are protecting the cheap part and leaving the expensive part exposed.
The sync link. A single redundancy cable between the CPUs is a single point of failure for the redundancy function itself — on ControlLogix that is the fiber between the 1756-RM2 pair, on M580 HSBY the fiber between the two CPUs' redundancy ports. Lose it and the pair disqualifies — you are running simplex without knowing unless you alarmed on it.
Power. Two CPUs on the same power supply or the same breaker fail together. Redundant CPUs want redundant, separately-fed power.
The network to SCADA. If both CPUs answer on one IP that follows the active primary, a switchover changes which physical CPU owns that IP. Confirm the SCADA reconnects cleanly and that no driver caches a stale MAC. If the CPUs have separate IPs, confirm the SCADA driver knows which one is active.

Walk the whole path from field terminal to SCADA tag and mark every component that is not duplicated. Those are your real failure modes. Say so in the commissioning record instead of letting "the PLC is redundant" imply the plant is.

Testing switchover during commissioning

A redundant pair that has never been forced to switch over is an untested pair. Test it deliberately, with the process in a safe and observed state, and test both directions — A-to-B and B-to-A are not guaranteed symmetric.

For each test, capture: did outputs hold bumpless, how long did the changeover take, did the SCADA reconnect and to which CPU, did alarms fire correctly, and did the pair return to synchronized afterward.

Confirm synchronized start. Verify the pair reads synchronized on the HMI before you touch anything. Never test a switchover from the disqualified state and call the result a pass.
Manual switchover, both directions. Command a swap from primary to standby, confirm bumpless control and clean SCADA reconnect, wait for re-synchronization, then swap back. This is the safest first test and the one operators will use for maintenance.
Pull primary power. With the process safe, remove power from the primary CPU. Confirm the standby takes control within the expected time, outputs held, and the failed CPU is clearly annunciated.
Pull the sync link. Confirm the pair disqualifies and raises a "not synchronized / no backup" alarm — and that control does not bump, since the primary keeps running alone. Restore the link and confirm it re-synchronizes on its own.
Force an I/O path loss if your platform switches on it. Confirm the documented behavior actually happens on this system, not just in the manual.
Time the reconnect from the operator's seat. Measure how long the HMI shows stale or lost data during a switchover. A two-scan CPU changeover can still mean several seconds of SCADA reconnect — set operator expectations to the measured number, not the CPU spec.
Verify retentive and accumulated data survives. Totalizers, sequence step numbers, latched states, and setpoints must carry across a switchover. Anything excluded from the crossload will reset — find those the safe way, on the bench, not during an event.

Commissioning checklist

Confirm both CPUs run identical firmware and identical, correctly crossloaded program versions.
Verify the pair reaches and holds the synchronized state, and measure how long a full crossload takes.
Measure synchronized scan time under realistic load; set SCADA poll rate and scan watchdog against it plus margin.
Expose "pair synchronized: yes/no" and "active CPU: A/B" as SCADA tags, and alarm on loss of synchronization with an alarm operators cannot silently defeat.
Walk the full I/O-to-SCADA path and record every non-redundant single point of failure (I/O adapter, sync cable, power feed, network).
Test manual switchover in both directions with bumpless outputs and clean SCADA reconnect.
Test a primary power-loss switchover and confirm timing, held outputs, and correct annunciation.
Test sync-link loss and confirm the pair disqualifies, alarms, keeps controlling, and re-synchronizes when restored.
Confirm retentive, accumulated, and latched data survives a switchover; document anything excluded from the crossload.
Rehearse the firmware/program update via the standby so a future change needs no process stop.
Record active-CPU, sync state, scan time, switchover times, and reconnect times alongside the I/O and network drawings.

The goal of a redundant PLC is boring: a CPU failure that the operators learn about from a maintenance alarm, not from a process trip. Get there by proving the switchover works in both directions, alarming loudly the moment the pair stops being redundant, and being honest in the record about every shared part the redundancy does not cover.