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

Жизненный цикл цифровой подстанции — ключевые SCL-файлы и инструменты
Жизненный цикл цифровой подстанции — ключевые SCL-файлы и инструменты

Рис. 1. Жизненный цикл цифровой подстанции — ключевые SCL-файлы и инструменты

Для того чтобы технологический процесс работал корректно, все звенья — инструмент формирования спецификации системы (SST), системный конфигуратор (SCT) и конфигуратор устройств производителя (ICT) — должны одинаково понимать SCL-конфигурацию и корректно с ней работать. Именно вопрос реальной совместимости программных средств разных производителей и стал предметом первых в отрасли испытаний зрелости программных инструментов, выполненных в рамках работы ПАО «Россети».

В этих испытаниях ООО «Теквел» выступила в роли независимой экспертной организации: компания предложила методику проверки, предоставила программное обеспечение «Теквел Парк Сервер» и «Теквел Магия» с функционалом, разработанным специально для испытаний, и провела полный анализ предоставленных производителями файлов ICD, SSD и SCD с оценкой совместимости и готовности инструментов.

Такой подход позволил не ограничиваться чек-листом возможностей производителей, а дополнить программу испытаний и повысить ценность результатов. В итоге была получена объективная техническая картина: где именно в цепочке работы с SCL возникают проблемы совместимости инструментов и насколько инструменты производителей готовы к работе в жизненном цикле ВАПС.

Определение подхода к испытаниям

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

Критически уязвимые этапы жизненного цикла, на которых сходятся программные инструменты разных производителей
Критически уязвимые этапы жизненного цикла, на которых сходятся программные инструменты разных производителей

Рис. 2. Критически уязвимые этапы жизненного цикла, на которых сходятся программные инструменты разных производителей

На основании семилетнего опыта компании в инжиниринге и пуско-наладочных работах ВАПС было выделено наиболее уязвимое место — применение SCD-файла при настройке терминалов. Именно на этом этапе сходятся инструменты разных производителей, и именно здесь становится видно, насколько технологический процесс ВАПС реализуем на практике. При этом влияние на результат начинается уже на стадии проектирования, поэтому проверку целесообразно начинать именно с нее. Для локализации источника ошибок была необходима поэтапная проверка, позволяющая определить, каким именно инструментом вносится нарушение.

Четыре вопроса, на которые отвечают испытания

Структурно испытания были разделены на четыре этапа.

Структура испытаний: четыре этапа проверки совместимости и готовности ПО
Структура испытаний: четыре этапа проверки совместимости и готовности ПО

Рис. 3. Структура испытаний: четыре этапа проверки совместимости и готовности ПО

Этап 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

{
  "title": { "text": "Результаты проверки ICD-файлов у 9 производителей", "left": "center", "textStyle": { "fontSize": 14 } },
  "tooltip": { "trigger": "axis", "axisPointer": { "type": "shadow" } },
  "legend": { "data": ["Пройдено (ДА)", "Ошибки (НЕТ)", "Н/П / нет файла"], "bottom": 0 },
  "grid": { "left": "3%", "right": "4%", "bottom": "15%", "containLabel": true },
  "xAxis": {
    "type": "category",
    "data": ["Соответствие МЭК 61850", "Соответствие корп. профилю"],
    "axisLabel": { "interval": 0 }
  },
  "yAxis": { "type": "value", "name": "ИЭУ × производитель", "max": 27 },
  "series": [
    {
      "name": "Пройдено (ДА)",
      "type": "bar",
      "stack": "total",
      "data": [13, 8],
      "itemStyle": { "color": "#67C23A" },
      "label": { "show": true, "formatter": "{c}" }
    },
    {
      "name": "Ошибки (НЕТ)",
      "type": "bar",
      "stack": "total",
      "data": [5, 10],
      "itemStyle": { "color": "#F56C6C" },
      "label": { "show": true, "formatter": "{c}" }
    },
    {
      "name": "Н/П / нет файла",
      "type": "bar",
      "stack": "total",
      "data": [9, 9],
      "itemStyle": { "color": "#C8C8C8" },
      "label": { "show": true, "formatter": "{c}" }
    }
  ]
}

Рис. 4. Результаты проверки ICD-файлов у 9 производителей

В проанализированных файлах девяти производителей набралось в сумме более 300 ошибок и почти столько же предупреждений. Распределение проблем по классам проверок показало типичную картину начальной зрелости:

  • подавляющее большинство замечаний относится к требованиям NSD — в первую очередь отсутствующие обязательные элементы (presCond = M) в классах логических узлов;
  • значительная часть замечаний — к нарушениям семантических ограничений OCL (корректность ссылок между типами, связность структур);
  • нарушения синтаксической схемы XSD встречаются единично, что подтверждает: на поверхностном уровне файлы «выглядят» валидно, а проблемы скрыты в семантике модели.

Результаты этапа 2 — проверка SSD/SCD

{
  "title": { "text": "Результаты проверки SSD/SCD-файлов", "left": "center", "textStyle": { "fontSize": 14 } },
  "tooltip": { "trigger": "axis", "axisPointer": { "type": "shadow" } },
  "legend": { "data": ["Пройдено (ДА)", "Ошибки (НЕТ)", "Н/П / нет файла"], "bottom": 0 },
  "grid": { "left": "3%", "right": "4%", "bottom": "15%", "containLabel": true },
  "xAxis": {
    "type": "category",
    "data": [
      "SSD: МЭК 61850",
      "SSD: корп. профиль",
      "SCD: МЭК 61850",
      "SCD: корп. профиль"
    ],
    "axisLabel": { "interval": 0, "fontSize": 11 }
  },
  "yAxis": { "type": "value", "name": "ИЭУ × производитель", "max": 27 },
  "series": [
    {
      "name": "Пройдено (ДА)",
      "type": "bar",
      "stack": "total",
      "data": [1, 0, 2, 6],
      "itemStyle": { "color": "#67C23A" },
      "label": { "show": true, "formatter": "{c}" }
    },
    {
      "name": "Ошибки (НЕТ)",
      "type": "bar",
      "stack": "total",
      "data": [3, 6, 4, 0],
      "itemStyle": { "color": "#F56C6C" },
      "label": { "show": true, "formatter": "{c}" }
    },
    {
      "name": "Н/П / нет файла",
      "type": "bar",
      "stack": "total",
      "data": [23, 21, 21, 21],
      "itemStyle": { "color": "#C8C8C8" },
      "label": { "show": true, "formatter": "{c}" }
    }
  ]
}

Рис. 5. Результаты проверки SSD/SCD-файлов у 9 производителей

Количество предоставленных файлов на этом этапе значительно меньше — не все участники подготовили SSD/SCD для каждого типа устройств. Из девяти производителей SSD-файлы предоставили четыре, SCD-файлы — шесть.

По SSD: лишь один комплект прошёл проверку на соответствие стандарту МЭК 61850, три выявили ошибки конфигурации. Ни один из шести проверенных комплектов не прошёл проверку на соответствие корпоративному профилю ПАО «Россети» — это говорит о том, что инструменты SST и SCT пока слабо ориентированы на корпоративные требования заказчика.

По SCD: два из шести комплектов полностью соответствуют требованиям стандарта, четыре содержат ошибки. Показательно, что по соответствию корпоративному профилю ПАО «Россети» все шесть производителей, предоставивших SCD-файлы с корпоративными параметрами, успешно прошли проверку — 6 из 6.

Результаты этапа 3 — совместимость SCT × ИЭУ

Критерии оценки результата преобразования ICD → SCD
Критерии оценки результата преобразования ICD → SCD

Рис. 6. Критерии оценки результата преобразования ICD → SCD

Для каждой пары «SCT производителя N / ICD производителя M» оценка была агрегирована по трём типам устройств (АМУ, ПДС, РЗА) по консервативному правилу «худший статус побеждает». Из 68 проанализированных пар, где SCT сумел сформировать SCD:

  • 37 пар (54%) получили статус «Допустимо» — SCT не внёс изменений, нарушающих целостность модели;
  • 16 пар (24%) — «Сомнительно» — изменения присутствуют, но не обязательно приводят к ошибке импорта;
  • 15 пар (22%) — «Критично» — высока вероятность, что устройство не сможет работать по полученному SCD.
{
  "title": { "text": "Результаты преобразования ICD → SCD: распределение по статусам совместимости", "textStyle": { "fontSize": 14 }, "left": "center" },
  "tooltip": { "trigger": "axis", "axisPointer": { "type": "shadow" } },
  "legend": { "data": ["Допустимо", "Сомнительно", "Критично"], "bottom": 0 },
  "grid": { "left": "3%", "right": "4%", "bottom": "15%", "containLabel": true },
  "xAxis": {
    "type": "category",
    "data": ["Все пары (68)", "Один производитель (10)", "Разные производители (58)"]
  },
  "yAxis": { "type": "value", "name": "Количество пар" },
  "series": [
    {
      "name": "Допустимо",
      "type": "bar",
      "stack": "total",
      "data": [37, 8, 29],
      "itemStyle": { "color": "#67C23A" },
      "label": { "show": true, "formatter": "{c}" }
    },
    {
      "name": "Сомнительно",
      "type": "bar",
      "stack": "total",
      "data": [16, 2, 14],
      "itemStyle": { "color": "#E6A23C" },
      "label": { "show": true, "formatter": "{c}" }
    },
    {
      "name": "Критично",
      "type": "bar",
      "stack": "total",
      "data": [15, 0, 15],
      "itemStyle": { "color": "#F56C6C" },
      "label": { "show": true, "formatter": "{c}" }
    }
  ]
}

Рис. 7. Сводные результаты преобразования ICD → SCD: распределение 68 пар «SCT — SCD» по статусам

Показателен разрыв между «внутренней» и «межвендорной» совместимостью. Когда SCT и ICD принадлежали одному производителю (10 пар), статус «Допустимо» получили 80 %, а ни одного «Критично» не зафиксировано. В остальных 58 парах распределение становится принципиально хуже: доля «Допустимо» падает до 50 % (29 пар), «Сомнительно» — около 24 % (14 пар), а «Критично» возрастает до 26 % (15 пар). Иными словами, почти каждая четвёртая межвендорная пара сопровождается высокой вероятностью того, что устройство не сможет работать по полученному SCD.

Роль Теквел: эффект от участия

Роль Теквел в испытаниях не сводилась только к предоставлению инструментария. Компания уже более десяти лет участвует в развитии стандарта МЭК 61850 и поддерживает инициативы ПАО «Россети», поэтому на каждом из трёх проводимых этапов выступала как независимая инженерная экспертиза:

  • Методическая работа. В рамках подготовки Теквел формализовал своё представление понятия «совместимость SCT» — как условие неизменности ICD-модели с точностью до разрешённых производителем правок. Это дало участникам испытаний общий язык и критерии («Допустимо / Сомнительно / Критично»), по которым можно обсуждать результаты.

  • Автоматизация проверок. ПО «Теквел Парк Сервер» и «Теквел Магия» заменили ручной анализ файлов, который в проектах современного масштаба (десятки и сотни тысяч строк SCL) просто невозможно выполнить человеком за разумное время. За счёт этого испытания удалось провести в комплексном формате, а не выборочно.

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

  • Независимая экспертная роль. Теквел не разрабатывает конкурирующих SCT/ICT-инструментов — компания предоставляет средства верификации и испытаний, что снимает конфликт интересов и позволило выступить в роли независимого аналитического центра.

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

Выводы и ближайшие шаги

Первый этап работ зафиксировал стартовую точку зрелости и совместимости программных инструментов МЭК 61850 в отрасли. Результаты показывают, что при переходе к межвендорному взаимодействию часть решений всё же попадает в зоны «Сомнительно» и «Критично» по совместимости. Вместе с тем именно такие результаты показывают ценность проведённых испытаний.

Особенно важно, что ПАО «Россети» проявляют инициативу и последовательно поддерживают проведение таких испытаний. Благодаря этому у отрасли появляется не только площадка для выявления проблем, но и механизм для их системного обсуждения и дальнейшего устранения на уровне производителей и разработчиков ПО.

Переход к сквозной автоматизированной проверке позволяет выявлять системные проблемы совместимости и даёт производителям понятный перечень того, что и где требуется исправить. Компания Теквел, в свою очередь, планирует развивать набор правил Tekvel-OCL и инструменты «Теквел Парк Сервер» и «Теквел Магия» именно в логике этих сценариев, чтобы следующая итерация испытаний могла быть выстроена по критериям, близким к реальной промышленной аттестации.