What Happens to Your I/O When a Cable Is Cut?

Somewhere in your plant there is a length of Ethernet cable that nobody thinks about. It runs through a cable tray, past a junction box, along a wall that a contractor will one day drill into.

The question worth asking is not whether that cable will ever be damaged. Over a twenty-year asset life, in a substation or a pumping station or a metro tunnel, something will eventually happen to it. The question is what your control system does in the following second.

For most remote I/O installations, the answer is uncomfortable.

KEY TAKEAWAYS

• In a daisy chain, one cut cable takes every station behind it offline.
• Ring protocols shorten the outage. They do not remove it — there is still a gap.
• HSR sends two copies of every frame in opposite directions, so a break interrupts nothing.
• Recovery time is zero — not “fast”, but nothing to recover from.
• Brodersen remote I/O runs HSR natively, plug & play, or on a normal LAN.

The daisy chain problem

Remote I/O is usually wired the way it is easiest to wire: a line from the controller to the first station, from the first station to the second, and onward down the row. It is neat, it uses the least cable, and it works perfectly right up until it doesn’t.

Cut one link in that chain and every station behind the break disappears at once. Not degrades — disappears. The controller stops receiving updates from those stations, so the last values it received simply stay where they are. Analogue inputs freeze at whatever they read a moment before the fault. Digital inputs hold their last state. Commands sent to outputs behind the break go nowhere.

Three things have gone wrong at once. You have lost visibility, because field data has stopped arriving and any alarm or interlock that depends on it is now blind. You have lost control, because outputs cannot be driven until the fault is found. And you have committed to a truck roll, because nothing recovers on its own.

Ring topologies, and the problem they don’t solve

The obvious fix is to close the line into a ring, so that every station has two paths back to the controller. This is right, and almost everyone does it. The question is what happens on the ring when a link fails.

With a spanning tree protocol, the network detects the break, recalculates the topology and reconverges on a new path. This works. It is also slow — classic STP is measured in tens of seconds, which is an eternity in a process context. Rapid and proprietary ring protocols brought that down to milliseconds, and for many applications that is genuinely good enough.

But look closely at what is being optimised. Every one of these protocols follows the same sequence: fail, detect, reconfigure, resume. The engineering effort goes into making the gap shorter. The gap is still there.

For a substation protection scheme, or a metro signalling interlock, or any application where a control decision might be made in the window between “fail” and “resume”, a short gap and no gap are not the same category of thing. Brodersen’s own guidance on this is blunt: their comparison material is titled around why you should never use RSTP in automation.

HSR: nothing to recover from

High-availability Seamless Redundancy takes a different approach, and the difference is worth understanding precisely because it is so simple.

In an HSR ring, every node sends two identical copies of every frame — one clockwise around the ring, one counter-clockwise. Both copies travel to the destination by opposite paths. The receiving node accepts whichever copy arrives first and silently discards the duplicate when it turns up.

Under normal conditions this looks wasteful. Two copies of everything, one of which is always thrown away.

Now cut a cable. One copy of each frame no longer completes its journey. The other copy, travelling the other way around the ring, arrives exactly as it always did. The receiving node takes it, as it was always going to take whichever copy came first, and passes the data up to the application.

Nothing detected the fault. Nothing reconfigured. The recovery time is zero — because there was no interruption to recover from.

This is why HSR is standardised, alongside PRP, under IEC 62439-3 — Clause 4 defines PRP and Clause 5 defines HSR. Both are described as redundancy protocols for industrial automation networks that require zero recovery time, and both are aimed at electrical substation automation and mission-critical applications that cannot tolerate any system downtime.

The ring has become a line, and the line still reaches every station. You repair the cable when it’s convenient. Operations continue uninterrupted.

HSR or PRP?

The two protocols in IEC 62439-3 solve the same problem with different topologies, and the choice between them is usually made on practical grounds rather than theoretical ones.

PRP uses two independent parallel networks. It needs two LAN ports and you can still program the device on the same network. It also lets you connect other equipment to the switch.

HSR uses a single closed ring. If you intend to program the RTU directly rather than from the topside, you need three LAN ports. HSR is a closed network by nature.

A useful way to think about both: HSR and PRP are a layer wrapped around whatever protocols you are already using. They encapsulate the drivers and make the communication link redundant. Your IEC 61850, IEC 60870-5-104, DNP3 or Modbus traffic does not change. It simply becomes impossible to interrupt with a single cable fault.

What this looks like in practice

The engineering argument for HSR has been settled for years. The practical objection has usually been that seamless redundancy sounds like something that requires a specialist to configure.

With Brodersen remote I/O it does not. HSR is native and plug and play — the same remote I/O runs in an HSR ring or on a normal LAN, and you do not need to know anything about HSR to use it. On Brodersen PLCs and RTUs the redundancy protocols are configured from the web page, with no programming: you select HSR or PRP.

Redundancy also does not stop at the network. Brodersen remote I/O supports a redundant I/O master and a redundant power supply, so the resilience is end to end rather than limited to the cabling. On the RTU32M the same thinking runs deeper still, with options for CPU and power supply redundancy in the same rack, CPU and power supply redundancy in separate racks addressing the same I/O, or full redundancy of CPU, power supply and I/O across different racks.

The I/O modules themselves are not passive terminal blocks. They handle SOE, debounce, chatter and filtering locally, and they are intelligent enough that even the power supply carries a substantial CPU. The LB2 modules used with the RTU32M and RTU32N each carry a 200 MHz processor to handle I/O processing, filtering, SOE, debounce, the module clock and general module logic, and they are hot pluggable with diagnostic variables available for every module.

Two more practical points. Brodersen remote I/O also works as Modbus remote I/O, so adopting it does not force a protocol migration across the plant. And you can evaluate the whole thing before committing to hardware: there is a simulator of the remote I/O stations, which means a complete proof of concept can be run without any physical units on the bench.

Where it matters most

Zero recovery time earns its keep wherever a brief loss of I/O is not a brief inconvenience. In electrical substations, protection and IEC 61850 traffic cannot tolerate a reconvergence window. In power generation and transmission, a control gap propagates quickly. In water and waste water, sites are unattended and a truck roll is expensive. In oil and gas, the environment is severe and access is limited. In renewable energy, assets are distributed and remote by design. In transportation and metro systems, signalling and interlocks are safety-relevant.

The common thread is not the industry. It is that in each case, somebody would rather not find out what the process does during a reconfiguration.

The question worth asking

Look at your remote I/O topology and find the single cable that would hurt most if it were cut this afternoon. Then ask what your system does in the second afterwards.

If the answer involves detection, reconfiguration and a gap of any length, it is worth knowing that a different answer exists — one where the second copy of the frame is already on its way around the other side of the ring, and the honest answer to “what happens?” is nothing.