Стандарт МЭК 61850 определяет модели данных, коммуникационные сервисы, а также язык и процесс конфигурирования интеллектуальных электронных устройств (ИЭУ). Он определяет три вида программных инструментов для инжиниринга и шесть типов конфигурационных файлов на языке SCL (System Configuration Language), создание которых производится на этапе проектирования.

Существующее инструментальное программное обеспечение для конфигурирования ИЭУ может в определенной степени обеспечивать визуализацию содержимого файлов SCL. Однако большинство таких программ разработано и предназначено для конфигурирования ИЭУ отдельно взятого производителя. Это делает невозможным или существенно осложняет задачу визуализации и проверки файлов SCL для проектов с участием нескольких фирм-производителей. Помимо этого, основные принципы контроля качества призывают к использованию при проверке технических решений инструментов, отличных от тех, которые использовались для разработки технических решений, поскольку последние, как показывает практика, могут создавать и скрывать допускаемые ошибки.

В реализуемых проектах обмен сигналами согласно коммуникационным сервисам GOOSE, Sampled Values и Reports обычно описывается с помощью таблиц Microsoft Word/Excel и структурно-функциональных схем, вручную формируемых специалистами проектных организаций. Данные таблицы чаще всего не соответствуют информационному обмену, описанному в файле SCD (System Configuration Description), также являющимся результатом рабочего проектирования и передаваемом далее на этап выполнения пуско-наладочных работ. Таким образом, работа по выявлению ошибок и их устранению мигрирует на этап выполнения пуско-наладочных работ на объекте и приводит к увеличению сроков ввода объектов в эксплуатацию, что противоречит основным принципам стандарта МЭК 61850 и цифровизации в целом. Складывающаяся ситуация прямо противоречит устоявшейся практике, когда все принципиальные технические решения в части РЗА и АСУ ТП, как результат проектирования, проходят экспертизу у конечного заказчика и системного оператора.

Рис. 1. Вручную составленные таблицы Excel вместо файлов SCD - работа впустую.

Выполняя проверки файлов SCD, становится возможным валидировать файл на соответствие стандарту МЭК 61850; верифицировать информационный обмен между ИЭУ ЦПС: идентифицировать отсутствующие и избыточные сигналы для передачи; ограничить использование логических узлов общего назначения и убедиться в использовании логических узлов и объектов данных согласно профилю стандарта МЭК 61850; проконтролировать правильность задания коммуникационных и прикладных параметров сообщений и др. Указанное позволяет повысить эффективность выполнения пуско-наладочных работ, а также достичь более высокого технического совершенства комплексов РЗА и АСУ ТП, простоты и удобства их эксплуатации.

Использование языка SCL при проектировании цифровых энергообъектов

Известно, что в отличии от других коммуникационных стандартов для электроэнергетики, стандарт МЭК 61850 определяет язык конфигурирования системы SCL (System Configuration Language), который может быть использован для описания первичной схемы энергообъекта, реализуемых на нем функций, конфигураций ИЭУ и информационного обмена между ИЭУ.

Сегодня язык SCL используется для решения следующих задач:

• Описание первичной схемы энергообъекта, состава реализуемых функций на элементах энергообъекта.
• Описание моделей данных и функциональных возможностей ИЭУ, привязки функций к ИЭУ.
• Описание коммуникационных параметров ИЭУ и информационного обмена между ИЭУ.

Есть еще две возможности, которые дает SCL, широко не используемые в проектах сегодня:

• Описание уставок (по сути, является частью описания модели данных ИЭУ, но, являясь опциональным, широко не используется).
• Описание программируемой логики, что не определено в [1], но описано в одном из технических отчетов стандарта МЭК 61850.

Упомянутые сценарии использования языка SCL закрывают все аспекты конфигурации ИЭУ. То есть через некоторое время файл SCL может стать единственным файлом конфигурации ИЭУ, что может быть чрезвычайно удобно для использования и версионирования.

Язык SCL и его восприятие человеком

Язык SCL основан на языке разметки Extensible Markup Language (XML). Язык XML может быть использован для описания практически любой структурированной информации. Он определяет набор правил для создания текстовых документов в машиночитаемом формате для того, чтобы исключить человеческий фактор при передаче информации от одного программного обеспечения другому. В то же время XML как текст в некоторой степени остается воспринимаемым человеком, что дает ему возможность проанализировать отдельные разделы файла SCL.

SCL является частным случаем XML, который определяет семантику и синтаксис, применимые для систем автоматизации энергообъектов. Ограничения по структуре и содержанию документа определены схемой языка SCL, которая фиксирует требования к структуре файлов SCL.

Рис. 2. Пример файла SCD, открытого в текстовом редакторе.

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

Проверка информационного обмена между ИЭУ по МЭК 61850

GOOSE и Sampled Values являются одними из самых значимых коммуникационных моделей стандарта МЭК 61850, которые дают возможность применять цифровые коммуникации в комплексах релейной защиты и автоматики. Передача GOOSE и Sampled Values сообщений производится на канальном уровне в многоадресном режиме с использованием модели «издатель-подписчик», когда на одно публикуемое сообщение может подписаться любое количество ИЭУ [2] [3].

Стандарт МЭК 61850 определяет правила описания публикации GOOSE/Sampled Values сообщений, а также подписки на них. Однако найти соответствующие поля в файле SCL и составить полноценную картину о предусмотренном информационном обмене оказывается чрезвычайно сложно по уже обозначенным причинам. Для того, чтобы решить эту проблему многие инженеры вручную создают таблицы, где отражаются публикации сообщений и подписки на них.

Создание таких таблиц имеет ряд существенных недостатков:

• При создании вручную таблицы могут содержать ошибки.
• Отсутствие возможности быстрого обзора параметров сообщений и состава наборов данных.
• Сложность анализа и поддержки при большом количестве ИЭУ в проекте.
• Отсутствие возможности для автоматизации проверок.

При наличии около ста ИЭУ в проекте оказывается крайне непросто верифицировать конфигурацию используя табличную форму.

Даже в том случае, если подобные таблицы или иная сопроводительная документация формируется системами автоматизированного проектирования по условиям стандарта МЭК 61850 разумным является использование сторонних инструментов для верификации файлов SCL, в которых не производилось их создание, поскольку сами САПР могут также вносить ошибки. Проверка результатов выполненных работ с использованием независимых инструментов является одним из основных принципов контроля качества.

Все указанное применительно к GOOSE и Sampled Values коммуникациям также относится и к отчётам (Reporting) – коммуникационной модели, обеспечивающей передачи телеинформации в АСУ ТП энергообъекта.

Отсутствие возможности выполнить полноценную проверку файла SCD на этапе проектирования влечет за собой серьёзные проблемы на этапах пуско-наладочных работ и эксплуатации энергообъекта. Эти проблемы приводят к увеличению сроков ввода объектов в эксплуатацию и неправильной работе РЗА в эксплуатации, в том числе при выполнении операций технического обслуживания.

Валидация файлов SCL

Валидация является базовым и обязательным этапом проверки электронной проектной документации на языке SCL. Как уже упоминалось, синтаксис и структура файлов SCL определяется схемой SCL, приведенной в [1]. Схема SCL является неотъемлемой частью стандарта МЭК 61850 и распространяется Международной Электротехнической Комиссией (МЭК) вместе со стандартом в виде набора файлов XSD, которые и используются для валидации. При этом стоит сделать несколько замечаний:

• На сегодняшний день существует три версии схемы SCL, которые могут использоваться для валидации: схемы редакций 1, 2 и 2.1 стандарта МЭК 61850.
• Для редакции 2 стандарта МЭК 61850 существует 2 схемы – ревизии А и Б. При этом действующей является только одна – ревизии Б, однако некоторые версии конфигураторов могут использовать ревизию А из-за того, что не были обновлены производителями своевременно.
• В некоторых случаях производители могут незначительным образом модифицировать файлы XSD для того, чтобы согласовать их со своими внутренними конфигурационными файлами. Это, в свою очередь, может приводить к проблемам функциональной совместимости.

Рис. 3. Неуспешная попытка загрузить файл SCD в ПО испытательной установки Omicron CMC - файл не валиден. Симуляция сообщений до устранения ошибок невозможна.

С учётом изложенного можно сделать вывод о том, что наилучшим вариантом, в особенности, в проектах с использованием ИЭУ различных фирм-производителей, является использование независимого программного инструмента для валидации, что позволит фиксировать все возможные несоответствия стандарту МЭК 61850, которые могут вызвать проблему функциональной совместимости.

Визуальный анализ информационного обмена

Как уже было указано ранее, файлы SCL, в частности, файлы SCD содержат в себе информацию об обмене данными между ИЭУ согласно коммуникационным сервисам Sampled Values и GOOSE, вплоть до отдельных элементов данных (объектов или атрибутов данных). Это даёт возможность визуализировать коммуникации между ИЭУ проекта и фиксировать ошибки и несоответствия. Наличие различных видов отображения коммуникаций (отображение коммуникаций между всеми ИЭУ проекта, коммуникаций только для выбранного ИЭУ, подписчиков на элементы данных выбранных сообщений, назначений элементов данных сообщений на внутренние сигналы ИЭУ и др.) позволяет поэтапно анализировать правильность организации связей, фиксировать как отличия в паттерне (то есть в повторяющемся образце) коммуникаций, так и смысловые ошибки (передачу и использование не тех сигналов, что требуется; не использование требуемых сигналов и др.). Такие решения как цветовая кодировка линий связи в зависимости от типа коммуникаций (GOOSE/Sampled Values), направление прорисовки линий связи в интерактивном режиме при визуализации, возможность отображения текстовых описаний для ИЭУ и передаваемых данных на языке пользователя (при их наличии в файле SCD) упрощает анализ информационного обмена. Пример визуализации согласно описанному формату представлен на рисунках 4-6.

Рис. 4. Визуализация файла SCD в целом.

Рис. 5. Визуализация информационного обмена для одного из ИЭУ проекта.

Рис. 6. Анализ состава сигнала в сообщениях и их назначений на виртуальные входы в ИЭУ-подписчиках.

Автоматический анализ файлов SCL

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

Перечень проверок, которые могут производиться в автоматическом режиме:

• GOOSE/SV-сообщение не имеет подписок.
• Наборы данных содержат элементы, на которые отсутствует подписка.
• Наличие подписок на несуществующие элементы данных.
• Атрибуты качества либо не передаются, либо на них отсутствует подписка.
• GOOSE/SV-сообщения имеют идентичные MAC-адреса назначения.
• и др.

Последующие подразделы подробно рассматривают каждую из перечисленных проверок, а также их влияние ошибок на функционирование системы.

GOOSE/SV-сообщение не имеет подписчиков

Существует две наиболее вероятные причины наличия в проекте GOOSE/SV-сообщений, не имеющих подписчиков:

• Заводская конфигурация ИЭУ включала в себя предварительно сконфигурированные блоки управления передачей сообщений, которые либо не были удалены, либо не были переконфигурированы под проектные.
• В проекте либо отсутствует ИЭУ-подписчик, либо отсутствует подписка у существующего в проекте ИЭУ (которая в действительности требуется).

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

Наборы данных сообщений содержат элементы, на которые отсутствует подписка

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

• Наборы данных были предварительно сконфигурированы производителем ИЭУ и не изменялись при конфигурировании системы.
• Требуемая подписка отсутствует.

Первая ситуация может не оказывать негативного влияния на функционирование системы, однако сообщения будут иметь больший размер и могут увеличиться времена их передачи по сети и обработки ИЭУ. На практике авторы встречали проекты с наборами данных, включающими в себя 90 элементов, из которых только на 3 элемента была организована подписка. Вторая ситуация является ошибкой, которая может приводить к неправильному функционированию РЗА и АСУ ТП, и требует обязательной корректировки.

Задана ссылка на несуществующий элемент

Наличие в проекте подписок (ссылок) на несуществующие элементы является ошибкой и означает то, что были внесены изменения в конфигурацию издателя. Например, какой-либо элемент набора данных публикуемого сообщения был удалён и/или заменён на новый или был удален или изменён блок управления передачей сообщения. Указанное может происходить после изменения файла конфигурации ИЭУ-издателя в проекте. Часто возникновение этой ошибки приводит и к появлению ранее описанных ошибок (GOOSE/SV-сообщение не имеет подписчиков и/или набор данных содержит элементы, на которые отсутствует подписок). Указанная ошибка может приводить к неправильному функционированию комплексов РЗА и АСУ ТП и требует корректировки.

Атрибуты качества либо не передаются, либо на них отсутствует подписка

Атрибуты качества являются важным элементом данных для систем, функционирующих на основе стандарта МЭК 61850. Атрибут Validity в составе атрибута качества может использоваться в алгоритмах РЗА для предотвращения неправильного функционирования в условиях плохого качества сигналов (q.validity=invalid/questionable) и при нарушении исправности коммуникаций. Помимо этого, атрибут качества играет важную роль в эксплуатации комплексов РЗА и АСУ ТП - при отсутствии атрибута качества в публикуемых сообщениях невозможно выполнять техническое обслуживание устройства РЗА и АСУ ТП в эксплуатации.

Практический опыт выполнения проверки файлов SCL

В зоне эксплуатационной ответственности одной сетевой компании были запроектированы пять цифровых подстанций с различными схемами распределительных устройств: три из которых запроектированы по III архитектуре (с применением протокола MMS для интеграции устройства РЗА и КП в единую систему АСУ ТП, применением протокола GOOSE для быстрой передачи информации между устройствами уровня присоединения (РЗА и КП) и передачи информации между устройствами защиты и автоматики и ПДС, а также применением протокола Sampled Values для передачи данных измерений токов и напряжений от устройств ПАС) и 2 запроектированы по II архитектуре (с применением протокола MMS для интеграции устройства РЗА и КП в единую систему АСУ ТП, применение протокола GOOSE для быстрой передачи информации между устройствами уровня присоединения (РЗА и КП) и передачи информации между устройствами защиты и автоматики и ПДС).

В ходе рассмотрения 5 проектов цифровых подстанций был выявлен ряд типовых ошибок файлов SCL (SSD, SCD), несущих как общие требования к оформлению файлов, для дальнейшего упрощения работы с ним в том числе и эксплуатирующим персоналом, так и ряд серьезных недочетов в части логики работы устройств РЗА, не устранение которых на этапе рассмотрения проектной документации привело бы к необходимости изменению файла SCD файла на этапе выполнения пуско-наладочных работ и к их затягиванию.

Перечень ошибок, выявленных в ходе рассмотрения визуализированных файлов SSD специалистами РЗА и АСУ ТП:

• У присоединений (уровнень Bay) диспетчерские наименования первичного оборудования некорректны или отсутствуют.
• Используются не корректные классы логических узлов.
• Состав логических узлов не соответствует заявленным требованиям.
• Присоединения имеют идентичное обозначение.

Перечень ошибок, выявленных в ходе рассмотрения визуализированных файлов SCD специалистами РЗА и АСУ ТП:

• SV- потоки не прописаны или прописаны не в полном объеме.
• Настройка SV-произведена неверно (smvID одинаковый для всех устройств);
• В файле отсутствуют GOOSE-сообщения устройств РЗА, включающие в себя сигналы УРОВ, ЛЗШ, АВР.
• Идентичные IP-адреса устройств.

К наиболее значимым выявленным ошибкам можно отнести:

• Ввод 10 кВ системы шин Т-1 ошибочно действует на отключение Т-2.
• Отсутствуют GOOSE сообщения ввода 10 кВ с СВ-10 кВ и ОЛ-10 кВ.
• ПДС Т-1 подписан на действие основных защит Т-2.
• Регистратор аварийных событий контролирующие сигналы положения выключателя берет сигналы с устройств РЗА, а не с ПДС.
• При проектировании ЦПС разных производителей выявлено несоответствие APPID некоторых устройств завяленным в руководстве по эксплуатации диапазонам.
• Присутствие в файле SCD устройств РЗА отсутствующих в проекте подстанции.
• При поэтапном вводе ПС 110 кВ формирование SV-потоков с измерениями от ТН 110 кВ 1, 2 с.ш. на первых этапах предусматривалось выполнять в ПАС линий до момента установки ТН 110 кВ 1,2 с.ш. При рассмотрении SCD файлов поэтапной реконструкции ПС SV-поток для ТН 110 кВ 1,2 с.ш. не был переподписан в момент установки ПАС ТН 110 кВ 1,2 с.ш.
• При рассмотрении файлов SCL также неоднократно выявлялось несоответствие сигналов АСУ ТП завяленным перечням в проектной и рабочей документации.

Выявление ошибок в файлах SCL связанных с особенностями взаимосвязи ИЭУ разных производителей позволяет разработчику файлов при необходимости обратиться на заводы изготовители, для получения разъяснений. Ошибки, связанные с неправильной логикой работы РЗА, могут быть выявлены только на последних этапах ПНР при опробовании действия РЗА на коммутационные аппараты.

Все ошибки выявленные на этапе ПНР ложатся на плечи наладчиков, что влечет за собой задержку ввода оборудования в работу.

Выводы

Проверка электронной проектной документации в формате файлов SCD с использованием специализированных инструментов позволяет обнаружить ошибки в коммуникационных параметрах ИЭУ, а также ошибки информационного обмена согласно коммуникационным моделям GOOSE, Sampled Values и Report на стадиях проектирования и, как следствие, обеспечить наиболее эффективное и своевременное выполнение пуско-наладочных работ. Помимо этого, наличие корректного файла SCD позволит полноценно решать следующие задачи:

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

Список литературы

1. IEC 61850-6, Communication networks and systems in substations – Part 6: Configuration description language for communication in electrical substations related to IEDs.
2. IEC 61850-8-1, Communication networks and systems in substations – Part 8-1: Specific Communication Service Mapping (SCSM) – Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC 8802-3
3. IEC 61850-7-2, Communication networks and systems in substations – Part 7-2: Basic communication structure for substation and feeder equipment – Abstract communication service interface (ACSI)