Table of Contents
ToggleIndustrial Automation · PLC · Redundancy · Switchover Failure
PLC Redundancy Switchover Failure: 7 Critical Reasons Most Engineers Miss
A PLC redundancy switchover is supposed to be invisible to the process, yet in the field it's one of the most common causes of unplanned trips on systems that were specifically installed to prevent them. This guide covers why switchover fails on a redundant PLC pair, how bumpless transfer should actually work, common trigger events, and a switchover time budget calculator.
What Is PLC Redundancy Switchover and Why Does It Fail?
This switchover process is what allows a standby CPU to take over control from a primary CPU after a detected fault, ideally without any interruption to outputs, timers, or process state. In a healthy redundant pair, both controllers continuously synchronize memory, and the standby is ready to assume control the instant a fault is confirmed. In practice, this switchover frequently fails to be bumpless — outputs glitch, sequences restart, or worse, both CPUs briefly believe they are in control at once.
Unlike a simple 4-20 mA current loop failure, a failed switchover can cascade into a full process trip, because the control system itself is the single point that was meant to prevent downtime. Understanding the mechanics of redundant PLC switchover, and where the common failure points sit, is what separates a redundant system that actually protects uptime from one that just adds cost without adding reliability.

How PLC Redundancy Switchover Should Work: 4 Steps
Memory, timers, and I/O status are mirrored from primary to standby over a dedicated redundancy link on every scan.
→Both CPUs exchange periodic heartbeat messages; missed heartbeats beyond a threshold indicate a possible fault.
→Once a fault is confirmed (not just suspected), the standby is commanded to assume active control of outputs.
→Outputs hold their last state during the transition, and the new primary resumes the scan from synchronized data.
Top Reasons PLC Redundancy Switchover Fails
If the redundancy link can't keep up with scan rate, standby memory falls behind, so switchover resumes control from stale data.
Typical symptom: outputs jump or timers reset immediately after switchover.
A watchdog timeout set too tight causes nuisance switchovers; set too loose, it delays legitimate fault detection.
Typical symptom: unexplained switchovers with no actual CPU fault present.
A break in the redundant communication ring can isolate the standby, or worse, let both units believe they're primary.
Typical symptom: split-brain condition with conflicting outputs.
If primary and standby CPUs run different firmware revisions or program versions, synchronization can silently fail.
Typical symptom: switchover appears to succeed but logic behaves differently afterward.
PLC Redundancy Switchover Time Budget Formula
Total Switchover Time = Detection Time + State Transfer Time + I/O Re-establishment Time
Where:
Heartbeat Interval = time between health checks (ms)
Missed Heartbeat Threshold = number of missed checks before fault confirmed
State Transfer Time = time for standby to assume active control (ms)
I/O Re-establishment Time = time for outputs to re-sync after transfer (ms)
Example: Heartbeat = 20 ms, Threshold = 3, Transfer = 15 ms, I/O = 10 ms Detection = 20 × 3 = 60 ms Total switchover time = 60 + 15 + 10 = 85 ms Compare this total against your process's allowable bumpless transfer window. If the calculated switchover time exceeds what the process can tolerate without upset, tightening the heartbeat interval or threshold is usually safer than assuming the redundant pair will "just work" during an actual fault.
Redundancy Mode Comparison: Hot, Warm and Cold Standby
Common Switchover Trigger Events
Loss of primary power to the active CPU is the most straightforward and reliable switchover trigger.
Internal diagnostics detect a processor, memory, or backplane fault and force a handover to standby.
Loss of the redundancy link or the primary's network connection can trigger, or wrongly suppress, switchover.
Manually forced I/O points on the primary that aren't mirrored to standby cause a bumped transfer.
Scheduled failover testing is the safest way to validate switchover behavior before a real fault occurs.
Overtemperature or excessive vibration detected by onboard diagnostics can force a preemptive switchover.
PLC Redundancy: What to Do and What to Avoid
- Test switchover regularly: a scheduled manual failover test is the only reliable way to confirm the redundant pair actually behaves as designed during switchover.
- Match firmware and program versions: keep primary and standby CPUs on identical revisions at all times.
- Monitor redundancy link health: alarm on sync lag before it becomes a failed switchover.
- Document the switchover time budget: compare it against the process's actual tolerance for a bumped transfer.
- Don't force I/O only on the primary: unmirrored forces are a leading cause of a bumped, not bumpless, transfer.
- Don't assume redundancy means zero risk: an untested redundant pair can fail exactly when it's needed most.
- Don't ignore intermittent sync warnings: they often precede a hard failure during switchover.
- Don't set watchdog thresholds by copying another site's settings: tune them to the actual process and network conditions.
PLC Redundancy Switchover Time Calculator
Enter your heartbeat interval, missed heartbeat threshold, and transfer times to estimate total switchover time.
Quick FAQs: PLC Redundancy Switchover
External References
- Wikipedia: Programmable Logic Controller
- IEC 61508: Functional Safety of Programmable Electronic Systems
- Rockwell Automation: ControlLogix Redundancy System User Manual
What we learn today
- PLC redundancy switchover is meant to be bumpless, transferring control from primary to standby without any visible process upset.
- The leading causes of switchover failure on a redundant PLC pair are data sync lag, watchdog misconfiguration, redundant network breaks, and firmware or configuration mismatches.
- The switchover time budget (detection + transfer + I/O re-establishment) should always be compared against the process's actual tolerance for disruption.
- Regular, scheduled switchover testing is the only reliable way to confirm a redundant PLC pair will actually perform as designed during a real fault.
