When a process cannot stop — a refinery crude unit, a pharmaceutical batch reactor, a power plant turbine — the PLC or PAC controlling it cannot stop either. A single CPU failure in these applications means lost production measured in millions per hour, or worse, a safety incident. Hot standby CPU redundancy is the architecture that prevents this: two identical CPUs running in lockstep, with the backup taking over in milliseconds when the primary fails. This article explains how synchronized failover works, what determines the switchover time, and when hot standby beats the alternatives.
What is hot standby CPU redundancy?
Hot standby is one of three redundancy architectures for industrial controllers. A primary CPU executes the control program and drives the outputs while a secondary (standby) CPU runs the same program in parallel, continuously synchronized with the primary's internal state — including program scan data, timer/counter values, and communication buffers. When the primary fails, the standby takes over within one or two program scan cycles, typically 10–50 ms, without re-initializing the application. This is fundamentally different from warm standby, where the backup loads the program but not the live data, and cold standby, where the spare CPU is simply powered off until needed — both of which incur a multi-second restart delay that can trip process interlocks.
How does synchronization work between the redundant CPUs?
Synchronization is the core engineering challenge. The primary CPU transmits its process image — inputs, outputs, internal flags, data blocks, and diagnostic status — to the standby over a dedicated high-speed link after every program scan. This link is typically a fiber-optic connection (for electrical isolation and noise immunity) running at 100 Mbps to 1 Gbps. At the start of each scan, both CPUs read their own input modules independently — they do not share input cards. The primary then executes the program, updates outputs, and sends the updated memory image to the standby. The standby compares this image with its own computed result. If they match, synchronization is confirmed. If the primary fails — detected by a heartbeat timeout, typically under 20 ms — the standby asserts control of the output bus and continues execution from the last synchronized data point.
What determines switchover time?
Switchover time is the sum of three delays: failure detection plus role transition plus output update. Failure detection uses a watchdog heartbeat between CPUs — if the primary misses 2–3 consecutive heartbeats (set conservatively at 5–15 ms intervals), it is declared dead. Role transition covers the standby enabling its output drivers and assuming bus mastership, typically 1–5 ms. The output update delay depends on whether the I/O is local backplane or distributed over a fieldbus; distributed PROFINET or EtherNet/IP I/O adds 1–2 network cycles. Total bumpless switchover — where the process cannot distinguish the transition from normal operation — requires the combined latency to stay under one process safety time, which for most continuous processes is 100–500 ms. Modern hot standby systems like the Emerson PACSystems RX3i CPL410 achieve switchover in under 50 ms, well within the budget for refinery, power, and chemical applications.
When does hot standby beat alternative redundancy approaches?
Hot standby is not the only way to achieve controller availability, and it is expensive — it doubles the CPU hardware cost plus adds dedicated synchronization modules. The alternatives each have a place:
- Software redundancy on a single CPU — task-level redundancy within one processor works for non-critical failures (memory corruption detected by ECC, watchdog-triggered task restart) but cannot survive a CPU hardware fault. Adequate for packaging machines and discrete assembly.
- Triple modular redundancy (TMR) — three CPUs with 2-out-of-3 voting on every output. Common in safety shutdown systems (SIS) requiring SIL 3. The extra CPU cost and voting complexity are justified only when the application demands continuous proof-test coverage.
- Warm standby with a maintenance bypass — common in water/wastewater where a 30-second restart is acceptable. The primary runs alone, and the standby periodically receives a program update. Restart requires re-reading all inputs and potentially re-homing motion axes.
Hot standby earns its place when a process cannot tolerate even a single-scan interruption — continuous chemical reactions, turbine-generator sets, steel continuous casters, and pharmaceutical lyophilization cycles where a temperature excursion ruins the batch. For these, the incremental hardware cost is dwarfed by the cost of an unplanned shutdown.
What does bumpless transfer actually mean in practice?
Bumpless transfer means the process variable does not deviate beyond the normal control band during the switchover. Achieving it requires three conditions: the standby must already hold the current PID integral term (not reset to zero on takeover), the output modules must hold their last state during the transition (not drop to zero), and the network connections to HMIs and SCADA must re-establish without tag timeout. The standby must also inherit the primary's communication role — Modbus TCP server IDs, OPC UA session tokens, and PROFINET device names — so that external systems continue addressing the same logical controller. Most modern redundant architectures handle this through a virtual MAC address or a shared IP that floats between the two physical CPUs, transparent to the connected devices.
The Emerson PACSystems RX3i CPL410 with redundancy support provides hot standby with sub-50 ms switchover and virtual IP failover for Modbus TCP and OPC UA — the reference architecture for continuous processes that cannot tolerate a single-scan outage. Browse our PACs catalog for additional high-availability controllers.
