When GOOSE can't fly!

Everyone who ever dealt with the commissioning of IEC 61850 based systems had situations when there were problems in establishing successful GOOSE communications between IEDs. The reasons for that are always different. There may be a fault of the commissioning engineer, a fault of the vendor or it may be a fault of both parties at the same time. We have faced such situation recently and this was the case when one could blame... decide yourself who is to blame in this situation, having read this note about nuances in configuring GOOSE-communications between IEDs of two different vendors.

Jan. 25, 2021, 11:24 a.m. | 668 Инжиниринг (SE)

We have faced this issue during one of our trainings where we traditionally have quite intensive hands-on sessions. Each hands-on session is accompanied with detailed configuration guidelines, which describe the task and configuration process itself. There was a small error in one of the tasks on configuring GOOSE publishing - destination MAC-address for published GOOSE message was specified as 01-0с-cd-04-05-05. No one paid attention at this value in the beginning. But was there really something wrong?

IEC 61850 defines recommendations on destination MAC-address selection for GOOSE and Sampled Values messages. The recommended range for GOOSE messages is: 01:0C:CD:01:00:00 - 01:0C:CD:01:01:FF; for Sampled Values: 01:0C:CD:04:00:00 - 01:0C:CD:04:01:FF. The recommended value of the fourth octet for GOOSE and Sampled Values messages is different (01 and 04, correspondingly). For the second and third octet the recommended value is 0C and CD correspondingly (both for GOOSE and Sampled Values). But all these values are not obligatory, but recommended ones. On the other side, the value of the first octet has mandatory value of 01 as GOOSE and Sampled Values are multicast frames and addresses begin with a hexadecimal 01 in the first byte.

Having configured IED A, it started publishing GOOSE-messages with destination MAC-address equal to 01-0с-cd-04-05-05. Subscription for this GOOSE-message has been configured on IED B. And now it was time to test if it worked. But GOOSE communications didn't work. At the same time IED B configuration tool or its diagnostics showed no inconsistencies or errors. We started to check all the parameters: confRev and NdsCom values, inclusion of quality in a dataset and its current status and etc. All was good. And then we came to destination MAC-address. We spotted that the fourth octet of the address was different from what is recommended by the standard for GOOSE and changed the value to the recommended one. And it worked. It is very sad that if for IED B as a subscriber it was important, why it didn't issue a warning when we imported SCD file to IED B configuration tool and made this subscription. Another sad thing is that when we configured IED A to publish GOOSE-message with the destination MAC-address out of recommended range it also didn't issue a warning.

We went further and started to experiment with the publishing IED configuration. We changed the second and the third octet of destination MAC-address to the value out of recommended range. It was taken by the IED without any warnings. And then we decided to make GOOSE-messaging unicast - and it also worked and IED started publishing unicast GOOSE. Again without any warnings.

Just imagine that all this could happen during the commissioning or, what even worse, during maintenance procedures? How much time it could take to find and resolve the issue for unexperienced engineer?


It is reasonable to make the verification of SCD configuration files with the independent tools, not with the tools where these configuration files are created. The example, presented in this note, clearly shows that otherwise the only victim of the situations is an engineer.

Latest blog posts

Disrespectful Sampled Values subscriber behaviour
Disrespectful Sampled Values subscriber behaviour

Teaser: Some IEDs require that SV (or maybe GOOSE) messages on ingress port of the IED have proper VLAN tag (as configured in the subscription), thus resulting in failure to receive the untagged messages (or messages with another VLAN ID tag). Such behaviour of an IED is wrong but sometimes you can meet this. Read the full article to dig into the details.

Transmission of data structures in a GOOSE message
Transmission of data structures in a GOOSE message

GOOSE-messaging has been covered a lot in many technical papers and to add anything valuable to the subject is rather difficult. But we will try. And functional constrained data will help us with that.

Quality Assurance requirements and experiences for GOOSE/SV configuration

The paper describes our experiences in applying quality assurance principles during the off-line SCL engineering phase independent of the engineering tool or Excel files used. These principles include requirements for inspection, visualisation and detailed analysis of the configuration of the GOOSE and SV communication all directly from the SCL files. The results of these processes are presented in regards to optimised data flow, identification of unpublished or unsubscribed GOOSE/SV, restriction of use of generic Logical Nodes and generic signal names ensuring better overall performance and reliability.