IEC 61850 GOOSE vs MMS vs Sampled Values

Back to Blog

The Decision in One Paragraph

Pick by what the data is for. Anything that a client polls, reports on, configures, or commands - status, measurements, setpoints, control - is MMS. Anything a device must publish to peers in milliseconds - a trip, a block, an interlock - is GOOSE. Anything that is a continuous digitized analog waveform from instrument transformers is Sampled Values. You do not choose one for the whole station; a real substation runs all three at once, each on the traffic it fits.

The trade-off axis is reliability versus latency. MMS uses TCP, so it retransmits and confirms but adds latency. GOOSE and SV are connectionless multicast on Layer 2, so they are fast but rely on repetition (GOOSE) or a steady sample rate (SV) rather than acknowledgements, which is why they are kept on a controlled network segment.

Service Comparison Table

Read a substation drawing with this table and the picture resolves quickly. The SCADA gateway talks MMS to relays. Relays exchange trips over GOOSE on the station bus. Merging units publish Sampled Values to protection on the process bus. All three are facets of the one IEC 61850 standard.

Network Engineering for Three Traffic Classes

The three services make three different demands on the LAN, and the network design has to honor each. MMS is ordinary routable TCP/IP: it can cross routers and firewalls, which is why it is the service that leaves the substation. GOOSE and Sampled Values are Layer 2 multicast: they do not route, they flood wherever the switches allow, and so they are contained by engineering - VLAN assignment to keep each traffic class in its lane, priority tagging so protection frames preempt bulk transfers, and multicast filtering so subscribers receive only the streams they need instead of every stream in the station.

Sampled Values adds a sizing consideration the other two lack: the stream runs continuously at its sample rate whether or not anything is happening, so process-bus capacity is consumed steadily, not in bursts. A process bus is therefore sized for the sum of its steady streams plus headroom, per the project's engineering study, rather than for an average that assumes idle periods. GOOSE, by contrast, is quiet until something changes and then bursts with repeated frames - the two share Layer 2 mechanics but not traffic profiles.

Time Synchronization Is a Per-Service Question

Each service has a different relationship with the clock. MMS reports carry timestamps applied by the publishing device, so station-wide time sync determines whether sequence-of-events records from different devices line up - important, but a data-quality matter. GOOSE subscribers act on the state in the message, not its timestamp, so protection signaling keeps working through modest clock drift. Sampled Values is the demanding one: streams from different merging units can only be combined - for differential schemes and phasor comparison - if their sampling is aligned to a common time reference, so precise synchronization, commonly engineered with the PTP power profile defined for the standard, is a functional prerequisite rather than a nicety.

That gradient has an operational consequence: loss of time synchronization means different things per service. For MMS reporting it degrades event-record alignment; for SV-based protection it can be a protection-affecting condition that the scheme must detect and respond to per its design and the site's procedures. Alarming on sync-source health is therefore part of the process-bus design, not an afterthought.

Troubleshooting by Service

When something misbehaves, the service tells you where to look first:

Complaint	Service	First checks
Client cannot read or control a device	MMS	TCP reachability, session state, report enablement
Missing events after an outage	MMS	Buffered vs unbuffered choice on the client's blocks
Subscriber declares a GOOSE failure	GOOSE	VLAN membership, multicast filtering, publisher state and sequence numbers
Protection alarms on the measurement stream	SV	Stream presence, sample counters, time-sync source

The pattern is consistent: MMS problems are session and configuration problems, GOOSE problems are almost always switch-engineering problems, and SV problems are stream-continuity or synchronization problems. A capture at the right point in the network - the station bus for the first two, the process bus for the third - resolves most arguments quickly, because all three services are observable on the wire.

What Leaves the Substation, and What Never Should

For SCADA and telemetry integration, the division of labor is clean: the upstream system consumes MMS - reports from report control blocks hosted on each intelligent electronic device - while GOOSE and SV stay inside the station doing protection's work. Wide-area routable profiles of GOOSE and SV do exist in the standard family for schemes that genuinely span sites, but they are specialist engineering; the default assumption for a monitoring integration is that if you find yourself wanting GOOSE outside the substation, what you actually want is an MMS report of the same information.

This split also simplifies the security story: the boundary device only needs to pass the client-server traffic, and the fast Layer 2 services never traverse it. Reviewing a proposed integration against that expectation - MMS out, GOOSE and SV contained - is a quick architecture sanity check that catches most category errors before commissioning.

Frequently Asked Questions