Как версии конфигурации могут загубить коммуникации?
На своем опыте мы часто встречаем различного рода ограничения по распознаванию конфигураций из файла 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 помогают наладочному и эксплуатационному персоналу в режиме реального времени идентифицировать, что у определенного ИЭУ на объекте изменилась конфигурация. Это повышает наблюдаемость за работающей системой и эффективность эксплуатации.
последние статьи
Регистратор событий высокоавтоматизированной подстанции (РС ВАПС)
17 апреля 2024
Длительный захват трафика с dumpcap
19 февраля 2024
«Теквел Парк» внедрен на крупнейшей гидроэлектростанции Карачаево-Черкессии
30 января 2023