Столкнулись мы с этой проблемой не в боевых условиях, а во время нашего очередного семинара по стандарту МЭК 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, проверка всех аспектов конфигурации производится в автоматическом режиме для всех устройств и сообщений проекта. Не требуется выполнять проверки вручную. Регистрируйтесь сейчас, чтобы попробовать!