GOOSE and sampled values: what goes wrong on the network
GOOSE messages (IEC 61850-8-1) carry trips, interlocks and status between IEDs. Each message repeats the whole data set: when a value changes, the publisher increments stNum, resets sqNum to 0 and sends the message several times in quick succession, then slows down to the steady repetition interval (MaxTime). Every message carries a time allowed to live (TAL); a subscriber that hears nothing within TAL treats the data as lost. Most field problems show up as gaps in stNum or sqNum, repetitions arriving too close to TAL, a changed data set without a new confRev, or a device left in simulation.
Sampled values (IEC 61850-9-2, usually to the 9-2LE profile) stream currents and voltages from a merging unit at 80 samples per cycle — 4,000 frames per second at 50 Hz. Lost or out-of-order samples, a sample counter that wraps at the wrong value, loss of time synchronisation (smpSynch) or invalid channel quality can block or mis-operate protection.
Frequently asked questions
Can the analyzer capture live traffic?
No. Browsers cannot read raw Ethernet frames. Capture with Wireshark (or a hardware capture device) and open the file here.
Which standard editions do the clause references follow?
IEC 61850-7-2:2010, IEC 61850-8-1:2011 and IEC 61850-9-2:2011 (Edition 2), the UCA 9-2LE guideline, IEC 61869-9, IEC 62439-3 and IEEE 802.1Q. Confirm the clause against your copy of the standard before quoting it.
Is my capture uploaded?
No. The capture and the SCD are read in your browser and never leave your computer.
Why does the analyzer warn about time allowed to live without margin?
If TAL is close to the repetition interval, a single delayed or lost repetition makes subscribers declare the GOOSE lost. A TAL of about twice the repetition interval is common practice.