Pitfall with GOOSE subscription in DIGSI 4.90

We like Siemens IEDs and do often reference DIGSI configuration tool as a very deliberate instrument to configure IEC 61850 communications. But having updated to version 4.90 of the tool, we encountered a pitfall in configuration of GOOSE communications. We have managed to understand and resolve a problem, only having looked into SCD file. We decided to tell the story so that other engineers do not waste their time (because it is always what we lack).

Jan. 18, 2016, 1:22 a.m. | 2453

First of all, we must say that one can encounter the problem if configuring SIPROTEC to receive a GOOSE message from an IED of other vendor. Another condition – there is a time stamp in the expected dataset (note that we haven’t checked any other combinations besides those with the time stamp).

IEC 61850 station has become some sort of stand-alone application and external IEC 61850 devices are now added to the project in station itself.

Having updated to the new version of DIGSI, we have noticed that the way of using IEC 61850 has changed. IEC 61850 station became some sort of stand-alone application. Now external IEC 61850 devices (not Siemens) are added to the project after the IEC 61850 station is opened (before that – user could add them straight in the general project environment of DIGSI as Other IEC 61850 Communicator). We will not dive into details how to create a project in DIGSI and how to add an IEC 61850 station. We suppose that you have already done this and you need to add an external IED, which GOOSE dataset includes stVal, q and t data attributes. Let this external IED be Alstom Grid relay.

We exported Alstom Grid CID file from Alstom’s configuration tool. Prior to its import in DIGSI IEC 61850 station, let’s have a look at it. Is our GOOSE message there? What is the dataset?

As you can see everything is fine. Let’s open IEC 61850 station, take this file and add Alstom IED. Station already included One Siemens IED which is 7SJ80. In GOOSE tab we subscribe Siemens IED to receive aforementioned GOOSE message from Alstom IED. Done. Now we update configuration, update IEC 61850 station and load configuration to Siemens IED.

We expect everything to work fine. But no. There is no communication though Alstom Grid IED is sending GOOSE message, Ethernet switch is transparent (no specific VLANs are set, multicast filtering is disabled). We spent several hours actually to get the solution.

To understand the reason why there is no communication, we have to take a look at SCD file. It has to be exported from IEC 61850 station (Export – IEC 61850 station). Then we open it in some text editing tools, preferably one which understands XML syntax. We search for subscription section in SIPROTEC data model (Inputs section, ExtRef). We see the following:

If you are attentive enough you will see that Siemens internal stVal is bound to the signals of the incoming GOOSE message twice: first time it is bound to external stVal; second time – the very same Siemens stVal is bound to time stamp data attribute from GOOSE. Looks like DIGSI doesn’t handle subscription with time stamp attribute in a proper way.

But there is good news – this can be fixed manually. We do this in a following way:

Then we go back to IEC 61850 station and import fixed SCD file in it. Okay, now it works fine. Sometimes it is nice to understand specifics of SCL files. Take care.

UPD: This issue was fixed in V5.10 released 2015

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.

When GOOSE can't fly!
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.

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.