В инженерном процессе IEC 61850 появляется новый важный механизм проверки SCL-файлов — OCL (Object Constraint Language), язык формального описания ограничений и правил для объектов информационной модели.

В 2025 году была опубликована техническая спецификация IEC TS 61850-6-3 «Format of machine-processable rules for validation of IEC 61850 XML-based files». Она определяет формат и метод описания формальных правил OCL, которые могут импортироваться и интерпретироваться программными инструментами. В числе предусмотренных сценариев — проверка SCL-файлов на различных этапах спецификации и проектирования.

Причём речь идёт уже не только о перспективной технологии. OCL-проверки начинают применяться на практике, в том числе в России.

Почему XSD уже недостаточно

Основой формальной проверки SCL традиционно является XML Schema Definition — XSD.

С её помощью можно проверить структуру XML-документа:

  • допустим ли определённый элемент;
  • может ли он находиться в данном месте;
  • какие атрибуты для него предусмотрены;
  • является ли атрибут обязательным;
  • соответствует ли значение определённому типу данных.

Такая проверка необходима. Но её возможности ограничены самой природой XML Schema. XSD хорошо отвечает на вопрос: «Правильно ли построен XML-документ?»

Однако многие требования IEC 61850 связаны не со структурой отдельных XML-элементов, а с отношениями между различными объектами и параметрами модели.

Наличие одного объекта может требовать наличия другого. Значение одного атрибута может накладывать ограничения на значение другого. Допустимость определённой конфигурации может зависеть сразу от нескольких элементов SCL.

При этом каждый из этих элементов по отдельности может полностью соответствовать XML Schema.

XSD проверяет структуру одного элемента, OCL — взаимосвязи между объектами
Рис. 1. XSD отвечает за структуру отдельных элементов, OCL — за правила и взаимосвязи между объектами модели. Каждый элемент может быть корректным по отдельности, а нарушение возникать в связи их значений.

Что даёт OCL

OCL позволяет формально описывать правила примерно следующего вида: если выполняется условие A, то объект B должен существовать или иметь определённые свойства.

После этого такое правило может автоматически применяться к SCL-файлу, а обнаруженные нарушения — фиксироваться программным инструментом.

Простой пример связан с декларацией сервисных возможностей IED.

В разделе Services устройство описывает поддерживаемые им возможности, в том числе связанные с отчётами. Если IED заявляет значение maxReports > 0, то есть сообщает о возможности использования одного или нескольких Report Control Block, одновременно должна быть задекларирована поддержка хотя бы одного типа отчётов:

  • bufReport = true — поддерживаются буферизованные отчёты;
  • unbufReport = true — поддерживаются небуферизованные отчёты.

Либо могут поддерживаться оба типа.

Иначе возникает логическое противоречие: устройство заявляет возможность работы с отчётами, но одновременно не заявляет поддержку ни одного их типа.

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

Пример OCL-правила для декларации отчётов в разделе Services
Рис. 2. Пример OCL-правила: если IED заявляет maxReports > 0, он обязан задекларировать хотя бы один тип отчётов. С точки зрения XSD оба варианта корректны — противоречие видно только на уровне взаимосвязи значений.

Именно такие взаимосвязи позволяет формализовать и автоматически проверять OCL.

XSD проверяет прежде всего корректность структуры документа. OCL позволяет проверять правила, которым должна соответствовать описанная в нём модель.

От текста стандарта к машиночитаемому правилу

Сегодня значительная часть требований IEC 61850 существует в текстовом виде. Разработчик программного продукта, производитель устройства, проектировщик или эксперт должен прочитать соответствующий пункт стандарта, интерпретировать его и реализовать необходимую проверку самостоятельно.

OCL позволяет часть таких требований представить в формальном машиночитаемом виде. Такое правило, как «если выполняется условие X, элемент Y должен обладать свойством Z», может существовать как формальное правило, которое программный инструмент способен выполнить автоматически.

При этом IEC TS 61850-6-3 определяет именно формат и способ описания таких правил, а сами правила могут использоваться как машиночитаемые компоненты соответствующих частей IEC 61850.

За счёт этого проверка SCL становится более воспроизводимой и меньше зависит от ручной интерпретации требований конкретным специалистом.

OCL — один из акцентов UCAIug IOP

Особенно хорошо направление развития видно по международным испытаниям функциональной совместимости IEC 61850.

OCL-валидация уже применялась в предыдущих циклах UCAIug IOP при проверке SCL наряду с другими направлениями тестирования инструментов конфигурирования. Ошибки и несоответствия SCL традиционно остаются одним из заметных классов проблем, выявляемых на таких мероприятиях.

Следующей крупной контрольной точкой станет UCAIug IEC 61850 IOP 2026.

Очная часть международных испытаний пройдёт в Утрехте, Нидерланды. Основная программа испытаний запланирована на 12–16 октября 2026 года. Мероприятие станет площадкой для практической проверки взаимодействия устройств, шлюзов и программных инструментов IEC 61850 разных производителей.

С учётом развития IEC 61850-6-3 и уже накопленного опыта предыдущих IOP OCL и автоматизированная проверка SCL становятся одним из заметных направлений международных испытаний функциональной совместимости.

Это важный сигнал для отрасли: OCL постепенно переходит из категории нового механизма стандарта в практический инструментарий проверки качества инженерных данных IEC 61850.

OCL уже применяли на испытаниях функциональной совместимости в России

Практический опыт такого подхода уже получен и в России.

В 2026 году в рамках испытаний функциональной совместимости программных инструментов IEC 61850 компания «Теквел» обеспечивала методологическую и техническую поддержку автоматизированного анализа SCL-файлов.

О применявшейся методологии и результатах испытаний рассказала менеджер по техническому маркетингу компании «Теквел» Наталья Мараракина на заседании секции №3 «Технологии и оборудование для автоматизации систем управления в электрических сетях» Научно-технического совета ПАО «Россети».

Для автоматизированной экспертизы файлов использовалось ПО «Теквел Парк Сервер» для экспертизы цифровых проектов в формате файлов SSD и SCD.

Проверка включала несколько уровней:

  • соответствие SCL-файлов XML Schema;
  • проверку информационной модели по NSD;
  • проверку требований корпоративного профиля;
  • OCL-проверки требований IEC 61850 и корпоративной нормативной документации.

Для повышения полноты анализа специалистами «Теквел» было дополнительно реализовано порядка сотни автоматизированных проверок.

В испытаниях участвовали 9 производителей устройств, которыми было предоставлено в общей сложности 18 ICD-файлов.

Полученные результаты оказались показательными.

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

От проверки XML к проверке инженерных правил

SCL давно перестал быть просто XML-файлом для обмена конфигурацией между программами.

В современном инженерном процессе IEC 61850 SCL фактически становится цифровым описанием системы автоматизации подстанции.

Поэтому закономерно развивается и инструментарий его проверки:

  • XSD — правильно ли построен XML-документ?
  • NSD — соответствует ли используемая информационная модель требованиям IEC 61850?
  • OCL — выполняются ли более сложные правила и взаимосвязи между объектами этой модели?

Именно в этом заключается ключевая ценность OCL.

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

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