Se tentássemos escolher o único tema que se destacou com mais clareza na área de exposição da CIGRE 2026 em Paris, para nós ele foi a virtualização da proteção.
E já não se trata de um único produto experimental nem de um belo conceito em slides. Ao longo de algumas horas percorrendo a feira, encontramos esse tema nos estandes de ABB, Siemens, Moxa, Welotec, Kalkitech e outros. Umas empresas oferecem diretamente funções de proteção virtualizadas, outras os servidores nos quais essas funções devem rodar, e outras ainda montam, a partir de componentes de diferentes fabricantes, arquiteturas multivendor praticamente prontas.
E quanto mais conversávamos com os representantes das empresas, mais evidente ficava: a questão-chave aqui já não é «é possível rodar a proteção numa máquina virtual?». Claro que é. Bem mais interessante é outra pergunta: quem agora define a arquitetura de hardware e responde pela confiabilidade de toda essa plataforma de computação?
ABB: a proteção se separa de vez do «ferro»
Uma das primeiras paradas foi o estande da ABB.
A proteção centralizada não é novidade para a ABB. Há vários anos o portfólio da empresa inclui o SSC600 — um dispositivo no qual as funções de proteção e controle, tradicionalmente distribuídas pelos terminais de cada bay, são centralizadas no nível da subestação.
O passo seguinte foi o SSC600 SW. Nesse caso, da plataforma de hardware dedicada da ABB resta apenas a implementação de software. A ABB descreve oficialmente o SSC600 SW como um produto puramente de software, entregue como máquina virtual e destinado a rodar em ambientes KVM e VMware; o cliente pode usar a plataforma de hardware que escolher.
Justamente a conversa com os representantes da ABB revelou-se especialmente interessante.
A lógica de fornecimento é mais ou menos assim: a imagem de software para implantação numa máquina virtual pode ser obtida à parte, e a funcionalidade necessária é então ativada por licença. Segundo os representantes da empresa no estande, prepara-se também uma versão para uso na plataforma aberta SEAPATH.
Mas o mais importante não foi nem isso.
A ABB se abstrai quase por completo de como exatamente o cliente construirá a infraestrutura de computação. A empresa está disposta a formular os requisitos de desempenho do servidor conforme o número e a composição das funções implementadas, porém a escolha da arquitetura de hardware específica fica a cargo do integrador de sistemas e do cliente.
Além disso, perguntamos à parte se há restrições de princípio para colocar outras aplicações no mesmo servidor físico. A resposta foi negativa. Em máquinas virtuais vizinhas podem rodar, por exemplo, SCADA, um controlador de comunicação e até funções de proteção virtualizadas de outros fabricantes.
E é aqui que aparece o outro lado da independência de hardware.
À pergunta de como exatamente deve ser construída uma arquitetura de servidor tolerante a falhas, não obtivemos uma resposta inequívoca. A redundância dos nós de computação, a arquitetura de disponibilidade contínua/alta, o comportamento na falha de um servidor físico — tudo isso já não está dentro do produto da ABB, mas passa a ser objeto do projeto do sistema como um todo.
Trata-se de uma mudança bastante fundamental na fronteira de responsabilidade.
Num terminal de proteção tradicional, o desenvolvedor do dispositivo controla o processador, o sistema operacional, as interfaces de hardware e boa parte dos mecanismos de garantia da confiabilidade. No mundo virtualizado, o fabricante fornece as funções de proteção como software mais os requisitos do ambiente de execução. E a tolerância a falhas de toda a plataforma passa a ser projetada pelo integrador, conforme os requisitos do cliente final. Na verdade, o cliente aqui já pode definir uma plataforma de hardware padrão — e não só de hardware, mas também de software, no que se refere ao ambiente de implantação das máquinas virtuais, ao seu número e assim por diante.
Outro exponente interessante da ABB complementava bem esse quadro — o compacto REX600, que recebe sinais de transdutores de medição de baixa potência e desempenha funções de conversor de sinais analógicos. O dispositivo também pode desempenhar funções locais de proteção de retaguarda. A ABB o posiciona como um elemento integrável ao SSC600 e ao SSC600 SW; ele suporta, entre outros, IEC 61869-9 e IEC 61869-13.
O resultado é uma arquitetura bastante característica: junto ao equipamento primário permanece uma interface de processo relativamente simples, enquanto as principais funções de computação migram para uma plataforma centralizada.
Moxa: se a proteção virou software, onde ela vai rodar?
Dos representantes da ABB recebemos os nomes de dois fabricantes de plataformas de hardware já usadas ou consideradas pelos clientes para tais tarefas: Moxa e Welotec.
Por isso, a parada seguinte foi, muito naturalmente, o estande da Moxa.
E praticamente no centro da exposição estava de fato o DA-920E — um novo servidor sem refrigeração ativa (do tipo sem ventoinhas), posicionado pela empresa especificamente como plataforma para Virtual Protection, Automation and Control — vPAC.
Isto já não é um computador industrial comum. O DA-920E vem em formato 2U e atende aos requisitos da IEC 61850-3, IEEE 1613 e IEC 60255. No núcleo, um Intel Xeon D-1834 com 8 núcleos e 16 threads; suporta até 256 GB de ECC RAM, quatro SSDs de 2,5 polegadas com RAID e um drive NVMe separado, além de expansão PCIe. A Moxa associa diretamente esse produto à transição para a proteção virtualizada.
Aqui se sente especialmente bem a formação de um novo mercado.
O fabricante de proteção já não precisa necessariamente desenvolver o próprio bloco de computação dedicado. Surgem plataformas de hardware independentes, projetadas justamente para a operação diretamente em instalações de energia.
Ou seja, o movimento não vai do equipamento dedicado direto para um servidor comum de data center. Antes, forma-se uma classe intermediária de dispositivos: arquitetura x86 padrão, mas num formato projetado para o ambiente eletromagnético e as condições de operação de uma subestação.
Contudo, o exponente mais inusitado da Moxa para nós não foi o servidor.
No estande mostravam um protótipo de receptor GNSS/GPS no formato SFP. Uma antena externa se conecta ao pequeno módulo, que é então instalado diretamente no slot SFP de um comutador compatível. A ideia é que tal módulo permite ao próprio comutador atuar como fonte de tempo preciso e PTP Grandmaster, sem um servidor de tempo separado.
Para pequenas subestações a ideia parece extremamente atraente: o dispositivo de sincronização separado literalmente «colapsa» num módulo SFP.
Mas por enquanto é justamente um protótipo. E se ele virar um produto real, a questão principal já não será o seu impressionante formato, mas a maturidade da implementação. Quão flexivelmente serão configurados os perfis PTP? Como o dispositivo se comportará na perda de GNSS? Como ocorrerá o restabelecimento da sincronização? Quão estável será a operação em diversos regimes transitórios?
É o caso em que uma ideia de engenharia muito bonita ainda precisa provar sua aptidão para a operação real.
Welotec: toda a arquitetura em um único armário
No estande da Welotec vimos não um elemento isolado, mas uma demonstração praticamente montada de como pode ser uma proteção virtual multivendor.
Na base estava o RSAPC Mk2 — Rugged Substation Automation Computer. Também é um servidor 2U de execução para subestação, sem ventoinhas, com IEC 61850-3 e IEEE 1613. Na configuração máxima usa-se um Intel Xeon W com 8 núcleos e 16 threads; a faixa de temperatura declarada é de −40 a +70 °C. A Welotec oferece para essa plataforma diversos ambientes operacionais, incluindo VMware ESXi, Red Hat Enterprise Linux Real Time e, o que é especialmente interessante, uma pré-instalação do LF Energy SEAPATH.
Mas bem mais importante que as características do servidor era a própria arquitetura de demonstração.
Numa única infraestrutura foram reunidos componentes de vários fabricantes. Como plataforma de virtualização atuava o SEAPATH, como proteção virtualizada demonstrava-se uma solução da ABB, e ao lado rodava a SCADA/HMI zenon da COPA-DATA. A infraestrutura de rede era representada pela Westermo, e a sincronização de tempo — inclusive por equipamento Hopf.
Na prática, a inscrição «Multi Vendor vPAC Demo Setup» no estande da Welotec revelou-se uma das imagens mais expressivas de toda a feira.
Ela mostra a mudança principal: a automação de subestações potencialmente deixa de ser um conjunto de dispositivos acabados de fabricantes individuais e se torna um sistema de computação integrável.
O servidor pode ser fabricado por uma empresa. O hipervisor ou a plataforma de virtualização — por outro ecossistema. Os dispositivos de proteção virtualizados — por um terceiro. A SCADA — por um quarto.
A liberdade aumenta consideravelmente.
Mas, ao mesmo tempo, fica bem mais difícil responder à pergunta: quem responde pelo resultado como um todo?
A presença de duas fontes de alimentação, RAID, PRP/HSR ou interfaces de rede redundantes não significa, por si só, a tolerância a falhas de um sistema de proteção virtualizado. É preciso definir os possíveis domínios de falha, a estratégia de redundância dos nós de computação, o tempo admissível de restabelecimento das funções, o comportamento das máquinas virtuais em falhas e os requisitos de atualização do software de infraestrutura.
Em outras palavras, a virtualização transfere boa parte da complexidade de engenharia do IED individual para o nível da arquitetura do sistema.
Kalkitech: o próximo passo — a subestação definida por software
No estande da Kalkitech deparamos de novo com o mesmo tema, mas aqui ele foi formulado de forma ainda mais ampla — Software Defined Substation (subestação definida por software).
Na arquitetura de demonstração usava-se a plataforma de servidor SYNC, um bare-metal hypervisor e várias máquinas virtuais. No diagrama, lado a lado, estavam funções de proteção virtuais, incluindo o próprio Kalkitech VPR e o SSC600 SW da ABB, e acima — outras aplicações de automação.
A Kalkitech desenvolve há bastante tempo o conceito de Virtual Protection Relay e oferece o seu próprio IEC 61850 VPR Framework. Ele inclui assinatura de Sampled Values, MMS, GOOSE, configuração SCL, reference protection functions e interfaces para conectar algoritmos de terceiros.
E se no estande da ABB falávamos antes de tudo da virtualização da proteção, a Kalkitech coloca uma questão mais ampla: se a proteção já pode ser aplicação, por que SCADA, gateway, HMI, monitoramento e outras funções devem obrigatoriamente permanecer dispositivos físicos separados?
Depois de quatro estandes diferentes — ABB, Moxa, Welotec e Kalkitech — a coincidência já é difícil de considerar casual. Em torno da proteção virtualizada começa a se formar um ecossistema tecnológico pleno.
Siemens: virtualização — sim, mas sob o controle do fabricante
Nesse contexto, a abordagem da Siemens parece especialmente interessante.
A empresa também demonstra proteção virtualizada — o SIPROTEC V, que usa os algoritmos comprovados do SIPROTEC 5. A Siemens declara escalabilidade de até 60 IEDs virtuais numa única plataforma de computação.
Contudo, o modelo comercial difere sensivelmente da abordagem da ABB.
A Siemens também usa o termo «hardware independent», mas a independência de hardware aqui está limitada a uma lista de plataformas de servidor de execução para subestação aprovadas, ou whitelisted. Além disso, a Siemens fala diretamente de uma «packaged approach»: ao cliente pretende-se fornecer um hardware/software bundle, no qual o SIPROTEC V e o sistema operacional já vêm pré-instalados em equipamento validado.
E esta é, talvez, uma das conclusões mais interessantes da visita à feira: mesmo dentro de uma única tendência, os fabricantes escolhem modelos diferentes.
A abordagem da ABB pode ser descrita, grosso modo, como «proteção como software». O fabricante dá um produto de software e os requisitos de recursos de computação, enquanto boa parte da arquitetura do sistema fica a cargo do integrador.
A abordagem da Siemens está mais perto de «virtualised protection as a validated system». O software de proteção já está separado do IED tradicional, mas o fabricante continua a controlar a combinação das plataformas de software e hardware.
Qual das duas ficará mais perto da futura arquitetura massiva das subestações digitais — ainda está longe de ser óbvio.
Arteche: uma tecnologia que nunca se tornou massiva
No contexto da história muito dinâmica da virtualização, o estande da Arteche parecia inesperadamente contrastante.
Ali apresentava-se um transformador de corrente óptico, o SDO-OCT — uma solução baseada no efeito Faraday. O transdutor de medição é totalmente passivo, e a eletrônica ativa foi deslocada para um bloco eletrônico capaz de formar Sampled Values conforme a IEC 61869-9.
O princípio em si está longe de ser novo. Dispositivos semelhantes eram demonstrados em feiras do setor muitos anos atrás. Por isso, ficamos especialmente interessados em perguntar aos representantes da Arteche: quanto o mercado avançou nesse tempo?
A resposta foi antes desanimadora.
Segundo os representantes da empresa, a escala de implantação dos transformadores de corrente ópticos ainda permanece extremamente pequena. Mais ainda: vários fabricantes que trabalharam com essa tecnologia, na avaliação deles, encerraram de vez as respectivas linhas.
E, visualmente, a feira não contradizia essa impressão: durante a nossa volta, o TC óptico da Arteche foi praticamente o único exponente desse tipo a atrair a nossa atenção.
Formou-se um contraste interessante.
Os sistemas secundários caminham com relativa rapidez rumo a uma arquitetura definida por software, à virtualização e a plataformas de computação independentes. Já a revolução nos transdutores de medição primários, prometida ao setor muitos anos atrás, avança por ora bem mais devagar.
Atratividade tecnológica e adoção em massa, como se sabe, estão longe de ser sempre a mesma coisa.
Hopf: 30 quilômetros entre a antena e o relógio
Outra descoberta inesperada para nós foi a empresa Hopf. Reparamos nela pela primeira vez na demonstração multivendor da Welotec, onde o seu equipamento era usado no sistema de sincronização de tempo, e então decidimos visitar o seu próprio estande.
A Hopf é especializada em sistemas de tempo único. No estande apresentavam-se diversos servidores de tempo, inclusive versões de alta estabilidade com osciladores de rubídio.
Mas o que mais atraiu a nossa atenção foi um pequeno componente do sistema de antena.
Trata-se de um conversor que permite transmitir o sinal entre uma antena GNSS e um servidor de tempo por fibra óptica. No estande declarava-se um alcance de até 30 km.
À primeira vista é um dispositivo bastante de nicho. Mas do ponto de vista de uma instalação real a ideia é muito interessante.
No caso comum, o comprimento do trajeto coaxial da antena GNSS é limitado pela atenuação. Mesmo na documentação da própria Hopf para os seus sistemas de antena, um cabo padrão fica limitado a dezenas de metros e, com certos tipos de cabo e amplificadores, fala-se já em centenas — mas não dezenas de milhares — de metros (embora esses cabos já não sejam tão flexíveis).
A migração para a fibra muda a situação de forma fundamental.
A antena pode ser afastada a uma distância significativa da instalação protegida — por exemplo, para onde a visão do céu de satélites é melhor ou é mais fácil atender aos requisitos de instalação. Ao mesmo tempo, desaparece o longo trajeto condutor entre a antena externa e o equipamento dentro do edifício, o que é interessante também do ponto de vista da isolação galvânica e da proteção contra descargas atmosféricas.
É um bom exemplo de que as coisas realmente interessantes numa grande feira estão longe de ocupar sempre o lugar central do estande.
O que a feira mostrou, afinal
Depois de percorrer esses estandes, a nossa principal conclusão não é que «surgiu a proteção virtualizada». Essa ideia já existe há vários anos.
Mudou outra coisa: em torno dela começa a surgir um mercado.
Há funções como aplicações na ABB e na Siemens. Há plataformas de computação dedicadas da Moxa e da Welotec. Há o ambiente aberto SEAPATH. Há empresas como a Kalkitech, que já veem a virtualização como base de uma Software Defined Substation mais ampla. Surgem demonstrações multivendor em que produtos de diferentes fabricantes realmente funcionam dentro de uma única arquitetura.
Isso significa que a próxima etapa de desenvolvimento estará ligada já não tanto à prova da viabilidade em princípio da proteção virtual, quanto à engenharia de sistemas.
Como tornar redundantes as plataformas de computação? Como definir os domínios de falha admissíveis? É possível colocar SCADA e proteção nos mesmos servidores físicos? Quem responde pela atualização do hipervisor? Como validar o sistema após uma mudança de infraestrutura? Onde passa a fronteira de responsabilidade entre o fornecedor das funções de proteção e o integrador de sistemas?
Numa subestação digital clássica, um dos objetos-chave do projeto era a rede IEC 61850.
Parece que a subestação definida por software ganha mais um objeto desse tipo — a própria infraestrutura de computação.
E talvez seja justamente aqui que esteja a principal mudança que se pode ver hoje na CIGRE.
A proteção deixa gradualmente de ser apenas um dispositivo.
Ela se torna uma função de software.
E, com isso, ao cliente final, ao projetista e ao integrador de sistemas caberá aprender a projetar não só a proteção, a rede e o sistema de sincronização, mas também a plataforma na qual essa proteção vive.