For a relay of one brand to receive the GOOSE of another, both must be described in the same SCD file: the publisher with its dataset and control block, and the subscriber with the subscription to each data item. The VLAN, multicast address, APPID, configuration revision and dataset structure must also match, and both must understand the same IEC 61850 edition or a compatible one.
Why it is not enough for both to say «IEC 61850»
GOOSE is the same message in every brand: a multicast Ethernet frame defined in IEC 61850-8-1. Interoperability, however, does not lie in the frame but in the configuration. The subscriber only accepts a GOOSE if it matches exactly what it expects, and what it expects is defined by a file someone had to build with both devices in it.
In practice, multi-vendor exchange fails less because of the hardware than because of the engineering. The interoperability tests of the UCA International Users Group point the same way: most multi-vendor problems show up in the SCL files.
How GOOSE works (stNum, sqNum, time allowed to live and retransmission) is covered in IEC 61850 GOOSE, and its role next to MMS in GOOSE vs MMS in IEC 61850. This guide deals with what changes when publisher and subscriber come from different manufacturers.
What it takes
| Requirement | Why it matters |
|---|---|
| ICD or IID file of each relay | Describes what each device can do; without it, the system configurator cannot include it |
| A common SCD | It is the only place where publisher and subscriber know each other |
| Compatible edition | An Edition 1 device and an Edition 2 device can coexist, but the SCD must be exported so that both accept it |
| Dataset with a structure the subscriber accepts | Some devices only accept datasets built attribute by attribute, or limit how many data items they can subscribe to |
| Multicast address, VLAN, priority and APPID | The subscriber filters on them; a different value on either side means receiving nothing |
| Configuration revision (confRev) | If the publisher changes its dataset, the revision changes, and a subscriber with the previous version discards the message |
| A network that carries it | Switches must pass the GOOSE VLAN on every port along the path |
| Logic in the subscriber | Receiving the data is not enough: it has to be connected to the function that uses it, with a defined behavior if the message is lost |
The files and their roles are in IEC 61850 SCL files, and the tool that merges them into a single file in IEC 61850 system configurator. To plan the multicast addresses and APPIDs of each stream without repeating them, you can use our free GOOSE and SV addresses tool.
The workflow, at a high level
- 01Files of each relayICD or IID exported by each manufacturer's tool
- 02Common SCDThe system configurator defines the dataset, the control block and the subscriptions
- 03Configuration of each relayEach tool imports the SCD and generates its download file
- 04NetworkVLAN and priority enabled along the path
- 05TestPublication, reception, subscriber logic and loss of the message
The critical part is the way back: if one of the manufacturer tools modifies the dataset or the control block when importing the SCD, the change must go back to the system configurator. If it does not, the SCD and what is loaded in the relays diverge, and the failure shows up months later, during an extension.
Typical multi-vendor problems
- The subscriber does not see the message. The VLAN is not allowed on some port, or the subscriber expects a different APPID or multicast address.
- It sees it but discards it. The configuration revision or the dataset structure does not match its configuration. It is the symptom of a CID that did not come from the current SCD.
- Data types do not match. For example, the publisher sends a double-point position and the subscriber logic expects a Boolean, or the dataset includes quality and the subscriber does not expect it.
- Test or simulation mode. A publisher in test mode or with the simulation bit set may be ignored by a subscriber that is not in the same mode.
- Subscriber limits. Some IEDs accept a limited number of messages or subscribed data items. Check this before designing the scheme.
- Loss supervision. If what the logic does when the GOOSE is lost is not configured, a network failure can block an interlock or, worse, let a switching operation through.
Step-by-step diagnosis of a GOOSE that does not arrive is in GOOSE not arriving or arriving late, and the simulators and analyzers for testing it in IEC 61850 test tools.
Before buying: what to check in the manufacturer’s documents
Many problems can be anticipated at the purchasing stage by reading the conformance documents each manufacturer publishes for its IED:
- IEC 61850 edition supported by the device and its conformance certificate per IEC 61850-10.
- How many GOOSE messages it can publish and how many it can subscribe to, and how many data items per message.
- Which dataset structures it accepts when subscribing: individual attributes or complete objects.
- How it treats quality and test mode of received messages.
- Which tool exports and imports its SCL files and which version is needed.
With that information at hand, the GOOSE scheme is designed around what the devices can do, instead of discovering their limits during commissioning.
How it is tested
During commissioning each stream is verified end to end with both real relays and the final network:
- the publisher changes the data and the subscriber acts within the expected time;
- the quality value and the mode on each side are as intended;
- when the message is cut, the subscriber detects the loss and the logic takes the safe value;
- the configuration revision of each relay matches the one in the delivered SCD.
When the GOOSE carries trips, testing of the complete protection is described in protection testing with GOOSE and Sampled Values.
When one of the two ends is not available, it is simulated with an IEC 61850 test tool or with the injection test set, which can publish and subscribe to GOOSE.
Most common uses
- Breaker failure (50BF) trip between the relay of one bay and those of the adjacent bays.
- Disconnector positions for GOOSE interlocking.
- Blocking signals in logic selectivity between feeder and bus relays.
- Extensions of existing substations, where the new relays are often of a different brand from those installed.
We configure your GOOSE exchange
At Tiza Group we configure GOOSE between relays and controllers of the main brands, in medium, high and extra-high voltage substations and in industry. With remote relay configuration we review the SCD, configure each relay and verify the streams remotely, with your technician on site, anywhere in the world. If you prefer the complete job in the field, see IEC 61850 configuration, in Colombia, or elsewhere on request.
Related guides
- IEC 61850 GOOSE: how it works, stNum, sqNum and testing
- IEC 61850 SCL files
- IEC 61850 Edition 1, 2 and 2.1
- GOOSE not arriving or arriving late
- VLAN and IEEE 802.1Q priority
- Top-down and bottom-up IEC 61850 engineering
- Substation automation system (SAS): functions and levels
- IEC 61850 test mode: Mod, Beh, Sim and the test bit
- IEC 61850 traffic in Wireshark: what a capture reveals
- Breaker failure 50BF (RBRF): what it is and how it works
References
- IEC 61850-6, SCL configuration language.
- IEC 61850-7-2, GOOSE services of the abstract model.
- IEC 61850-8-1, mapping of GOOSE to ISO/IEC 8802-3.
- IEC 61850-10, conformance testing.
- UCA International Users Group, IEC 61850 interoperability test (IOP) reports.
Frequently asked questions
Why does the subscribing relay not receive the GOOSE if I can see it on the network?
Because the subscriber compares the message with what it expects from its configuration: control block reference, identifier, configuration revision, dataset and its structure. If any of them differs, it discards the message. The usual cause is that the CID loaded in one of the two does not come from the current SCD.
Can IEC 61850 Edition 1 and Edition 2 relays be mixed with GOOSE?
Yes, in many cases, but you have to plan how the SCD is exported for the Edition 1 device and verify that data types and the new features, such as subscription supervision or simulation mode, are handled consistently on both sides.
Is the same software needed to configure both relays?
No. Each relay is configured with its manufacturer's tool, and a system configurator builds the SCD with both. What matters is that both tools read and write compatible SCL files and that changes go back to the SCD.