В рамках пилотного проекта vPAC (виртуализированная платформа управления и защиты) в 2026 году имеется широкий выбор продуктов. ABB SSC600 SW, GE PhasorController, Siemens SIPROTEC V, референсная платформа LF Energy SEAPATH, версия которой достигла v1.0 в феврале 2025 года, а также длинный ряд предложений участников альянса vPAC. Каждый из них предлагает свой собственный ответ на один и тот же набор инженерных вопросов: какой интерфейс МЭК 61850 должен предоставлять виртуализированное ИЭУ, как он конфигурируется, как поддерживается его синхронизация времени, как осуществляется контроль в процессе эксплуатации и как устанавливаются исправления (патчи) без вывода подстанции из работы.

Чего не хватало, так это общеотраслевой структуры, которая закрепляла бы эти ответы — и сейчас эта структура находится в процессе разработки. Рабочая группа CIGRE B5.84 — полное название: «Рекомендации и ограничения для разработки и сопряжения виртуальных интеллектуальных электронных устройств, реализованных в системах релейной защиты, автоматизации и управления» — является органом, выполняющим эту работу. Она созвана Дэвидом Макдоналдом (GB), при участии Дэвита Мадрида и Маркуса Штолфусса в качестве соавторов статьи о структуре, опубликованной в CIGRE Future Connections 20 января 2026 года и повторно представленной в ELECTRA 345 в апреле 2026 года.

CIGRE не является органом по стандартизации — это международная ассоциация крупных электрических систем, и её рабочие группы выпускают технические брошюры (Technical Brochures), а не нормативные стандарты. Однако CIGRE имеет связь категории А между Исследовательским комитетом B5 (Релейная защита и автоматизация) и IEC TC 57 — техническим комитетом, отвечающим за МЭК 61850. На практике это означает, что работа SC B5 CIGRE — и, в частности, работа соответствующих vIED (виртуальным ИЭУ) рабочих групп, таких как B5.60 (TB 891) и B5.84 — является прямым каналом передачи данных в IEC TC 57 WG 10 и WG 17. Таким образом, определение vIED, выходящее из B5.84, не является обязательным правилом, но это именно тот документ, к которому редакторы МЭК обратятся, когда следующая часть МЭК 61850 потребует явного рассмотрения вопросов виртуализации.

Статья о структуре и техническое задание (TOR) вместе определяют ожидаемый объем окончательной технической брошюры, выпуск которой запланирован на первый квартал 2028 года, а также последствия для пилотных проектов vPAC, ввод в эксплуатацию которых осуществляется сейчас.

Почему CIGRE взялась за это

Рабочая группа B5.84 не появилась из ниоткуда. Она является прямым преемником WG B5.60, которая была инициирована в 2017 году и выпустила техническую брошюру TB 891 «Архитектуры защиты, автоматизации и управления с функциональностью, независимой от аппаратного обеспечения (FIH)» в апреле 2023 года. TB 891 заложила концептуальную основу: функции PAC (защиты, автоматизации и управления) могут быть отделены от устройства, в котором они в данный момент функционируют, и существует два архитектурных пути для этого — ИЭУ на базе промежуточного программного обеспечения (middleware) со стандартизированными интерфейсами к контейнерам приложений, и серверная централизованная система защиты и управления, которая агрегирует приложения на резервируемых вычислительных мощностях.

TB 891 также представил отрасли аргумент о жизненном цикле, который с тех пор приводится в каждом предложении по внедрению vPAC (виртуальных панелей автоматизации): жизненные циклы оборудования ПАС (преобразователя аналоговых сигналов) составляют примерно 10–15 лет, в то время как жизненные циклы первичного оборудования составляют 40–60 лет. Вы заменяете устройство релейной защиты несколько раз за срок службы выключателя. Каждая замена — это пересборка панели, новый SCD-файл, новая кампания по наладке и вводу в эксплуатацию. Функциональность, не зависящая от аппаратного обеспечения, обещает разорвать этот цикл.

Чего TB 891 намеренно не сделал, так это не определил сам vIED (виртуальное интеллектуальное электронное устройство). В нем описывался архитектурный вариант; в нем не говорилось, как должен выглядеть vIED на своих интерфейсах, как он конфигурируется, как осуществляется его контроль или обновление программного обеспечения. Именно этот пробел восполняет B5.84.

Формулировка в статье CIGRE (Международного совета по большим электроэнергетическим системам) предельно прямолинейна: значительная часть установленной базы ИЭУ (интеллектуальных электронных устройств) находится в конце своего срока полезного использования или приближается к нему. Энергоснабжающие организации стоят на пороге принятия следующего раунда решений о замене оборудования. Если они примут их без взгляда со стороны органов стандартизации на то, что представляет собой vIED, отрасль получит ровно то же самое, что и при первой волне внедрения МЭК 6ASS (Международного электротехнического комитета 61850) — шесть вендорских диалектов одной и той же идеи.

Что на самом деле охватывает рабочая группа

Техническое задание (TOR), подписанное председателем SC B5 (технического комитета B5) и датированное 8 января 2024 года, перечисляет темы, которые будет рассматривать рабочая группа.

%%{init: {
  "theme": "base",
  "themeVariables": {
    "background": "#fafaf7",
    "fontFamily": "Roboto Flex, Inter, system-ui, sans-serif",
    "primaryColor": "#1e1f1d",
    "primaryTextColor": "#fafaf7",
    "primaryBorderColor": "#58c1da",
    "lineColor": "#cbcbc4",
    "mainBkg": "#1e1f1d",
    "nodeTextColor": "#fafaf7",
    "darkTextColor": "#fafaf7",

    "cScale0":  "#1e1f1d", "cScaleLabel0":  "#fafaf7", "cScaleInv0":  "#58c1da",
    "cScale1":  "#d6f0f6", "cScaleLabel1":  "#0d5566", "cScaleInv1":  "#58c1da",
    "cScale2":  "#fdf0c5", "cScaleLabel2":  "#5c3f00", "cScaleInv2":  "#f5b301",
    "cScale3":  "#d1efe1", "cScaleLabel3":  "#0e4f31", "cScaleInv3":  "#2f9e6a",
    "cScale4":  "#fbd6d8", "cScaleLabel4":  "#6e1014", "cScaleInv4":  "#e5484d",
    "cScale5":  "#c3e7ef", "cScaleLabel5":  "#0d4452", "cScaleInv5":  "#2fa9c6",
    "cScale6":  "#dde0e3", "cScaleLabel6":  "#2e3338", "cScaleInv6":  "#6e7681",
    "cScale7":  "#1e1f1d", "cScaleLabel7":  "#fafaf7", "cScaleInv7":  "#58c1da",
    "cScale8":  "#1e1f1d", "cScaleLabel8":  "#fafaf7", "cScaleInv8":  "#58c1da",
    "cScale9":  "#1e1f1d", "cScaleLabel9":  "#fafaf7", "cScaleInv9":  "#58c1da",
    "cScale10": "#1e1f1d", "cScaleLabel10": "#fafaf7", "cScaleInv10": "#58c1da",
    "cScale11": "#1e1f1d", "cScaleLabel11": "#fafaf7", "cScaleInv11": "#58c1da"
  }
}}%%
mindmap
  root((Рабочая группа B5.84<br/>область применения))
    Определение
      Виртуальное ИЭУ: что это и чем не является
      Риски, преимущества, решения
    Интерфейс
      МЭК 61850 обязательно
      Правила и файлы конфигурации
      Синхронизация времени
    Жизненный цикл
      Администрирование и обновление
      Надзор за vIED
    Ресурсы
      Пропускная способность сети
      Объем памяти
      Мощность ЦП
    Сторона хоста
      Требования к серверу для размещения vIED
      Требования к интерфейсу Сервер-vIED
      Требования к промышленному серверу
      Сравнение гипервизоров
      Резервирование
      Мониторинг оборудования/промежуточного ПО/ПО
    Будущее
      Будущее концепции vIED
      Связь с Цифровым двойником

Несколько моментов из этой схемы заслуживают особого внимания.

Интерфейс МЭК 61850 является обязательным. И в Техническом задании (ТЗ), и в статье CIGRE это утверждается дважды: vIED (виртуальное интеллектуальное электронное устройство) должен предоставлять интерфейс МЭК 61850 и должен быть настраиваемым с использованием правил и файлов конфигурации МЭК 61850. Пути «собственного проприетарного эквивалента производителя» не существует. Если продукт называет себя vIED, но не использует SCD-файл, то это что-то другое.

Как методы на базе виртуальных машин (VM), так и контейнеров включены в рассмотрение. В статье CIGRE явно описываются два основных метода виртуализации: системы на основе гипервизора, где каждая VM содержит собственную операционную систему, и системы на основе контейнеров, где контейнеры работают в операционной системе хоста через движок контейнеризации. Рабочая группа (РГ) охватывает оба метода. Она не выбирает победителя, и, судя по формулировкам ТЗ, вряд ли это сделает. Следует ожидать сравнительного анализа.

Надзор и обновление выделены в отдельные главы. Две из перечисленных тем — это «администрирование и обновление виртуального ИЭУ» и «надзор за виртуальным ИЭУ». Любому, кто имеет опыт полевого обновления прошивок на целом парке ИЭУ уровня присоединения, этот раздел стоит прочитать первым сразу после выхода брошюры. Виртуальное ИЭУ (vIED), которое легко развернуть при заводских приёмо-сдаточных испытаниях, но невозможно поддерживать в полевых условиях, является регрессом, а не прогрессом.

Хост-платформа входит в сферу охвата — но не сама архитектура ПАС. Рабочая группа (WG) охватывает серверную сторону: требования к промышленным серверам, сравнение гипервизоров, резервирование, мониторинг аппаратного обеспечения/промежуточного ПО/программного обеспечения. Она не охватывает то, как в целом выстроена архитектура ПАС, и не охватывает структуру серверов для централизованной ПАС — это закреплено за WG B5.70.

Это полезное разграничение для понимания. B5.84 говорит вам о том, каким должен быть vIED на своих интерфейсах и как должен вести себя его хост-сервер для его поддержки. Она не говорит вам, следует ли строить централизованную ПАС, распределенную vPAC или гибридную систему. Архитектура — это задача другой рабочей группы.

Что рабочая группа явно не охватывает

%%{init: {
  "theme": "base",
  "themeVariables": {
    "background": "#fafaf7",
    "fontFamily": "Roboto Flex, Inter, system-ui, sans-serif",
    "primaryColor": "#ffffff",
    "primaryTextColor": "#1e1f1d",
    "primaryBorderColor": "#e2e2dc",
    "lineColor": "#cbcbc4"
  }
}}%%
flowchart LR
    subgraph IN["B5.84 В сфере охвата"]
        direction TB
        I1["Определение vIED"]
        I2["Интерфейс МЭК 61850"]
        I3["Конфигурация · синхронизация времени"]
        I4["Обновление · надзор"]
        I5["Расчет ресурсов ЦП · памяти · сети"]
        I6["Требования к хост-платформе"]
        I7["Сравнение гипервизоров"]
        I1 ~~~ I2 ~~~ I3 ~~~ I4 ~~~ I5 ~~~ I6 ~~~ I7
    end
    subgraph OUT["ВНЕ сферы охвата"]
        direction TB
        O1["Выбор архитектуры ПАС"]
        O2["Структура централизованного сервера ПАС<br/>(зарезервировано для WG B5.70)"]
        O3["Сертификация продукции вендора"]
        O4["Выбор между ВМ и контейнером как политика"]
        O1 ~~~ O2 ~~~ O3 ~~~ O4
    end
    IN -.->|"дополняет"| OUT

    classDef inItem  fill:#d6f0f6,stroke:#58c1da,color:#0d5566;
    classDef outItem fill:#dde0e3,stroke:#6e7681,color:#2e3338;
    class I1,I2,I3,I4,I5,I6,I7 inItem
    class O1,O2,O3,O4 outItem
    style IN  fill:#eff8fb,stroke:#58c1da,stroke-width:1.5px,color:#0d5566;
    style OUT fill:#f3f3ee,stroke:#6e7681,stroke-width:1.5px,color:#2e3338;

Инженеры, которые читали только маркетинговые материалы по vPAC, склонны полагать, что структура CIGRE в конечном итоге подскажет им, какую архитектуру выбрать — центральный сервер, распределенные серверы или гибрид с граничными узлами (edge boxes). Этого не произойдет. WG B5.84 принимает архитектуру как данность и отвечает на более узкий и полезный вопрос: независимо от того, где вы размещаете vIED, что сам vIED «должен» остальной системе?

В техническом задании (ТЗ) также указана «перспектива концепции vIED» и отмечена связь между виртуальным ИЭУ (vIED) и концепцией цифрового двойника как тема, которую будет обсуждать рабочая группа (РГ). Каким именно будет эта взаимосвязь в брошюре, в открытых источниках на данный момент не зафиксировано.

Два метода виртуализации рядом друг с другом

В статье CIGRE (Международного совета по крупным электроэнергетическим системам) эти два метода описываются следующим образом. Сопоставим их с тем, что фактически поставляется на рынок в настоящее время:

%%{init: {
  "theme": "base",
  "themeVariables": {
    "background": "#fafaf7",
    "fontFamily": "Roboto Flex, Inter, system-ui, sans-serif",
    "primaryColor": "#ffffff",
    "primaryTextColor": "#1e1f1d",
    "primaryBorderColor": "#e2e2dc",
    "lineColor": "#cbcbc4"
  }
}}%%
flowchart TB
    subgraph H["Гипервизор + ВМ"]
        direction TB
        HW1["Промышленное серверное оборудование<br/>(МЭК 61850-3 / IEEE 1613)"]:::hw
        HV["Гипервизор (KVM / VMware ESXi)"]:::platform
        OS1["Гостевая ОС · vIED-A"]:::runtime
        OS2["Гостевая ОС · vIED-B"]:::runtime
        OS3["Гостевая ОС · vIED-C"]:::runtime
        APP1["Приложение защиты A"]:::app
        APP2["Приложение защиты B"]:::app
        APP3["Приложение защиты C"]:::app
        HW1 --> HV
        HV --> OS1 --> APP1
        HV --> OS2 --> APP2
        HV --> OS3 --> APP3
    end
    H ~~~ C
    subgraph C["Движок контейнеров + контейнеры"]
        direction TB
        HW2["Промышленное серверное оборудование<br/>(МЭК 61850-3 / IEEE 1613)"]:::hw
        OSH["Хостовая ОС (Linux, ядро реального времени)"]:::platform
        CE["Движок контейнеров"]:::platform
        CT1["Контейнер · vIED-A"]:::runtime
        CT2["Контейнер · vIED-B"]:::runtime
        CT3["Контейнер · vIED-C"]:::runtime
        AP1["Приложение защиты A"]:::app
        AP2["Приложение защиты B"]:::app
        AP3["Приложение защиты C"]:::app
        HW2 --> OSH --> CE
        CE --> CT1 --> AP1
        CE --> CT2 --> AP2
        CE --> CT3 --> AP3
    end

    classDef hw       fill:#1e1f1d,stroke:#1e1f1d,color:#fafaf7;
    classDef platform fill:#d6f0f6,stroke:#58c1da,color:#0d5566;
    classDef runtime  fill:#fdf0c5,stroke:#f5b301,color:#5c3f00;
    classDef app      fill:#d1efe1,stroke:#2f9e6a,color:#0e4f31;
    style H fill:#fafaf7,stroke:#e2e2dc,stroke-width:1.5px,color:#1e1f1d;
    style C fill:#fafaf7,stroke:#e2e2dc,stroke-width:1.5px,color:#1e1f1d;

В статье CIGRE различие сформулировано прямо: «разница между ними заключается в том, что виртуальная машина содержит собственную операционную систему (ОС), тогда как все контейнеры работают на хостовой операционной системе». Это различие меняет ответ практически на каждый вопрос, на который призвана ответить брошюра:

  • Синхронизация времени: в модели виртуальных машин (VM) каждая гостевая операционная система (ОС) завершает процесс PTP (IEEE 1588) отдельно. В контейнерной модели хостовая ОС удерживает время, а контейнеры его наследу deют. Правила настройки, которые вы пишете для одного метода, не применимы к другому.
  • Администрирование обновлений: обновление VM означает оркестрацию ОС плюс приложения; обновление контейнера означает замену образа. Профиль рисков здесь различается.
  • Надзор: то, что считается сигналом «vIED (виртуальное ИЭУ) работает», отличается. Контейнер может быть запущен, в то время как его приложение не функционирует; VM может быть запущена, даже если её сетевой интерфейс (NIC) потерял драйвер. Рабочей группе (WG) потребуется определить сигнал надзора на уровне МЭК 61850 так, чтобы он не зависел от того, какой метод использует хост.

Сегодня у каждого производителя продукции vPAC (виртуальный процессор автоматизации подстанции) есть свой собственный ответ на эти вопросы. В брошюре не будет предписана конкретная реализация, но ожидается, что в ней будет определен интерфейс и поведение на уровне МЭК 61850, которые vIED должен обеспечивать независимо от используемого метода виртуализации.

Работа в реальном времени, детерминизм и вещи, которые рабочая группа не может игнорировать

В статье CIGRE (Международный совет по большим электроэнергетическим системам и сетевым системам) «одной из проблем виртуализации» названо «гарантирование низкой задержки и детерминированной производительности». Для функций защиты, имеющих решающее значение: МЭК 61850-5 устанавливает время передачи для сообщения о срабатывании типа 1A в пределах 3 мс. Виртуализированная платформа либо соответствует этому требованию в худшем случае нагрузки, при худшем фоновом процессе, при худшем эффекте «шумного соседа» на том же сокете — либо нет.

В недавних академических работах были четко указаны необходимые методы: ядра Linux реального времени, привязка процессора (CPU pinning) для выделения ядер под vIED, размещение с учетом архитектуры NUMA (не-единый доступ к памяти), аппаратная трансляция (hardware passthrough) для сетевых интерфейсов, обрабатывающих трафик SV (мгновенные значения) и GOOSE, а также настройка планировщика гипервизора для обеспечения детерминированной задержки. Опубликованные бенчмарки Делфтского технического университета (TU Delft) виртуализированных контроллеров на программно-определяемой подстанции МЭК 61850 показали среднее время срабатывания GOOSE ниже требования МЭК 61850 по времени передачи в 3 мс — но только при наличии конфигурации реального времени и только при контролируемой нагрузке трафика. В оценочной работе MDPI (Multidisciplinary Digital Publishing Institute) содержится та же оговорка: задержка связи увеличивается по мере добавления vIED и роста фонового трафика, и эта зависимость не является линейной.

Это самая сложная часть, которую рабочей группе необходимо сформулировать, не превращая документ в руководство по выбору поставщика. Ожидается, что брошюра будет определять параметры надзора и формирования отчётов (Reporting), которые позволят сетевой компании измерить, соответствует ли её хост целевым показателям детерминизма, а не предписывать конкретную версию ядра Linux или гипервизора. Формулировка технического задания (TOR) — «оценка пропускной способности связи, памяти и процессора» — подтверждает такую интерпретацию.

Результаты работы и сроки

В ТЗ указаны четыре квартала с фиксированными контрольными точками; всё остальное (начало работы над рабочим проектом, периодичность внутреннего рецензирования) не привязано к датам и не должно подразумеваться:

Раздел Этап 4 кв. 2027 1 кв. 28 2 кв. 28
Брошюра Черновик технической брошюры (ТБ) для рассмотрения Комитетом по исследованию (SC) ◆
Брошюра Итоговая техническая брошюра (критически важно) ◆
Коммуникации Обучающий курс ◆
Коммуникации Вебинар ◆

4 кв. 2027 года — представление черновика технической брошюры (ТБ) в Комитет по исследованию. 1 кв. 2028 года — выпуск итоговой ТБ. 2 кв. 2028 года — проведение обучающего курса и вебинара. Обсуждаемая здесь статья, опубликованная в ELECTRA, является частью этого графика — это первый публичный программный документ рабочей группы (РГ), предназначенный для представления основ концепции, пока брошюра еще находится в процессе написания.

По стандартам рабочих групп CIGRE (Международного совета по большим электрическим системам) — это сжатый график. Но он также является верным. Рынок виртуальных подстанций (vPAC) развивается достаточно быстро, так что брошюра, опубликованная ближе к концу десятилетия, будет описывать музейный экспонат.

Три инженерных решения, которые необходимо принять до выхода брошюры

Если вы проводите пилотное внедрение vPAC в 2026 году, из текущей концепции следуют три важных момента.

Во-первых, убедитесь, что ваши перспективные виртуальные интеллектуальные электронные устройства (vIED) имеют интерфейс МЭК 61850, который можно настраивать с помощью SCL-файлов (согласно требованию Технического задания (ТЗ) о том, что vIED должны «настраиваться на основе правил и файлов конфигурации МЭК 61850»), а не только через проприетарный графический пользовательский интерфейс (GUI) производителя. Любое устройство, введенное в эксплуатацию сегодня с использованием закрытого инструмента конфигурации, не будет соответствовать этому требованию и, скорее всего, потребует переработки после публикации брошюры.

Во-вторых, решите сейчас, пойдете ли вы по пути виртуальных машин (VM) или контейнеров, и настройте процессы мониторинга и обновления в соответствии с этим выбором. РГ не будет выбирать победителя. Однако она определит, какие функции мониторинга и обновления vIED должен предоставлять остальной системе; если ваш пилотный проект уже передает эти сигналы через MMS, вам не придется проводить модернизацию после выхода брошюры.

В-третьих, обратите внимание на то, что РГ не охватывает. Архитектура вашей системы автоматизации цифровых подстанций (PACS) — централизованная, распределенная или гибридная — не входит в сферу компетенции рабочей группы B5.84. Это ваше инженерное решение; структура централизованного сервера PACS упоминается в ТЗ для B5.84 как работа, относящаяся к РГ B5.70 (отдельной рабочей группе). Не ждите, что B5.84 скажет вам, стоит ли строить централизованный контроллер присоединения (CPC). Она этого не сделает.

Что касается мониторинга — главы, которую, скорее всего, придется интегрировать в существующие инструменты, а не разрабатывать с нуля, — сетевые компании, использующие сегодня мониторы трафика МЭК 61850 в реальном времени, имеют преимущество. Для инструментов вроде Tekvel Park, которые уже осуществляют мониторинг трафика GOOSE, SV и MMS в реальных сетях PACS, vIED является просто еще одним источником данных; им не важно, является ли источником реле или виртуальная машина, до тех пор, пока интерфейс и поведение МЭК 61850 остаются неизменными. Именно эту мысль отстаивает РГ: идентификатором vIED для остальной части подстанции является его интерфейс МЭК 61850, а не его аппаратная часть.

Гипервизор против контейнера и граница кибербезопасности

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

Первый вопрос — это рекомендация по выбору между гипервизором и контейнером. В статье CIGRE (Международный совет по большим электроэнергетическим системам) оба метода представлены в равной степени. Техническое задание (ТЗ) включает «сравнение гипервизоров». Реальная промышленная практика разделена: в лагере виртуальных машин (ВМ) доминируют VMware ESXi и Linux KVM; в лагере контейнеров появляются Kubernetes, k3s и специализированные движки контейнеров. SEAPATH, эталонное решение LF Energy, основан на KVM. Большинство поставляемых сегодня вендорами продуктов vPAC (виртуализированных панелей управления присоединениями) базируются на ВМ. Если рабочая группа (РГ) в итоге займет нейтральную позицию, брошюра станет полезным справочным материалоном; если же она будет продвигать один из методов, это изменит дорожные карты вендоров.

Второй вопрос — граница с кибербезопасностью. Виртуализация уменьшает поверхность атаки в одних местах (один защищенный хост вместо двадцати незащищенных устройств) и увеличивает в других (компрометация гипервизора теперь означает компрометацию подстанции). В ТЗ кибербезопасность не вынесена в отдельный заголовок главы, но эта тема неизбежна. Интересный вопрос заключается в том, будет ли B5.84 ссылаться на работу РГ B5.66 / SC D2 по кибербезопасности операционных технологий (OT), или же напишет собственное краткое заявление о том, какие требования предъявляет интерфейс vIED (виртуального интеллектуального электронного устройства) к архитектуре безопасности. Статья CIGRE не дает ответа на этот вопрос.

Для инженеров, которые до сих пор рассматривают некоторые части стека МЭК 61850 как необязательные — особенно мгновенные значения (Sampled Values, SV), где стоимость ПАС (преобразователей аналоговых сигналов) и шины процесса использовалась в качестве аргумента для откладывания внедрения, — структура РГ B5.84 является, по сути, ответом. У vIED нет собственных входов/выходов (I/O). У него нет медных входов. Единственный способ, которым он «видит» подстанцию, — это через шину процесса и станционную шину МЭК 61850. Виртуализация делает весь стек обязательным так, как это никогда не было при использовании аппаратных ИЭУ, потому что аппаратное ИЭУ всегда могло переключиться на проводной вход от трансформатора тока. В мире vIED нет резервного варианта — шина процесса И ЕСТЬ вход. Экономия от удаления двадцати ИЭУ будет достигнута только в том случае, если инфраструктура ПАС под ними уже существует.

Будьте осторожны с ожиданием ответов в течение двух лет. Подстанции, которые проходят наладку и ввод в эксплуатацию сейчас, будут работать 4fmt40 лет. Эта структура разрабатывается именно для них.

Источники