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

18 января 2016 г. 1:22 | 2633

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

Свежие записи в блоге

Проверка электронной проектной документации ЦПС: требования и практический опыт
Проверка электронной проектной документации ЦПС: требования и практический опыт

Люди могут читать файлы SCL, но простое чтение не даёт полного и точного понимания работы комплексов РЗА и АСУ ТП. Рассказываем про основные принципы и практический опыт выполнения проверки файлов электронной проектной документации для цифровых подстанций в виде файлов SCL.

Недостойное поведение подписчика Sampled Values
Недостойное поведение подписчика Sampled Values

Тизер: Некоторые интеллектуальные электронные устройства (ИЭУ) требуют того, чтобы сообщения Sampled Values (или GOOSE), поступающие на их интерфейс, имели значение тега VLAN ID как задано при подписке. Указанное приводит к тому, что данные ИЭУ отказываются принимать и обрабатывать сообщения без тега VLAN ID или сообщения с иным значением тега VLAN ID. Указанное поведение подписчиков не является правильным, однако его можно встретить на практике. Прочитайте до конца, чтобы понять в чём заключается суть.

GOOSE не работает, но вы там держитесь!
GOOSE не работает, но вы там держитесь!

Каждый, кто участвует в наладке устройств с поддержкой стандарта МЭК 61850, сталкивался с ситуацией, когда не получается организовать обмен данными по GOOSE между устройствами. Причины всегда разные: может быть виноват наладчик, производитель, а иногда винить можно обе стороны. Недавно мы столкнулись с такой проблемой и это был случай, когда можно винить... решайте сами кого, прочитав заметку до конца. Кстати, речь пойдет об организации GOOSE-коммуникаций между устройствами двух производителей, наиболее часто (и одновременно) применяемых на ЦПС в России :)