Redundancy sells itself as “never stops”; engineering it honestly means knowing exactly which failures it absorbs and which it politely forwards to you.
The architecture
Two CPUs run synchronized as one logical controller — primary executes, backup shadows with synchronized state, and on primary failure the backup continues without program restart: sequences keep their step, setpoints their values. R-series couples via Profinet ring (S2 devices), H-series via fiber sync links with higher performance and the fuller feature set. The program is ordinary S7-1500 engineering with a redundancy-aware configuration — no exotic programming model, which is the quiet achievement.
What it protects: CPU hardware death, one power branch (design your feeds separately!), planned CPU maintenance. What it does not: I/O failures (an ET200 station that dies is dead for both CPUs — availability continues around it only if your I/O topology says so), software bugs (both CPUs faithfully execute the same mistake), network single points (the ring or media redundancy design is a separate discipline), and actuator reality.
Design implications
The I/O tree decides real availability: S2 system redundancy support per device, ring topologies, dual power feeds — the CPU pair is the easy 20 %. Peripheral choices (which devices support redundant access, switchover-tolerant timing of the process) deserve more review hours than the CPU order code.
FAQ
How long is switchover? Bumpless from the program’s view; process-visible effects depend on I/O update behavior during the transition — validate on your time-critical loops rather than quoting brochure numbers.
Do I need R/H, or fast repair? Count the cost of an hour’s stop: many plants buy more availability with a cold-standby CPU, current archives and trained staff than with redundancy they cannot maintain.
Zone Otomasyon designs availability to the failure modes that actually occur in your plant. Availability engineering.