Designing Power and Communication Redundancy

Redundancy is valuable only when it removes a credible single point of failure without creating a new, hidden dependency. In an industrial control system, adding a second power supply, controller, server, or network path does not automatically produce higher availability. The two paths must be sufficiently independent, their failure modes must be understood, and transfer behavior must be tested under realistic process conditions.

Start With the Required Control Function

Before selecting hardware, define what must continue when a component fails. A process may need uninterrupted closed-loop control, continued alarm visibility, preservation of historical data, or simply a controlled shutdown. These are different requirements. A redundant PLC pair may preserve logic execution but still lose control if both CPUs depend on one remote I/O adapter, one field power feed, or one unmanaged switch.

Build a dependency map from incoming power through DC distribution, controllers, I/O, communications, operator stations, time synchronization, and engineering access. Mark every shared component. The exercise often reveals that the most important single point of failure is not the processor but a circuit breaker, terminal block, fiber converter, configuration server, or field junction.

Designing Power Redundancy

Two DC power supplies can be arranged so either unit can support the required load, but their outputs should not simply be paralleled unless the manufacturer permits it. Redundancy or ORing modules isolate the sources and prevent one failed supply from pulling down the healthy bus. Each supply path should have appropriate upstream protection, conductor sizing, and diagnostics.

Engineers should calculate the normal load, peak load, temperature derating, and expansion margin. A useful design test is to remove either supply at maximum credible load and confirm that the remaining path stays within its continuous rating. If both supplies share the same AC feeder, disconnect, or enclosure hot spot, the arrangement protects against a power-supply failure but not against the common source or environmental event.

Critical field devices may also require redundant 24 VDC feeds, yet dual feeds can create backfeed paths through I/O commons or shields. Review the complete circuit, including protective earth and reference conductors. For replacement parts and cabinet planning, the Power & Electrical Components collection provides a practical starting point, but final selection must follow the device manual and project calculations.

Controller and I/O Failover

A redundant controller system normally maintains a primary and a standby processor. The standby receives enough state, configuration, and application data to assume control when the active unit or its communication path fails. The important engineering question is not whether failover exists, but what state is synchronized and what the process experiences during transfer.

Timers, sequence steps, totalizers, recipe values, output states, and communication sessions may not all transfer identically. Scan-time differences or unsynchronized external devices can produce a bump even when the CPU switchover is fast. Define acceptable transfer behavior for every critical loop and sequence. For motion, burner management, turbine control, and safety-related functions, use only architectures explicitly supported and certified for the application.

Remote I/O deserves separate analysis. Dual controllers connected through one network adapter still share that adapter. Some systems support redundant adapters, media, and fieldbus masters; others do not. Document which faults are tolerated and which faults force a safe shutdown.

Communication Redundancy Is More Than a Ring

Network resilience can use independent LANs, ring recovery, parallel paths, or protocol-specific redundancy. The choice affects convergence time, duplicate-frame handling, switch configuration, and device compatibility. A ring may recover from one cable break, but it will not survive a failed switch that disconnects several single-homed devices.

Separate paths should avoid the same cable tray, power source, and switch cabinet when a common event must be tolerated. Assign management addresses, alarm contacts, and topology documentation so technicians can distinguish a degraded-but-running network from a healthy one. The Communication & Networking collection can help identify hardware categories, while the architecture must be verified against the selected protocol and OEM design guidance.

Diagnostics Must Expose Degraded Operation

A redundant system can continue operating after its first failure, which makes clear diagnostics essential. If the plant never notices that it is running on the standby supply or a single network path, the second fault can become the outage. Bring redundancy alarms into the HMI or maintenance system, with enough detail to identify the affected channel and the time of transfer.

Useful indicators include power-supply DC-OK contacts, controller role and synchronization state, network path status, server replication health, and I/O adapter ownership. Alarm priorities should reflect urgency: loss of redundancy may not stop production immediately, but it should initiate prompt corrective action.

Commissioning and Proof Testing

Test one failure at a time under controlled conditions. Remove each power feed, interrupt each network path, stop the active controller, isolate a server, and confirm that alarms, outputs, operator displays, and recovery behave as designed. Record transfer time and any process disturbance. Then restore the failed element and verify resynchronization without an unintended second transfer.

Common-cause tests are equally important. Check what happens when a shared cabinet loses cooling, a common switch is rebooted, the time source disappears, or a configuration mismatch prevents standby synchronization. NIST SP 800-82 Rev. 3 emphasizes that operational technology resilience depends on understanding system dependencies and maintaining safe, reliable operation; redundancy should therefore be treated as a tested system property, not a parts count.

Maintenance Boundaries

Redundant equipment requires controlled change management. Firmware, configuration, and replacement hardware must remain compatible across both paths. A maintenance procedure should state which unit is active, how the standby is isolated, how synchronization is confirmed, and when the system has returned to a fully redundant state.

The best design is not the one with the most duplicated hardware. It is the one whose tolerated faults are explicit, whose common dependencies are minimized, and whose failover behavior has been proven against the real process risk.