Most controllers offer one kind of redundancy: a second CPU. It protects the CPU. It protects nothing else.
That distinction matters more than it sounds. A standby CPU does nothing for you when an I/O card fails, when a power supply drops, or when a cabinet is lost to a fire or a flood. The process stops anyway.
The RTU32M supports three types of redundancy. Choosing between them is really one question: how much of the system do you need to duplicate?
WHAT CAN ACTUALLY FAIL
- The CPU — all three types cover this.
- An I/O card — only Type 1 keeps running.
- A cabinet — power loss, fire, lightning. Types 1 and 3 can be split across separate cabinets.
Type 1 — Full redundancy
Every piece of hardware is duplicated, including the I/O. The two CPUs are joined by a LAN cable that replicates the data, plus a serial cable that stays live if the LAN link fails.
Because the I/O is completely redundant, an I/O card can fail and the process continues — no stop, no dropout. And the two systems can sit in separate cabinets, so a single power outage, fire or lightning strike does not take both.
Choose this when an I/O card failure is not something the process can absorb.
Type 2 — CPU redundancy
The layout most engineers already know, because it is what the majority of high-end PLCs and RTUs offer — and often all they offer. Data is mirrored across the backplane and through the REDLINK connection.
It is the easiest to retrofit: plug in the RL02A REDLINK and an existing system becomes redundant. It is also the lowest cost and lowest complexity of the three. The trade-off is plain — the I/O is not duplicated, so this does not protect against an I/O card failure.
Type 3 — Shared I/O
The system splits into three parts: two CPU sections and one shared I/O section. Both CPUs scan the same I/O, from the left and from the right.
The CPUs and the shared I/O can sit in separate cabinets, and it can be added to an existing installation. It gives high protection against shutdown at lower price and complexity than Type 1.
Side by side
| Type 1 | Type 2 | Type 3 | |
|---|---|---|---|
| Protects the CPU | Yes | Yes | Yes |
| Protects the I/O | Yes | No | Shared |
| Separate cabinets | Yes | No | Yes |
| Retrofit to existing | — | Easiest | Yes |
| Relative cost | Highest | Lowest | Middle |
What doesn’t change, whichever you pick
Program one CPU
The application mirrors to the standby automatically. No second project to maintain.
Redundant power supplies
Add a second PSU to share the load and take over if one fails.
Redundant networks
HSR and PRP are built in, so the LAN can be made redundant alongside the hardware.
SIL2 capable
The RTU32M can be used in SIL2 (IEC 61508) environments, where the higher availability comes from redundant hardware.
All three protect the CPU. What changes is the I/O — and that is the decision.
Start from what the process can’t lose
Don’t start from a redundancy type. Start from the failure you cannot absorb — the I/O card, the cabinet, the network — and work back to the level that covers it. Anything more is cost you don’t need; anything less is a gap you will find out about at the worst moment.
Not sure which level your site needs?
Tell us what the process can tolerate losing and we will show you which of the three fits — and what it costs to get there.