Как версии конфигурации могут загубить коммуникации?
Back to blog

Как версии конфигурации могут загубить коммуникации?

На своем опыте мы часто встречаем различного рода ограничения по распознаванию конфигураций из файла SCD в конфигураторах интеллектуальных электронных устройств (ИЭУ) и всегда стараемся разобраться в причинах неуспешного импорта конфигурации. Один из таких кейсов и связанные с ним условия работы конфигураторов системы (System Configuration Tool – SCT) и конфигураторов ИЭУ (IED Configuration Tool – ICT) мы рассмотрим в настоящей публикации.

По нашим наблюдениям 8 из 10 конфигураторов не распознают конфигурацию файлов SCD в полном объеме. Недавно мы столкнулись с интересным случаем некорректного импорта, который привел нас к написанию tissues.

Предыстория

Для одного их объектов, на котором установлено 43 ИЭУ, нами был разработан файл SCD. В состав описанного в файле оборудования входили преобразователи аналоговых сигналов (ПАС), преобразователи дискретных сигналов (ПДС), терминалы релейной защиты и автоматики (РЗА), контроллеры присоединений (КП) 8 различных производителей. При разработке файла SCD учитывались особенности конфигурирования устройств каждого производителя для обеспечения их совместимости и общего конфигурирования на этапе пуско-наладочных работ.

В ходе импорта файла SCD и его распознавания конфигураторами устройств (ICT) было выявлено, что у одного из производителей нельзя оформить подписку на GOOSE сообщения и SV потоки. Возможность отсутствовала, поскольку не отображались сконфигурированные блоки управления при импорте конфигурации устройств издателей. Разработанный файл успешно проходил валидацию на соответствие синтаксису SCL и при импорте файла ICT не сигнализировал о наличии ошибок. Как выяснилось позже, причина неотображения блоков управления заключалась в отсутствии атрибута сonfRev у блоков управления устройства издателя в SCD файле. В рамках этой публикации мы выясним, почему ICT производителя не отобразил конфигурацию и корректно ли такой поведение.

Что за атрибут confRev и для чего он нужен?

СonfRev – это атрибут, указывающий количество изменений конфигурации набора данных, на которую ссылается атрибут DatSet блока управления. Атрибут требуется для согласования конфигурации между издателем и подписчиком, текущее значение входит в состав публикуемого GOOSE сообщения и SV потока.

В случае получения подписчиком кадра, в котором значение атрибута confRev отличается от ожидаемого значения согласно загруженной конфигурации, можно констатировать несоответствие использованной конфигурации издателя по отношению к фактической. Обращает ли внимание подписчик на этот атрибут или нет, можно узнать в документе PIXIT на устройство.

В представленном PIXIT указывается, что подписчик обращает внимание на значение confRev. Значит, в случае его отличия от ожидаемого, сигналы из входящего сообщения не будут обрабатываться. Так, с помощью этого атрибута можно обезопасить работу устройства-приемника от некорректной интерпретации входных сигналов.

Эволюция confRev

С момента выхода стандарта МЭК 61850 в редакции 1 до текущей действующей редакции 2.1 происходила формализация требований к описанию функциональной нагрузки атрибута confRev, которые повлияли на возникшую проблему.

МЭК 61850 Ed1

В первой редакции глав стандарта МЭК 61850 атрибут confRev определяется, как номер конфигурации блока управления. Наличие атрибута указывается обязательным для блоков управления Report и опциональным для блоков управления GOOSE и SV. Для блока управлениями отчетом confRev должен увеличиваться при удалении элемента из набора данных и изменении порядка следования элементов. Начальное значение confRev стандартом не регламентируется. Значение 0 является зарезервированным. При перезапуске устройства значение confRev не должно сбрасываться на начальное.

МЭК 61850 Ed2

С выпуском второй редакции стандарта формализация в части описания атрибута confRev расширилась и частично изменилась. СonfRev – это атрибут, отображающий количество раз, когда конфигурация набора данных, на которую ссылается атрибут DatSet, была изменена. Основное отличие редакции 2 от редакции 1 – это обязательность атрибута confRev у блоков управления передачей GOOSE и SV по тексту стандарта. В XML схеме редакции 2 атрибут confRev блока управления GOOSE и SV также остается опциональным. Формализовались условия, при которых требуется инкрементировать значение атрибута.

Изменения, которые должны учитываться для блоков управления Report:

  • удаление элемента набора данных;
  • изменение порядка следования элементов в наборе данных;
  • настройка конфигурации набора данных через сервис SetBRCBValues, при котором значение атрибута DatSet изменяется.

Изменения, которые должны учитываться для блока управления GOOSE:

  • удаление элемента набора данных;
  • добавление элемента в набор данных;
  • изменение порядка следования элементов в наборе данных;
  • изменение конфигурации с помощью SetGoCBValues, при котором ИЭУ отвечает за инкрементацию значения confRev;
  • установление ссылки на DatSet с помощью SetGoCBValues на уже установленное значение DatSet.

Изменения, которые должны учитываться для блока управления SV:

  • удаление элемента набора данных;
  • изменение порядка следования элементов в наборе данных;
  • изменение значения атрибутов MsvID, DatSet, SmpMod, SmpRate, OptFids.

Обратите внимание, что на инкрементацию confRev для блока управления передачей SV влияет не только конфигурация набора данных, но и параметры самого блока управления. Для SV изменения конфигурации наборов данных с помощью сервисов не допускается.

Добавилась рекомендация на число увеличения атрибута confRev (для блоков управления GOOSE и SV - в tissue 1590 поднимается вопрос, почему аналогичная рекомендация не применяется к блоку управления Report - до настоящего момента этот вопрос находится на обсуждении): стандарт рекомендует увеличивать значение на 10000, если изменение происходило в конфигураторах (SCT, ICT), и увеличивать на 1 в случае изменения через MMS сервисы.

Начальное значение для ConfRev стандартом IEC 61850 не устанавливается, но указывается целочисленный диапазон от 0 до 4 294 967 295.

Значение, которое будет принимать атрибут confRev у блоков управления Report и GOOSE при перезагрузке устройства, допускается реализовывать в двух вариантах:

  • выставлять значение из базовой конфигурации;
  • выставлять значение из конфигурации до перезагрузки устройства.

Реализация для конкретного устройства должна указываться в PIXIT.

Для блоков управления SV значение confRev не должно сбрасываться при перезагрузке устройства, т.е. должно выставляться значение из конфигурации до перезагрузки.

За изменение значения атрибута отвечают конфигураторы (SCT и ICT). SCT и ICT должны ставить значение confRev блока управления при их создании и изменении, как определено в IEC 61850-7-2.

МЭК 61850 Ed2.1

На текущий момент действуют требования к описанию confRev по ред 2.1. Они практически полностью совпадают с требованиями редакции 2 со следующими дополнениями:

  • для зарезервированного значения confRev=0. оставленного согласно редакции 2, добавилось указание, что оно должно использоваться только у блока управления Report, GOOSE, SV, у которого нет ссылки на набор данных;

  • для блока управления Report будет увеличение confRev в случае добавления элемента в набор данных. Но, согласно ответу на tissue 673, по редакции 2 тоже допускается увеличение confRev при добавлении новых элементов в набор, несмотря на то что в списке изменений добавление не указано.

Расследование

Вернемся к проблеме, которая побудила к написанию этой публикации. Правильно ли повел себя конфигуратор, не импортировав блоки управления GOOSE и SV сообщений из SCD файла и тем самым не дав возможность закончить конфигурирование устройства.

Из-за несогласованности описания наличия атрибута в тексте стандарта и в тексте схемы возникла наблюдаемая нами проблема. Встроенная валидация SCT и ICT в большинстве случаев ограничивается проверкой только на соответствие файлов синтаксису SCL, объявленному в XML схемах. По этой причине ICD файлы без сonfRev и разработанные на их основе SCD файлы также без сonfRev успешно проходят валидацию.

В своем tissue мы предложили сделать атрибут ConfRev обязательным, чтобы схема редакции 2 и 2.1 соответствовала тексту стандарта и при проверке можно было выявить ошибку. В ответ мы получили, что данный атрибут останется опциональным по схеме для обеспечения совместимости между редакциями и что проверка файлов конфигураторами не должна ограничиваться проверкой только по XML схеме.

Работая с SCT и ICT российских производителей, можно наблюдать, что большая часть из них не придерживается положений стандарта в части требований к описанию атрибута confRev. Из-за проверки файлов SCL только по XML схеме, в которой наличие атрибута является опциональным для GOOSE и SV, зачастую атрибут отсутствует у блоков управления в ICD файле, и далее он не добавляется в SCT. А при наличии в ICD confRev инструменты оставляют его значения без изменений, то есть изменение конфигурации набора данных никак не отслеживается.

Просмотрев другие tissues на сайте заметили, что никто ранее не затрагивал этот вопрос, а значит зарубежные коллеги с такими проблемами либо не сталкивались, либо не обращали внимания. Чтобы посмотреть зарубежную реализацию, мы воспользовались ICT известного и часто поставляемого на объекты, в том числе в России, производителя.
В ходе анализа тестировались изменения значения confRev через воспроизведение разных сценариев работы, а также воспроизведения сценариев из методик испытаний на ICT и SCT.

Результаты

При создании блока управления GOOSE по умолчанию ICT поставил значение 1. Значение 0 не использовалось, потому что рассматриваемый ICT работает по 2 редакции. Также попробовали загрузить ICD без confRev – ICT по умолчанию поставил значение 1.

При указании ссылки на набор данных у блока управления значение confRev было увеличено на 10000.

При удалении ссылки на набор данных у блока управления GOOSE confRev снова увеличился на 10000.

Далее были произведены изменения порядка следования атрибутов в наборе данных, удаление атрибутов из набора данных, изменение ссылки на набор данных. Все эти изменения приводили к увеличению значения confRev на 10000, согласно рекомендациям стандарта МЭК 61850.

При попытке удалить значение confRev у блока управления, ICT не разрешает завершить сохранение конфигурации, указывая допустимый диапазон от 0 до 4294967295.

Выводы

Подводя итог расследования, получаем, что конфигуратор производителя на нашем объекте некорректно повел себя при импорте SCD файла. Загружаемый SCD файл не соответствовал требованиям стандарта, а ICT загрузил невалидную конфигурацию и никак не проинформировал пользователя о наличии ошибки. Также проблема выявлена и на стороне SCT, в котором разрабатывался используемый файл. Он в свою очередь дал возможность разработать и экспортировать файл, не соответствующий стандарту МЭК 61850.

Чтобы подобных случаев больше не возникало, разработчикам SCT и ICT следует обратить внимание, как в их инструментах реализована работа с атрибутом confRev и увеличивается ли его значение при:

  • изменении ссылки на набор данных у блока управления (изменение атрибута DatSet);
  • удалении элементов из набора данных;
  • изменении порядка следования атрибутов в наборе данных;
  • добавлении элементов в набор данных.

Для блока управления SV дополнительно при:

  • изменении параметров MsvID, DatSet, SmpMod, SmpRate, OptFids.

В методиках испытаний МЭК 61850-10 в части ICT и SCT, а также в документах Server Devices with IEC 61850-8-1 и PIXIT указывается, как должны вести себя инструменты и устройства при изменении конфигурации набора данных блока управления.

Разработчикам ICD, IID файлов следует контролировать наличие confRev в блоках управления, если они уже имеются в файле.

Компанией «Теквел» были разработаны программные комплексы, позволяющие осуществлять автоматизированные проверки конфигураторов ИЭУ (ICT) и конфигураторов системы (SCT) на соответствие требованиям стандарта МЭК 61850. Проведение проверок ICT и SCT равнозначно по важности уже внедренным и проводимым проверкам ИЭУ на соответствие стандарту МЭК 61850. Такие проверки крайне необходимы для успешной реализации концепции инжиниринга, предложенной стандартом МЭК 61850 и действующими стандартами ПАО «ФСК ЕЭС»/ПАО «Россети».

И как нам указали в ответ на tissue, требуется использовать инструменты дополнительной экспертизы SCD файлов, которые способны делать проверку конфигурации не только на соответствие схемы XML, но и на соответствие требованиям стандарта. Одна из таких систем – ПТК «Теквел Парк». ПТК «Теквел Парк» используется на российском и зарубежном рынке для проведения экспертизы разрабатываемых файлов SCD. Инструмент выявляет несоответствия схеме, стандарту, а также помогает конечному заказчику и проектировщику SCD, указывая на места в конфигурации, где требуется доработка, и дает указания стандарта, которым следует придерживаться при конфигурировании. Использование во время наладки SCD файла, прошедшего экспертизу системой «Теквел Парк», позволяет избежать большого количество проблем с применением конфигурации, тем самым сокращая сроки наладочных работ.

Также важно отметить необходимость контроля значений атрибута confRev на этапах наладки и дальнейшей эксплуатации. На указанных этапах, когда происходит переконфигурирование набора данных исходящего сообщения, которое влечет за собой изменения confRev, очень важно знать, что произошло изменение. Ведь в таком случае устройство-издатель будет формировать GOOSE/SV-сообщения с увеличенным значением сonfRev, отличным от файла SCD, а подписчик будет ожидать иное значение этого атрибута, которое указано в SCD. При таком сценарии достаточно сложно будет найти причину проблем в информационном взаимодействии устройств, так как конфигурирование проводилось с помощью одного и того же SCD файла. Без постоянного контроля изменений все это ведет к долгой локализации проблем коммуникаций, а это в свою очередь ведет к увеличению продолжительности работ.

Установка ПТК «Теквел Парк» на объект помогает избежать таких проблем. Постоянный мониторинг и диагностика коммуникаций МЭК 61850 помогают наладочному и эксплуатационному персоналу в режиме реального времени идентифицировать, что у определенного ИЭУ на объекте изменилась конфигурация. Это повышает наблюдаемость за работающей системой и эффективность эксплуатации.