Технологический процесс реализации высокоавтоматизированной подстанции опирается на SCL-файлы, описывающие конфигурацию как отдельного устройства, так и всего энергообъекта. Эти файлы проходят через все этапы — от разработки проектной документации до эксплуатации. На каждом из этапов используются разные программные инструменты, зачастую от разных производителей, и именно на стыке между ними возникают наиболее уязвимые места.
Для того чтобы технологический процесс работал корректно, все звенья — инструмент формирования спецификации системы (SST), системный конфигуратор (SCT) и конфигуратор устройств производителя (ICT) — должны одинаково понимать SCL-конфигурацию и корректно с ней работать. Именно вопрос реальной совместимости программных средств разных производителей и стал предметом первых в отрасли испытаний зрелости программных инструментов, выполненных в рамках работы ПАО «Россети».
В этих испытаниях компания Теквел выступила в роли независимой экспертной организации: компания предложила методику проверки, предоставила программное обеспечение «Теквел Парк Сервер» и «Теквел Магия» с функционалом, разработанным специально для испытаний, и провела полный анализ предоставленных производителями файлов ICD, SSD и SCD с оценкой совместимости и готовности инструментов.
Такой подход позволил не ограничиваться чек-листом возможностей производителей, а дополнить программу испытаний и повысить ценность результатов. В итоге была получена объективная техническая картина: где именно в цепочке работы с SCL возникают проблемы совместимости инструментов и насколько инструменты производителей готовы к работе в жизненном цикле ВАПС.
Определение подхода к испытаниям
Как отмечает компания Теквел, основополагающей частью при подготовке к испытаниям стало понимание методологии. Прежде чем переходить к разработке функционала для испытаний, необходимо было определить, что именно понимается под совместимостью, какие критерии должны использоваться для оценки готовности инструментов, какой функционал требуется для такой автоматической проверки и в каком формате должны быть представлены результаты, чтобы с ними могли работать все участники процесса.
На основании семилетнего опыта компании в инжиниринге и пуско-наладочных работах ВАПС было выделено наиболее уязвимое место — применение SCD-файла при настройке терминалов. Именно на этом этапе сходятся инструменты разных производителей, и именно здесь становится видно, насколько технологический процесс ВАПС реализуем на практике. При этом влияние на результат начинается уже на стадии проектирования, поэтому проверку целесообразно начинать именно с нее. Для локализации источника ошибок была необходима поэтапная проверка, позволяющая определить, каким именно инструментом вносится нарушение.
Четыре вопроса, на которые отвечают испытания
Структурно испытания были разделены на четыре этапа.
Этап 1. Проверка моделей ИЭУ (ICD)
Работа началась с анализа ICD-файлов, поскольку именно исходная модель устройства задаёт границы для всех последующих изменений. Если начальный файл содержит ошибки, говорить о совместимости системных конфигураторов бессмысленно: они будут либо «наследовать», либо «исправлять» эти ошибки, и в обоих случаях нельзя корректно определять причину несоответствия. Поэтому первичная проверка исходных данных стала необходимым условием для всей последующей оценки совместимости.
На этом этапе была реализована большая группа проверок с помощью ПО «Теквел Парк Сервер», который выполнял:
- валидацию по XSD-схемам МЭК 61850 (структура и синтаксис);
- OCL-проверки общего стандарта и расширенных правил Tekvel (семантика, связи, целостность модели, связность DataTypeTemplates);
- проверку соответствия NSD требуемой редакции стандарта;
- проверку соответствия корпоративному профилю ПАО «Россети».
Всего в «Теквел Парк Сервер» реализовано более 300 автоматизированных проверок, включающих не только формализованные машиночитаемые ограничения, но и требования, вынесенные в текстовые разделы самого стандарта. Именно эта семантическая часть проверок позволяет отлавливать ошибки, которые проходят через обычные валидаторы, но делают файл непригодным для дальнейшего использования.
Этап 2. Проверка цифрового проекта (SSD/SCD)
Следующим этапом стала проверка работы инструментов SST и SCT в части формирования спецификации подстанции (SSD) и конфигурации оборудования подстанции (SCD). На этом этапе особое внимание уделялось тому, насколько корректно программные инструменты описывают однолинейную схему, функции и конфигурацию устройств, включая GOOSE, SV и MMS. Иными словами, проверялась корректность формирования проектной документации, которая создаётся на этапе проектирования в соответствии с требованиями стандарта МЭК 61850.
Дополнительно анализировалось соответствие разработанных файлов требованиям СТО ПАО «Россети». Ожидание от работы программных средств в данном случае заключалось в том, что они должны обеспечивать создание конфигурации объекта, полностью соответствующей стандарту МЭК 61850 и нормативной документации. Именно в таком случае можно говорить о готовности инструмента к работе в среде ВАПС.
В этой части с помощью ПО «Теквел Парк Сервер» выполнялись автоматический анализ SSD- и SCD-файлов, протоколирование ошибок и несоответствий конфигурации, проверка на соответствие СТО ПАО «Россети», а также визуализация структуры объекта, устройств и связей между ними. Это позволяло просматривать разработанную конфигурацию в удобном и наглядном формате.
Этап 3. Проверка совместимости SCT с ИЭУ (ICD → SCD)
Отдельным и, пожалуй, самым показательным этапом стала проверка совместимости системного конфигуратора (SCT) с устройством конкретного производителя. С точки зрения Теквел именно она наиболее точно отвечает на вопрос совместимости между производителем устройства и программным инструментом в контексте SCL.
В центре внимания находилось сохранение исходной модели устройства после обработки в системном конфигураторе. Анализ охватывал структуру дерева устройства, состав логических узлов, объекты данных и их атрибуты, функциональные ограничения, принадлежность к общим классам данных и базовым типам, а также сохранность исходных значений и разрешённых параметров.
Для этого анализа Теквел разработал более 40 целевых проверок, объединённых в единый автоматизированный сценарий. Проверке подлежат семь групп параметров модели: структура модели данных, EnumType, триггеры данных, экземпляры логических узлов, неизменяемые значения, политики конфигурирования, редакция и ID-параметры устройства.
Почему это важно
По опыту Теквел, одна из главных проблем при работе с цифровыми проектами заключается не в том, чтобы исправить уже найденную ошибку, а в том, чтобы локализовать её источник — то есть понять, на каком именно этапе и каким инструментом было внесено критичное расхождение между исходной моделью и результатом работы SCT.
Модель устройства может содержать десятки или даже сотни тысяч строк, которые могут изменяться при работе SCT, но найти среди всех этих изменений именно неразрешённые — без специализированных инструментов практически невозможно. Поэтому испытания совместимости имеют самостоятельную ценность: если после обработки ICD-файла критически изменяются описание функций или параметры модели, дальнейшие этапы теряют смысл, поскольку уже ясно, что конфигурация не будет корректно загружена в устройство.
Как это работает
Инструмент «Теквел Магия» автоматически сравнивает исходный ICD-файл и соответствующий фрагмент SCD-файла, сформированный после работы SCT с тем же устройством. По итогам формируется отчёт с точной локализацией расхождений — в какой части модели устройства произошли недопустимые изменения.
Такая проверка занимает не более двух минут, но даёт очень наглядное представление о совместимости инструментов разных производителей и о том, где именно возникает нарушение модели.
Итоги и оценки
По итогам работ была сформирована сводная оценка инструментов всех производителей SCT и всех производителей оборудования. Для этого использовалась градация, отражающая степень сохранности модели: достоверная работа с моделью, сомнительная работа и критические расхождения. Такая форма представления результатов удобна тем, что она не только фиксирует проблему, но и показывает, на каком уровне она возникает.
Для этапности испытаний это особенно полезно: если системный конфигуратор не сохраняет исходную модель, нет смысла переходить сразу к этапу загрузки в устройство. Логичнее сначала устранить расхождения на уровне совместимости инструментов, а уже затем проверять готовность к полноценному импорту и эксплуатации.
Этап 4. Проверка готовности ICT (SCD → ИЭУ)
Завершающим этапом предлагаемой методологии становится проверка того, насколько ICT-инструмент готов к работе с файлами SCL при настройке терминала. На этом уровне проверяется не только сам факт успешного/неуспешного импорта, но и реальная способность инструмента перенести в устройство все необходимые конфигурационные параметры.
К таким параметрам относятся IP-настройки, маска, шлюз, параметры терминала (IEDname), настройка публикации GOOSE и SV, подписки на GOOSE и SV, MMS-настройки и уставки, если они были заданы в исходной конфигурации. Если всё это корректно импортируется и устройство функционирует в соответствии с разработанной для него конфигурацией, то можно говорить о высокой степени готовности инструмента к работе в среде цифровой подстанции.
Предлагаемая реализация
ПО «Теквел Магия» считывает модель устройства по протоколу MMS и сравнивает её с тем, что было в SCD: сетевые параметры, параметры ИЭУ, конфигурацию GOOSE, Sampled Values и MMS, подписки на GOOSE/SV, значения и уставки. Результат выдаётся в виде доли успешно импортированной конфигурации в процентах. Такой подход позволяет не ограничиваться бинарной оценкой успешности импорта, а получить более точное представление о том, насколько полно инструмент производителя сохраняет конфигурацию.
Этап 4 завершает предложенную методологию и направлен на оценку готовности ICT-инструмента к работе на ВАПС. В настоящей статье данный этап описан на концептуальном уровне и рассматривается, как направление дальнейших этапов испытаний.
Что показали результаты
В испытаниях участвовало девять производителей ИЭУ и шесть системных конфигураторов. Конкретные названия не раскрываются — далее приведены агрегированные показатели.
Результаты этапа 1 — проверка ICD
В проанализированных файлах девяти производителей набралось в сумме более 300 ошибок и почти столько же предупреждений. Распределение проблем по классам проверок показало типичную картину начальной зрелости:
- подавляющее большинство замечаний относится к требованиям NSD — в первую очередь отсутствующие обязательные элементы (presCond = M) в классах логических узлов;
- значительная часть замечаний — к нарушениям семантических ограничений OCL (корректность ссылок между типами, связность структур);
- нарушения синтаксической схемы XSD встречаются единично, что подтверждает: на поверхностном уровне файлы «выглядят» валидно, а проблемы скрыты в семантике модели.
Результаты этапа 2 — проверка SSD/SCD
В рамках данного этапа приведены результаты проверки по одному SSD- и одному SCD-файлу для каждого производителя SCT. При этом каждый производитель формировал SCD-файлы как для собственных устройств, так и для устройств других участников тестирования. В настоящей работе представлены результаты, полученные для конфигураций собственных устройств (то есть при совпадении производителя ICD и SCT), что позволило минимизировать влияние межвендорной совместимости и особенностей сторонних решений.
По SSD: пять проверенных файлов успешно прошли проверку на соответствие стандарту МЭК 61850, один файл содержит ошибки. При этом проверка на соответствие корпоративному профилю ПАО «Россети» выявила несоответствия во всех случаях (6 из 6), что указывает на недостаточную ориентированность инструментов SST на выполнение корпоративных требований заказчика.
По SCD: четыре файла успешно прошли проверку на соответствие стандарту, тогда как в двух случаях выявлены ошибки. В то же время все шесть предоставленных SCD, сформированных с учётом требований корпоративного профиля ПАО «Россети», успешно прошли проверку на соответствие данному профилю (6 из 6), что свидетельствует о корректной реализации требований в части конфигурации GOOSE, SV и MMS.
Дополнительно следует отметить, что ошибки, присутствующие в исходных ICD-файлах, не учитывались: в случаях, когда инструменты SCT переносили такие ошибки в SCD-файл без изменений, они не рассматривались как ошибки, внесённые на этапе формирования SCD.
Результаты этапа 3 — совместимость SCT × ИЭУ
Для каждой пары «SCT производителя N / ICD производителя M» оценка была агрегирована по трём типам устройств (ПАС, ПДС, РЗА) по консервативному правилу «худший статус побеждает». Из 68 проанализированных пар, где SCT сумел сформировать SCD:
- 37 пар (54%) получили статус «Допустимо» — SCT не внёс изменений, нарушающих целостность модели;
- 16 пар (24%) — «Сомнительно» — изменения присутствуют, но не обязательно приводят к ошибке импорта;
- 15 пар (22%) — «Критично» — высока вероятность, что устройство не сможет работать по полученному SCD.
Показателен разрыв между «внутренней» и «межвендорной» совместимостью. Когда SCT и ICD принадлежали одному производителю (10 пар), статус «Допустимо» получили 80 %, а ни одного «Критично» не зафиксировано. В остальных 58 парах распределение становится принципиально хуже: доля «Допустимо» падает до 50 % (29 пар), «Сомнительно» — около 24 % (14 пар), а «Критично» возрастает до 26 % (15 пар). Иными словами, почти каждая четвёртая межвендорная пара сопровождается высокой вероятностью того, что устройство не сможет работать по полученному SCD.
Роль Теквел: эффект от участия
Роль Теквел в испытаниях не сводилась только к предоставлению инструментария. Компания уже более десяти лет участвует в развитии стандарта МЭК 61850 и поддерживает инициативы ПАО «Россети», поэтому на каждом из трёх проводимых этапов выступала как независимая инженерная экспертиза:
-
Методическая работа. В рамках подготовки Теквел формализовал своё представление понятия «совместимость SCT» — как условие неизменности ICD-модели с точностью до разрешённых производителем правок. Это дало участникам испытаний общий язык и критерии («Допустимо / Сомнительно / Критично»), по которым можно обсуждать результаты.
-
Автоматизация проверок. ПО «Теквел Парк Сервер» и «Теквел Магия» заменили ручной анализ файлов, который в проектах современного масштаба (десятки и сотни тысяч строк SCL) просто невозможно выполнить человеком за разумное время. За счёт этого испытания удалось провести в комплексном формате, а не выборочно.
-
Точная локализация расхождений. В отчёте Теквел производитель системного конфигуратора получает не общее сообщение о несовпадении файлов, а конкретные указания на элементы модели, атрибуты и строки, в которых выявлены отклонения. Это позволяет использовать отчёт не только для фиксации проблемы, но и как инструмент для её оперативного устранения.
-
Независимая экспертная роль. Теквел не разрабатывает конкурирующих SCT/ICT-инструментов — компания предоставляет средства верификации и испытаний, что снимает конфликт интересов и позволило выступить в роли независимого аналитического центра.
В совокупности это тот эффект, который хотела получить компания — «дать ценность заказчику и производителям»: не просто провести проверки, а оставить после себя инструменты, критерии и практики, которые могут помогать в дальнейшей работе — уже в рамках следующих испытаний.
Выводы и ближайшие шаги
Первый этап работ позволил зафиксировать текущий уровень зрелости и совместимости программных инструментов МЭК 61850 в отрасли. Полученные результаты показывают, что при переходе к межвендорному взаимодействию для ряда решений сохраняются области, требующие дополнительной проработки. В то же время выявление таких зон подтверждает практическую значимость проведённых испытаний и формирует основу для дальнейшего повышения уровня совместимости.
Важно отметить, что данные испытания проводились впервые, при этом достигнутый уровень результатов можно оценить как достаточно высокий. Несмотря на сжатые сроки подготовки, в тестировании приняли участие многие производители, что дополнительно подчёркивает репрезентативность полученных данных. В целом, для пилотной проверки такого масштаба достигнутые показатели можно считать успешными.
Особую роль в развитии данного направления играет инициатива ПАО «Россети», которые последовательно поддерживают проведение подобных испытаний. Благодаря этому у отрасли формируется не только площадка для выявления проблем, но и устойчивый механизм их системного обсуждения и последующего устранения на уровне производителей и разработчиков программного обеспечения.
Переход к сквозной автоматизированной проверке позволяет выявлять системные проблемы совместимости и предоставляет производителям структурированный перечень необходимых доработок. Компания Теквел, в свою очередь, планирует и дальше развивать набор правил OCL, а также инструменты «Теквел Парк Сервер» и «Теквел Магия» в логике подобных сценариев проверки, чтобы следующая итерация испытаний могла быть еще более технически совершенной.