Тестирование инструментов конфигурирования SCT/ICT на мероприятиях UCAIug IEC 61850 IOP: методология, эволюция и результаты

Главный вывод пятнадцатилетней истории IOP: качество SCL-файлов — прежде всего ICD, генерируемых ICT-инструментами вендоров, — остаётся критическим узким местом мультивендорной интеграции. На IOP 2019 только 10 из 159 файлов ICD (6,28%) прошли валидацию без ошибок, что привело к фундаментальному пересмотру философии тестирования UCAIug: с 2020 года ICT-функциональность стала обязательной частью сертификационных испытаний IED. Параллельно выросла роль машиночитаемых правил валидации (OCL), а IOP 2024 выявил более 120 проблем, подавляющее большинство из которых связано с SCL-файлами. Эти результаты транслируются напрямую в IEC TC 57 WG10 через механизм User Feedback Task Force и базу TISSUE, влияя на развитие самого стандарта IEC 61850-6.

История и хронология мероприятий UCAIug IOP

UCA International Users Group (UCAIug) — некоммерческая организация, продвигающая интеграцию и совместимость систем электроэнергетики на базе международных стандартов. Организация является зонтичной структурой для трёх пользовательских групп: CIM, IEC 61850 и OpenFMB. В области IEC 61850 UCAIug выполняет три ключевые функции: аккредитация испытательных лабораторий для сертификационного тестирования, сертификация результатов conformance-тестов, а также организация мероприятий по тестированию совместимости (Interoperability Testing — IOP).

IOP-мероприятия проводятся раз в два года с 2011 года. Принципиальное отличие IOP от conformance-тестирования: если conformance-тесты проверяют соответствие конкретного устройства стандарту, то IOP нацелен на выявление тех участков стандарта, которые допускают различные интерпретации и могут помешать обмену информацией между сертифицированными устройствами разных вендоров.

Важно отметить: начиная с цикла 2021–2022, каждый IOP разделён на виртуальный SCL-компонент (тестирование обмена файлами конфигурации) и очный F2F-компонент (функциональное тестирование с реальным оборудованием), проводимые с интервалом в несколько месяцев.

Когда тестирование инструментов конфигурирования стало отдельным направлением

Эволюция подхода к тестированию SCT/ICT — одна из наиболее показательных тенденций в истории IOP.

На IOP 2011 в Париже тестирование SCL-обмена было обязательным для всех участников (каждый вендор должен был представить ICD и/или CID), но проводилось как вспомогательная активность без выделенного трека. Основной вывод: «Не существует полноценного инструмента валидации SCL» — XML-валидация оказалась недостаточной для проверки соответствия IEC 61850-6, а реализации не могли корректно интерпретировать XSD без глубокого чтения стандарта.

На IOP 2013 в Мюнхене инженерный рабочий процесс (top-down и bottom-up) впервые стал одной из основных тестовых областей. Именно здесь были обнаружены «многочисленные проблемы, связанные с конфигурированием устройств и инженерным процессом на базе SCL» (по данным DNV), что послужило катализатором для разработки формализованных процедур тестирования инструментов.

В 2015 году DNV GL инициировал разработку первых conformance-процедур для SCT и ICT: «DNV GL is working with the UCAIug to develop the first release of the conformance test procedures for Substation engineering and device configuration tools». На IOP 2015 в Брюсселе при участии ENTSO-E было проведено первое глубокое тестирование SCL-процессов, а результаты немедленно представлены на заседании IEC TC57 WG10, которое стратегически запланировали на следующую неделю в том же здании ENTSO-E.

Формально выделенный трек SCT появился на IOP 2019: мероприятие было разделено на два независимых тестовых направления — (1) обмен SCL между System Configuration Tools и (2) integrated application. Это стало поворотным моментом, после которого тестирование инструментов конфигурирования приобрело системный характер.

Методология тестирования SCT/ICT

Процедурная база

Тестирование SCT/ICT опирается на несколько уровней документации. UCAIug Test Procedure Working Group (TPWG) разрабатывает и поддерживает процедуры тестирования, отслеживая проблемы через систему Redmine (redmine.ucaiug.org) с выделенными подпроектами: SCL Tooling, Server, Client, GOOSE Performance. Процедуры для SCT и ICT были разработаны DNV GL на базе Edition 2, аккредитованы UCAIug и включают тест-кейсы с индексами вида sCnf (conformance), sDs (DataSet), sSvp (Sampled Values) и др.

Базовый стандарт IEC 61850-10 (Ed.2, 2012) определяет методы и абстрактные тест-кейсы, но конкретные процедуры для SCT/ICT вышли за его рамки и были разработаны UCAIug совместно с производителями. С развитием стандарта к ним добавляются правила IEC 61850-6-3 — машиночитаемые правила верификации SCL на базе OCL (Object Constraint Language), которые впервые широко применялись на IOP 2024.

Типы SCL-файлов в тестировании

Все шесть типов файлов IEC 61850-6 участвуют в тестировании IOP, хотя их роль существенно менялась от мероприятия к мероприятию:

Тестируемые инженерные рабочие процессы

Top-down подход — основной метод, продвигаемый стандартом и наиболее активно тестируемый на IOP начиная с 2019 года. Процесс включает создание SSD с однолинейной схемой, импорт ICD-файлов от всех вендоров в SCT, назначение IED функциям, конфигурирование GOOSE/SV-подписок, блоков отчётов, параметров связи и генерацию SCD, далее импорт SCD в вендор-специфичные ICT для извлечения CID, и наконец загрузку CID в физические IED. На IOP 2021 этот процесс был отработан от начала до конца с привлечением независимого интегратора POWER Engineers. Один из SCT работал сверху вниз (создание виртуальных IED → определение потоков данных → наложение реальных ICD), второй — снизу вверх (от ICD-файлов к привязке сигналов).

Bottom-up подход предполагает индивидуальную конфигурацию IED через вендор-специфичные ICT, генерацию IID/CID-файлов и последующий импорт в SCT для системной интеграции (адресация, межсоединения). Этот подход остаётся необходимым, когда top-down инструменты не могут обработать вендор-специфичные особенности подписки.

Round-trip engineering — итеративный обмен между SCT и ICT, когда изменения на системном уровне (SCD) передаются обратно в ICT (через IID), а изменения ICT возвращаются в SCT. На IOP этот процесс тестировался неявно при каждом цикле итерации SCD→ICT→обратная связь→коррекция SCD. На IOP 2021 POWER Engineers описали процесс так: SCD передавался вендорам на контрольных точках, вендоры импортировали его в ICT, сообщали об ошибках, после чего следовал итеративный цикл обмена.

Эволюция тестирования по редакциям стандарта

Эра Edition 1 (IOP 2011)

IOP 2011 работал исключительно с Ed.1 SCL (схема 2003 года). Доступны были только типы файлов ICD, SSD, SCD, CID — без IID и SED. Основное тестирование покрывало MMS Client/Server, базовый GOOSE, начальные SV (9-2). Тестирование SCT/ICT ограничивалось обменом CID-файлами и базовым созданием SCD. Ключевые выводы Ed.1-эры: XSD-валидация не эквивалентна SCL-валидации; отсутствовал валидированный релиз XSD с исправлениями TISSUE; «хороший процент обнаруженных проблем уже был решён в Edition 2».

Переход к Edition 2 (IOP 2013, 2015, 2017)

IOP 2013 стал первым мероприятием, на котором тестировались возможности Edition 2: новые типы файлов IID и SED, обратная совместимость с Ed.1, расширенная секция Services. Проблемы, зафиксированные в Redmine и переданные в WG10, включали: вопросы обработки пространств имён (Issue #445), смешивание моделей данных Ed.1 и Ed.2 в одном SCL-файле (Issue #444), неясный формат ClientLN для резервирования RCB (Issue #446), использование ExtRef для подписки GOOSE и SV (Issue #445), управление типами данных в DataSets для GOOSE-подписки (Issue #463).

На IOP 2015 при участии ENTSO-E был разработан обобщённый инженерный процесс и выведены из него тест-кейсы — впервые SCL-область тестировалась столь глубоко. Результаты немедленно передавались в WG10: «большинство проблем, обнаруженных на IOP 2015, удалось решить во время заседания WG». Более того, именно IOP-результаты стали одной из причин задержки публикации IEC 61850-6 Ed.2.1 CDV — чтобы успеть включить исправления.

IOP 2017 в Новом Орлеане принёс принципиальное изменение парадигмы: переход от парного тестирования к интегрированному приложению — моделированию реальной подстанции с распределением устройств по функциям. Для этого SCT-инструменты использовались для проектирования мультивендорной системы, хотя формальный план тестирования SCT подготовлен не был (это было учтено как lesson learned для IOP 2019). Среди обнаруженных проблем — отсутствие в IEC 61850-6 возможности описать конфигурацию аутентификации для клиента (Issue IOP_2017/8).

Эра Edition 2.1 (IOP 2019, 2021–2022, 2023–2024)

IOP 2019 стал переломным для тестирования SCT/ICT. Результат валидации 159 ICD-файлов через 5 инструментов — только 6,28% без ошибок — привёл к фундаментальному пересмотру философии тестирования: ICT-функциональность включена в обязательные conformance-тесты IED для Ed.2 Amendment 1. Отдельные conformance-тесты для SCT и ICT также были усилены.

На IOP 2021–2022 впервые два SCT работали параллельно над созданием SCD для одной и той же подстанции. Один SCT использовал top-down подход (виртуальные IED → потоки данных → наложение ICD), второй — bottom-up (от ICD к привязке сигналов). Независимый интегратор POWER Engineers впервые выступил в роли нейтрального разработчика SCD. Для функционального тестирования в Милане было проведено 7 end-to-end тестов цифровой подстанции, включая заказной тест бельгийского TSO Elia, который выявил неожиданную проблему: некоторые IED блокировали защиту при потере PTP-синхронизации. Впервые протестированы: функциональная ADMS на базе IEC 61850, secure R-GOOSE через маршрутизируемую среду с Key Distribution Center (KDC).

IOP 2023–2024 ознаменовал несколько принципиальных нововведений. Виртуальный SCL IOP (декабрь 2023) впервые широко применил OCL-правила для валидации ICD-файлов, а также протестировал автоматическую конфигурацию сетевого оборудования на основе SCD-файла. Очный IOP в Бирмингеме (сентябрь 2024) внедрил подход на основе Basic Application Profiles (BAP) по IEC 61850-7-6: вместо одной большой подстанции проектировались типовые ячейки с ролями IED (LPU, BCU, PIU) и произвольными комбинациями вендоров. SSD-файл специфицировал все функции (LN) и сигналы; BAP определяли, какие сигналы устройство с конкретной функцией должно генерировать или потреблять. Однако, как отметил Christoph Brunner (конвенор WG10): «Во время подготовки IOP24 мы обнаружили, что многие ICD-файлы от различных вендоров содержали неполные или некорректные элементы Services» — в частности, проблемы с ClientServices (при отсутствии атрибута goose SCT считает устройство неспособным подписываться на GOOSE) и valKind/valImport (устройства по-прежнему используют valKind=«Conf», что Brunner считает неприемлемым для современных IED). Из 120+ обнаруженных проблем большинство относились к SCL и были найдены новыми OCL-правилами.

Результаты, проблемы и инструменты-участники

Участвовавшие SCT и ICT

Следует подчеркнуть: полные списки участников не публикуются — приведённые данные основаны на публично доступных источниках (статьи PAC World, блоги вендоров, LinkedIn).

Типичные проблемы совместимости инструментов

Обработка пространств имён (namespaces) — хронически проблемная область. Вендоры используют проприетарные пространства имён в приватных секциях без предоставления соответствующих XSD-схем, что делает невозможной корректную валидацию. IEC 61850-7-1 (раздел 14.2) определяет пространства имён для ldNs, lnNs, dataNs, cdcNs — вендор-специфичные пространства имён могут модифицироваться только вендорским ICT, но не SCT. На IOP 2013 смешивание моделей данных Ed.1 и Ed.2 в одном SCL-файле (Issue #444) стало одной из центральных проблем.

Приватные секции остаются источником несовместимости. SCT-инструменты зачастую не могут обработать проприетарные данные в Private-элементах от IED-вендоров. Когда уставки защиты моделируются в приватных секциях (а не через стандартные объекты данных IEC 61850), SCT не может манипулировать этими данными или сохранять их при преобразовании файлов. Потеря информации при конвертации SCL-файлов (ICD→SCD→CID) — документированная проблема: ряд инструментов теряет описания (desc), единицы измерения (unit), имена устройств (IEDName) или объявления multicast-подписчиков.

Несоответствия DataTypeTemplates возникают, когда производители модифицируют или расширяют типы данных стандарта без соблюдения установленных процедур. Нестандартные типы данных не распознаются оборудованием других вендоров. Характерная ошибка валидации: «FCDA does not refer any existing DA or BDA in DataTypeTemplates section». Некоторые производители модифицируют XSD для ослабления ограничений — файлы проходят внутреннюю валидацию, но отвергаются другими инструментами.

Конфликты адресов и блоков управления: GOOSE AppID, MAC-адреса, IP-адреса должны координироваться через SCT, но разные вендоры по-разному реализуют GSESettings, ReportSettings, SMVSettings (Fix vs. Conf vs. Dyn). Нарушение конвенций именования (длина, спецсимволы) — распространённая проблема, которую не все инструменты обнаруживают.

Конфигурация подписки GOOSE/SV — «наиболее сложная часть» мультивендорного тестирования (GE Vernova). Привязка подписки через ExtRef-элементы значительно различается между вендорами. На практике часто требуется bottom-up подход, при котором каждый ICT самостоятельно конфигурирует приём GOOSE-сообщений от устройств других производителей.

Работа с большими SCD-файлами: реальные SCD могут содержать более миллиона строк кода, что делает их практически неинтерпретируемыми для человека. На крупных проектах (например, 2300 IED) отмечены проблемы производительности и сбои SCT-инструментов, в ряде случаев требующие разбиения проекта на части.

Секция Services — проблема, вновь обострившаяся на IOP 2024. Многие ICD-файлы содержали неполные или некорректные элементы Services, из-за чего SCT не могли определить разрешённые операции с устройством. Особенно критична ситуация с ClientServices: при отсутствии атрибута goose (по умолчанию — false) SCT считает устройство неспособным подписываться на GOOSE. Проблемы valKind/valImport также сохраняются: устройства по-прежнему используют valKind=«Conf» (значение в SCL, но не видно в коммуникационной модели данных), что несовместимо с ожиданиями современных SCT.

Достижения и позитивная динамика

Несмотря на хронические проблемы, динамика тестирования демонстрирует устойчивый прогресс. По данным IOP 2015, в области Client/Server выявлено всего 4 проблемы (против 15 в 2013); проблем с GOOSE не обнаружено вовсе. ENTSO-E констатировал: «IOP показал, что части стандарта IEC 61850 и продукты очень стабильны… нет необходимости ждать для применения IEC 61850».

Привлечение независимого интегратора (POWER Engineers с 2021) валидировало рабочий процесс инжиниринга с пользовательской, а не вендорской точки зрения. Появление open-source SCT (OpenSCD/CoMPAS, проект LF Energy) — парадигмальный сдвиг: Transpower NZ к 2024 году реализовал полный рабочий процесс на базе OpenSCD, создавая единый SCD-файл для всей подстанции без вендорной привязки.

Автоматическая конфигурация сетевого оборудования из SCD-файла, впервые продемонстрированная на IOP 2024, открывает путь к значительному сокращению затрат на ввод в эксплуатацию цифровых подстанций. Первый мультивендорный secure R-GOOSE с распределением ключей и политик безопасности — ещё одно важное достижение IOP 2024.

Влияние на стандарт IEC 61850 и смежные документы

Связь между IOP и развитием стандарта носит двунаправленный и тесный характер. Прямой канал (IOP → WG10) реализован через IEC 61850 User Feedback Task Force, поддерживаемую UCAIug через систему Redmine, и через базу TISSUE (Technical ISSUE, iec61850.tissue-db.com). Обнаруженные на IOP стандартные проблемы формально подаются через национальные комитеты IEC в TC57/WG10. Пример: все 9 стандартных проблем IOP 2019 были поданы, рассмотрены и разрешены WG10. На IOP 2015 результаты были представлены WG10 на следующий день после окончания тестирования, и «большинство проблем удалось решить в ходе заседания рабочей группы». Задержка публикации IEC 61850-6 Ed.2.1 CDV частично объясняется необходимостью включить решения, найденные на IOP.

Обратный канал (WG10 → IOP) выражается в том, что WG10 разрабатывает OCL-правила валидации, которые тестируются на IOP, а результаты тестирования определяют необходимость дополнительных правил. IEC 61850-6-3 (в разработке) формализует эти машиночитаемые правила. Кадровое пересечение усиливает интеграцию: Herbert Falk — одновременно вице-президент UCAIug по тестированию и редактор IEC 61850; Christoph Brunner — конвенор WG10 и активный участник/аналитик IOP.

IOP также повлиял на развитие IEC 61850-6 Amendment 2 (2024), который ввёл UUID-идентификацию элементов (ICT создаёт UUID для элементов в ICD; SCT генерирует новый instance UUID в контексте SCD, сохраняя template UUID), элемент SclFileReference для ссылок между SCL-файлами и улучшенное отслеживание прав инжиниринга.

Результаты IOP нашли отражение в технических брошюрах CIGRE: TB 819 (WG B5.50, 2020) — ожидания пользователей и взаимодействие заинтересованных сторон для систем автоматизации на базе IEC 61850, где отмечено, что «из-за ограниченной совместимости продуктов IEC 61850 и высокой сложности стандарта… ряд проектов столкнулся с серьёзными трудностями». WG B5.68 (Terms of Reference, 2018) — «Optimisation of the IEC 61850 PACS Engineering Process and Tools» — прямо адресует требования к совместимости инструментов конфигурирования, гармонизацию инженерного процесса, границу между гармонизацией и кастомизацией, use cases для частичной модификации конфигурации. TB 401 предоставляет структурированный метод функционального тестирования систем IEC 61850.

Временная шкала эволюции тестирования SCT/ICT

Заключение: стратегические выводы для рынка инструментов конфигурирования

Пятнадцатилетняя история IOP демонстрирует несколько фундаментальных тенденций, критически важных для разработчиков SCT/ICT. Во-первых, качество ICD/IID-файлов — ахиллесова пята мультивендорной интеграции, и включение ICT-тестирования в обязательную сертификацию IED создаёт новый рыночный императив для IED-вендоров. Во-вторых, машиночитаемая валидация (OCL) вытесняет XSD-валидацию как основной инструмент проверки SCL-файлов — инвестиции в поддержку OCL-правил IEC 61850-6-3 становятся стратегическими. В-третьих, подход BAP (IEC 61850-7-6) и автоконфигурация сетевого оборудования из SCD определяют вектор развития инжиниринга цифровых подстанций на ближайшие годы. В-четвёртых, появление open-source SCT (OpenSCD) и независимых интеграторов сигнализирует о деконцентрации рынка инструментов конфигурирования, где конкурентным преимуществом становится не только функциональность, но и способность к бесшовной мультивендорной интеграции.

Наконец, каждый IOP подтверждает: top-down инжиниринг остаётся правильным подходом, но практические препятствия к его полноценной реализации — различные интерпретации стандарта, проблемы с приватными секциями и Services-элементами — по-прежнему требуют гибридных решений. IOP 2026 в Европе, с учётом дальнейшего развития IEC 61850-6-3 (OCL), IEC 61850-90-30 (функциональное моделирование) и Edition 2 IEC 61850-7-6 (BAP в SCL-формате), обещает стать следующей контрольной точкой зрелости инструментов конфигурирования.