Decision guide

GOOSE interlocking versus hardwired contacts: an engineering comparison

2026-10-29 · 7 min read

Moving an interlock from a copper contact to a GOOSE message removes a wire and adds a network. That trade is neither automatically better nor automatically worse, but it changes what fails, how you test it, and what you have to prove to the utility that signs it off.

How each fails

• Hardwired: a broken wire, a loose terminal, a welded contact, a blown fuse. The failure is physical, visible with a meter, and usually discovered during maintenance testing.
• GOOSE: a multicast stream that stops, a switch that drops frames, a publisher that restarts, a VLAN misconfiguration. The failure is invisible without a capture, and the receiver learns about it only because the stream went quiet.
• The consequence: the GOOSE design needs an explicit, tested behaviour for "the message stopped", and the hardware design needs an explicit, tested behaviour for "the wire broke". Both need one; only one is traditionally written down.

What GOOSE genuinely buys

• Many signals over one connection: a single stream can carry the whole interlocking state, instead of a contact per condition.
• Diagnostics: the message carries quality, counters and identity, so "who said what, when" is answerable after the fact.
• Change without rewiring: adding a condition is a configuration change, which is a real operational benefit in retrofit.
• Fewer terminals, which reduces the failure surface that copper itself contributes.

What it costs

• Engineering: VLAN design, priority handling, and a network that must be maintained as infrastructure rather than as wiring.
• Test tooling: a capture-capable test set and staff who can read it.
• Approval: utilities differ on whether network signals are acceptable in a protection path, and some require redundancy plus a documented failure analysis.
• Cyber surface: a switch and a VLAN are now part of the interlocking path, which brings them into scope for security assessment.

The questions a utility will ask

• What happens when the publisher is lost — does the interlock fail safe, and is that documented?
• Is the network redundant, and was each path proven independently?
• How is the time behaviour bounded, and what is the measured worst case?
• How is testing isolated from in-service equipment?
• What evidence exists that the implementation is conformant, and what does it not cover?

A pragmatic position

Use GOOSE where the signal is rich, where diagnostics matter, or where rewiring is expensive — interlocking between bays, status distribution, scheme selection. Keep copper where the design depends on a single irreversible operation and the organisation's competence is in copper. Mixed designs are normal and are not a compromise; they are a consequence of different requirements.

Questions that come up

Is GOOSE allowed in protection tripping?

In many jurisdictions yes, with conditions on redundancy, failure analysis and testing. It is a regulatory and utility-approval question first and a technical one second.

Do we need redundant networks for GOOSE?

For interlocking and tripping paths, usually yes. What matters is that the redundancy is tested one path at a time, not that it exists on the drawing.

Can we keep hardwired interlocking and still use 61850?

Yes, and it is common: 61850 for supervision and reporting, copper for the interlock. That hybrid is often the lowest-risk first step.

Keep reading