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. | 1620

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.

Latest blog posts

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.

Software Based Centralized Protection: commissioning experience
Software Based Centralized Protection: commissioning experience

In 2018 Tekvel signed several contracts to commission centralized protection system based on servers and independent software. In this article we would like to share our experience and discuss some of the problems, that might require special attention from utilities on the way to mass deployment of centralized PAC systems.