Большинство проектов цифровых подстанций представляют собой единичные подтверждения концепции (proof of concept), реализуемые одним вендором на одном объекте. RTE — оператор магистральной сети Франции, состоящей из 2600 подстанций, — реализует более сложную задачу: с нуля строит полностью цифровую АСУ ТП ПС (автоматизированную систему управления подстанцией) от разных производителей, выступая в роли собственного системного интегратора и масштабируя её на всю сеть. Проект называется R#SPACE. Первая подстанция была введена в эксплуатацию в Плорене (63 кВ, южная Бретань) в конце 2023 года; по состоянию на начало 2026 года еще несколько объектов находятся на этапе наладки и ввода в эксплуатацию, и начался этап промышленного масштабирования.

Необычность R#SPACE заключается не только в технологиях, но и в операционной модели. RTE закупает ИЭУ (интеллектуальные электронные устройства) уровня присоединения у одного поставщика, устройства сопряжения с шиной процесса — у другого, запускает ЧМИ (человеко-машинный интерфейс) на совместно разработанной открытой платформе виртуализации и объединяет автоматизацию уровня подстанции с виртуальными ПЛК (программируемыми логическими контроллерами) в контейнерах Docker. Ни один вендор не владеет системой. Владельцем является RTE.

Ниже представлены архитектура, экосистема поставщиков, реалии тестирования и дорожная карта развертывания — включая трудные уроки, которые не попадают в пресс-релизы производителей.

Почему RTE создала R#SPACE

Предыдущее поколение АСУ ТП ПС компании RTE представляло собой модель «под ключ»: один вендор, одна система, ограниченная гибкость после наладки и ввода в эксплуатацию. Изменение функции на уровне подстанции — например, добавление новой схемы регулирования напряжения или обновление шлюза телемеханики — означало необходимость обращения к первоначальному подрядчику. Затраты были высокими, а сроки — длительными.

Три фактора заставили RTE пересмотреть эту модель:

  • Французская энергосистема поглощает огромные объемы возобновляемой генерации. Новые требования к мониторингу (интерфейсы LPIT через МЭК 61869-9, расширенные данные с датчиков) не могут ждать следующего полного цикла обновления АСУ ТП ПС.

  • Удаленное техническое обслуживание стало общекорпоративной политикой. Старая архитектура с её специфичными для вендора инструментами и проприетарными методами доступа делала централизованное удаленное администрирование практически невозможным в условиях парка оборудования от разных производителей.

  • RTE уже протестировала эту концепцию. Демонстрационный проект «Postes Intelligents» [9] — две полностью цифровые подстанции МЭК 61850 с шиной процесса и станционной шиной — доказал работоспособность технологии, но выявил пробелы в координации: проблемы согласования векторных значений LPIT, сложности обработки деградации синхронизации и трудности управления SCL-файлами (Substation Configuration Language) от разных производителей. R#SPACE была разработана для исправления того, что выявил проект «Postes Intelligents».

Трехблочная архитектура

R#SPACE разделяет АСУ ТП ПС на три функциональных блока. Это разделение преднамеренно — оно отделяет то, что можно виртуализировать сегодня, от того, что всё еще требует выделенного оборудования.

flowchart TD
    subgraph SL["Уровень подстанции (виртуализированный)"]
        HMI["ЧМИ / SCADA"]
        GW["Шлюз телеуправления\nи диспетчерского контроля"]
        AUTO["Автоматика\nстанционного уровня"]
        CYBER["Серверы\nкибербезопасности"]
        STORE["Хранение и\nконфигурация"]
    end

    subgraph NET["Сетевой уровень"]
        direction LR
        PROC["Сеть процесса\n(дублированная, PRP)\n+ синхронизация PTP"]
        ADMN["Выделенная\nадминистративная ЛВС"]
        PROC ~~~ ADMN
    end

    subgraph BAY["Уровень присоединения и процесса"]
        direction LR
        BCU["Контроллеры присоединения\n(защита + автоматика)"]
        SCU["Блоки управления\nраспределительным устройством (РУ)"]
        PIU["Устройства сопряжения\nс шиной процесса"]
        SAMU["Автономные\nПАС"]
        BCU ~~~ SCU
        PIU ~~~ SAMU
    end

    SL <--> NET
    NET <--> BAY

Блок 1 — Уровень подстанции. Этот уровень работает на SEAPATH, платформе виртуализации с открытым исходным кодом RTE, разработанной совместно с LF Energy. SEAPATH использует KVM в качестве гипервизора, Corosync/Pacemaker для обеспечения высокой доступности и libvirt для управления виртуальными машинами (ВМ). Виртуализированные функции включают локальный ЧМИ, шлюз телеуправления, серверы кибербезопасности и автоматику станционного уровня. Эти механизмы автоматики — отвечающие за расчет аварийных сигналов, регулирование напряжения и управление перегрузками — работают как виртуальные программируемые логические контроллеры (ПЛК) внутри контейнеров Docker с циклом 10 мс, управляя до 30 000 входов/выходов (I/O) и 60 000 переменных [7].

На этапе 1 виртуализируются только те функции, время отклика которых превышает 100 мс. Функции релейной защиты остаются на выделенном аппаратном обеспечении.

Блок 2 — Сеть. Дублированная локальная вычислительная сеть (ЛВС) с использованием протокола параллельного резервирования (PRP) переносит весь трафик. Синхронизация PTP (IEEE 1588) транслируется через ЛВС PRP. Отдельная физическая ЛВС используется для администрирования ИЭУ. Топология коммутации проста: 2 центральных коммутатора для общеподстанционных и общих функций присоединения, плюс по 2 коммутатора на каждое присоединение, подключенных к центральной паре по топологии «звезда».

graph TB
    subgraph Central["Центральные коммутаторы"]
        CS1["Центральный коммутатор A\n(Общеподстанционный &\nобщий для присоединений)"]
        CS2["Центральный коммутатор B\n(Общеподстанционный &\nобщий для присоединений)"]
    end

    subgraph Bay3["Присоединение N"]
        B3S1["Коммутатор А\nприсоединения N"]
        B3S2["Коммутатор B\nприсоединения N"]
    end

    subgraph Bay2["Присоединение 2"]
        B2S1["Коммутатор А\nприсоединения 2"]
        B2S2["Коммутатор B\nприсоединения 2"]
    end


    subgraph Bay1["Присоединение 1"]
        B1S1["Коммутатор А\nприсоединения 1"]
        B1S2["Коммутатор B\nприсоединения 1"]
    end

    CS1 --- B1S1
    CS1 --- B2S1
    CS1 --- B3S1

    CS2 --- B1S2
    CS2 --- B2S2
    CS2 --- B3S2

Блок 3 — Уровень присоединения и процесса. Контроллеры присоединения (КП) обеспечивают функции защиты и автоматики на уровне присоединения. Устройства сопряжения с шиной процесса (PIU), блоки управления РУ (SCU) и автономные ПАС (SAMU) отвечают за интерфейс с первичным оборудованием. В рамках пилотного проекта в Плорене только на стороне шины процесса было развернуто 10 ИЭУ уровня процесса [1].

Сегментация сети: VLAN

RTE выбрала сегментацию трафика на основе VLAN (виртуальных локальных сетей) вместо фильтрации по MAC-адресам. Обоснованием является масштабируемость — управление фильтрами MAC становится невозможным по мере увеличения количества присоединений. Структура VLAN выглядит следующим образом:

  • Каждое присоединение получает свои собственные VLAN для SV (мгновенных значений) и GOOSE, что позволяет локализовать высокочастотный трафик мгновенных значений.

  • Межсоединительные подписки — необходимые для защиты шины и блокировок — получают отдельные VLAN.

  • Синхронизация PTP (IEEE 1588) и MMS (Manufacturing Message Specification) также имеют выделенные VLAN.

  • Качество обслуживания (Quality of Service, QoS) использует биты приоритета IEEE 802.1Q (0–7), настроенные для каждого ИЭУ и описанные в SCD-файле [2].

Для подстанции с 6 присоединениями это означает минимум 14 VLAN: 6 × SV + 6 × GOOSE + 1 межсоединительный SV + 1 межсоединительный GOOSE (плюс PTP и MMS). В масштабах всей сети это требует серьезных инженерных усилий по проектированию сети, но это предотвращает распространение штормов многоадресной рассылки SV за пределы границ присоединений.

RTE как системный интегратор

R#SPACE по своей конструкции является мультибрендовой системой. RTE не покупает готовую систему «под ключ» у одного подрядчика. Вместо этого она определяет структуру функциональной совместимости — модели данных МЭК 61850, базовые профили приложений (BAP), шаблоны SCL и требования к кибербезопасности — и закупает отдельные компоненты в соответствии с этой спецификацией. Разные поставщики поставляют БУП (контроллеры присоединения), ИЭУ интерфейса процесса, платформу ЧМИ и программную среду управления на уровне подстанции. Некоторые компоненты разрабатываются внутри компании или совместно в рамках проектов с открытым исходным кодом.

Инженеры проводят наладку и ввод в эксплуатацию шкафов ИЭУ R#SPACE. Источник: Straton

Структура функциональной совместимости выходит за рамки протоколов связи. Она охватывает оперативную функциональную совместимость (общие модели данных, гармонизированные профили, скоординированное управление качеством данных) и не оперативную функциональную совместимость (сверху вниз конфигурация SCL, стандартизированное администрирование ИЭУ на основе API, скоординированная кибербезопасность). Каждая функция ПАС (первичной автоматики подстанции) моделируется как логическое устройство МЭК 61850, а настройки описываются с использованием классов объектов данных ING и ASG [2].

Масштаб обязательств RTE виден в цифрах закупок. Восьмилетнее рамочное соглашение на поставку ИЭУ уровня присоединения начинается с начальной партии из 41 БУП и 92 ПАС (устройств сопряжения с шиной процесса). Максимальные объемы, прописанные в контракте: 2418 БУП и 5390 ПАС [3]. Это не пилотная программа.

Шкафы ИЭУ R#SPACE, собранные для заводских приёмо-сдаточных испытаний. Источник: Efacec

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

Доклад CIGRE по тестированию R#SPACE (Сессия 2024, SC B5) необычайно откровенно говорит о трудностях [4]. Процесс тестирования состоит из четырех этапов:

  • тестирование соответствия отдельных компонентов,

  • квалификация системы интегрированной ПАС,

  • заводские приёмо-сдаточные испытания (FAT) подрядчиком по сборке,

  • и приёмо-сдаточные испытания на объекте (SAT).

Тестовая лаборатория RTE на площадке «Transfo» близ Лиона включает стойки для инжекции напряжения/тока, панели дискретных входов/выходов, сервер реального времени с поддержкой MMS/GOOSE/SV и эмулятор центра МЭК 61870-5-104. Около 60% тестов на системном уровне были автоматизированы с помощью скриптов Python.

Выделяются три основных вывода:

Большинство аномалий были локальными для каждого ИЭУ, а не межблочными. Изначально ожидалось, что основным источником проблем станет интеграция оборудования различных производителей. На практике же большинство проблем было связано с несоответствиями отдельных ИЭУ — устройств, которые не полностью реализовывали свои собственные заявленные профили МЭК 61850.

Конвергенция SCL была крайне сложной. Доведение файла описания конфигурации системы (SCD-файла) до состояния, при котором инструменты всех производителей могли его проанализировать и импортировать, заняло несколько недель согласований между группой конфигурирования RTE и поставщиками ИЭУ. Это известная проблема интеграции МЭК 61850, но в контексте мультибрендового оборудования она усугубилась тем, что инструменты SCL каждого производителя имели слегка отличающиеся интерпретации граничных случаев.

Периодические сбои было труднее всего обнаружить. После того как система прошла все квалификационные испытания, непрерывный мониторинг выявил случайные неисправности: некоторые ИЭУ переставали повторять GOOSE-сообщения на длительные периоды, а затем возобновляли передачу. Определение первопричины заняло три месяца [4]. Это тот тип проблем, который в системах одного производителя может никогда не проявиться, так как тестовая среда производителя слишком однородна.

План развертывания

gantt
    title График развертывания R#SPACE
    dateFormat  YYYY
    axisFormat  %Y

    section НИОКР
    Демонстраторы Postes Intelligents     :done, pi, 2014, 2017
    Концепция и спецификация R#SPACE       :done, spec, 2017, 2020

    section Разработка
    Внешняя и внутренняя разработка       :done, dev, 2020, 2022
    Предварительная интеграция и ЗПСИ     :done, fat, 2022, 2023

    section Развертывание
    Пилотный проект в Плорене (63 кВ)      :done, pilot, 2023, 2024
    +1 подстанция                         :done, y2024, 2024, 2025
    +3 запланированные подстанции          :active, y2025, 2025, 2026
    Промышленное масштабирование           :y2026, 2026, 2030
    Цель — 100 подстанций                 :milestone, m1, 2030, 2030

Темп развертывания намеренно осторожный. Одна подстанция добавлена в 2024 году, еще три запланированы на 2025 год. Цель — 100 подстанций, работающих на базе R#SPACE, к 2030 году [5], что составляет примерно 4% от парка из 2600 подстанций компании RTE. Фаза 1 охватывает меньшие подстанции: один уровень напряжения, ограниченное количество присоединений, преимущественно 63–90 кВ. Фаза 2 будет касаться многоуровневых подстанций напряжением до 400 кВ со сложной топологией шинных систем.

Платформа SEAPATH, выпущенная под лицензией Apache 2.0 организацией LF Energy, привлекла контрибьюторов помимо RTE — среди них National Grid Electricity Transmission и GE Vernova. Каждое изменение кода должно проходить более 700 юнит-тестов, тестов реального времени и тестов задержки в рамках непрерывной интеграции (CI) [6]. Это необычайно высокий уровень строгости для проекта с открытым исходным кодом в области операционных технологий (OT).

Что R#SPACE значит для отрасли

Три аспекта этого проекта заслуживают внимания инженеров за пределами Франции.

Модель системного интегратора работает, но она дорога. RTE, по сути, создала внутреннюю инженерную базу, которую большинство сетевых компаний полностью отдают на аутсорсинг. Выгода заключается в независимости: RTE может менять поставщиков, добавлять функции и обновлять отдельные компоненты без пересмотра условий контракта «под ключ». Ценой этого является наличие постоянной специализированной команды, обеспечивающей моделирование данных МЭК 61850 (IEC 61850), работу с инструментами SCL (Substation Configuration Language), проектирование сетей, виртуализацию и кибербезопасность. Не каждая ОАО (операторная компания в электроэнергетике / TSO) может себе это позволить.

Виртуализация подстанций на базе открытого исходного кода — это реальность. Платформа SEAPATH не является теоретическим проектом. Она обеспечивает работу промышленного трафика на подстанции Плорен. KVM, Coroscap/Pacemaker и контейнеры Docker для функций уровня станции — это достойная альтернатива проприетарным платформам SCADA (система диспетчерского управления и сбора данных), по крайней мере, для тех функций, где допустимое время отклика составляет более 100 мс. Остается открытым вопрос, сможет ли в конечном итоге тот же подход обеспечить работу функций релейной защиты (с требованиями менее 4 мс).

Интеграция МЭК 61850 от разных производителей по-прежнему представляет сложность. Несмотря на два десятилетия мероприятий по тестированию функциональной совместимости, достижение конвергенции SCL занимало недели, диагностика сбоев повторения GOOSE требовала месяцев, а большинство ошибок были связаны с проблемами соответствия конкретных ИЭУ (интеллектуальных электронных устройств). R#SPACE служит напоминанием о том, что стандарт МЭК 61850 обеспечивает функциональную совместимость — но не гарантирует её. Инженерные усилия, необходимые для достижения этого в масштабе всей сети, весьма значительны.

RTE планирует делиться дальнейшим эксплуатационным опытом через рабочие группы IEC TC57 WG10 и CIGRE B5. Для всех остальных вопрос заключается в том, станет ли модель R#SPACE — ОАО как интегратор, платформа с открытым исходным кодом, вендоронезависимая архитектура — исключением или шаблоном для подражания.


Источники

[1] SCLE, "RTE R#SPACE: Ploeren pilot station," https://scle.fr/en/cas-client/rte-rspace-ploeren-pilot-station/

[2] PAC World, "Towards an Industrial Deployment of Fully Digital PACS at RTE," Issue 74, 2024, https://www.pacw.org/towards-an-industrial-deployment-of-fully-digital-pacs-at-rte

[3] Efacec, "Efacec strengthens strategic contract with RTE for substation automation," https://www.efacec.com/news/efacec-strengthens-strategic-contract-with-rte-for-substation-automation/

[4] CIGRE Science & Engineering, No. 35, "Testing approach for RTE's R#SPACE Protection Automation and Control System," https://cse.cigre.org/cse-n035/b5-testing-approach-for-rtes-rspace-protection-automation-and-control-system.html

[5] LF Energy, "RTE Deploys LF Energy SEAPATH for Virtual Protection Automation and Control," https://lfenergy.org/rte-deploys-lf-energy-seapath-for-virtual-protection-automation-and-control/

[6] SEAPATH Project, https://seapath.energy/

[7] Straton, "RTE revolutionizes the management of French substations thanks to straton," https://straton-plc.com/en/rte-revolutionizes-the-management-of-french-substations-thanks-to-straton/

[8] Codra, "Distributed control system R#SPACE," https://codra.net/en/news/2020/08/distributed-control-system-rspace/

[9] V. Astier, V. Leitloff, T. Babagana, A. Kurtz Bui, et al., "Проектирование, испытания и наладка и ввод в эксплуатацию — «Интеллектуальные подстанции»", PAC World Magazine, сентябрь 2018 г., стр. 46–51.