Engineering

Redundancy in substation networks: PRP, HSR, and what the software has to do

2026-10-29 · 7 min read

Redundancy in a substation is usually specified as a network property and then quietly becomes a software requirement, because duplicated frames arrive at the application and something has to decide what to do with them. Getting that decision wrong produces the worst outcome: a redundant network that works, and a device that fails anyway.

Two mechanisms, one idea

Both PRP and HSR send the same frame twice over independent paths, and both add a trailer that lets the receiver identify and discard the duplicate. PRP does this over two parallel networks; HSR does it around a ring, where each frame traverses the ring in both directions.

In both cases the receiver sees each frame twice, in either order, and is expected to deliver it once to the application.

What the software must handle

• Duplicate suppression, correctly: identify duplicates by the trailer, not by comparing payloads or timestamps.
• Out-of-order arrival: the second copy may arrive first. If the stack assumes first-arrival ordering, it will occasionally process a stale state.
• Association continuity: TCP survives a path failure only if the network layer actually fails over transparently. A device that drops the association on a single lost frame turns a redundancy feature into an outage generator.
• GOOSE and SV are layer-2 and are duplicated directly, so the subscriber must suppress duplicates itself — and must not interpret a duplicate as a state change.

Where redundancy designs quietly fail

• Only one path is actually exercised during commissioning, so the second path is proven by assumption.
• The redundancy trailer is stripped by a switch or a capture tool, hiding whether duplication was ever there.
• Time synchronisation is not redundant, so the network survives and the data becomes unalignable.
• The application keeps its own sequence counters and treats the duplicate as a lost message, producing spurious discontinuity alarms.

Testing it honestly

The only meaningful test is to break one path while the system is running and confirm that no association drops, no report is lost and no spurious event appears. Do it on both paths, in both directions, and while a file transfer is in progress — the last one is where the state machines usually break.

Questions that come up

Do we need special hardware for PRP/HSR?

Usually yes, at least at the network interface level, because the trailer handling and duplicate detection need to happen before the application sees the frame. Some platforms do it in software with acceptable results at modest rates.

Is redundancy worth the cost for a small station?

That is a network design decision, not a protocol one. What matters on our side is that the software does not undo whatever redundancy the design provides.

Can we support both PRP and HSR?

Many devices offer both on different ports. Verify that the duplicate suppression is implemented once, correctly, rather than twice with different bugs.

Keep reading