A Wireshark traffic capture shows what actually travels over the substation network: for GOOSE, the state number (stNum), the sequence number (sqNum), the time allowed to live (TAL), the configuration revision and the simulation bit; for Sampled Values, the sample counter and synchronization; for MMS, associations, reports and TCP retransmissions. Compared with the SCD, a capture tells a network problem from a configuration problem in minutes.
What a capture gives you
When a GOOSE message does not arrive or arrives late, an IED loses its MMS connection or the relay declares the sampled values invalid, each device tells its own version of events. The traffic capture is the referee: it shows which frames exist at a point of the network, with what content and at what rate. Wireshark, the most widely used open-source protocol analyzer, includes dissectors for the three IEC 61850 services that matter in the substation: GOOSE, Sampled Values (SV) and MMS.
GOOSE and SV travel directly over Ethernet, without IP, with their own EtherTypes: 0x88B8 for GOOSE and 0x88BA for SV. MMS travels over TCP/IP, on port 102. That is why a single capture can be used to review the whole station bus, as long as the connection point sees the traffic.
Where the analyzer is connected
The substation switch does not send everything to everyone. With VLANs and multicast filtering, each port receives only what it needs, and a laptop plugged into a free port will see very little. There are three ways to reach the traffic:
| Capture point | What it sees | Watch out for |
|---|---|---|
| Switch mirror (SPAN) port | A copy of the traffic of the selected ports or VLANs | Under high load the mirror can drop frames; depending on the model, it keeps or strips the VLAN tag |
| TAP on an IED link | Everything that enters and leaves that IED, without altering the network | The link has to be opened to install it |
| Port of the subscribing IED itself | What actually reaches the relay | Only possible if the IED has a second port or a mirror function |
Networks with redundancy add one more point. With PRP, each frame travels duplicated over two independent LANs; to know whether one of them is failing, you have to capture on both. With HSR, frames carry their own tag and circulate in both directions of the ring; the analyzer is normally connected behind a RedBox. The guide on PRP and HSR explains the mechanism.
What a GOOSE frame reveals
Each GOOSE message carries in its header what is needed to diagnose almost any problem:
- gocbRef, datSet and goID: identify the control block, the data set and the message. If they do not match what the subscriber expects from the SCD, the frame is discarded even though it arrives.
- APPID, multicast MAC address and VLAN: the identity at the link layer. An error here makes the switch or the subscriber filter out the message.
- stNum: state number. It increases by one each time any member of the data set changes.
- sqNum: sequence number. It advances with each repetition of the same state and returns to zero when the state changes.
- timeAllowedtoLive (TAL): how long the subscriber must wait for the next message before declaring it lost.
- confRev: configuration revision of the data set. It must match in publisher and subscriber.
- Test or simulation bit: in edition 1 it was “test”; in edition 2 it flags the message as simulated, and only subscribers in simulation mode accept it.
- ndsCom: flags that the control block needs commissioning, for example because of an empty data set.
The details of the retransmission mechanism are in the guide on GOOSE.
Patterns that point to each problem
The value of a capture lies in recognizing patterns. These are the most common:
| What the capture shows | What it usually means |
|---|---|
| The message does not appear at the subscriber’s point but does next to the publisher | The network filters it: VLAN not allowed on some port, or multicast filtering misconfigured |
| The message arrives, but the subscriber rejects it | Mismatch in gocbRef, datSet, APPID, MAC or confRev against the SCD, or simulation bit set |
| stNum keeps increasing without real events | A data set member oscillates: bouncing input, unstable quality or an analog included by mistake |
| Two interleaved stNum and sqNum sequences with the same gocbRef | Two publishers with the same identity, typical after copying an IED’s configuration |
| Gaps in sqNum or intervals longer than the TAL | Lost frames: congestion, saturated mirror port or a link with errors |
| Untagged frames where a VLAN tag was expected | IEEE 802.1Q priority lost; critical traffic competes with everything else |
The last two cases tie in with the VLAN and IEEE 802.1Q priority configuration and with traffic storm problems.
- Does the message appear on a mirror port or TAP next to the subscriber?
- NoDoes it appear next to the publisher?
- YesThe network filters it: check VLANs and multicast filtering on each switch along the path
- NoThe publisher does not send it: check the control block and whether it is enabled in the IED
- YesDo gocbRef, datSet, APPID, MAC and confRev match what the subscriber expects from the SCD?
- NoConfiguration error: correct the SCD or the IED and reload
- YesCheck the simulation bit, the subscriber's mode and whether the TAL expires between messages
Sampled Values and MMS
Sampled Values. On the process bus the capture shows each merging unit stream with its identifier (svID), the sample counter (smpCnt), the synchronization flag (smpSynch) and the quality of each channel. An smpCnt with jumps means lost frames; smpSynch at zero means the merging unit lost its time reference. Both lead the relay to block its functions, as described in lost sampled values on the process bus. The volume is also visible: an SV stream has thousands of frames per second, and the capture reveals whether a port receives streams it should not.
MMS. Here the capture is TCP/IP: you see the association between client and IED, the model read, report enabling and controls. The typical patterns are TCP retransmissions (loss or congestion), rejected associations (the IED’s client limit or authentication parameters), connections the client opens and closes in a loop, and reports arriving with buffer overflow. The IEC 61850 MMS guide describes the services.
Limits of a capture
- The time stamp belongs to the laptop. It cannot measure the transfer time of a GOOSE with the accuracy a trip requires; that takes equipment with hardware time stamping and a common time reference.
- The mirror is not neutral. Under heavy traffic it can drop frames itself and make it look as if the network loses them.
- The capture shows the network, not the logic. If the GOOSE arrives correctly and the relay does not act, the problem is in the logic or in the IED’s mode.
- With IEC 62351 authentication the content is still visible, but the signature cannot be validated without the keys.
To compare what was captured with what was designed, open the SCD in our free IEC 61850 SCL viewer and check the expected addresses of each message.
When to ask for support
If the capture confirms a configuration problem (identifiers, data sets, VLANs or addresses), the fix lies in the SCD and the IEDs. At Tiza Group we do the IEC 61850 engineering and configuration of medium, high and extra-high voltage substations and industrial plants, including traffic review during commissioning, and the network design as part of our communications engineering service. If the problem is in a relay’s settings or logic, we solve it with remote relay configuration. Contact us with the brand and model of your equipment.
Related guides
- IEC 61850 GOOSE: how it works, stNum, sqNum and testing
- GOOSE that does not arrive or arrives late
- IEC 61850 Sampled Values
- IEC 61850 MMS
- Substation Ethernet switch
- IEC 61850 SCL files
- VLANs and IEEE 802.1Q priority for GOOSE and SV
- Substation communication network testing
- IEC 61850 test mode: Mod, Beh, Sim and the test bit
- Substation communications by voltage level
References
- IEC 61850-8-1, Specific communication service mapping (SCSM) – Mappings to MMS and to ISO/IEC 8802-3 (GOOSE and MMS).
- IEC 61850-9-2, Specific communication service mapping (SCSM) – Sampled values over ISO/IEC 8802-3.
- IEC 61850-7-2, Basic information and communication structure – Abstract communication service interface (ACSI).
- IEC TR 61850-90-4:2020, Network engineering guidelines.
- IEC 62439-3, Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR).
- Wireshark documentation: GOOSE, SV and MMS dissectors (wireshark.org).
Frequently asked questions
Where do I connect the laptop to capture GOOSE in a substation?
On a mirror (SPAN) port of the switch that carries the traffic of interest or, better, with a TAP on the IED link. Plugging into any free port does not work if the switch filters multicast by VLAN or group: you will only see what that port is allowed to receive.
Why does the stNum of a GOOSE message increase when no event has occurred?
Because some member of the published data set is changing. It is usually a bouncing binary input, an oscillating quality or an analog value included in the data set by mistake. The capture shows which member changes at each increment.
Can I measure GOOSE transfer time with Wireshark?
Only roughly. The time stamp is applied by the laptop's network card, which is not synchronized with the IEDs and adds its own delay. Transfer time is measured with test equipment that has hardware time stamping and a common time reference.