In critical process control — a refinery FCC unit, an ethylene cracker, a power plant boiler — the control system cannot stop. Not for a CPU failure, not for a firmware update, not for a backplane swap. Two redundancy architectures dominate the market for keeping a controller pair in lockstep: reflective memory, where dual CPUs share a dedicated hardware memory bus, and Ethernet-based redundancy, where synchronization runs over standard industrial Ethernet. They solve the same problem through fundamentally different mechanisms, and the choice between them determines your switchover time, your geographic flexibility, and your upgrade path.
How Reflective Memory Redundancy Works
Reflective memory is a hardware-level synchronization scheme. Two CPUs — primary and secondary — are connected by a dedicated fiber-optic or copper link that mirrors a shared memory region between them at the hardware level. When the primary CPU writes to a designated memory address, the reflective memory controller automatically replicates that write to the secondary CPU's memory in under a microsecond, without software intervention. The secondary CPU executes the same logic scan in parallel, operating on the same input data. If the primary fails — detected by a watchdog timeout or a hardware health signal — the secondary takes over within one scan cycle, typically 10–50 milliseconds.
The defining characteristic is determinism. The memory mirroring happens at bus speed, not network speed. There is no TCP/IP stack, no packet loss, no jitter, no switch latency. The secondary CPU is not one network packet behind the primary — it is one memory write behind. In a trip-critical application where a 100 ms gap between primary and secondary state could mean the difference between a controlled shutdown and a plant trip, that hardware-level determinism is the entire reason reflective memory exists.
How Ethernet-Based Redundancy Works
Ethernet-based redundancy synchronizes the primary and secondary CPUs over standard industrial Ethernet — typically PROFINET MRP, EtherNet/IP DLR, or EtherCAT redundancy. The primary CPU sends synchronization packets to the secondary at a configurable interval, carrying the contents of the data memory that changed since the last sync. The communication stack is standard TCP/UDP/IP or a real-time Ethernet protocol, running over copper or fiber physical media.
This is a software-level synchronization. The primary CPU must serialize its state, push it through the network stack, across the physical link, and up through the secondary's stack — all within the sync interval. The secondary always lags the primary by at least one sync period plus network latency. For a 10 ms sync interval over a lightly loaded network, that lag is typically 20–40 ms. For a 100 ms sync interval, it can exceed 150 ms.
The upside is geographic freedom. Reflective memory links are limited by the physical reach of the dedicated bus — typically 300 meters over fiber with a reflective memory card. Ethernet redundancy works across switches, routers, and fiber rings. The primary and secondary CPUs can be in different buildings, different cities, or — with appropriate network engineering — different sites. For geographically distributed processes like pipeline stations or water treatment plants spread across a city, Ethernet redundancy is the only practical option.
Switchover Time: The Hard Number That Drives the Decision
Switchover — also called failover or bump-less transfer — is the interval from primary CPU failure detection to the secondary CPU assuming active control with a valid output state. The two architectures deliver dramatically different numbers.
Reflective memory switchover is typically one logic scan cycle: 10–50 ms. Because the secondary CPU's memory image is a hardware-level mirror of the primary, it can assert control immediately upon detecting the primary's failure. Outputs do not glitch because the secondary already holds the correct output image — it was written to its memory by the reflective memory link on the previous scan.
Ethernet-based switchover is typically 1–3 sync intervals: 50–500 ms. The secondary must process the last received sync packet, validate that it has a complete state image, and then assume control. During the gap between the last successful sync and the switchover, any process change that occurred on the primary is lost. For a level-control loop with a 30-second time constant, losing 300 ms of data is irrelevant. For an anti-surge compressor controller where the surge cycle is 40–80 ms, losing 300 ms of data means the secondary takes over with a stale state — potentially commanding the wrong valve position for the first scan after switchover.
Scalability and Lifecycle Cost
Reflective memory requires dedicated hardware — a reflective memory card in each CPU chassis, plus the fiber or copper link between them. This hardware is proprietary to the PLC/PAC vendor or sourced from a reflective memory specialist. Adding a third CPU (for triple modular redundancy, common in safety systems) requires a second reflective memory card and a ring topology. Upgrading the CPUs to a newer generation may orphan the reflective memory hardware if the new backplane does not support the legacy interface.
Ethernet-based redundancy uses standard network infrastructure — the same managed switches and fiber rings that carry your HMI traffic and plant data. Adding a third CPU means plugging it into the same redundancy VLAN. Upgrading CPUs does not require replacing the network. The cost of the network is amortized across every device on the plant floor, not dedicated to the redundancy function. The trade-off is that the network must be engineered for the additional redundancy traffic — a 100 ms sync interval at 10 Mbps consumes about 1% of a 100 Mbps link, which is negligible for most systems.
When to Choose Each Architecture
Use reflective memory when:
- Switchover must complete within one scan cycle (under 50 ms) — compressor anti-surge, turbine control, reactor trip systems
- The primary and secondary CPUs are in the same control room or adjacent cabinets
- The control platform natively supports reflective memory (common in DCS and high-end PAC systems)
- You need bumpless transfer with zero output perturbation on failover
Use Ethernet-based redundancy when:
- The primary and secondary CPUs are separated by more than 300 meters — different buildings, sites, or geographic locations
- Process time constants are measured in seconds, not milliseconds — level control, temperature loops, water treatment
- You are building on a standard industrial Ethernet infrastructure and want to avoid dedicated redundancy hardware
- Future CPU upgrades are planned and you need to preserve the network investment
The Yokogawa STARDOM FCN-500 integrated PLC with dual redundant CPU illustrates the reflective memory approach in a process-automation controller — both CPUs share a synchronized memory image for scan-level failover without network dependency.
For trip-critical loops with sub-100 ms tolerance, pay for reflective memory hardware. For everything else, Ethernet-based redundancy over a well-engineered network delivers the right balance of reliability and flexibility.
