IEC 61850 and GOOSE messages — fast peer-to-peer protection communication between relays

The [guide on line current differential protection (87L) over a fibre-optic channel](/guides/protection/lijndifferentieelbeveiliging-87l-glasvezelkanaal) and the guide on teleprotection (85) — permissive/blocking schemes for distance protection both cover communication between relays at different stations. This article covers communication within a single station: how modern numerical relays (IEDs, Intelligent Electronic Devices) communicate with each other and with the station automation system via IEC 61850, and specifically via the GOOSE protocol.

Three communication services within IEC 61850

IEC 61850 ("Communication networks and systems for power utility automation") defines a standardised data model for protection and switching functions (each function is a "logical node", for example XCBR for a circuit breaker or PTOC for time-overcurrent protection) and three communication services built on that same data model:

MMS (client-server): the regular reporting and control traffic between an IED and the station automation system or SCADA — comparable to traditional RTU communication, but with a standardised object model instead of vendor-specific register addresses.
GOOSE (Generic Object Oriented Substation Event): fast, peer-to-peer communication directly between IEDs, intended for time-critical events (trip commands, switch position, interlocking signals).
Sampled Values (SV, IEC 61850-9-2): continuously streamed, digitised current and voltage values from a merging unit, as a digital alternative to conventional copper wiring from current and voltage transformers (see also the guide on CT protection class and knee-point voltage for the conventional, analogue counterpart of that signal).

GOOSE: directly over Ethernet, without routing

A GOOSE message is sent directly at layer 2 of the OSI model over Ethernet (Ethertype 0x88B8), without IP addressing, as a multicast message that can be received by every IED on the same Ethernet segment (or the same VLAN). That makes GOOSE unrouted — it stays within the local station Ethernet — but very fast: a status change (for example a trip command or a switch-position change) is placed on the network within a few milliseconds, considerably faster than would be possible via MMS client-server traffic.

The repetition scheme: reliability without acknowledgement

Unlike MMS, GOOSE has no application-layer acknowledgement — the sending IED cannot be certain a receiver has actually processed the message. Instead, IEC 61850-8-1 compensates for this with a repetition scheme: on a status change, the message is first repeated several times at a very short interval (for example every few milliseconds), after which the interval gradually increases to a stable, "quiescent" interval of typically a few seconds as long as no new change occurs. This stable repeated message functions as a heartbeat: every GOOSE message carries a "Time Allowed to Live" (how long the receiver may consider the last-received message valid), and if no new message arrives before that time expires, the receiving IED knows communication itself has been lost — even without any explicit fault message ever being sent.

Note: this heartbeat mechanism is why a GOOSE connection needs no separate "communication OK" check the way a classic hardware contact does — the absence of the periodic quiescent message is the fault indication.

Why this replaces copper wiring

Before IEC 61850, functions such as interlocking signals between bays, switch-position indications to adjacent IEDs, or intertrip commands for a busbar protection scheme were all implemented via physical copper wiring between relays — with the associated cabling, testing and maintenance burden. GOOSE replaces much of that hard wiring with a software-defined peer-to-peer message over the same Ethernet network that also carries MMS and SV traffic, which can substantially reduce cabling within a station, but shifts the responsibility for correct operation from physical wiring to the Ethernet network design itself.

Network discipline: the flip side of less copper

Because GOOSE is unrouted, unacknowledged and time-critical, a reliable GOOSE implementation places strict demands on the underlying Ethernet network:

Prioritisation: GOOSE traffic is typically marked with a high IEEE 802.1Q priority tag, so network switches give it priority over less time-critical traffic on the same network.
Network redundancy: because a GOOSE message is not acknowledged or retransmitted on request at application level, network redundancy is typically solved at layer 2 itself — for example via PRP (Parallel Redundancy Protocol) or HSR (High-availability Seamless Redundancy) from IEC 62439-3, which send a message simultaneously over two independent paths so that loss of one path costs no message at all.
Interoperability via SCL files: the configuration of which IED subscribes to which GOOSE messages from which other IEDs (and what logical signal is behind them) is captured in standardised SCL files (.icd, .cid, .scd) — intended to configure IEDs from different manufacturers interoperably within the same station.

Note: IEC 61850 does not automatically replace every form of hardware wiring — many installations combine GOOSE for time-critical logic with conventional wiring for critical functions where an extra, physically independent path is desired, or during a phased migration where older IEDs do not yet support IEC 61850.

Practical relevance

When designing, extending or maintaining a substation with IEC 61850-based IEDs, it is important to recognise that the reliability of GOOSE-based protection functions depends just as heavily on the Ethernet network design (prioritisation, redundancy, VLAN separation between process bus and station bus) as on the IEDs themselves — a network change that at first glance seems to affect only IT traffic can inadvertently also affect time-critical GOOSE signalling.

Common mistakes

Sending GOOSE traffic without priority tagging over the same network as non-time-critical IT traffic — under network congestion this can delay the arrival time of a trip signal.
Assuming the absence of an explicit fault message means GOOSE communication is working — without monitoring the heartbeat mechanism (Time Allowed to Live), a lost connection can go unnoticed.
Failing to update SCL configuration files of different IEDs consistently after a change — a GOOSE subscription that references an outdated dataset definition can lead to a silent configuration mismatch.
Treating network redundancy as an IT matter separate from the protection function, while PRP/HSR design for GOOSE traffic is just as critical a part of the protection design as the relay settings themselves.