На туториале исследовательского комитета B5 СИГРЭ три признанных международных эксперта в области РЗА и цифровых подстанций показали следующую ступень эволюции отрасли. Функции защиты постепенно отделяются от специализированных терминалов и переходят на серверные вычислительные платформы. Но самая интересная дискуссия сегодня идёт уже не о том, возможно ли это технически, а о том, как такие комплексы проектировать, испытывать и эксплуатировать — и кто в конечном счёте отвечает за их работу.
В зале парижского Palais des Congrès за столом президиума — Алекс Апостолов, главный редактор журнала PAC World и специалист OMICRON electronics; Ратан Дас, специалист Siemens Energy и руководитель рабочей группы IEEE, разработавшей руководство IEEE C37.300 по централизованной защите и управлению; Дэвид Макдональд, архитектор решений и стандартизации GE Grid Automation и руководитель рабочей группы CIGRE B5.84 по виртуализированным устройствам РЗА.
Туториал исследовательского комитета B5 СИГРЭ был посвящён развитию архитектур комплексов защиты, автоматики и управления с особым вниманием к шине процесса и виртуализации устройств РЗА.
Три доклада выстроились практически в одну историческую последовательность.
Сначала связь устройств РЗА с первичным оборудованием становится цифровой благодаря шине процесса. Затем функции защиты отделяются от многочисленных физических терминалов и централизуются. Наконец, следующий шаг — виртуализация: функция РЗА превращается в программное приложение, а сервер — в вычислительную платформу, которую в дальнейшем можно заменить, не меняя сам алгоритм защиты.
За двадцать с лишним лет отрасль прошла путь от первых демонстраций передачи оцифрованных мгновенных значений по IEC 61850 до работающих на серверных платформах виртуализированных комплексов РЗА.
И характер вопросов изменился вместе с технологией.
Сегодня главный вопрос звучит уже не «будет ли это работать?», а: как этим владеть, как это испытывать и обслуживать — и кто отвечает за комплекс, если его компоненты поставлены разными производителями?
Двадцать лет от демонстрации до промышленного применения
Первый доклад Алекса Апостолова был посвящён шине процесса.
В его основе — техническая брошюра CIGRE TB 949 Process Bus in Protection, Automation & Control Systems, обобщающая накопленный отраслью опыт применения шины процесса: архитектурные решения, резервирование, реальные проекты, результаты опросов энергокомпаний и производителей, экономические аспекты и дальнейшие направления развития.
История оказалась длиннее, чем иногда представляется.
Работа, которая впоследствии привела к IEC 61850, началась ещё в 1990-х годах. В 2004 году профиль 9-2LE стал важным практическим этапом развития передачи оцифрованных мгновенных значений и совместимости оборудования разных производителей. Апостолов вспомнил, как на сессии СИГРЭ того же года ABB, Siemens и Omicron уже демонстрировали совместную работу устройств с потоками SV.
Однако между демонстрацией технологии и её широким промышленным применением прошло около десятилетия.
Отрасль присматривалась к новой архитектуре, накапливала опыт, запускала опытные проекты. С середины 2010-х годов количество внедрений начало быстро расти.
«Мы в переломной точке: практически все крупные энергокомпании мира взяли курс на цифровизацию».
За этим выводом стоит довольно масштабный материал: более 200 проанализированных публикаций, около 60 рассмотренных проектов и результаты отраслевого опроса.
Большинство изученных проектов относятся не к строительству новых объектов, а к реконструкции действующих подстанций. Это важно: шина процесса постепенно перестаёт быть технологией только для новых «идеальных» цифровых объектов и входит в практику модернизации существующих подстанций.
Небольшой словарь
Для дальнейшего разговора полезно определить несколько терминов, которые зафиксированы в международной терминологии.
- MU / SAMU — устройства, преобразующие аналоговые сигналы тока и напряжения в цифровые потоки мгновенных значений SV.
- SCU — устройство сопряжения с коммутационным оборудованием, обеспечивающее дискретный ввод-вывод.
- PIU — устройство сопряжения с процессом, объединяющее функции преобразования аналоговых и дискретных сигналов.
Как отметил Апостолов, терминология здесь до сих пор используется не вполне последовательно.
- PRP и HSR — механизмы сетевого резервирования с бесшовным восстановлением передачи данных.
- PTP — протокол высокоточной синхронизации времени IEEE 1588, позволяющий передавать временную шкалу непосредственно по сети Ethernet и во многих архитектурах отказаться от отдельных линий импульсной синхронизации.
Что двигает шину процесса — и что её тормозит
Причины внедрения можно разделить на экономические и технологические.
Экономика — это меньше медных кабелей и монтажных работ, более компактные шкафы и помещения, сокращение объёма работ при реконструкции и потенциальное снижение затрат на обслуживание и модернизацию.
Технологические преимущества — повышение безопасности персонала, гибкость архитектуры, масштабируемость, более широкие возможности мониторинга состояния оборудования и основа для дальнейшей функциональной интеграции.
Но и барьеры вполне конкретны.
Энергокомпаниям не хватает собственного опыта работы с технологией. Сложности совместной работы оборудования разных производителей особенно заметны на стадии проектирования и настройки. Кибербезопасность предъявляет дополнительные требования к архитектуре. Нужны новые методы диагностики и испытаний.
И, пожалуй, один из важнейших вопросов — инструменты.
Сам стандарт IEC 61850 позволяет построить множество разных архитектур, однако сложность конфигурирования по-прежнему слишком часто перекладывается непосредственно на инженера. Апостолов отдельно подчеркнул необходимость инструментов, которые должны скрывать технологическую сложность IEC 61850 от пользователя, а не заставлять его постоянно работать с ней вручную.
«Рынку нужны инструменты, которые будут скрывать технологическую сложность IEC 61850 от пользователя, а не заставлять его постоянно работать с ней вручную».
Отдельная проблема — экономика.
Нередко цифровую подстанцию оценивают, сравнивая стоимость отдельных компонентов традиционного и цифрового решения. Но реальная выгода проявляется только при оценке совокупной стоимости владения: проектирования, кабельного хозяйства, строительства, наладки, обслуживания, реконструкции и последующей замены оборудования.
И именно жизненный цикл становится особенно интересен на следующем этапе развития.
От десяти тысяч соединений к централизованной защите
Ратан Дас начал свой доклад с личной истории.
В 1981 году, только придя работать в энергокомпанию, он получил задачу подготовить схему соединений между устройствами на объекте с тремя энергоблоками мощностью по 500 МВт.
Около 10 000 соединений.
Проектировщик разрабатывал схемы, затем они проверялись, а затем всё это необходимо было физически смонтировать и проверить на объекте.
Следующие поколения РЗА постепенно сокращали эту сложность.
Электромеханические реле сменились статическими, затем появились микропроцессорные терминалы. IEC 61850 позволил заменить значительную часть проводных связей цифровым обменом.
Следующий логичный вопрос возник примерно десятилетие назад: если аналоговые измерения и дискретные сигналы уже доступны через шину процесса, обязательно ли каждому присоединению иметь собственный вычислительный терминал?
Так появилась концепция централизованной защиты и управления — CPC (Centralized Protection and Control).
Устройства сопряжения остаются рядом с первичным оборудованием. Они получают измерения, состояния и команды. А алгоритмы защиты и управления переносятся на централизованную вычислительную платформу станционного уровня.
По словам Даса, это можно рассматривать как следующее поколение развития комплексов РЗА.
«Когда в 2013 году мы написали статью о серверном комплексе РЗА, многие смотрели на неё как на дикую фантазию. Сегодня на стендах этой сессии защита работает именно на серверах».
Но централизация решает только часть задачи.
Функции уже собраны на общей вычислительной платформе, однако программное обеспечение всё ещё может оставаться тесно связанным с конкретной аппаратной платформой производителя.
Следующий шаг — отделить одно от другого.
Функции отдельно, аппаратная платформа отдельно
Именно в этом состоит идея независимости функциональности от аппаратной платформы — FIH (Functionality Independent of Hardware).
Основной принцип прост: замена вычислительной платформы не должна требовать существенной переработки прикладных функций РЗА.
Конечно, абсолютной независимости не существует. Для новой платформы могут потребоваться драйверы, проверка совместимости, настройка среды выполнения.
Но сам алгоритм защиты не должен каждый раз создаваться заново только потому, что производитель процессора снял старое поколение с производства или изменилось серверное оборудование.
В этом и заключается фундаментальное изменение жизненного цикла.
Сегодня терминал РЗА фактически является единым изделием: алгоритмы защиты, процессор, операционная система, сетевые интерфейсы, блок питания и конструктив поставляются вместе.
Когда аппаратная часть устаревает, зачастую приходится заменять весь терминал.
В виртуализированном комплексе прикладная функция и вычислительная платформа начинают жить разными жизненными циклами.
Для энергетики это особенно важно. Первичное оборудование эксплуатируется десятилетиями, тогда как вычислительные платформы развиваются намного быстрее.
В результате за срок службы первичного оборудования может смениться несколько поколений вычислительных средств РЗА.
При новой архитектуре менять каждый раз саму функцию защиты уже необязательно.
Испытаний может стать больше, а работ на объекте — меньше
На первый взгляд кажется, что виртуализация должна уменьшить объём испытаний.
Дас сделал важную оговорку: правильнее говорить совсем не так.
Испытаний можно выполнять даже больше — но значительную их часть перенести с объекта в лабораторию.
Программное приложение можно всесторонне проверить независимо от конкретного объекта.
Если впоследствии меняется только вычислительная платформа, а код самой функции РЗА остаётся прежним, полный объём функциональных испытаний приложения уже не обязательно повторять непосредственно на подстанции.
Основной объём проверки новой платформы можно выполнить заранее.
Это потенциально серьёзно меняет сам процесс замены оборудования.
Сегодня замена терминала часто означает проект, согласование, вывод оборудования, монтаж, настройку и полный объём проверок.
В программно-определяемом комплексе РЗА замена аппаратной платформы в перспективе может стать значительно более типовой операцией.
Но вместе с этим появляется фундаментальный организационный вопрос: кто даёт гарантию на весь комплекс и как распределяется ответственность между участниками?
К нему дискуссия вернулась после докладов.
Что именно даёт виртуализация
Третий доклад — Дэвида Макдональда, руководителя рабочей группы CIGRE B5.84 по виртуализированным устройствам РЗА, — был посвящён непосредственно виртуализации.
Главное отличие виртуализированного комплекса от обычного централизованного комплекса состоит не только в использовании сервера.
Между прикладными функциями и аппаратной платформой появляется слой виртуализации, позволяющий отделить программные приложения от конкретного серверного оборудования и изолировать их друг от друга.
Для виртуальных машин базовым элементом такого слоя является гипервизор — программное средство, позволяющее одновременно запускать на одном физическом сервере несколько изолированных виртуальных машин.
Прикладные функции РЗА могут выполняться в отдельных виртуальных машинах. Другой подход — контейнеризация, когда несколько приложений используют общую операционную систему, но изолируются друг от друга программными средствами. Возможен и комбинированный вариант — например, размещение контейнеризированных приложений внутри виртуальной машины.
Для комплексов, где предполагается использование приложений разных производителей, виртуальные машины особенно интересны благодаря более жёсткому разделению программных сред.
Отдельную виртуальную функцию РЗА можно развернуть, испытать или обновить независимо от других функций, выполняющихся на том же сервере.
Именно эта возможность создаёт предпосылки для комплексов, в которых на общей вычислительной платформе могут работать приложения разных производителей.
В традиционном централизованном комплексе такой свободы значительно меньше: функции объединены, но всё решение остаётся единым программно-аппаратным комплексом одного поставщика.
Аппаратная платформа не исчезает
Здесь важно не попасть в терминологическую ловушку.
Независимость от аппаратной платформы не означает, что для РЗА подойдёт любой сервер.
Требования к вычислительной платформе остаются крайне серьёзными.
Необходимо учитывать производительность процессора и памяти, сетевые интерфейсы, резервирование питания и дисков, условия эксплуатации, электромагнитную совместимость, средства удалённого управления, схему резервирования и требования к надёжности.
Кроме того, для каждого виртуального устройства необходимо определить требуемые вычислительные ресурсы и характеристики виртуальной сети.
То есть виртуализация не отменяет инженерное проектирование аппаратной части.
Она меняет другое: аппаратная платформа перестаёт определять саму прикладную функциональность РЗА.
Это важное различие.
Две модели резервирования
Для серверного комплекса РЗА можно использовать разные подходы к резервированию.
Наиболее очевидный — два независимых сервера, на которых одновременно работают одинаковые экземпляры защит. Каждый способен выдать собственную команду отключения.
Более сложный вариант — кластер из нескольких серверов.
В этом случае группа узлов управляется как единая вычислительная система. При отказе сервера его приложения могут быть автоматически перезапущены на другом узле.
Для принятия решений о состоянии участников кластера используется нечётное число узлов — например, три или пять. Это позволяет определить большинство и исключить отказавший узел.
Возможен также перенос виртуальной машины с одного физического сервера на другой.
И здесь возникает одна из фундаментальных особенностей новой архитектуры: резервируется уже не обязательно само физическое устройство, а возможность исполнения функции.
Для традиционного комплекса РЗА эти два понятия практически совпадали.
Для виртуализированного — уже нет.
Микросекунды: где виртуализация встречается с реальным временем
Однако серверный комплекс РЗА предъявляет к вычислительной инфраструктуре требования, сильно отличающиеся от обычных информационных систем.
Недостаточно обеспечить малое время выполнения функции в среднем.
Защите требуется предсказуемое время реакции и ограниченный разброс задержек даже при неблагоприятных условиях.
Обычные операционные системы прежде всего оптимизируются для эффективного использования ресурсов, а не для жёсткого временного детерминизма.
Дополнительные задержки может вносить и сама виртуализация: сетевой пакет проходит через несколько программных уровней, прежде чем попадёт к приложению защиты.
Для сокращения этого пути и уменьшения задержек используются специальные механизмы прямого и ускоренного доступа к сетевым интерфейсам — в частности, PCI passthrough, SR-IOV и DPDK.
Подробный разбор этих технологий — тема отдельного материала. Здесь важно другое: в виртуализированном комплексе РЗА сетевой тракт и способ доставки данных до приложения становятся такой же частью инженерного проектирования, как выбор процессора, распределение вычислительных ресурсов или настройка работы в реальном времени.
Но главный вывод Макдональда заключался не в выборе конкретной технологии.
Детерминизм нельзя просто заявить. Его необходимо измерять и подтверждать испытаниями.
Как устроена открытая платформа SEAPATH
В качестве наглядного примера архитектуры Макдональд рассмотрел открытую платформу LF Energy SEAPATH.
Здесь виртуальные устройства РЗА располагаются поверх набора стандартных средств виртуализации и управления вычислительной инфраструктурой.
Используются Linux с ядром для работы в реальном времени, KVM, QEMU и libvirt. Для виртуальной сети применяются соответствующие программные средства, а для построения отказоустойчивой инфраструктуры — механизмы кластеризации.
Важную роль играет распределение вычислительных ресурсов.
Процессорные ядра можно закреплять за определёнными задачами. Учитывается архитектура NUMA — организация доступа процессоров к оперативной памяти в многопроцессорных серверных платформах. Управляются приоритеты потоков и обработка прерываний.
То есть сервер перестаёт быть просто «компьютером, на котором запустили защиту».
Он становится специально настроенной вычислительной средой для выполнения критичных функций в реальном времени.
Испытание одной защиты без остановки остальных
Очень интересные возможности виртуализация даёт совместно со штатными механизмами IEC 61850 Test и Simulation.
Представим, что на одном сервере работают виртуальные устройства нескольких присоединений.
Одно из них необходимо испытать.
Его можно перевести в испытательный режим и подать ему моделируемые потоки SV и GOOSE от испытательного комплекса.
При этом соседние виртуальные устройства продолжают работать с реальными данными объекта.
Тестовые GOOSE-сообщения соответствующим образом маркируются, поэтому исполнительные устройства, остающиеся в нормальном режиме, не должны выполнять содержащиеся в них команды.
Таким образом появляется возможность локализовать испытание отдельной функции внутри работающего комплекса.
Для традиционной централизованной архитектуры такая независимость отдельных программных компонентов достигается значительно сложнее.
Детерминизм нужно доказывать под нагрузкой
Рабочая группа рассматривает и специальные испытания вычислительной платформы.
Измеряется, насколько фактическое время выполнения задач отличается от ожидаемого.
Такие испытания выполняются многократно и под искусственно созданной нагрузкой на процессор, память и сетевую подсистему.
Наиболее показательно сквозное испытание.
Испытательный комплекс формирует воздействие, виртуальная защита его обрабатывает и возвращает GOOSE-команду отключения.
Измеряется полный путь сигнала — от воздействия до ответной команды.
Причём вычислительную платформу специально ставят в неблагоприятные условия конкуренции за ресурсы.
Именно здесь становится видна принципиальная разница между обычным серверным приложением и функцией РЗА.
Для защиты важен не лучший результат и даже не средний.
Важна гарантированная характеристика в худших предусмотренных условиях.
Кибербезопасность: преимуществ без новых рисков не бывает
Централизация и виртуализация одновременно создают новые средства защиты и новые угрозы.
С одной стороны, изоляция виртуальных машин позволяет ограничивать распространение отказов и последствия компрометации отдельных приложений.
Можно применять доверенную загрузку, проверку целостности и подписи программных образов, разграничение прав, многофакторную аутентификацию и шифрование.
С другой стороны, появляются новые критичные компоненты: сама среда виртуализации, операционная система узла, средства централизованного управления, цепочка поставки программного обеспечения.
Кроме того, последствия успешной атаки на общую серверную инфраструктуру потенциально могут быть значительно масштабнее, чем компрометация отдельного терминала.
Поэтому утверждать, что виртуализированный комплекс сам по себе «безопаснее», было бы слишком просто.
Корректнее сказать, что виртуализация меняет модель угроз и набор средств защиты.
Вопросы из зала: от надёжности до ответственности
Самая интересная часть туториала началась после открытия микрофонов.
Вопросы из зала хорошо показали, насколько изменился характер профессиональной дискуссии.
Спор уже шёл не о возможности виртуализации как таковой, а о её практических границах.
«Не создаём ли мы новую единую точку отказа?»
Первый естественный вопрос касался надёжности.
В традиционной цифровой подстанции десятки физических устройств распределены по присоединениям. Отказ конкретного терминала обычно локализован ограниченным набором функций.
В виртуализированном комплексе значительная часть функций может зависеть всего от нескольких серверов.
Не возникает ли новая единая точка отказа?
Ответ докладчиков состоял в том, что вычислительную инфраструктуру можно резервировать значительно глубже и экономичнее, чем большое количество специализированных устройств.
Функция защиты может иметь несколько одновременно работающих экземпляров, размещённых на разных серверах. При отказе одного узла возможно продолжение работы на другом.
Но представители энергокомпаний справедливо обратили внимание и на обратную сторону.
Отказ общего компонента действительно потенциально способен затронуть сразу множество функций.
Поэтому просто сравнивать «два терминала» и «два сервера» нельзя.
Необходим анализ надёжности всей архитектуры: серверов, коммутаторов, сетевых карт, источников питания, среды виртуализации, средств управления и самих приложений.
Виртуализация не отменяет традиционную инженерию надёжности.
Она только предоставляет другие способы построения резервирования.
«А кто отвечает, если программное обеспечение и сервер — от разных производителей?»
Пожалуй, самый практический вопрос прозвучал от представителя Scottish and Southern Electricity Networks (SSEN, Великобритания) — оператора электрических сетей Великобритании.
Допустим, виртуальную защиту разработал производитель А.
Серверную платформу поставил производитель Б.
Среду виртуализации — производитель В.
Защита отработала неправильно.
Кому должен звонить заказчик?
Это и есть одна из ключевых нерешённых задач новой архитектуры.
Докладчики отметили, что определённый аналог существует уже сегодня в цифровых подстанциях с оборудованием разных производителей.
Устройства разных компаний объединяются общей сетью IEC 61850, но ответственность за комплекс в целом всё равно должна быть закреплена за конкретной стороной — заказчиком или назначенным системным интегратором.
Для виртуализированного комплекса РЗА эта проблема становится только более заметной.
Следовательно, отрасли нужны не только технические стандарты интерфейсов.
Нужны правила квалификации вычислительных платформ, совместимости приложений, диагностики, испытаний и контрактного распределения ответственности.
Фактически речь идёт о формировании новой модели эксплуатации комплексов РЗА.
Лучше говорить не о независимости, а об освобождении от ограничений
Интересную формулировку предложил участник дискуссии из Electricity Supply Board (ESB, Ирландия) — ирландской энергетической компании.
По его мнению, выражение «независимость от аппаратной платформы» не вполне точно описывает проблему.
Традиционная функция РЗА не столько «зависит» от аппаратной платформы, сколько ограничена ею.
Срок службы алгоритмов защиты зачастую определяется вовсе не их моральным устареванием.
Из строя выходят блоки питания, преобразователи напряжения, процессорные модули. Производитель снимает конкретную аппаратную платформу с производства — и вместе с ней приходится менять всё устройство.
Даже если сами алгоритмы полностью устраивают энергокомпанию.
Виртуализация потенциально разрывает эту связь.
Функция остаётся, а вычислительную платформу можно обновлять независимо.
В этом смысле речь действительно скорее идёт не о полном отсутствии аппаратной зависимости, а об освобождении прикладной функциональности от ограничений конкретного поколения оборудования.
Где заканчивается независимость от аппаратной платформы
Представитель Schweitzer Engineering Laboratories (SEL, США) — известного производителя устройств и решений для релейной защиты, автоматики и управления — поднял ещё более интересный технический вопрос.
Стандартные функции РЗА можно виртуализировать и выполнять на типовой серверной платформе.
Но существуют методы, в которых алгоритм тесно связан со специализированным измерительным оборудованием.
Например, волновые защиты требуют чрезвычайно высокой частоты дискретизации.
В подобных случаях передавать огромный поток данных на центральный сервер может быть нерационально.
Один из вариантов — выполнять такую обработку непосредственно в устройстве сопряжения с процессом.
Но и здесь всё не так просто.
Если функция использует данные нескольких удалённых точек, локальное вычисление на одном устройстве уже не решает задачу.
В итоге дискуссия привела к более важному выводу, чем идея «всё перенести на сервер»: виртуализация не означает обязательной централизации абсолютно всех функций.
Разные алгоритмы могут исполняться на разных уровнях.
Функции, использующие исключительно локальные данные и требующие минимальной задержки, могут оставаться рядом с процессом.
Функции, использующие информацию нескольких присоединений, — выполняться на уровне подстанции.
Системные функции — на ещё более высоком уровне.
То есть будущее может оказаться не полностью централизованным, а представлять собой иерархически распределённый программно-определяемый комплекс РЗА, где место исполнения каждой функции выбирается исходя из её требований.
А что со средним напряжением?
Отдельный вопрос касался распределительных сетей.
На высоких классах напряжения терминал РЗА — сравнительно дорогой элемент. На среднем напряжении стоимость отдельных устройств существенно ниже.
Сохраняется ли там экономический смысл виртуализации?
Докладчики считают, что да.
Современные комплектные распределительные устройства всё чаще получают встроенные цифровые средства измерения и управления. В перспективе устройство сопряжения с процессом может стать частью самого коммутационного аппарата.
А функции РЗА при этом добавляются программно.
Получается ещё один уровень разделения жизненных циклов: закупка первичного оборудования отделяется от закупки и последующего развития функций защиты и автоматики.
Именно массовые распределительные подстанции в перспективе могут стать одним из крупнейших направлений применения программно-определяемых комплексов РЗА.
Что в итоге
Самое показательное на туториале прозвучало не со слайдов.
За весь блок открытой дискуссии практически никто не спросил: «Зачем вообще нужна виртуализированная РЗА?»
Вопросы были другими.
Как обеспечить требуемый детерминизм? Как резервировать серверную инфраструктуру? Как испытывать отдельную функцию, не затрагивая остальные? Что оставлять непосредственно у процесса, а что переносить на сервер? Как меняется кибербезопасность? И, наконец, кто отвечает за результат, если приложение, среду виртуализации и аппаратную платформу поставляют разные компании?
Для технологии, которую ещё около десяти лет назад многие воспринимали как весьма смелую концепцию, это, пожалуй, лучший показатель зрелости.
Релейная защита действительно начинает уходить с «железа».
Но главный вызов следующего этапа заключается уже не в том, чтобы доказать принципиальную возможность виртуализации.
Отрасли предстоит научиться проектировать, квалифицировать, испытывать и эксплуатировать РЗА как программно-определяемый комплекс.
И судя по тому, о чём спорили специалисты на СИГРЭ-2026, этот переход уже начался.