Um piloto vPAC em 2026 tem uma ampla gama de produtos para escolha. ABB SSC600 SW, GE PhasorController, Siemens SIPROTEC V, a plataforma de referência LF Energy SEAPATH que alcançou a versão 1.0 em fevereiro de 2025, e uma longa lista de ofertas dos membros da vPAC Alliance. Cada uma tem sua própria resposta para o mesmo conjunto de questões de engenharia: qual é a interface IEC 61850 que um IED virtualizado precisa expor, como é configurado, como é mantida sua disciplina de tempo, como é supervisionado em operação e como é atualizado sem desligar a subestação.

O que tem faltado é um quadro setorial que fixe essas respostas — e esse quadro está sendo elaborado agora. O Grupo de Trabalho B5.84 da CIGRE — título completo "Recomendações e restrições para o desenvolvimento e interface de Dispositivos Eletrônicos Inteligentes virtualizados em Sistemas de Proteção, Automação e Controle" — é o órgão responsável pelo trabalho. É convocado por David Macdonald (GB), com David Madrid e Marcus Stollfuss como coautores do artigo do quadro publicado em CIGRE Future Connections em 20 de janeiro de 2026 e reexibido em ELECTRA 345 em abril de 2026.

A CIGRE não é um órgão de normas — é a associação internacional de grandes sistemas elétricos, e seus grupos de trabalho produzem Brochuras Técnicas, não normas normativas. O que a CIGRE possui é uma ligação de Categoria A entre o Comitê de Estudos B5 (Proteção e Automação) e o TC 57 da IEC, o comitê técnico responsável pelo IEC 61850. Na prática, isso significa que o trabalho do CIGRE SC B5 — e especificamente o trabalho de grupos de trabalho relevantes para vIED, como o B5.60 (TB 891) e o B5.84 — é um canal direto de entrada para o WG 10 e o WG 17 do TC 57 da IEC. Uma definição de vIED proveniente do B5.84, portanto, não é uma regra vinculante, mas é o documento que os editores da IEC consultarão quando a próxima parte do IEC 61850 precisar abordar explicitamente a virtualização.

O artigo do quadro e o Termo de Referência (TOR) juntos estabelecem o escopo esperado da brochura técnica final, prevista para o primeiro trimestre de 2028, e as implicações para os pilotos vPAC que estão sendo comissionados agora.

Por que a CIGRE se interessou

O Grupo de Trabalho B5.84 não surgiu do nada. É o sucessor direto do WG B5.60, que foi iniciado em 2017 e produziu a Brochura Técnica 891, "Arquiteturas de Proteção, Automação e Controle com Funcionalidade Independente de Hardware (FIH)", em abril de 2023. A TB 891 estabeleceu o fundamento conceitual: as funções de PAC podem ser desacopladas da caixa em que atualmente residem, e existem dois caminhos arquiteturais para isso — um IED baseado em middleware com interfaces padronizadas para contêineres de aplicação, e um sistema Centralizado de Proteção e Controle baseado em servidor que agrega aplicativos em computação redundante.

O TB 891 também proporcionou à indústria o argumento do ciclo de vida que tem sido citado em cada apresentação de vPAC desde então: os ciclos de vida do hardware PAC são aproximadamente de 10 a 15 anos, enquanto os ciclos de vida das instalações primárias são de 40 a 60 anos. Substitui-se o relé várias vezes ao longo da vida do disjuntador. Cada substituição representa uma reconstrução do painel, um novo SCD, uma nova campanha de comissionamento. A funcionalidade independente do hardware promete quebrar esse ciclo.

O que o TB 891 deliberadamente não fez foi especificar o próprio vIED. Ele descreveu a opção arquitetural; não disse como o vIED tem que ser na sua interface, como é configurado, como é supervisionado ou como é atualizado. É essa lacuna que o B5.84 está preenchendo.

A formulação no artigo da CIGRE é direta: uma grande porcentagem da base instalada de IEDs está no final de sua vida útil ou se aproximando dela. As concessionárias estão prestes a tomar as próximas decisões de substituição. Se o fizerem sem uma visão do corpo de normas sobre o que é um vIED, a indústria terá exatamente o que teve com a primeira onda de implantações do IEC 61850 — seis dialetos específicos de cada fornecedor da mesma ideia.

O que o GT realmente abrange

O termo de referência (TOR), assinado pela presidente do SC B5 e datado de 8 de janeiro de 2024, lista os tópicos que o GT tratará.

%%{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((WG B5.84<br/>alcance))
    Definição
      IED virtual · o que é e o que não é
      Riscos, benefícios, soluções
    Interface
      IEC 61850 obrigatória
      Regras e ficheiros de configuração
      Sincronização de tempo
    Ciclo de vida
      Administração e atualização
      Supervisão do vIED
    Recursos
      Capacidade de comunicação
      Capacidade de memória
      Capacidade de CPU
    Lado do host
      Requisitos do servidor para alojamento do vIED
      Requisitos da interface servidor-vIED
      Requisitos do servidor industrial
      Comparação de hipervisores
      Redundância
      Monitorização de hardware/middleware/software
    Futuro
      Futuro do conceito de vIED
      Ligação ao Digital Twin

Algumas observações merecem destaque a partir deste mapa.

**A interface IEC 61850 é obrigatória.** Tanto o TOR quanto o artigo da CIGRE mencionam duas vezes: um vIED deve expor uma interface IEC 61850 e deve ser configurável utilizando regras e ficheiros de configuração IEC 61850. Não existe uma via alternativa proprietária do fornecedor. Se um produto se autodenomina vIED e não consome um SCD, trata-se de algo diferente.

**Tanto os métodos VM como container estão incluídos.** O artigo da CIGRE descreve explicitamente os dois métodos principais de virtualização: sistemas baseados em hipervisor, onde cada VM contém o seu próprio sistema operativo, e sistemas baseados em containers, onde os containers executam no sistema operativo hospedeiro através de uma engine de containers. O WG abrange ambos. Não escolhe um vencedor, e pelo modo como o TOR está redigido, é improvável que o faça. Espere uma abordagem comparativa.

**A supervisão e a atualização recebem um capítulo cada.** Dois dos tópicos listados são "administração e atualização do IED virtual" e "supervisão do IED virtual". Para quem tem experiência de campo em atualizações em massa de firmware em uma frota de IEDs de nível de barramento, esta é a seção a ser lida primeiro quando o folheto for lançado. Um vIED que é fácil de implantar em aceitação de fábrica e impossível de manter em campo representa um retrocesso, não um avanço.

**A plataforma hospedeira está dentro do escopo — mas não a arquitetura do PACS.** O WG abrange o lado do servidor: requisitos de servidor industrial, comparação de hypervisors, redundância, monitoramento de hardware/middleware/software. O que ele não aborda é como o PACS como um todo é arquitetado, nem a estrutura do servidor para PACS centralizados — isso é reservado para o WG B5.70.

Este é um limite útil para compreender. O B5.84 está dizendo o que um vIED deve ser em suas interfaces e como sua plataforma hospedeira deve se comportar para apoiá-lo. Ele não está dizendo se você deve construir um PAC centralizado, um vPAC distribuído ou um híbrido. A arquitetura é assunto de outro grupo de trabalho.

## O que o WG explicitamente não aborda

```mermaid
%%{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 Dentro do escopo"]
        direction TB
        I1["Definição do vIED"]
        I2["Interface IEC 61850"]
        I3["Configuração · sincronização de tempo"]
        I4["Atualização · supervisão"]
        I5["Dimensionamento de CPU · memória · rede"]
        I6["Requisitos da plataforma hospedeira"]
        I7["Comparação de hypervisors"]
        I1 ~~~ I2 ~~~ I3 ~~~ I4 ~~~ I5 ~~~ I6 ~~~ I7
    end
    subgraph OUT["Fora do escopo"]
        direction TB
        O1["Escolha da arquitetura do PACS"]
        O2["Estrutura do servidor do PACS centralizado<br/>(reservado para o WG B5.70)"]
        O3["Certificação de produtos do fornecedor"]
        O4["Escolha entre VM ou container como política"]
        O1 ~~~ O2 ~~~ O3 ~~~ O4
    end
    IN -.->|"complementa"| 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;

Engenheiros que leram apenas o material de marketing em torno do vPAC tendem a assumir que a estrutura da CIGRE acabará dizendo a eles qual arquitetura escolher — servidor central, servidores distribuídos, híbrido com caixas de borda. Não o fará. O WG B5.84 toma a arquitetura como dada e responde a uma pergunta mais restrita e útil: independentemente de onde você coloca o vIED, o que o próprio vIED deve ao resto do sistema?

O TOR também lista o "futuro do conceito de vIED" e observa uma ligação entre o IED virtual e o conceito de Digital Twin como um tópico que o WG discutirá. Qual será essa ligação no folheto ainda não está registrado publicamente.

Os dois métodos de virtualização, lado a lado

O artigo da CIGRE descreve os dois métodos da seguinte forma. Mapeando-os ao que atualmente está sendo comercializado:

%%{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["Hipervisor + VMs"]
        direction TB
        HW1["Hardware industrial de servidor<br/>(IEC 61850-3 / IEEE 1613)"]:::hw
        HV["Hipervisor (KVM / VMware ESXi)"]:::platform
        OS1["Sistema operacional convidado · vIED-A"]:::runtime
        OS2["Sistema operacional convidado · vIED-B"]:::runtime
        OS3["Sistema operacional convidado · vIED-C"]:::runtime
        APP1["Aplicação de proteção A"]:::app
        APP2["Aplicação de proteção B"]:::app
        APP3["Aplicação de proteção C"]:::app
        HW1 --> HV
        HV --> OS1 --> APP1
        HV --> OS2 --> APP2
        HV --> OS3 --> APP3
    end
    H ~~~ C
    subgraph C["Motor de contêineres + contêineres"]
        direction TB
        HW2["Hardware industrial de servidor<br/>(IEC 61850-3 / IEEE 1613)"]:::hw
        OSH["Sistema operacional hospedeiro (Linux, kernel em tempo real)"]:::platform
        CE["Motor de contêineres"]:::platform
        CT1["Contêiner · vIED-A"]:::runtime
        CT2["Contêiner · vIED-B"]:::runtime
        CT3["Contêiner · vIED-C"]:::runtime
        AP1["Aplicação de proteção A"]:::app
        AP2["Aplicação de proteção B"]:::app
        AP3["Aplicação de proteção 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;

O artigo da CIGRE afirma a distinção diretamente: "a diferença entre eles é que a máquina virtual contém seu próprio Sistema Operacional (OS), enquanto os contêineres executam todos no sistema operacional hospedeiro." Essa distinção altera a resposta para quase todas as perguntas que o folheto pretende abordar:

  • Sincronização de tempo: no modelo de VM, cada sistema operacional convidado termina o PTP separadamente. No modelo de contêiner, o sistema operacional hospedeiro detém o tempo e os contêineres o herdam. A disciplina que você escreve para um não se aplica ao outro.
  • Administração de atualizações: atualizar uma VM significa orquestrar um sistema operacional mais uma aplicação; atualizar um contêiner significa trocar uma imagem. O perfil de risco é diferente.
  • Supervisão: o que conta como sinal de "vIED está ativo" difere. Um contêiner pode estar ativo enquanto sua aplicação está inativa; uma VM pode estar ativa enquanto sua placa de rede perdeu o driver. O WG precisará definir o sinal de supervisão no nível do IEC 61850 para que não dependa do método utilizado pelo host.

Hoje, cada fornecedor que produz produtos vPAC tem sua própria resposta para essas questões. A brochura não prescreverá uma implementação, mas espera-se que defina a interface e o comportamento no nível do IEC 61850 que um vIED deve expor, independentemente do método de virtualização subjacente.

Tempo real, determinismo e as coisas que o WG não pode ignorar

O artigo da CIGRE identifica como "um dos desafios da virtualização" a "garantia de baixa latência e desempenho determinístico". Para proteção, isso é decisivo: o IEC 61850-5 estabelece um tempo de transferência de 3 ms para uma mensagem de disparo do tipo 1A. Uma plataforma virtualizada ou atende a esse requisito em todas as condições de carga pior, em todos os processos de fundo mais intensos, em todos os vizinhos ruidosos no mesmo soquete — ou não atende.

Trabalhos acadêmicos recentes têm sido explícitos sobre as técnicas necessárias. Núcleos Linux em tempo real, fixação de CPU para dedicar núcleos ao vIED, posicionamento consciente de NUMA, passagem direta de hardware para placas de rede que lidam com tráfego SV e GOOSE, configuração do agendador do hipervisor para latência determinística. As avaliações publicadas pela TU Delft de controladores virtualizados em uma subestação IEC 61850 definida por software mostraram tempos médios de disparo GOOSE abaixo do requisito de tempo de transferência de 3 ms do IEC 61850 — mas somente com a configuração em tempo real em vigor e somente sob cargas de tráfego controladas. O trabalho de avaliação da MDPI faz a mesma ressalva: a latência de comunicação aumenta à medida que se adicionam vIEDs e o tráfego de fundo cresce, e a relação não é linear.

Este é o aspecto mais difícil que o WG precisa documentar sem se tornar um guia de seleção de fornecedores. Espera-se que a brochura especifique a supervisão e a reportagem que permitam à concessionária medir se seu host está atendendo às metas de determinismo, em vez de mandatar uma versão específica de kernel Linux ou hipervisor. A formulação do TOR — "avaliação de capacidade de comunicação, memória e CPU" — apoia essa interpretação.

Os entregáveis e o cronograma

O TOR lista quatro trimestres de marcos com fonte; todo o resto (início do rascunho de trabalho, ritmo de revisão interna) não está vinculado a uma data e não deve ser inferido:

Seção Marca 4º tri. 2027 1º tri. 2028 2º tri. 2028
Brochura Rascunho da TB para revisão pelo SC ◆
Brochura Brochura Técnica Final (crítica) ◆
Comunicações Tutorial ◆
Comunicações Webinário ◆

4º tri. 2027 para o rascunho da Brochura Técnica apresentado ao Comitê de Estudo. 1º tri. 2028 para a TB final. 2º tri. 2028 para o tutorial e o webinário. O artigo publicado pela ELECTRA que está sendo discutido aqui faz parte desse cronograma — o primeiro documento público do GT, projetado para apresentar a estrutura enquanto a brochura ainda está sendo elaborada.

De acordo com os padrões dos grupos de trabalho da CIGRE, este é um cronograma apertado. Mas também é o correto. O mercado de vPAC está evoluindo rápido o suficiente que uma brochura publicada no final da década descreveria um museu.

Três decisões de engenharia a tomar antes da brochura ser publicada

Se você está conduzindo um piloto de vPAC em 2026, três coisas decorrem do quadro como está atualmente.

Primeiro, certifique-se de que seus candidatos a vIEDs exibam uma interface IEC 61850 configurável a partir de arquivos SCL (conforme a exigência do TOR de que os vIEDs sejam "configuráveis com base nas regras e arquivos de configuração IEC 61850"), e não a partir de uma interface gráfica proprietária. Qualquer equipamento comissionado hoje com base em uma ferramenta de configuração proprietária ficará fora dessa exigência e será um candidato provável a reestruturação assim que a brochura for publicada.

Segundo, decida agora se você seguirá pela rota de VMs ou contêineres, e configure seus processos de supervisão e atualização de acordo com essa escolha. O GT não vai escolher um vencedor. No entanto, definirá o que um vIED deve ao resto do sistema em termos de supervisão e atualização; se seu piloto já expõe esses sinais via MMS, você não precisará fazer retrofit quando a brochura for lançada.

Terceiro, preste atenção ao que o GT não está abrangendo. A arquitetura do seu PACS — centralizada, distribuída, híbrida — não está dentro do escopo do B5.84. Essa é uma decisão de engenharia sua; a estrutura de servidor PACS centralizada é mencionada no TOR do B5.84 como trabalho pertencente ao GT B5.70 (um grupo de trabalho separado). Não espere o B5.84 dizer se você deve ou não construir um CPC. Ele não o fará.

Para a supervisão especificamente — o capítulo mais provável de ser adaptado a ferramentas existentes em vez de desenvolvido do zero — as concessionárias que operam monitoradores de tráfego IEC 61850 em tempo real hoje têm uma vantagem. Um vIED, assim como um IED de hardware, publica dados em um barramento. Ferramentas como o Tekvel Park, que já supervisionam tráfego GOOSE, SV e MMS em redes PACS reais, veem um vIED como apenas outro publicador; elas não se importam se a fonte é uma relé ou uma VM, desde que a interface e o comportamento IEC 61850 estejam intactos. É esse o ponto que o GT está impondo: a identidade do vIED para o resto da subestação é sua interface IEC 61850, não seu hardware.

Hipervisor versus contêiner e a fronteira de cibersegurança

Restam duas grandes questões, e a brochura terá que respondê-las.

A primeira é a recomendação entre hypervisor e container. O artigo da CIGRE apresenta ambos os métodos de forma equilibrada. O TOR inclui "comparação de hypervisors". A prática industrial real está dividida — o VMware ESXi e o Linux KVM dominam o campo de VMs; o Kubernetes, o k3s e motores de container personalizados estão surgindo no campo de containers. O SEAPATH, a referência da LF Energy, é baseado em KVM. A maioria dos produtos vPAC enviados por fornecedores atualmente é baseada em VMs. Se o WG terminar neutro, o folheto será uma referência útil; se acabar favorecendo um dos métodos, isso reconfigurará as estratégias de produto dos fornecedores.

A segunda é o limite com a segurança cibernética. A virtualização torna as superfícies de ataque menores em alguns lugares (um host hardenado em vez de vinte dispositivos expostos) e maiores em outros (uma comprometida do hypervisor agora é uma comprometida da subestação). O TOR não eleva a segurança cibernética a um título de capítulo, mas o tema é inevitável. A questão interessante é se o B5.84 fará referência cruzada ao trabalho do WG B5.66 / SC D2 sobre segurança cibernética em OT, ou se escreverá sua própria declaração curta sobre o que a interface do vIED deve à arquitetura de segurança. O artigo da CIGRE não revela isso.

Para engenheiros que ainda tratam partes da pilha IEC 61850 como opcionais — especialmente os Valores Amostrados, onde o custo das unidades de fusão e da rede de processo tem sido usado como argumento para adiar a adoção — a estrutura do WG B5.84 é, de passagem, uma resposta. Um vIED não tem I/O nativo. Não tem entradas por cobre. A única forma como ele vê a subestação é através da rede de processo IEC 61850 e da rede de estação. A virtualização torna a pilha completa obrigatória de uma forma que os IEDs de hardware nunca fizeram totalmente, porque um IED de hardware sempre poderia recorrer a uma entrada de CT por cabo. No mundo do vIED não há fallback — a rede de processo É a entrada. As economias provenientes da remoção de vinte IEDs só são viáveis se a infraestrutura de unidades de fusão abaixo deles já existir.

Tenha cuidado ao esperar dois anos pelas respostas. As subestações sendo comissionadas agora viverão por 40 anos. A estrutura está sendo escrita para elas.

Fontes