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

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

15 января 2021 г. 11:21 | 1533 Инжиниринг (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, проверка всех аспектов конфигурации производится в автоматическом режиме для всех устройств и сообщений проекта. Не требуется выполнять проверки вручную. Регистрируйтесь сейчас, чтобы попробовать!

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

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

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

«Россети Сибирь» будет использовать «Теквел Парк» для управления проектами цифровых подстанций
«Россети Сибирь» будет использовать «Теквел Парк» для управления проектами цифровых подстанций

Компания «Россети Сибирь» внедрила комплекс для автоматизированной экспертизы и анализы цифровых моделей подстанций «Теквел Парк». Программно-аппаратный комплекс, который разработан участником «Сколково» компанией Теквел, поможет специалистам «Россети Сибирь» в цифровизации основной производственной деятельности.

Опыт выполнения пуско-наладочных работ централизованной РЗА
Опыт выполнения пуско-наладочных работ централизованной РЗА

В 2018 году компания «Теквел» заключила несколько договоров на выполнение пуско-наладочных работ централизованной релейной защиты и автоматики (РЗА), реализуемой с использованием независимых серверных платформ и специализированного программного обеспечения (ПО). В настоящей статье мы хотим поделиться полученным опытом и рассказать о тех проблемах, которые могут потребовать особенного внимания у электросетевых компаний, заинтересованных в масштабном внедрении подобных централизованных систем.