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.
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?
Conclusions
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.
