В традиционном инжиниринге МЭК 61850 ошибки выявляются в самый неподходящий момент: во время пусконаладочных работ, когда оборудование уже доставлено на объект, команды мобилизованы, а сроки поджимают. Процесс top-down инжиниринга — формализованный в IEC TR 61850-90-30:2025 и IEC TR 61850-7-6 (Ed. 2) — переносит этот момент значительно раньше: до выбора первого IED (интеллектуального электронного устройства), до подписания контракта, до появления какого-либо физического устройства. В 2023 году четырнадцать европейских ТСО, включая Elia и 50Hertz, подписали Общую декларацию, подтвердив этот подход как направление развития инжиниринга цифровых подстанций. Первая статья серии рассматривала, почему отрасль движется в этом направлении и что стало основой консенсуса четырнадцати энергокомпаний. Настоящая статья объясняет механику: что происходит на каждом из пяти шагов, какие файлы обмениваются и почему процесс даёт лучшие результаты по сравнению с предшествующим подходом.

Почему подход снизу вверх не работает

Традиционный процесс МЭК 61850 начинается с IED. Вы получаете ICD-файл от поставщика, строите систему на основе возможностей устройства и передаёте требования через PDF-документы — которые каждый поставщик читает и интерпретирует самостоятельно. К моменту выявления несоответствий оборудование уже закуплено, проект зафиксирован, а исправления обходятся дорого. Процесс top-down полностью переворачивает эту последовательность: сначала функциональные требования определяются в машиночитаемом формате, проверяются без оборудования — и только затем передаются поставщикам в виде структурированной спецификации, которую они могут обработать в собственных инструментах.

Пять шагов: общая картина

Процесс состоит из пяти шагов, каждый из которых создаёт структурированный файл, служащий входными данными для следующего. Задействованы три категории инструментов: System Specification Tool (SST) — инструмент системной спецификации, используемый инженером энергокомпании; IED Configuration Tool (ICT) — инструмент конфигурации IED, используемый поставщиком; и System Configuration Tool (SCT) — инструмент системной конфигурации, снова используемый инженером энергокомпании. Вот как они взаимосвязаны:

flowchart LR
    A["Шаг 1\nСистемное профилирование\nFSD / ASD\n(SST)"] -->|"ASD files\n6-100 namespace"| B["Шаг 2\nСистемная спецификация\nISD / SSD\n(SST)"]
    B -->|"SSD\nв симуляцию"| C["Шаг 3\nМоделирование\nи верификация\n✅ итеративный цикл"]
    C -->|"пройдена: провалидированная SSD\n+ ISD поставщику"| D["Шаг 4\nВозможности IED\nprocess ICD (ICT)"]
    C -->|"не пройдена:\nна корректировку"| B
    D -->|"process ICD + SSD"| E["Шаг 5\nСистемная конфигурация\nSCD (SCT)"]
    E -->|"SCD"| F["Развёртывание\nIED"]

    style C fill:#d4f4dd,stroke:#2d9e5a

Все файлы используют формат SCL с расширениями пространства имён 6-100. Шаг 3 может включать итеративный цикл — моделирование интегрировано в процесс разработки спецификации: инженер специфицирует, тестирует и уточняет до подтверждения корректности поведения. ISD-файлы передаются поставщикам только после верификации спецификации.

Шаг 1: системное профилирование — функциональные шаблоны без привязки к поставщику

Шаг 1 создаёт функциональные строительные блоки, используемые на протяжении всего проекта. Системный инженер разрабатывает повторно используемые шаблоны — Function Specification Descriptions (FSD) и Application Specification Descriptions (ASD) — без какой-либо привязки к конкретному производителю IED или продуктовой линейке.

FSD описывает отдельную функцию защиты или управления: её логические узлы, сигналы и требуемые атрибуты данных. ASD объединяет несколько FSD в законченное приложение — например, приложение дистанционной защиты (P21) или приложение управления выключателем. ASD также содержит:

  • Data flow — как сигналы перемещаются между функциями, с аннотацией типа сервиса (GOOSE, SMV или внутренний) и направления
  • BehaviorDescription — функциональную логику, представленную либо в виде текстовых требований, либо формализованную как функциональные блочные диаграммы (FBD) по МЭК 61131-3
  • ProcessResources — заполнители для сигналов, ожидаемых от других приложений, которые ещё не включены в проект

Последний элемент важен. Когда приложение защиты ожидает поступления команды отключения на выключатель, это соединение не может быть полностью разрешено в рамках одного ASD — приложение CB является отдельным шаблоном. Поэтому оно моделируется как заполнитель ProcessResource и разрешается на Шаге 2, когда оба приложения объединяются.

Функции в ASD группируются с помощью AllocationRoles — логических ролей, таких как «PIU», «Bay Controller» или «Protection». AllocationRole определяет, что будет делать логическое IED; она не называет физическое устройство или производителя. На этом этапе ни один поставщик не вовлечён.

В пилотном проекте (PoC) Elia, продемонстрированном в декабре 2023 года с использованием Helinks STS (Helinks/Alvexis), команда создала два шаблона ASD: приложение управления выключателем с четырьмя ролями размещения и приложение дистанционной защиты P21 с логикой отключения по МЭК 61131-3. Оба шаблона были полностью независимы от возможностей продуктов какого-либо поставщика.

Thomas Sterckx из Elia сформулировал принцип: «Это действительно можно сделать технологически-независимым способом. Это также независимая от поставщика спецификация».

Шаг 2: системная спецификация — машиночитаемые требования к IED

На Шаге 2 инженер инстанциирует шаблоны библиотеки ASD в конкретный проект. При объединении двух приложений разрешаются их ProcessResources: ожидаемый сигнал отключения от приложения защиты теперь сопоставляется с реальной функцией в приложении CB. Система начинает приобретать форму — по-прежнему без оборудования.

Для каждого физического IED в проекте инженер формирует IED Specification Description (ISD) — машиночитаемый файл, заменяющий традиционный пакет PDF-документов с требованиями. ISD содержит:

  • Ожидаемую модель данных: логические устройства, логические узлы, объекты данных и атрибуты (заданные через элементы DOS/DAS)
  • Спецификации DataFlow: какие сигналы IED должен принимать и передавать, с типом сервиса и UUID источника (SourceRef)
  • BehaviorDescriptions: требуемую функциональную логику, которую IED должен реализовать
  • Ожидания к физическому интерфейсу и именованию (элементы LNodeSpecNaming)

Один ISD может быть одновременно направлен нескольким поставщикам. Каждый поставщик обрабатывает его в своём ICT — не путём чтения и интерпретации текста, а посредством машинного разбора SCL-файла. Ответы поступают в структурированном, сопоставимом формате. Как объяснил Thomas Sterckx: «Вместо того чтобы давать [поставщику IED] большой пакет письменных документов, можно передать ему нечто машиночитаемое, что он сможет обработать в своём собственном инструменте».

Результат Шага 2 двойственен: ISD-файлы для каждого IED и SSD (System Specification Description) — полная спецификация проекта, которая одновременно служит входными данными для Шага 3. SSD сразу поступает на моделирование. ISD-файлы, однако, на этом этапе поставщикам не передаются: их отправка происходит только после верификации спецификации в ходе моделирования (Шаг 3, или по завершении итеративного цикла моделирования). Такая последовательность принципиальна — отправка ISD поставщику до верификации рискует зафиксировать спецификацию, корректность работы которой ещё не подтверждена.

Шаг 3: системное моделирование и верификация — тестирование до появления оборудования

Этот шаг определяет суть top-down инжиниринга.

Никакого оборудования. Поставщик не выбран. Контракт не подписан.

SSD или ASD импортируется в инструмент моделирования, и поведение системы проверяется по функциональной спецификации — полностью в программной среде. Это стало возможным благодаря формальной структуре самого ASD. PDF-спецификация описывает логику защиты на естественном языке. ASD кодирует те же требования как функциональные блочные диаграммы (FBD) по МЭК 61131-3 — представление, которое инструменты могут разбирать, отображать и выполнять напрямую. Это не моделирование в смысле приближённого воспроизведения — это выполнение спецификации в том виде, в каком она написана.

Доступны два представления. Первое — граф потока данных: входные данные (process resources) слева, функциональная логика в центре, выходные данные справа. Все сигнальные пути видны, включая тип сервиса и направление — инженер может проследить любой вход до любого выхода ещё до того, как настроен хотя бы один IED. Второе — выполнение логики поведения: если ASD содержит FBD по МЭК 61131-3, инструмент отображает её и позволяет интерактивно управлять ею. Установите входное значение в активное состояние — сигнал распространяется через функциональную блочную диаграмму в реальном времени, и вы наблюдаете, какие выходы срабатывают.

Для структурированной верификации в масштабе сценарии можно задавать в виде табличных тест-кейсов: по одной строке на сценарий, с заданными входными значениями и ожидаемыми выходными значениями для каждого сигнала приложения. Инструмент выполняет последовательность, фиксирует расхождения и захватывает временны́е метки — позволяя верифицировать зависящее от времени поведение там, где важна точность до миллисекунды.

Важно понимать, что моделирование — это не обязательно однопроходная проверка по завершении разработки спецификации. Как описал Jackson Moore: «это может быть итеративный процесс — тестирование может происходить ещё в ходе разработки проекта». На практике это означает, что инженер может специфицировать фрагмент ASD или SSD, промоделировать его, уточнить по результатам и промоделировать снова — проходя цикл «специфицировать → моделировать → уточнять» до полного подтверждения корректности поведения. Инструмент моделирования интегрирован в рабочий процесс разработки спецификации, а не пристыкован к нему на выходе.

Результатом Шага 3 является не новый файл. Это верифицированная спецификация — тот же SSD или ASD, подтверждённый в части соответствия заданному поведению. На этом этапе ISD-файлы готовы к передаче поставщикам (Шаг 4): они несут спецификацию, которая была выполнена и верифицирована, а не просто написана. Экономическое обоснование прямолинейно: ошибка спецификации, найденная на Шаге 3, обойдётся в несколько часов доработки SCL-файла. Та же ошибка, обнаруженная при пусконаладке — после закупки оборудования, после мобилизации, когда оборудование уже на объекте и команды развёрнуты — обойдётся на порядки дороже. Технический механизм столь же прямолинеен: поскольку поведение формализовано в МЭК 61131-3, а не на естественном языке, оно может быть выполнено инструментом независимо от какого-либо конкретного устройства.

Jackson Moore, демонстрировавший моделирование в пилотном проекте Elia: «Многие потенциальные ошибки теперь можно выявить значительно раньше в процессе инжиниринга — и их сравнительно дешевле и проще исправить».

Шаг 4: описание возможностей IED — ответ поставщика

ISD-файл передаётся производителю IED, который импортирует его в свой ICT. Инструмент автоматически сопоставляет спецификацию с реальной моделью данных устройства — определяя, какие логические узлы и объекты данных доступны, какие необходимо создать, и где соглашения об именовании поставщика расходятся со спецификацией.

Результатом является process ICD — стандартный ICD-файл, расширенный информацией о сопоставлении из пространства имён 6-100. Он явно документирует:

  • Как каждый логический узел в спецификации сопоставляется с реальным LN поставщика (mappedLnUuid, mappedDoName)
  • Заполнители ExtRef (extRefUuid), привязанные к записям SourceRef в спецификации — они будут автоматически разрешены SCT на Шаге 5
  • Отклонения BehaviorDescription: если поставщик не может реализовать указанную логику точно так, как написано, это отклонение документируется в файле, а не остаётся неявным
  • Прослеживаемость на основе UUID, связывающую process ICD с исходными SSD и ISD через запись SourceFiles в заголовке

У поставщиков есть два варианта реализации. Они могут сохранить проприетарное именование, документируя полное сопоставление — максимально сохраняя обратную совместимость с существующими инструментальными цепочками. Либо они могут импортировать унифицированную модель данных из спецификации, принимая имена точно так, как указано — максимизируя интероперабельность ценой бо́льшего объёма работ по адаптации в ICT.

В PoC Elia Cedric Harispu продемонстрировал этот шаг с использованием Siemens DIGSI 5 с объединяющим блоком 6MU и реле дистанционной защиты 7SA87. DIGSI 5 автоматически распознал логические устройства из ISD, выполнил сопоставление LNode с LN и сформировал process ICD-файлы для обоих устройств — включая создание входных записей GOOSE, не входивших в стандартную конфигурацию устройства.

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

Process ICD — это не только «ответ поставщика». Он разработан для того, чтобы обеспечить автоматизированную верификацию на стороне заказчика. После получения process ICD инструмент SCT может автоматически сопоставить реализацию поставщика с исходной спецификацией — выявляя несопоставленные сигналы, отклонения в именовании и пробелы в BehaviorDescription без ручной инспекции. Как заявил Thomas Sterckx: «этот process ICD также позволяет автоматизировать шаг верификации на стороне заказчика — верифицировать то, что вы получили от поставщика IED».

Шаг 5: системная конфигурация — автоматизированная сборка SCD

Системный инженер получает process ICD-файлы от всех поставщиков и импортирует их в SCT. Инструмент считывает информацию о сопоставлении из пространства имён 6-100 и автоматизирует сборку финального SCD (Substation Configuration Description — описание конфигурации подстанции).

В частности, SCT:

  1. Создаёт экземпляры IED из шаблонов process ICD
  2. Разрешает записи SourceRef из спецификации в конкретные ссылки ExtRef, используя сопоставления extRefUuid, предоставленные поставщиком
  3. Формирует наборы данных (datasets), управляющие блоки GOOSE и SMV, а также параметры связи
  4. Отмечает неразрешённые сигналы — там, где элемент спецификации не был охвачён в process ICD

В PoC Elia импорт двух process ICD-файлов (PIU и реле дистанционной защиты Siemens) в Helinks STS заполнил матрицу GOOSE подписками, сформировал управляющие блоки с наборами данных для сигналов положения и отключения и обеспечил полную конфигурацию связи — 28 записей ExtRef в IED PIU были разрешены автоматически, а управляющие блоки GOOSE появились там, где их прежде не было.

Инструменты SCT, поддерживающие импорт process ICD и автоматическое разрешение привязки SourceRef — например, Tekvel Park — могут выполнять эту сборку с минимальным ручным вмешательством.

Степень автоматизации на Шаге 5 прямо пропорциональна качеству работы на Шагах 1–4. Полный ISD, тщательно выполненный process ICD с исчерпывающим сопоставлением и верифицированный BehaviorDescription из Шага 3 в совокупности делают Шаг 5 практически автоматическим. Любой пробел в этих предшествующих файлах непосредственно выражается в ручной работе по конфигурации на данном этапе.

После экспорта SCD файл возвращается поставщику IED для окончательной загрузки в устройство. В PoC Elia SCD был импортирован в DIGSI 5 и верифицирован в среде Siemens Digital Twin — два виртуальных устройства подтвердили корректный приём выборочных значений (sampled values), поведение GOOSE-подписок и согласованность именования модели данных — ещё до того, как было задействовано какое-либо физическое оборудование.

Что это меняет

Top-down инжиниринг МЭК 61850 меняет три вещи для практикующего инженера. Ошибки спецификации выявляются на этапе проектирования — до принятия решений о закупках, до обязательств перед поставщиками, до появления какого-либо оборудования на объекте. Взаимодействие с поставщиками IED становится структурированным: ISD заменяет PDF-документы, process ICD заменяет неформальные ответы, и весь обмен является машиночитаемым и прослеживаемым. А выбор поставщика становится по-настоящему конкурентным: один ISD, направленный нескольким поставщикам, даёт сопоставимые структурированные ответы, которые можно оценивать по техническим критериям.

Thomas Sterckx из Elia сформулировал это прямо: «Теперь можно проверить то, что вы запроектировали, ещё до того, как это будет реализовано в устройстве. Многие потенциальные ошибки теперь можно выявить значительно раньше в процессе инжиниринга».

Технические стандарты опубликованы. Инструментарий существует. Процесс закупок запущен в Elia. Следующая статья серии рассматривает как формат ISD меняет процесс закупки и тендерования IED на практике.

Источники

  1. Thomas Sterckx, Yannick Thiessoz, Jackson Moore, Cedric Harispu — IEC 61850 Top-Down Engineering PoC Webinar (Elia Group, December 2023)
  2. Elia Group — Common Vision for IEC 61850 Top-Down Engineering (2023)
  3. TR IEC 61850-90-30:2025 — Communication networks and systems for power utility automation — Part 90-30: IEC 61850 system engineering guidelines
  4. TR IEC 61850-7-6:2024 (Ed. 2) — Guidelines for IEC 61850 system and project management