В 2026 году в рамках анализа зрелости решений МЭК 61850 основное внимание было сосредоточено на совместимости программных инструментов разных производителей: системных конфигураторов SCT, конфигураторов устройств ICT и корректности передачи информационной модели ИЭУ между ними.
Следующий этап, запланированный на 2027 год, существенно расширяет эту задачу. Проверка должна выйти за пределы анализа файлов и конфигураторов и перейти непосредственно к оборудованию: необходимо установить, действительно ли конфигурация, описанная в цифровом проекте, полностью загружена в устройство и соответствует ли фактическое поведение ИЭУ предусмотренным сценариям работы ВАПС.
Таким образом, происходит переход от проверки данных о системе к проверке самой системы.
Что показали испытания 2026 года
Методика 2026 года изначально строилась не как разовая демонстрация совместимости отдельных продуктов. Требовалось получить воспроизводимую процедуру, в которой результат не зависит от конкретного специалиста или производителя.
Для этого были сформулированы несколько принципов: наличие объективного критерия совместимости, формализованные сценарии получения результата, воспроизводимость, автоматизация и локализация каждого обнаруженного отклонения вплоть до конкретного элемента модели и требования МЭК 61850 или СТО ПАО «Россети».
Практика подтвердила, что одной формальной проверки SCL-файла по XSD недостаточно. При анализе 18 ICD-файлов девяти производителей было обнаружено более 50 ошибок и отклонений, при этом нарушения непосредственно XSD-схемы носили единичный характер. Существенная часть вопросов находилась на уровне информационной модели, семантики и требований корпоративного профиля.
Следующим шагом стала проверка того, что происходит с моделью ИЭУ при передаче ICD в системный конфигуратор и формировании SCD. Контролировались типы данных, логические узлы, неизменяемые значения, политики конфигурирования, ExtRef и другие элементы модели. Для 68 сочетаний SCT и ИЭУ 54% результатов попали в категорию «допустимо», 24% — «сомнительно», а в 22% были обнаружены критические отклонения. При этом выявленные проблемы не носили архитектурного характера.
На очном этапе проверялся более сложный цикл:
SCD₀ → изменение проекта → SCD₁ → изменение конфигурации устройства → IID → обновление проекта → SCD₂
При сравнении 92 пар SCL-файлов 88% случаев не содержали критических нарушений: в 78% были зафиксированы только предусмотренные изменения, ещё в 10% — дополнительные изменения без критического влияния. В 12% случаев обнаруживалась потеря подписок, связей или элементов модели. Критические ошибки также не были связаны с принципиальной несовместимостью архитектуры.
Всего мероприятие 2026 года охватило девять производителей ИЭУ, 12 SCT и ICT, 68 сочетаний SCT×ИЭУ, 69 SCD-файлов и 92 сравнения SCL-файлов на очном этапе.
При этом существующий подход не закрывал весь путь конфигурации от цифрового проекта до фактического состояния устройства.
Главный вопрос 2027 года: что на самом деле оказалось внутри ИЭУ?
Можно проверить исходный ICD. Можно проверить сформированный SSD или SCD. Можно установить, сохранил ли системный конфигуратор исходную модель ИЭУ.
Но остаётся ещё один этап: полностью ли ICT перенёс конфигурацию из SCD в реальное устройство?
Путь передачи модели и конфигурации ИЭУ разделён на четыре последовательных шага:
- ICD — корректна ли исходная модель ИЭУ?
- SSD / SCD — корректно ли сформирован цифровой проект?
- ICD → SCD — сохранил ли SCT модель устройства?
- SCD → ИЭУ — полностью ли ICT загрузил конфигурацию?
Первые три этапа стали предметом основной работы 2026 года. Четвёртый включён в планы на 2027 год.
Факт успешного импорта SCD в конфигуратор устройства сам по себе не подтверждает, что реальная конфигурация ИЭУ полностью соответствует цифровому проекту.
Поэтому после загрузки SCD через ICT предлагается считывать фактическую модель и конфигурацию непосредственно из устройства и сопоставлять их с исходным проектом.
Предусматривается считывание модели по MMS и автоматизированная проверка конфигурации MMS, GOOSE и Sampled Values на соответствие SCD. Результатом должен становиться протокол, показывающий полноту реально загруженной конфигурации.
Тем самым замыкается цифровая цепочка:
проект → SCD → ICT → ИЭУ → фактическая конфигурация → сравнение с проектом
Второе направление: проверка фактического поведения устройства
Полное совпадение конфигурации с SCD ещё не отвечает на вопрос о поведении устройства в реальной системе.
Поэтому вторым направлением испытаний 2027 года предлагается сделать проверку фактического поведения ИЭУ.
Этот этап обозначен как переход «от SCL-файлов к реальным ИЭУ». Базовые проверки 2026 года сохраняются, но к ним добавляются импорт SCD в реальное устройство и испытания его поведения в штатных и аварийных режимах. Результатом должны стать две независимые оценки: совместимость инструментов и корректность поведения устройства.
Устройство может быть корректно сконфигурировано с точки зрения SCL, но при этом по-разному реагировать на отдельные эксплуатационные ситуации. При этом разные варианты поведения могут быть обусловлены особенностями реализации конкретного производителя.
В ходе обсуждения, например, отмечались различия в реализации тестовых режимов. У разных производителей перевод устройства в test или test-block может по-разному влиять на физические выходы и сохранение изменённых параметров. Для эксплуатации подобные особенности необходимо выявлять и формализовать.
Какие режимы предлагается проверять
Предварительный перечень испытаний включает:
- поведение ИЭУ в тестовых режимах;
- штормовые испытания;
- реакцию на дублирующиеся пакеты;
- работу при различном статусе синхронизации SV-потоков;
- поведение при перезагрузке, включая проверку объёма конфигурации, сохраняемого в энергонезависимой памяти;
- функциональное поведение РЗА в различных штатных и аварийных сценариях.
Такой набор испытаний переносит проверку из области анализа статической конфигурации в область оценки поведения оборудования в условиях, приближенных к эксплуатации цифровой подстанции.
Для автоматизации этих сценариев испытательная система должна работать с основными механизмами МЭК 61850 — SV, GOOSE и MMS: формировать воздействия, контролировать обмен, фиксировать реакцию устройства, сравнивать её с ожидаемым поведением и автоматически формировать протокол. Такой подход представлен в материалах на примере программного обеспечения «Теквел Магия».
Воспроизводимость как обязательное свойство испытаний
Одним из базовых требований к методике остаётся воспроизводимость результатов.
Ручной сценарий, при котором специалист самостоятельно формирует SV-поток, переводит устройство в требуемый режим, контролирует GOOSE и затем экспертно оценивает результат, сложно повторить в идентичных условиях для десятков устройств и производителей.
Поэтому испытание должно строиться по формализованной последовательности:
сценарий → автоматическое воздействие → наблюдаемая реакция → ожидаемая реакция → результат → протокол
Такой подход позволяет повторить испытание после изменения версии программного обеспечения, сравнить устройства разных производителей и исключить влияние человеческого фактора.
Необходимость автоматизации была заложена ещё в методику 2026 года, когда значительное количество проверяемых файлов и сочетаний конфигураторов сделало ручной анализ трудоёмким. Одновременно требовалась точная локализация каждого выявленного отклонения.
В 2027 году этот же принцип переносится с анализа файлов на реальные ИЭУ.
Испытания как непрерывный процесс развития технологии
Анализ зрелости не рассматривается как аттестация производителя или обязательная процедура допуска оборудования. В ходе обсуждения отдельно подчёркивалось, что это добровольная площадка совместной работы заказчика, производителей и специалистов по испытаниям, предназначенная для выявления разночтений, уточнения требований и повышения совместимости решений.
Поэтому одна из задач 2027 года — не только расширить состав испытаний, но и повторить проверки 2026 года после устранения выявленных замечаний.
В плане на 2027 год повторная проверка исправлений выделена отдельным этапом.
Формируется последовательный цикл:
испытание → обнаружение отклонения → локализация причины → уточнение требований или корректировка продукта → повторное испытание
Такой подход позволяет использовать результаты испытаний не только для оценки текущего состояния решений, но и для последовательной корректировки требований, программных инструментов и оборудования.
От совместимости файлов — к проверке всей цифровой цепочки
В 2026 году основной вопрос можно сформулировать следующим образом:
«Могут ли программные инструменты разных производителей корректно передать друг другу цифровую модель?»
В 2027 году к нему добавляются ещё два:
«Полностью ли эта модель загружена в реальное устройство?»
«Соответствует ли фактическое поведение устройства требованиям и предусмотренным сценариям работы ВАПС?»
Таким образом, следующий этап анализа зрелости МЭК 61850 предполагает переход от проверки отдельных SCL-файлов и программных инструментов к воспроизводимым функциональным испытаниям реальных ИЭУ в мультивендорной цифровой среде — от проектной модели до фактической реакции оборудования.