IEC 61850 GOOSE Testing Explained

A GOOSE message is the digital replacement for a trip wire, an interlock contact and a blocking signal. That single sentence explains both why GOOSE is attractive and why testing it makes experienced engineers uneasy: the signal path you used to be able to see, ring out and clip a meter onto is now a multicast Ethernet frame that exists only while the network is passing it.

This article covers what GOOSE is, the mechanics you need to hold in your head to test it, how to drive testing from the substation configuration files rather than from a mapping spreadsheet, and how the Edition 2 test facilities let you work on an energized bay. It closes with an honest statement of what GridAPM ProtectionAI does and does not do in this area today.

Key takeaways

• GOOSE is a publish/subscribe multicast service defined in IEC 61850-8-1. It carries a dataset, not a single point, and it repeats continuously rather than only on change.
• The two numbers that matter most for interpretation are stNum (increments on a state change) and sqNum (increments on each retransmission of that state).
• Loss of a publisher is detected by expiry of the time-allowed-to-live value carried in each frame, not by an absence of wiring continuity.
• The SCL files are the specification. Verification means comparing live traffic against the SCL, not against someone’s spreadsheet.
• Mode/Behaviour, the Sim flag and the LGOS supervision logical node make testing on an energized substation possible — but you must verify that the subscriber actually switched to your simulated stream.
• Published ProtectionAI v1.3 encodes, publishes and monitors GOOSE and publishes 9-2LE Sampled Values on a built-in loopback transport only. The v1.4 source candidate adds explicit physical-NIC transport, still pending isolated IED and timing qualification.

Where GOOSE sits

IEC 61850 splits substation communication into two broad domains, and the distinction drives everything about how you test.

The station bus carries client/server MMS traffic — settings, reports, control from a gateway or HMI — and it carries GOOSE. GOOSE is a publish/subscribe service: a publishing IED sends a dataset to a multicast address, and any number of subscribers pick it up. There is no acknowledgement and no session. The publisher does not know or care who is listening. This is what makes GOOSE fast and what makes it hard to verify by inspection.

The process bus carries Sampled Values, the digitised current and voltage streams that come from merging units or non-conventional instrument transformers. The widely deployed implementation guideline is usually called 9-2LE, published by the UCA International Users Group as a constrained subset of IEC 61850-9-2; the formal product-standard treatment of digital instrument-transformer output is IEC 61869-9. Sampled Values impose a hard time-synchronisation requirement that GOOSE, on its own, does not.

GOOSE frames are sent as multicast Ethernet with their own EtherType, normally inside an IEEE 802.1Q VLAN tag that also carries a priority value. IEC 61850-8-1 recommends address and priority ranges for GOOSE and for Sampled Values so that engineered systems do not collide; treat the values in Part 8-1 as authoritative rather than a number you remember from a previous project, because both the recommendations and vendor defaults have moved between editions.

The mechanics you have to understand to test it

The dataset and the control block

A GOOSE publication is defined by two objects. The dataset lists the data attributes being published, in order — typically a set of boolean status values with their quality attributes, sometimes analogue values. The GOOSE control block (GoCB) references that dataset and carries the publication parameters: the GoID, the destination multicast MAC address, the APPID, the VLAN identifier and priority, the retransmission timing, and the configuration revision confRev.

The dataset order is not cosmetic. A subscriber maps input number three to dataset member three. If a dataset is re-ordered during an engineering change and only one side is re-imported, the mapping is silently wrong and nothing in the traffic will look malformed.

stNum and sqNum

Every GOOSE frame carries a state number and a sequence number.

• stNum increments when any value in the published dataset changes. It identifies the event.
• sqNum increments on each repeat transmission of the current state and restarts when stNum changes.

So a subscriber that sees stNum unchanged and sqNum climbing knows it is looking at heartbeat repeats of a state it has already accepted. A subscriber that sees stNum step knows a real change has occurred and must be processed immediately. A subscriber that sees stNum jump backwards, or go to its initial value, knows the publisher has restarted. Implementations differ in whether sqNum restarts at zero or one after a state change; do not build a test acceptance criterion on that detail without checking the vendor’s own documentation.

Retransmission and time-allowed-to-live

GOOSE does not rely on the network delivering a single frame. On a state change the publisher sends a short burst of repeats a few milliseconds apart, then backs the interval off progressively until it reaches a slow steady heartbeat, commonly one to a few seconds. The exact burst profile is a configuration choice and varies by vendor.

Each frame also carries a timeAllowedtoLive value — a promise from the publisher that another frame will arrive within that window. A common convention is to set it to roughly twice the current retransmission interval, so it shrinks during the burst and grows back out at heartbeat rate.

That mechanism is how a subscriber detects loss of a publisher. If the TAL window expires with no new frame, the subscription is declared lost, the received values are marked invalid, and the receiving logic is expected to take a defined fallback position. This is the digital equivalent of a supervised trip circuit, and it is one of the things worth testing explicitly, because the fallback behaviour on loss of subscription is a scheme design decision, not a protocol default.

SCL is the specification

IEC 61850 systems are engineered in the configuration description language defined in IEC 61850-6. In practice you meet four file types:

File	What it is	Typical use in testing
ICD	A device’s capability description, as shipped	Confirms what a device type can do
IID	An instantiated description of one configured IED	Interim engineering exchange
CID	The configured description delivered to one IED	What that IED should actually be doing
SCD	The whole-system description	The authoritative map of publishers, subscribers and datasets

The SCD is the closest thing a digital substation has to a schematic. It states which GoCB publishes which dataset to which address, and which IED subscribes to it and where each member lands internally.

That makes the verification task specific: compare the live traffic against the SCL. Does the frame on the wire carry the GoID, APPID, destination address, VLAN, confRev and dataset structure that the SCD says it should? Does the subscriber’s internal mapping match what the SCD claims? Testing against a screenshot of a mapping spreadsheet verifies the spreadsheet, not the substation. The spreadsheet is a secondary artefact and is often the stale one.

Test modes and virtual isolation

This is the part that decides whether digital-substation testing is practical or terrifying. Edition 2 of IEC 61850 added facilities specifically so that a function can be tested without physically isolating it.

Three mechanisms work together.

Mode and Behaviour (Mod/Beh). IEC 61850-7-4 defines a mode attribute on logical devices and logical nodes with values including on, blocked, test, test/blocked and off, and a derived behaviour attribute that reflects the mode of the node and of its superiors. Placing a function in test means it still operates but its outputs are marked as test data; test/blocked additionally suppresses the outputs. This is virtual isolation: the equivalent of pulling a trip link, done in software and reported in the data model.

The Sim flag. A test set can publish a simulated GOOSE frame carrying the same identity as the real publisher, with a simulation indication set in the frame. A subscriber that has been told to accept simulation (through its own simulation-enable attribute) is expected to prefer the simulated stream and ignore the real publisher for as long as the simulated stream is present. That is how you inject a state change into a subscriber on an energized bay without touching the real publisher.

Supervision logical nodes. LGOS supervises a GOOSE subscription and LSVS supervises a Sampled Values subscription. Between them they expose whether the subscription is healthy, whether the configuration revision matches, and — importantly — whether the subscriber is currently consuming a simulated source.

The workflow that follows from this is:

1. Place the function under test into test or test/blocked behaviour and record what you set.
2. Enable simulation acceptance on the subscriber under test.
3. Publish simulated GOOSE with the simulation indication set.
4. Verify that the subscriber has actually switched to the simulated source — read the supervision status, watch a mapped input, or both.
5. Run the functional test.
6. Restore simulation acceptance and mode, and verify the restoration.

Step 4 is not a formality. Whether a subscriber switches on the first simulated frame, whether it switches back when simulation stops, how it treats a simulated frame with a mismatched confRev, and what it reports in LGOS while simulating all differ between vendors and between firmware revisions of the same product. That variability is the argument for a tool that reads the supervision data and confirms the state rather than a procedure that assumes it. Verify, do not assume — and record that you verified, because “we set the flag” is not the same claim as “the subscriber followed it”.

What to test, and what each test proves

• Publisher content against the SCL. Confirms the dataset members, order, addressing, VLAN, priority and confRev on the wire match the engineered design. Proves the publication is what the SCD says it is.
• Subscriber reaction and mapped binary inputs. Drive each dataset member and confirm the intended internal signal changes. Proves the mapping, which is the most common place for a silent engineering error.
• End-to-end trip path timing through GOOSE. Stimulate the protection function and measure to the operation of the downstream device. Proves the whole chain, including network transit and subscriber processing, not just the relay’s own operate time.
• TAL and loss-of-publisher behaviour. Stop the publication and confirm the subscriber declares loss within the expected window and takes the designed fallback. Proves the supervision works and the scheme fails in the intended direction.
• VLAN and priority handling. Confirms that the frames are tagged as engineered and that the switch path forwards them. Proves the network was configured to match the SCL.
• Behaviour under the Sim flag. Confirms simulation acceptance, switchover, switch-back and supervision reporting. Proves that your energized-substation test method is actually valid on this equipment.
• Network-level checks. Traffic inventory against the SCL, unexpected publishers, and behaviour under a broadcast or multicast storm. These need a network analyser with visibility of the relevant switch port, not a test set alone.

Timing needs a shared clock

IEC 61850-5 defines message types and transfer-time requirements, and the fastest trip-class messages carry a total transfer-time budget of only a few milliseconds. Consult Part 5 for the exact class figures rather than quoting them from memory; the classes and their names have been a frequent source of confusion.

The practical consequence is that a meaningful GOOSE trip-time measurement needs a common time reference between the point of stimulus and the point of observation. If the two ends are timed by independent clocks, your measurement uncertainty can be comparable to the quantity you are measuring.

On the process bus this becomes non-negotiable, because Sampled Values from separate merging units must be time-aligned before a differential or distance function can use them. The relevant profiles are IEC/IEEE 61850-9-3 and IEEE C37.238, both PTP profiles for power system use. Any digital-substation test plan should state what the time source is and how its health is verified during the test.

Pitfalls worth planning for

• The multicast never reaches your port. Switch configuration, multicast filtering, a VLAN the analyser port is not a member of, or a trunk that strips the tag will all produce the same symptom: nothing to see. Prove your capture point before you conclude anything about the IED.
• Mismatched confRev. Re-engineering a dataset bumps the configuration revision. A subscriber that checks it will reject the publication; a subscriber that does not check it may accept a re-ordered dataset and map it wrongly. Both failure modes are worse than an obvious error.
• The quietly ignored dataset. If a subscriber cannot parse a dataset — wrong number of members, unexpected type — it may simply not use it, without a conspicuous alarm. Read the supervision data.
• Proving a negative. “It did not trip” is hard to evidence. A GOOSE test that verifies only operation, and never verifies restraint or blocking, has tested half the scheme. Design explicit non-operation cases and record the duration over which non-operation was observed.
• Trusting the restoration. Modes and simulation flags left set after a test are a live risk. Verify the restored state in the data model, not from the procedure sheet.

CIGRE’s Study Committee B5 (protection and automation) published Technical Brochure 760 on test strategy for protection, automation and control functions in a fully digital substation, covering certification, interoperability, factory and site acceptance, and post-commissioning maintenance testing. Later B5 working groups have continued this line of work toward commissioning guidance for fully digital protection and control systems; check CIGRE’s own publication list for the current set rather than relying on a reference list here. If your organisation is moving to a process bus, this is guidance to read rather than guidance to summarise from a blog post — including this one.

What GridAPM ProtectionAI does here, precisely

We would rather be useful than impressive, so here is the boundary drawn clearly.

ProtectionAI today:

• Imports SCL files — SCD, ICD and CID — into its data model, so test intent can be derived from the engineered configuration rather than re-typed.
• Encodes, publishes and monitors GOOSE with correct protocol encoding, including dataset structure, stNum/sqNum behaviour and retransmission timing.
• Publishes IEC 61850-9-2LE Sampled Values with correct protocol encoding.

And the release boundary, stated plainly: published v1.3 runs on built-in loopback, not on a substation network. The v1.4 source candidate can explicitly open a SharpPcap/Npcap NIC for GOOSE/SV capture and injection, but no physical IED round trip or hardware-timing qualification has been completed.

The loopback capability is genuinely good for real work of a different kind: training on GOOSE and SV structure, validating that a dataset definition imported from an SCD is encoded the way you expect, and developing test logic before it goes near equipment. Message validation without a substation outage is worth having.

Implemented in the v1.4 source candidate but not yet live-qualified: raw-network GOOSE and SV capture/publication on an explicitly selected physical interface, SCL-bound test GOOSE, and Sim/Test indicators. Still roadmap or unqualified: subscription-based virtual binary inputs and outputs, audited energized-substation isolation workflows, hardware-timed merging-unit behavior, and physical test-set end-to-end qualification. ProtectionAI is therefore not presented as a qualified digital-substation commissioning tool.

The current standards coverage is documented on the ProtectionAI standards page, including the published-v1.3 and source-v1.4 boundaries. For adjacent testing topics see relay testing software and XRIO templates explained.