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

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

Jan. 15, 2021, 11:21 a.m. | 1532 Инжиниринг (SE)

Столкнулись мы с этой проблемой не в боевых условиях, а во время нашего очередного семинара по стандарту МЭК 61850. Наши семинары по стандарту МЭК 61850 славятся обширными практическими занятиями. К каждому занятию мы выдаем задание на выполнение работы и подробные руководящие указания, описывающие процесс взаимодействия с оборудованием и программным обеспечением в пошаговом режиме. В задание на выполнение работы по настройке публикации GOOSE-сообщения от устройства А мы непреднамеренно вставили текст задания по настройке публикации Sampled Values и его отредактировали. В результате такой редактуры один из пунктов задания по настройке публикации GOOSE гласил, что MAC-адрес назначения для сообщения должен равняться 01-0с-cd-04-05-05. Как говорят по ТВ, впоследствии именно это станет роковым фактором, оказавшим влияние на ход дела. А на начальном этапе никто и не обращал на это внимания. А есть тут на что стоит обратить внимание?

Стандарт МЭК 61850 определяет рекомендации по диапазону MAC-адресов назначения для сообщений GOOSE и Sampled Values. Так, для GOOSE рекомендуемый диапазон MAC-адресов назначения: 01:0C:CD:01:00:00 - 01:0C:CD:01:01:FF; для Sampled Values: 01:0C:CD:04:00:00 - 01:0C:CD:04:01:FF. Для четвертого октета рекомендуемое значение для GOOSE и Sampled Values отличаются (01 и 04, соответственно). Для второго и третьего октета рекомендуемое значение 0C и CD, соответственно. Но всё это не обязательные требования, а лишь рекомендации. В оригинальной версии стандарта МЭК 61850 в части описания этих позиций адреса присутствует модальный глагол should, который согласно онлайн словарю Webster's Online Dictionary, выражает рекомендацию, а не требование, в отличие от модального глагола shall, который выражает обязательное требование. Например, для первого байта MAC-адреса фигурирует модальный глагол shall, указывая на значение первого байта равное 01 (признак многоадресной рассылки), ведь GOOSE и Sampled Values должны быть именно многоадресными посылками.

Выполнив конфигурацию по заданию на публикацию GOOSE-сообщения, устройство A успешно начало формировать GOOSE-сообщения с заданным MAC-адресом 01-0с-cd-04-05-05 в сеть. Участники семинара выполнили конфигурирование устройства Б, подписав его на это GOOSE-сообщение. И вот наступил момент проверки взаимодействия устройств по GOOSE и... ничего не вышло. Конфигуратор подписчика не анонсировал каких-либо недочетов. Всё должно было работать. Должно. Но не работало. Мы начали проверять все моменты: соответствие версий конфигурации (confRev); наличие признака качества в GOOSE-сообщении и его значение; и др. Все было в порядке. И вот мы добрались до MAC-адреса назначения сообщения. Мы заметили, что в четвертом октете он отличался от рекомендуемого стандартом и поменяли его. И все заработало. Весьма досадно, что, если для устройства-подписчика Б, это имеет значение, почему он не предупредил об этом на этапе конфигурирования, когда в него мы загружали файл конфигурации SCL. А еще досадно то, что при конфигурировании устройства-издателя конфигуратор нас не предупредил, что мы задаем значения вне рекомендуемого стандартом диапазона.

Мы пошли дальше и решили поэкспериментировать с конфигурацией издателя. Мы изменили и второй и третий октеты, задав их значения вне рекомендуемого стандартом диапазона. Все было принято без предупреждений пользователя. А потом мы еще и решили попробовать сделать GOOSE одноадресным (unicast) - и это тоже сработало. Устройство А начало публиковать одноадресные GOOSE-сообщения.

Представьте, если эти все ошибки будут допущены пользователями на этапе пуско-наладочных работ? А на этапе эксплуатации? Сколько времени можно будет «убить» в поисках решения?

Выводы

Целесообразным является выполнение проверок конфигурационных файлов в независимых программным инструментах, которые способны осуществлять локализацию ошибок и недочетов, вне зависимости от суждений и представлений о прекрасном у производителей. Недопустимо выполнять проверку конфигурационных файлов используя конфигурационный софт производителей. Приведенный пример (а их еще много) наглядно демонстрирует это, и «жертвой» в указанной ситуации становится эксплуатационный персонал.

Имея SCD-файл, который является неотъемлемым атрибутом реализации цифровых подстанций, и используя программное обеспечение «Теквел Парк» для экспертизы файлов SCL, проверка всех аспектов конфигурации производится в автоматическом режиме для всех устройств и сообщений проекта. Не требуется выполнять проверки вручную. Регистрируйтесь сейчас, чтобы попробовать!

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.