GOOSE Messaging on SEL RTAC
for Protection Schemes

01 — What GOOSE is (the practical version)

GOOSE stands for Generic Object Oriented Substation Event. It is defined in IEC 61850-8-1 as the layer-2 multicast protocol that carries time-critical messages between substation devices over Ethernet. The practical short version: it is how one relay tells another relay "I just tripped" or "I see a fault on my zone" without going through TCP, without routing through a SCADA system, and without waiting on a polling cycle.

GOOSE messages are Ethernet multicast frames with a specific EtherType (0x88B8). They are not IP. They do not route. They live on the local LAN segment. A subscriber receives the message at line speed, which on a 100 Mbps switch with quality of service set up correctly is a fraction of a millisecond.

GOOSE has a retransmission scheme that is worth understanding. When a signal does not change, the publisher sends a heartbeat every few seconds (the "long" interval, typically 1–5 s). When a signal changes state, the publisher sends a burst of frames at decreasing rates — first frame immediately, then again at a few milliseconds, then a few tens of milliseconds, gradually backing off until the long interval resumes. This means a state change is hammered onto the network multiple times in quick succession so that even if one frame is lost, the next one will be received.

02 — The RTAC as a GOOSE publisher and subscriber

The SEL RTAC supports both publishing and subscribing to GOOSE messages, configured in AcSELerator RTAC. You add a GOOSE publisher block, define the dataset (the list of values to publish), give it a multicast MAC address, an AppID, and a configuration revision. On the subscriber side you import the publisher's IED Capability Description (ICD) file or manually configure the subscription.

Three things you have to get right on every GOOSE configuration. I'll show you what each one looks like when it's broken, because the failure modes are silent — no alarm fires, the data is just wrong.

GoID mismatch — the silent zero

What it looks like. You build the subscription, push the config, and the AcSELerator diagnostic page shows the subscription as configured. Green dots all around. But the GOOSE input on your protection logic stays at zero. The received-frame count for that subscription stays at zero while the stale-message timer climbs. No alarm tells you anything is wrong — from the RTAC's point of view, no frame ever arrived that matched the subscription, which is not an error condition.

How to find it. Capture on a span port with Wireshark filtered on EtherType 0x88B8. You will see the publisher sending frames at the heartbeat interval just fine. Read the GOOSE Identifier field in the captured frame and compare it byte-for-byte to the GoID configured in the subscription. The usual cause is a case-sensitive string mismatch — Plant_Main_52a on the publisher side and plant_main_52a in the subscription. Both look identical on a scan and the field tech didn't catch it. Trailing whitespace also bites here.

How to fix it. Edit the subscription's GoID to exactly match the publisher's. Push the config. The frame count starts incrementing immediately if it was a string mismatch — you don't need to restart anything.

AppID collision — cross-subscribed garbage

What it looks like. You configured two RTACs to publish GOOSE on the same protection VLAN. Both got left at the default AppID 0x0001 because the field tech didn't change it. Now RTAC-B's subscribers occasionally pick up data that looks like it came from RTAC-A — breaker states flip to the wrong values, fault flags assert on the wrong feeder. The behavior is intermittent because it depends on packet timing and the order subscribers process duplicate frames. No error, no alarm. The relay just trips into a fault that isn't on its feeder.

How to find it. Same Wireshark capture, EtherType 0x88B8. Filter further by APPID and look at how many unique publisher MAC addresses are sending frames with the same APPID value. If you see two, you have a collision. Some site conventions assign APPID = last octet of publisher IP, which makes collisions impossible by construction; others assign APPIDs from a managed range in the substation engineering binder. Both work.

How to fix it. Assign unique APPIDs to every publisher on the protection VLAN. Push configs. Re-capture. Verify each publisher's APPID is unique. Don't skip the re-capture step — if the project file gets pushed but the controller doesn't actually pick it up (compile error nobody noticed, wrong project loaded), you'll think it's fixed when it isn't.

ConfRev mismatch — parsing the wrong field

What it looks like. Worse than the other two. You added a value to the GOOSE dataset on the publisher — say, you added BreakerOverloadFlag as a fifth boolean. You forgot to bump the ConfRev. Subscribers using the old ConfRev keep their old dataset definition. The fifth element gets dropped on receipt. So far so good. But on some subscriber implementations, adding a member shifts the binary positions of fields that come after it, and the subscriber that didn't get the ConfRev bump now parses the wrong bits into the wrong field. Your "52a closed" status starts coming through as "fault active" because the bytes line up differently in the new dataset.

How to find it. Compare the ConfRev value reported in the captured frame against the ConfRev shown in the subscription configuration. If they differ, your subscribers are out of sync with the publisher. The diagnostic page in AcSELerator RTAC will sometimes flag this as a configuration revision mismatch warning, but not always — some implementations only check ConfRev on subscription activation, not on every frame.

How to fix it. Always bump ConfRev on the publisher when you change the dataset. Always re-import the publisher's ICD/CID file into every subscriber project after a dataset change. Push configs to all subscribers. Never edit the dataset on a live plant without re-importing the CID into every subscriber that uses it.

The RTAC ICD/CID file describes its own GOOSE publications. The proper way to configure a subscription is to import the publisher's ICD/CID file into your subscriber project. AcSELerator RTAC does this with the System Configurator. Manual configuration is possible but it is error-prone — the field names, data types, and order all have to match the publisher exactly. Use the file import.

03 — Real use case 1 — trip blocking

The classic GOOSE use case on a solar plant: the substation feeder relay needs to block its trip when the plant breaker is already open. Without coordination, a fault on the utility side could cause the feeder relay to trip into a plant that has already isolated itself, which is unnecessary and adds to outage duration.

The pattern: the plant main breaker IED publishes a GOOSE message containing "main breaker status" (52a). The feeder relay subscribes to it. When 52a goes low (breaker open), a trip block bit is asserted in the feeder relay's protection logic. The feeder relay still sees the fault but holds its trip decision.

The RTAC fits in this picture as the aggregator. It subscribes to GOOSE from every breaker IED on the plant, runs a logical OR or AND across them, and republishes a single composite "plant isolated" status that the utility-side equipment subscribes to. This keeps the utility relay subscribed to one GOOSE message instead of fifteen.

04 — Real use case 2 — anti-islanding

Anti-islanding is the requirement that the plant must shut down within a defined window after the utility source disappears, so that linemen working downstream are not exposed to backfeed from the inverters. IEEE 1547-2018 specifies the trip times based on voltage and frequency excursion.

GOOSE accelerates the deterministic side of this. The utility-side disconnect (recloser, tie breaker, or transmission relay) publishes a GOOSE message when it opens. The plant RTAC subscribes, and on assertion sends an immediate stop command to every inverter via Modbus and an open command to the plant main breaker. This is the "direct transfer trip" replacement that has gone GOOSE on most utility-scale plants built in the last five years.

The pure passive anti-islanding (voltage and frequency detection at the inverter) still runs as a backup. GOOSE gives you a deterministic trip in under 50 ms; passive detection eventually catches it within a few hundred ms based on grid impedance change. You want both.

05 — Real use case 3 — breaker-fail backup

Breaker-fail is the protection scheme that says "if I commanded a breaker to trip and it did not actually open within X cycles, trip the next breaker upstream." Traditionally this is implemented inside the relay that owns the breaker. On a plant with multiple breakers, you want the breaker-fail decision to propagate up the chain.

GOOSE makes this clean. Each breaker IED publishes its "breaker fail timer expired" bit. The next-upstream relay subscribes and uses it as a transfer-trip input. The RTAC can also sit in the chain — subscribing to multiple BF signals, running an OR, and republishing a single transfer-trip GOOSE to the utility tie breaker. Same aggregation pattern as the trip-blocking case, applied to BF.

06 — GOOSE vs hardwired — when to use which

This is the question that comes up on every commissioning. The honest answer is "both, for different things."

The pattern I have seen work on multiple plants: GOOSE for everything that propagates a status or a blocking signal between IEDs, hardwired for every trip path that actually opens a breaker. The RTAC participates in the GOOSE layer for status aggregation and republishing, but never sits in a critical trip path on its own.

07 — Network design that does not lose GOOSE

GOOSE depends on the Ethernet network getting the message there fast and reliably. The network design has to support that. A few non-negotiable points:

• Dedicated VLAN for protection traffic. Keep GOOSE off the same VLAN as DNP3, Modbus, engineering access, and SCADA. Tag the protection VLAN and prioritize it.
• QoS / 802.1p priority on protection frames. GOOSE frames carry a priority tag (usually 4 or higher). The switches have to honor it. On a congested switch, an unprioritized GOOSE frame can be queued behind a Modbus burst and miss its window.
• Redundant network paths. PRP (Parallel Redundancy Protocol) or HSR (High-availability Seamless Redundancy) for any GOOSE path that carries a real protection function. RSTP is acceptable for status-only schemes but adds reconvergence delay on a link failure.
• Managed switches only. No unmanaged consumer-grade switches in the protection LAN. Period. You need the ability to set port priorities, mirror traffic for debug, and lock down which MAC addresses can publish on which port.
• Multicast filtering. Configure IGMP snooping or static multicast filtering so that GOOSE frames only reach the switch ports that actually have subscribers. This keeps traffic clean and makes debug easier.

The RTAC has two independent Ethernet ports that can be configured for PRP. The two ports go to two physically separate switches. The RTAC sends every GOOSE frame on both ports; subscribers receive on whichever arrives first and ignore the duplicate. This is the standard redundancy pattern on utility-scale plants.

08 — Commissioning checklist for GOOSE on the RTAC

This is what I actually run through during commissioning before declaring GOOSE working.

1. Import every publisher's ICD/CID file into the subscriber project. Do not type fields manually.
2. Verify GoID, AppID, multicast MAC, and ConfRev match between publisher and subscriber. Mismatched ConfRev is the number one cause of "GOOSE configured but not receiving."
3. Use Wireshark on a span port to capture the actual GOOSE frames. Confirm the publisher is sending heartbeats at the long interval, and that state-change bursts trigger when you assert the source signal.
4. Force a state change on the publisher (open a breaker, simulate a trip, toggle a control input). Verify the subscriber's GOOSE input updates on the RTAC tag and the protection logic responds.
5. Pull the primary network cable. Confirm that with PRP or HSR, the GOOSE keeps flowing on the redundant path with no loss. Without redundancy, confirm the subscriber alarms on stale GOOSE within the long interval.
6. Check the RTAC's GOOSE diagnostics — AcSELerator RTAC shows received-frame count, last-update time, and stale-message alarms for every subscribed GOOSE. Confirm all are green.
7. End-to-end timing test — force a publisher state change while logging the subscriber's response. Total propagation should be under 20 ms for a properly tuned scheme. If you are seeing 100+ ms, your priority tagging or switch QoS is wrong.
8. Document the GoIDs, AppIDs, and multicast MACs in the commissioning binder. Next person on site will need them.

← Back to the SEL RTAC PPC design article · GridConnect Library vs Custom ST →