Explainer

MMS, GOOSE and SV: three protocols, one standard, three very different jobs

2026-10-29 · 6 min read

The first surprise when you open IEC 61850 is that it is not one protocol. It is a data model plus three ways of moving that data, each chosen for a different requirement: browsing, fast peer-to-peer events, and continuous waveform sampling. Understanding why the three exist explains most of the design decisions you will meet in a device specification.

MMS — client/server, for everything that is not time-critical

MMS carries readings, datasets, reports, controls, file transfer and model discovery over TCP. It is request/response with a rich service set, which makes it flexible and, by design, not the place for time-critical interlocking.

This is the stack most products mean when they say "61850 support": a server that publishes a model, answers reads, accepts controls and sends reports.

GOOSE — publish/subscribe, for events that matter in milliseconds

GOOSE moves a small, fixed structure over layer-2 multicast, repeated at increasing intervals until it is superseded. No association, no acknowledgement, no request — the publisher states a fact and keeps stating it. Subscribers detect both new states and silence.

Interlocking, trip and status distribution between devices in a bay belong here. Anything that must be confirmed, logged or browsed does not.

SV — a continuous stream of samples

Sampled values carry the digitised output of current and voltage transformers from a merging unit to the devices that consume it: a continuous, high-rate stream where every sample carries a counter so the receiver can detect loss and reordering.

SV is the reason merging units and process bus exist. It is also the stack that demands the most from the platform: sustained bandwidth, hardware timestamping and predictable scheduling.

Which do you need?

• A protection relay that must interoperate with a control centre: MMS, both roles possible, plus GOOSE for bay interlocking.
• A bay controller or merging unit: SV and/or GOOSE are the point of the product; MMS is for configuration and supervision.
• A monitoring device or gateway: MMS client to collect, GOOSE subscriber if it participates in interlocking, SV subscriber only if it needs waveforms.
• A test tool: all three, and the ability to capture at layer 2, which is a different problem from parsing TCP.

The mistake to avoid

Trying to do all three in one thread. They have incompatible timing requirements: MMS tolerates tens of milliseconds, GOOSE wants a few, SV wants a schedule. A product that serialises them in one loop will pass every functional test and fail on the day the station is busy.

Questions that come up

Can GOOSE and MMS share a network?

In principle yes, in practice they are usually separated by VLAN and priority, because a burst of MMS file transfer must not delay an interlocking message.

Is SV always required in a digital substation?

No. Many "digital" stations use conventional CT/VT wiring into the relay and use GOOSE only for interlocking. SV appears when merging units are introduced, which is a process-bus decision.

Which stack has the steepest learning curve?

MMS, because the service set and the model are large. SV and GOOSE are small protocols that are hard to implement well for timing reasons rather than complexity reasons.

Keep reading