IEC 61850 GOOSE

ELI5

Imagine a building full of security guards. When one guard sees a fire, they don’t call the front desk and wait for the desk to call other guards one by one (that’s polling, like Modbus). Instead, the guard shouts “FIRE IN ZONE 3!” and every guard in the building hears it at the same time. If a guard stops hearing periodic “all clear” shouts, they assume something is wrong and activate their backup plan. That’s GOOSE — guards shouting alerts that everyone hears instantly.

Outsider’s Guide

IEC 61850 GOOSE (Generic Object Oriented Substation Event) is a multicast publish/subscribe protocol used for fast protection and control signaling between intelligent electronic devices (IEDs) — protective relays, breaker controllers, and automation controllers.

Where it sits: GOOSE operates on the substation LAN between protection relays and control IEDs. It is not a SCADA protocol. Where Modbus TCP and DNP3 carry monitoring data from devices up to a gateway or HMI, GOOSE carries control-critical signals horizontally between peer devices — relay-to-relay, relay-to-breaker controller, generator protection to load breaker.

What it replaces: Hardwired auxiliary contacts. Traditionally, a trip signal from Relay A to Breaker B is a copper wire carrying a dry contact closure. GOOSE replaces that wire with a multicast Ethernet message. One relay can signal dozens of subscribers simultaneously — something that would require dozens of individual wires in a hardwired design.

What it complements: Modbus TCP and DNP3 still handle the monitoring layer — metering data, status polling, event logging. GOOSE handles the time-critical control path where polling latency is unacceptable. A typical data center critical power system uses both: GOOSE for protection interlocking (< 10ms), Modbus/DNP3 for SCADA monitoring (500ms-2s polling).

Why a prime contractor should care: GOOSE dramatically reduces panel wiring cost and commissioning time for complex interlocking schemes. But it introduces network infrastructure as a dependency in the protection path. The quality of the GOOSE publish/subscribe matrix and SCL file management determines whether the system is maintainable long-term. A poorly documented GOOSE implementation is harder to troubleshoot than hardwiring — because the “wires” are invisible.

Red flags from a sub:

• No GOOSE publish/subscribe matrix in the submittal. Without a pub/sub matrix documenting every message (publisher, subscribers, dataset name, mapped signals), the project has no GOOSE design — just a list of IEDs that happen to support 61850.
• “SCL files will be provided during commissioning.” SCL file management (ICD/CID/SCD exchange) requires upfront coordination between vendors and the system integrator. Deferring to commissioning means multi-week delays while engineers sort out dataset structures and naming conflicts on-site.
• No mention of VLAN configuration for GOOSE traffic. GOOSE uses Layer 2 multicast. Without dedicated VLANs and priority tagging (802.1Q priority 4), GOOSE competes with all other traffic on the network — monitoring, MMS, SNMP, everything.
• Claiming GOOSE experience but specifying single-vendor IEDs. Single-vendor GOOSE is straightforward — one engineering tool handles all SCL files. Multi-vendor is where the complexity lives: SCL exchange across different vendor tools with different import/export capabilities and naming conventions. Single-vendor-only proposals may indicate limited cross-platform experience.
• No defined fail-safe behavior on GOOSE communication loss. When a publisher goes offline, every subscriber needs an explicit fallback — hold last state, fail to a safe state, or alarm. Default behavior varies by vendor; without an explicit specification per subscription, each IED’s default governs and the system’s response to network or publisher failure becomes inconsistent and undocumented. A submittal with a complete pub/sub matrix but no fail-safe column is still incomplete.

Visual Explanation

Where GOOSE Sits in a Data Center Critical Power System

┌─────────────────────────────────────────────────────────────┐
│                     SCADA / HMI Layer                       │
│              (Operator displays, historians)                │
├────────────────────────┬────────────────────────────────────┤
│                        │  DNP3 / Modbus TCP                 │
│                        │  (monitoring, metering)            │
│                        ▼                                    │
│  ┌──────────────────────────────────────┐                   │
│  │        Gateway / RTAC                 │                   │
│  │    (protocol conversion, data        │                   │
│  │     aggregation, event logging)      │                   │
│  └──────────────┬───────────────────────┘                   │
│                 │  DNP3 / Modbus TCP                        │
│                 ▼                                           │
├─────────────────────────────────────────────────────────────┤
│           Substation LAN (PRP — dual redundant)             │
│                                                             │
│  ┌─────────┐  ◄── GOOSE ──►  ┌─────────┐                   │
│  │ Relay A │  (multicast,    │ Relay B │                   │
│  │ (SEL)   │   under 10ms,  │ (Wood-  │                   │
│  │         │   Layer 2)     │  ward)  │                   │
│  └────┬────┘                 └────┬────┘                   │
│       │                           │                         │
│       │  GOOSE                    │  GOOSE                  │
│       ▼                           ▼                         │
│  ┌─────────┐                 ┌─────────┐                   │
│  │ Breaker │                 │ Breaker │                   │
│  │ Ctrl C  │                 │ Ctrl D  │                   │
│  └─────────┘                 └─────────┘                   │
├─────────────────────────────────────────────────────────────┤
│           Physical Layer (fiber, managed switches)          │
└─────────────────────────────────────────────────────────────┘

KEY:
  ◄── GOOSE ──►  = Layer 2 multicast, sub-10ms, peer-to-peer
  │ DNP3/Modbus  = Layer 4-7 polled, 500ms-2s, client/server

GOOSE Retransmission with Exponential Backoff

Event: Relay A trips (state change)

Time ──────────────────────────────────────────────────►

  0ms   2ms   4ms   8ms   16ms         1000ms        1000ms
   │     │     │     │     │              │              │
   ▼     ▼     ▼     ▼     ▼              ▼              ▼
  [T1]  [T2]  [T3]  [T4]  [T5]   ...   [Tn]          [Tn+1]
   │                                      │              │
   StNum = 5                              StNum = 5      StNum = 5
   SqNum = 0  1     2     3     4        100            101

   ◄──── Fast burst ────►  ◄─── Exponential backoff ──► ◄─ Heartbeat ─►

  • StNum increments ONCE (state change)
  • SqNum increments on EVERY retransmission
  • Subscriber detects missed event if StNum jumps by >1
  • Subscriber detects publisher failure if heartbeat times out

GOOSE Frame Structure

┌──────────────────────────────────────────────────────────┐
│                    Ethernet Frame                         │
├──────────────┬───────────────────────────────────────────┤
│ Dest MAC     │ 01:0C:CD:01:XX:XX (multicast)            │
│ Src MAC      │ Publisher IED MAC address                 │
│ TPID         │ 0x8100 (VLAN tag)                        │
│ TCI          │ Priority (4) + VLAN ID                    │
│ Ethertype    │ 0x88B8 (GOOSE)                           │
├──────────────┼───────────────────────────────────────────┤
│              │         GOOSE PDU (ASN.1 BER)             │
│  APPID       │ Application identifier (2 bytes)          │
│  Length       │ PDU length (2 bytes)                      │
│  Reserved     │ 4 bytes (reserved for future)             │
├──────────────┼───────────────────────────────────────────┤
│  gocbRef     │ GOOSE Control Block reference             │
│  timeAllowed │ Max time between heartbeats               │
│  datSet      │ Dataset reference (what data is carried)  │
│  goID        │ GOOSE identifier string                   │
│  t           │ Timestamp of state change                 │
│  stNum       │ State number (increments on change)       │
│  sqNum       │ Sequence number (increments on retransmit)│
│  simulation  │ Boolean — test mode flag                  │
│  confRev     │ Configuration revision                    │
│  ndsCom      │ Needs commissioning flag                  │
│  numDatSet   │ Number of entries in dataset              │
│  allData     │ Dataset values (booleans, analogs, etc.)  │
└──────────────┴───────────────────────────────────────────┘

StNum / SqNum State Machine

Publisher State Machine:
                                ┌──────────────────┐
                                │                  │
                     Heartbeat  │                  │ State change
                     timeout    │                  │ detected
                        │       │                  │       │
                        ▼       ▼                  │       ▼
                    ┌──────────────┐          ┌──────────────┐
                    │   STABLE     │          │  BURST MODE  │
                    │              │──────────│              │
                    │ StNum = N    │  change  │ StNum = N+1  │
                    │ SqNum++      │──────►   │ SqNum = 0    │
                    │ interval =   │          │ interval =   │
                    │  heartbeat   │          │  min (2ms)   │
                    └──────────────┘          └──────┬───────┘
                          ▲                          │
                          │     interval doubles     │
                          │     each retransmit      │
                          │     until heartbeat      │
                          └──────────────────────────┘

Subscriber State Machine:
  ┌──────────┐  frame received   ┌──────────┐
  │ WAITING  │──────────────────►│ PROCESS  │
  │          │                   │          │
  │ timeout  │                   │ check    │
  │ watchdog │                   │ StNum    │
  │ running  │                   │ check    │
  └────┬─────┘                   │ confRev  │
       │                         └────┬─────┘
       │ timeout                      │
       ▼                              ▼
  ┌──────────┐                   ┌──────────┐
  │ FAIL-SAFE│                   │ UPDATE   │
  │          │                   │ DATA     │
  │ degrade  │                   │          │
  │ to backup│                   │ reset    │
  │ action   │                   │ watchdog │
  └──────────┘                   └──────────┘

Cheat Sheet

Parameter	Value
Ethertype	0x88B8
Multicast MAC range	01:0C:CD:01:00:00 — 01:0C:CD:01:01:FF
VLAN priority (recommended)	4 (high, below network control)
Max dataset entries	Vendor-dependent (typically 64-128)
Heartbeat interval (typical)	1000ms (configurable per GOOSE Control Block)
Min retransmission interval	2-4ms (vendor-dependent)
APPID range	0x0000 — 0x3FFF (must be unique per GOOSE Control Block on the network)
Encoding	ASN.1 BER (Basic Encoding Rules)
confRev	Must match between publisher and subscriber — mismatch = silent ignore

Performance classes (IEC 61850-5):

Class	Max Transfer Time	Use Case
P1	100ms	Non-critical monitoring, annunciation
P2	10ms	Protection interlocking, load shedding
P3	3ms	Busbar protection, breaker failure, ZSI

GOOSE PDU key fields:

Field	Purpose	Watch for
gocbRef	Identifies the GOOSE Control Block	Must match subscriber configuration exactly
datSet	Names the dataset being carried	Dataset structure mismatch = silent failure
stNum	State number — increments on value change	Jump > 1 = missed state change
sqNum	Sequence number — increments every retransmit	Gap = missed frame (usually acceptable)
confRev	Configuration revision	Publisher ≠ subscriber = subscriber ignores all frames
ndsCom	Needs commissioning flag	If true, subscriber should not act on data
timeAllowed	Max heartbeat interval (ms)	Subscriber uses this as watchdog timeout

Wireshark filters:

goose                                    # All GOOSE traffic
goose && eth.dst == 01:0c:cd:01:00:01   # Specific multicast group
goose.appid == 0x0001                    # Specific APPID
goose.stnum > 0                          # State changes only (skip initial)
goose.ndsCom == TRUE                     # Devices needing commissioning
goose.confRev != <expected>              # Configuration revision mismatch
eth.type == 0x88b8                       # GOOSE by Ethertype (alternative)

Quick test with libiec61850:

# Subscribe to GOOSE on interface eth0 — prints received GOOSE frames
goose_subscriber -i eth0

# Publish test GOOSE frame (for lab testing only)
goose_publisher -i eth0 --appid 0x0001 --gocbref "IED1/LLN0$GO$gcb01"

Best Practices

1. Dedicate a VLAN for GOOSE traffic Separate GOOSE from MMS, SCADA, and corporate traffic. GOOSE is multicast at Layer 2 — without VLAN isolation, GOOSE frames flood every port on every switch in the broadcast domain. Why: A GOOSE storm (misconfigured publisher flooding at minimum interval) on a shared VLAN can saturate switch backplanes and disrupt all traffic, including MMS polling and SCADA communication. If you don’t: Any GOOSE burst impacts all traffic on the same VLAN. A misbehaving IED can take down the entire monitoring layer.

2. Set QoS priority 4 for GOOSE VLANs Configure managed switches to honor 802.1p priority. GOOSE should be priority 4 (Video, below Network Control at 7 but above default at 0). This ensures GOOSE frames get switch queue priority over bulk MMS traffic. Why: During network congestion (large MMS file transfers, SCADA polling storms), GOOSE frames must not be delayed by lower-priority traffic in switch output queues. If you don’t: Under heavy MMS traffic, GOOSE latency can exceed the P2/P3 performance class budget, causing protection coordination failures that only appear under load.

3. Enforce APPID uniqueness across the entire network Every GOOSE Control Block must have a unique APPID on the network. Maintain an APPID allocation table in the system design documentation. Assign APPIDs systematically (e.g., by panel and IED number, not randomly). Why: Duplicate APPIDs cause subscribers to process frames from the wrong publisher. This is a silent, dangerous failure — the subscriber acts on data from the wrong device with no alarm. If you don’t: Two publishers with the same APPID create intermittent, load-dependent failures where the subscriber alternates between correct and incorrect data.

4. Manage confRev rigorously — increment on every configuration change The configuration revision (confRev) field must be incremented every time the dataset structure changes. Subscribers compare confRev against their configured value and silently ignore mismatches. Why: confRev mismatch is the #1 cause of “GOOSE is configured but not working” during commissioning. The subscriber is receiving frames but ignoring all of them because confRev doesn’t match. If you don’t: After any configuration change, subscribers silently stop processing GOOSE. No alarm, no error — just silent loss of protection.

5. Enable multicast filtering (IGMP snooping or static multicast groups) on all switches Without multicast filtering, every GOOSE frame is flooded to every port on the VLAN. With 20+ IEDs each publishing 2-4 GOOSE Control Blocks, this creates significant unnecessary traffic on every link. Why: Unfiltered multicast wastes bandwidth on ports where no subscriber exists and increases switch CPU load. On large networks, this can approach switch capacity limits. If you don’t: Every switch port receives every GOOSE frame on the VLAN, regardless of whether a subscriber exists on that port. This scales poorly with IED count.

6. Design fail-safe actions for every GOOSE subscription Every subscriber must define what happens when GOOSE communication is lost (heartbeat timeout). The fail-safe action depends on the application — typically reverting to time-delay coordination or blocking trip commands. Why: GOOSE loss means the subscriber no longer knows the publisher’s state. Acting on stale data or assuming a default state can cause misoperation. The fail-safe must maintain protection coordination without GOOSE. If you don’t: A network failure or publisher IED failure leaves subscribers in an undefined state. Depending on the application, this can cause nuisance trips, blocked protection, or loss of interlocking.

7. Establish naming conventions and SCL ownership before engineering begins Adopt a gocbRef and datSet naming convention that encodes the publisher IED name, protection function, and signal type — making every GOOSE message identifiable from its name alone without cross-referencing a spreadsheet. Define SCD file ownership early: one party owns the master SCD and is responsible for merging ICD files from each vendor. Ambiguous ownership leads to parallel XML edits that produce unresolvable merge conflicts. Documentation deliverables should include: a tabular pub/sub matrix (publisher, subscribers, dataset name, mapped signals, APPID, VLAN), final CID files per IED, VLAN configuration with GOOSE priority tagging documented per switch port, and heartbeat interval/timeout settings per subscriber pair.

Strengths, Weaknesses & When to Choose an Alternative

Strengths in Detail

Speed: GOOSE end-to-end latency is typically 2-5ms on a well-configured network — fast enough for protection-grade interlocking where Modbus (500ms+) and DNP3 (100ms+) are far too slow.

Simplicity of publish/subscribe: One publisher, many subscribers. Adding a new subscriber requires only configuring the new device — the publisher doesn’t need to change. This scales better than hardwired point-to-point connections where each new subscriber requires a new wire.

Redundancy via PRP: GOOSE frames naturally duplicate on PRP networks. The publisher sends on both LAN-A and LAN-B; the subscriber accepts the first and discards the duplicate. Zero-switchover time — no RSTP reconvergence, no packet loss during network failure.

Weaknesses in Detail

Layer 2 confinement: GOOSE cannot cross a router. Every device that publishes or subscribes to GOOSE must be on the same Layer 2 broadcast domain (VLAN). R-GOOSE (routable GOOSE, IEC 61850-8-2) exists in the standard but has minimal vendor support as of 2025.

Invisible complexity: Hardwired interlocking is physically traceable — you can follow a wire from terminal A to terminal B. GOOSE interlocking is configuration-based — a misconfigured dataset or wrong confRev produces silent failure with no physical indicator. Troubleshooting requires Wireshark and protocol knowledge.

Vendor interoperability gap: Despite IEC 61850 standardization, cross-vendor GOOSE requires careful SCL file exchange and testing. Each vendor’s engineering tool (SEL AcSELerator Architect, Woodward ToolboxST, ABB PCM600) has different SCL import/export capabilities and limitations.

Comparison Table

Criterion	GOOSE	Hardwired	Mirrored Bits (SEL)	DNP3
Latency	2-5ms	under 1ms (contact closure)	2-5ms	100ms+ (polled)
Cross-vendor	Yes (with SCL)	Yes (copper is universal)	SEL-only	Yes
Redundancy	PRP (zero-switchover)	Dual wiring	SEL failover	TCP redundancy
Scalability	Excellent (multicast)	Poor (1 wire per signal)	Good (within SEL)	Good (polled)
Troubleshooting	Wireshark + protocol knowledge	Multimeter	SEL tools	Wireshark
Infrastructure	Managed switches, VLANs, PRP	Copper wire, terminal blocks	SEL network	IP network
Documentation	SCL files, pub/sub matrix	Wiring diagrams	SEL config files	DNP3 point maps
Failure mode	Silent (config mismatch)	Visible (broken wire)	Silent (config)	Timeout + alarm

When to Choose an Alternative

• Hardwired: When there are fewer than 5 interlock signals, all within the same panel, and no future expansion is expected. The infrastructure cost of GOOSE (switches, VLANs, PRP) isn’t justified for a few wires.
• SEL Mirrored Bits: When the scheme is SEL-only (no cross-vendor requirement) and the speed requirement is met. Mirrored Bits is simpler to configure than GOOSE and doesn’t require SCL file management.
• DNP3: When the signal is not time-critical (>100ms acceptable) and needs to cross IP subnet boundaries. DNP3 unsolicited responses can carry binary status changes over IP — something GOOSE cannot do at Layer 2.

Biggest Pitfalls

1. Dataset mismatch after configuration change — subscriber silently ignores all frames A publisher’s dataset structure (number of entries, data types, order) must exactly match what the subscriber expects. After any configuration change to the publisher, the confRev must be incremented and the subscriber must be updated to match. If confRev doesn’t match, the subscriber silently ignores every frame — no alarm, no error, no indication that protection is lost. Prevention: After every configuration change, verify confRev matches on both sides. Include confRev verification in the commissioning checklist. Use Wireshark to confirm subscriber is actually processing frames (not just receiving them). Detection: goose.confRev in Wireshark — compare against subscriber’s configured confRev. Check subscriber’s GOOSE status/diagnostic register if available.

2. VLAN misconfiguration — GOOSE frames never reach the subscriber GOOSE is Layer 2 multicast. If the publisher and subscriber are on different VLANs, or if an intermediate switch isn’t configured to pass the GOOSE VLAN, frames are silently dropped. This is the most common commissioning failure for GOOSE. Prevention: Document the VLAN design before configuring any IEDs. Verify VLAN membership on every switch port in the GOOSE path. Use Wireshark on the subscriber’s switch port (mirror/span) to confirm frames arrive. Detection: Wireshark on the subscriber’s network segment — if you see no GOOSE frames with the expected APPID, it’s a VLAN/switching issue, not a GOOSE configuration issue.

3. Multicast storm from missing VLAN pruning Without proper multicast filtering (IGMP snooping or static groups), every GOOSE frame floods to every port on the VLAN. With 20+ IEDs, each publishing 2-4 GOOSE Control Blocks with heartbeats every 1000ms and burst retransmissions on state change, the aggregate multicast traffic can saturate 100Mbps links and overwhelm switch CPU. Prevention: Enable IGMP snooping or configure static multicast groups on all managed switches. Monitor switch CPU utilization during load testing. Use 1Gbps links (not 100Mbps) for GOOSE VLANs. Detection: Switch port statistics — check multicast frame counters. If every port shows the same multicast count, multicast filtering is not working.

4. No fail-safe action on GOOSE loss — subscriber continues operating on stale data When a GOOSE publisher fails or the network between publisher and subscriber is disrupted, the subscriber must detect the loss (heartbeat timeout) and execute a fail-safe action. If no fail-safe is configured, the subscriber continues using the last received GOOSE values indefinitely — which may be dangerously stale. Prevention: Define the fail-safe action for every GOOSE subscription in the protection coordination study. Common fail-safe actions: revert to time-delay coordination, block trip commands, or assert a default safe state. Test fail-safe behavior by disconnecting the publisher during commissioning. Detection: Simulate publisher failure during commissioning — disconnect the publisher’s network cable and verify the subscriber executes the defined fail-safe within the heartbeat timeout period.

5. Cross-vendor GOOSE fails after SCL file round-trip Cross-vendor GOOSE failure pattern: A dataset naming mismatch between the publisher’s ICD file (e.g., SEL) and the subscriber’s import (e.g., ABB PCM600) is one of the most common cross-vendor failures. PCM600 remaps dataset references during ICD import, silently altering the datSet string the subscriber expects. The result: the subscriber’s GOOSE status shows “active” — it is receiving frames — but it is subscribed to a dataset name that no publisher actually sends. Data quality stays “invalid,” and the protection logic falls back to its safe default (typically time-delay coordination instead of instantaneous GOOSE-based tripping). The failure is invisible from the subscriber’s front-panel display alone. Diagnosis requires a Wireshark GOOSE dissector capture on the subscriber’s network segment, comparing the actual goose.datSet field in received frames against the datSet string configured in both the publisher’s CID and the subscriber’s CID. The fix is aligning the dataset reference in the subscriber’s configuration to match exactly what the publisher transmits on the wire.

6. Cross-vendor GOOSE attribute mapping shifts after SCL round-trip — values look plausible but come from the wrong source A subtler cross-vendor failure than dataset-name mismatch. The publisher’s SCD encodes data attribute paths in one form; the subscriber’s tool imports and re-encodes them in a slightly different form. Dataset structure looks correct in both engineering tools and the data types align (boolean to boolean, integer to integer), but the attribute-to-attribute mapping has shifted by one — subscriber attribute 1 reads publisher attribute 2, attribute 2 reads attribute 3, and so on. The result is particularly insidious: GOOSE messages are delivered on time, the subscriber shows “active” status, data quality reads “valid,” and the values look plausible (real boolean states, just from the wrong source). No quality flag fires. Unlike Pitfall #5, there is no datSet mismatch to catch in Wireshark — the names align, only the bindings drift. Prevention: Lock SCL round-trip workflows to a single integrator-owned SCD file. When importing a vendor’s ICD into the master SCD, validate the attribute path encoding against the original ICD before re-exporting CIDs to subscribers. Detection: Point-by-point verification during commissioning — force a state change on one specific publisher attribute and confirm exactly one subscriber attribute changes, not its neighbor. Repeat for every dataset entry, not just the first.

Field Tips & Tools

Wireshark Setup for GOOSE Commissioning

Step 1 — Capture filter (reduce capture size):

ether proto 0x88b8

Step 2 — Display coloring (Edit → Coloring Rules):

• Green: goose && goose.stnum == 0 (initial/stable heartbeat)
• Blue: goose && goose.stnum > 0 && goose.sqnum == 0 (state change — first frame of burst)
• Yellow: goose && goose.sqnum > 0 (retransmissions — normal, but watch burst rate)
• Red: goose && goose.ndsCom == TRUE (device flagging “needs commissioning”)

Step 3 — Custom columns (right-click column header → Column Preferences):

Column Title	Field	Why
APPID	goose.appid	Identify which GOOSE Control Block this frame belongs to
gocbRef	goose.gocbRef	Human-readable publisher identification
StNum	goose.stnum	State changes — increments on value change
SqNum	goose.sqnum	Retransmission counter — resets on state change
confRev	goose.confRev	Configuration revision — mismatch = silent failure
Dataset	goose.datSet	Dataset being carried

Step 4 — Statistics (Statistics → IO Graph):

• Graph 1: goose — total GOOSE frames per second (baseline)
• Graph 2: goose && goose.sqnum == 0 — state changes per second (should be rare in steady state) Use this to verify heartbeat rate and detect storm conditions.

Testing Tools

Tool	Purpose	Platform
Wireshark	Capture, decode, and analyze GOOSE frames	All
libiec61850 (goose_subscriber/publisher)	Command-line GOOSE subscribe and publish — lab testing	Linux
Omicron IEDScout	Professional IEC 61850 browser — browse MMS data model and monitor GOOSE	Windows
SEL AcSELerator Architect	SEL SCL/configuration tool — builds ICD/CID files for SEL relays	Windows
Relay test sets (Omicron CMC, Doble F6150)	Inject analog/binary signals and monitor GOOSE simultaneously	Hardware

Commissioning Sequence

GOOSE commissioning sequence:

1. Verify network infrastructure first. Confirm VLAN configuration on every switch port in the GOOSE path, 802.1Q priority 4 tagging, and multicast filtering (IGMP snooping or static groups). Do not configure any IED GOOSE until the network is verified end-to-end.
2. Commission publishers one at a time. Enable each GOOSE publisher individually with a Wireshark capture running on a mirror/span port. Confirm the publisher is transmitting frames with the correct APPID, gocbRef, datSet, and confRev before moving to the next.
3. Verify subscriber reception. For each pub-sub pair, confirm the subscriber’s GOOSE data quality changes from “invalid” to “valid” when the publisher is active. Check the subscriber’s diagnostic registers or front-panel status for GOOSE-specific health indicators.
4. Test each pub-sub pair with forced signals. Inject test values at the publisher (forced binary outputs or simulated analog thresholds) and verify the subscriber receives the correct state change. Measure end-to-end latency — expect under 4ms for direct IED-to-IED, under 20ms through an RTAC or gateway.
5. Test failover behavior. Disable the publisher (pull the network cable or disable the GOOSE Control Block) and verify the subscriber detects heartbeat timeout within the configured interval and executes its defined fail-safe action (e.g., revert to time-delay coordination, block trip commands).
6. Document the as-commissioned state. Deliverables: final CID file per IED, Wireshark capture archive per pub-sub pair, annotated pub/sub matrix with measured latency values, and VLAN/switch configuration backup. This documentation package is the baseline for future troubleshooting and expansion.

Troubleshooting: “GOOSE Subscriber Not Receiving”

Subscriber not receiving GOOSE?
│
├── Can you see ANY GOOSE frames on the subscriber's switch port?
│   │
│   ├── NO → VLAN / switching issue
│   │   ├── Check VLAN membership on subscriber's switch port
│   │   ├── Check trunk ports between switches carry the GOOSE VLAN
│   │   ├── Check publisher is actually transmitting (Wireshark on publisher port)
│   │   └── Check cable/SFP — Layer 1 failure
│   │
│   └── YES → GOOSE configuration issue
│       │
│       ├── Does APPID match?
│       │   └── NO → Fix APPID in subscriber configuration
│       │
│       ├── Does gocbRef match?
│       │   └── NO → Fix gocbRef in subscriber configuration
│       │
│       ├── Does confRev match?
│       │   └── NO → Update confRev in subscriber to match publisher
│       │
│       ├── Does dataset structure match?
│       │   └── NO → Regenerate SCL files, re-import into subscriber
│       │
│       └── All match but still not working?
│           ├── Check multicast MAC address filtering on subscriber
│           ├── Check subscriber GOOSE diagnostic registers
│           └── Check IED firmware version compatibility

Deep Dive

Protocol Stack

GOOSE operates directly on IEEE 802.3 Ethernet — no IP, no TCP, no UDP. This is deliberate: eliminating the IP and transport layers removes their processing overhead and jitter, achieving deterministic latency.

┌────────────────────────────┐
│   IEC 61850 Application    │  ← Protection logic, interlocking
├────────────────────────────┤
│   GOOSE Encoding (ASN.1)   │  ← IEC 61850-8-1, BER encoding
├────────────────────────────┤
│   IEEE 802.3 Ethernet      │  ← Ethertype 0x88B8
│   + IEEE 802.1Q VLAN tag   │  ← Priority 4, GOOSE VLAN ID
├────────────────────────────┤
│   Physical (fiber/copper)  │  ← Typically 100Mbps or 1Gbps
└────────────────────────────┘

NOT present (by design):
  × IP layer (no routing)
  × TCP/UDP (no transport)
  × TLS/SSL (no encryption in Edition 1)

Timing and Latency Budget

IEC 61850-5 defines three performance classes for GOOSE messages. The total transfer time is the sum of processing and network delays:

Total GOOSE Transfer Time =
    Publisher encoding time        (~0.5-1ms)
  + Switch forwarding delay        (~0.01-0.1ms per hop)
  + PRP duplicate handling         (~0.01ms)
  + Subscriber decoding time       (~0.5-1ms)
  + Application processing time    (~0.5-2ms)
  ─────────────────────────────────
  = Typical total: 2-5ms (P2/P3 capable)

Performance Class	Max Transfer Time	Typical Use
P1	100ms	Annunciation, non-critical status
P2	10ms	Fast load shedding, interlocking
P3	3ms	Busbar protection, breaker failure

Verification method: Inject a state change at the publisher (e.g., simulate a trip condition with a relay test set), capture the GOOSE frame at the publisher port and the subscriber port using Wireshark with hardware-timestamped capture (e.g., Profishark). The difference is the network transfer time. Add application processing time (measured from relay test set — time from GOOSE arrival to subscriber output contact).

ASN.1 BER Encoding

GOOSE payloads use ASN.1 Basic Encoding Rules (BER), not the compact binary encoding used by protocols like Modbus. Each data element is encoded as a Type-Length-Value (TLV) triplet:

Each dataset entry:
┌──────────┬──────────┬──────────────────┐
│ Tag (1B) │ Len (1B) │ Value (variable) │
└──────────┴──────────┴──────────────────┘

Common tags:
  0x83 = Boolean (1 byte value: 0x00 or 0xFF)
  0x84 = Integer (variable length)
  0x85 = Unsigned integer
  0x87 = Floating point (IEEE 754)
  0x89 = Octet string
  0x8A = Visible string
  0x91 = UTC time

This encoding is self-describing but larger than compact binary. A dataset of 32 boolean values requires ~96 bytes of ASN.1 encoding (vs. 4 bytes in a packed binary format). For protection-speed GOOSE with small datasets, this overhead is negligible. For large datasets, it increases frame size and marginally increases encoding/decoding time.

Security Model

Edition 1 (IEC 61850:2003/2011): No built-in security. GOOSE frames are unauthenticated and unencrypted. Any device on the VLAN can publish frames with any APPID, and subscribers will accept them. This is mitigated by:

• VLAN isolation (physical separation of GOOSE traffic)
• IEEE 802.1X port-based access control (only authorized devices connect)
• Physical security of the substation LAN

IEC 62351-6: Defines authentication for GOOSE using digital signatures (HMAC-SHA256 or RSA). The signature is appended to the GOOSE PDU in the reserved fields. This prevents frame injection and replay attacks. However, as of 2025:

• Vendor support is limited (some SEL and ABB devices support it, many do not)
• Key distribution and certificate management add operational complexity
• Performance impact of signature verification may affect P3 latency budgets

Edition 2 (IEC 61850:2020+): Incorporates IEC 62351-6 security as a mandatory capability (not mandatory to enable, but mandatory to support). Also introduces R-GOOSE (routable GOOSE over UDP/IP) for inter-substation communication.

Interoperability

IEC 61850 Edition 1 vs. Edition 2: Edition 2 extended the data model and added new logical node classes. GOOSE encoding is backward-compatible, but extended datasets from Edition 2 publishers may not be parseable by Edition 1 subscribers. Always verify edition compatibility between devices.

Conformance testing: The UCA International Users Group (UCAIUG) maintains an IEC 61850 conformance testing program. Devices with UCAIUG conformance certificates have been tested for basic GOOSE publish/subscribe interoperability. However, conformance does not guarantee interoperability with every other conformant device — it guarantees protocol encoding/decoding correctness.

Cross-vendor reality: Even with conformant devices, cross-vendor GOOSE requires:

1. ICD file export from each vendor’s tool
2. SCD file assembly (often manual, sometimes with a system-level tool)
3. CID file generation and import back into each device
4. Round-trip testing — the SCL file exchange process can introduce errors that only manifest at runtime

PRP Interaction

GOOSE over PRP (IEC 62439-3) provides seamless network redundancy:

Publisher IED (DANP)
    │
    ├── LAN-A: GOOSE frame + RCT trailer (SeqNr, LanID=A)
    │          │
    │          ▼
    │     Switch A ──► Subscriber IED (DANP)
    │                       │
    │                       ├── Receives LAN-A frame first → ACCEPT
    │                       │
    └── LAN-B: GOOSE frame + RCT trailer (SeqNr, LanID=B)
               │            │
               ▼            ├── Receives LAN-B frame second → DISCARD (duplicate)
          Switch B ─────────┘

RCT = Redundancy Control Trailer (6 bytes appended after GOOSE payload)
DANP = Doubly Attached Node with PRP
SeqNr = PRP sequence number (independent of GOOSE SqNum)

Key behaviors:

• The publisher sends identical GOOSE frames on both LANs with PRP trailers
• The subscriber accepts whichever arrives first and discards the duplicate
• If one LAN fails, the other continues delivering GOOSE with zero switchover delay
• No protocol modification needed — PRP is transparent to GOOSE
• SAN (Singly Attached Node) devices on one LAN still receive GOOSE but without redundancy

Edge Cases

confRev mismatch handling: Per IEC 61850-8-1, a subscriber that receives a GOOSE frame with a confRev different from its configured value SHALL ignore the frame. This means a publisher configuration change immediately and silently breaks all subscribers. There is no “negotiate” or “fallback” — it’s all-or-nothing.

stNum wraparound: stNum is a 32-bit unsigned integer. It wraps around to 0 after 4,294,967,295 state changes. Most implementations handle this correctly, but custom subscriber logic that uses stNum > lastStNum for change detection will fail at wraparound. Use modular arithmetic or detect the specific wraparound condition.

Network partition: If the network partitions (e.g., a switch fails creating two isolated segments), subscribers on the other side of the partition will time out and enter fail-safe. When the partition heals, subscribers resume processing GOOSE frames. However, any state changes that occurred during the partition are lost — the subscriber sees only the current state after reconnection, not the history of changes.

Simulation mode: The simulation flag in the GOOSE PDU allows publishers to mark frames as “test” data. Subscribers configured to reject simulation frames will ignore them. This is used during commissioning to test GOOSE communication without triggering real protection operations. However, not all vendor implementations honor this flag consistently — always verify simulation mode behavior during factory acceptance testing.