No tutorial do comitê de estudos B5 do CIGRE, três renomados especialistas internacionais em proteção e subestações digitais mostraram o próximo degrau da evolução do setor. As funções de proteção estão gradualmente se separando dos terminais dedicados e migrando para plataformas de computação em servidor. Mas a discussão mais interessante hoje já não é se isso é tecnicamente possível, e sim como projetar, testar e operar tais complexos — e quem, em última instância, responde pelo seu funcionamento.
Na sala do Palais des Congrès de Paris, à mesa da presidência estão Alex Apostolov, editor-chefe da revista PAC World e especialista da OMICRON electronics; Ratan Das, especialista da Siemens Energy e coordenador do grupo de trabalho da IEEE que elaborou o guia IEEE C37.300 sobre proteção e controle centralizados; e David MacDonald, arquiteto de soluções e padronização da GE Grid Automation e coordenador do grupo de trabalho CIGRE B5.84 sobre dispositivos de proteção virtualizados.
O tutorial do comitê de estudos B5 foi dedicado ao desenvolvimento das arquiteturas dos sistemas de proteção, automação e controle, com atenção especial ao barramento de processo e à virtualização dos dispositivos de proteção.
As três palestras alinharam-se praticamente numa única sequência histórica.
Primeiro, a ligação dos dispositivos de proteção com o equipamento primário se torna digital graças ao barramento de processo. Depois, as funções de proteção se separam dos numerosos terminais físicos e são centralizadas. Por fim, o passo seguinte — a virtualização: a função de proteção se torna uma aplicação de software, e o servidor, uma plataforma de computação que depois pode ser trocada sem mudar o próprio algoritmo de proteção.
Em pouco mais de vinte anos, o setor percorreu o caminho das primeiras demonstrações de transmissão de valores instantâneos digitalizados por IEC 61850 até complexos de proteção virtualizados funcionando em plataformas de servidor.
E o caráter das perguntas mudou junto com a tecnologia.
Hoje a pergunta principal já não é «vai funcionar?», mas: como possuir isso, como testá-lo e mantê-lo — e quem responde pelo complexo se os seus componentes forem fornecidos por diferentes fabricantes?
Vinte anos da demonstração ao uso industrial
A primeira palestra de Alex Apostolov foi dedicada ao barramento de processo.
Na sua base está a brochura técnica do CIGRE TB 949, «Process Bus in Protection, Automation & Control Systems», que resume a experiência acumulada pelo setor na aplicação do barramento de processo: soluções de arquitetura, redundância, projetos reais, os resultados de pesquisas com concessionárias e fabricantes, aspectos econômicos e direções futuras de desenvolvimento.
A história revelou-se mais longa do que às vezes se imagina.
O trabalho que mais tarde levou à IEC 61850 começou ainda nos anos 1990. Em 2004, o perfil 9-2LE tornou-se um marco prático importante no desenvolvimento da transmissão de valores instantâneos digitalizados e na interoperabilidade de equipamentos de diferentes fabricantes. Apostolov lembrou como, na sessão do CIGRE daquele mesmo ano, ABB, Siemens e Omicron já demonstravam dispositivos trabalhando em conjunto com fluxos SV.
Contudo, entre a demonstração da tecnologia e o seu amplo uso industrial passou-se cerca de uma década.
O setor observava de perto a nova arquitetura, acumulava experiência, lançava projetos-piloto. A partir de meados da década de 2010, o número de implantações começou a crescer rapidamente.
«Estamos num ponto de inflexão: praticamente todas as grandes concessionárias do mundo traçaram um rumo para a digitalização».
Por trás dessa conclusão há um material bastante amplo: mais de 200 publicações analisadas, cerca de 60 projetos examinados e os resultados de uma pesquisa do setor.
A maioria dos projetos estudados refere-se não à construção de novas instalações, mas à reforma de subestações existentes. Isso é importante: o barramento de processo deixa gradualmente de ser uma tecnologia apenas para novas instalações digitais «ideais» e entra na prática da modernização de subestações existentes.
Um pequeno glossário
Para a conversa a seguir, é útil definir alguns termos fixados na terminologia internacional.
- MU / SAMU — dispositivos que convertem os sinais analógicos de corrente e tensão em fluxos digitais de valores instantâneos SV.
- SCU — unidade de interface com o equipamento de manobra, que fornece E/S binária.
- PIU — unidade de interface com o processo, que combina as funções de conversão de sinais analógicos e binários.
Como observou Apostolov, a terminologia aqui ainda é usada de forma não totalmente consistente.
- PRP e HSR — mecanismos de redundância de rede com recuperação sem perdas da transmissão de dados.
- PTP — o protocolo de sincronização de tempo de alta precisão IEEE 1588, que permite transmitir a escala de tempo diretamente pela rede Ethernet e, em muitas arquiteturas, dispensar linhas separadas de sincronização por pulsos.
O que impulsiona o barramento de processo — e o que o freia
As razões para a adoção podem ser divididas em econômicas e tecnológicas.
A economia — menos cabos de cobre e trabalho de montagem, painéis e salas mais compactos, redução do volume de trabalho na reforma e uma potencial diminuição dos custos de manutenção e modernização.
As vantagens tecnológicas — maior segurança do pessoal, flexibilidade de arquitetura, escalabilidade, mais amplas possibilidades de monitoramento do estado do equipamento e uma base para a futura integração funcional.
Mas as barreiras também são bem concretas.
Falta às concessionárias experiência própria de trabalho com a tecnologia. As dificuldades de operação conjunta de equipamentos de diferentes fabricantes são especialmente perceptíveis na fase de projeto e configuração. A cibersegurança impõe exigências adicionais à arquitetura. São necessários novos métodos de diagnóstico e ensaios.
E, talvez, uma das questões mais importantes sejam as ferramentas.
O próprio padrão IEC 61850 permite construir muitas arquiteturas diferentes, porém a complexidade da configuração ainda é transferida com demasiada frequência diretamente para o engenheiro. Apostolov ressaltou à parte a necessidade de ferramentas que devem ocultar a complexidade tecnológica da IEC 61850 do usuário, em vez de obrigá-lo a trabalhar com ela manualmente o tempo todo.
«O mercado precisa de ferramentas que ocultem a complexidade tecnológica da IEC 61850 do usuário, em vez de obrigá-lo a trabalhar com ela manualmente o tempo todo».
Uma questão à parte é a economia.
Muitas vezes a subestação digital é avaliada comparando o custo de componentes individuais de uma solução tradicional e de uma digital. Mas o benefício real só se manifesta ao avaliar o custo total de propriedade: projeto, cabeamento, construção, comissionamento, manutenção, reforma e posterior substituição do equipamento.
E é justamente o ciclo de vida que se torna especialmente interessante na etapa seguinte de desenvolvimento.
De dez mil conexões à proteção centralizada
Ratan Das começou a sua palestra com uma história pessoal.
Em 1981, recém-chegado a uma concessionária, recebeu a tarefa de preparar o diagrama de conexões entre dispositivos numa instalação com três unidades geradoras de 500 MW cada.
Cerca de 10 000 conexões.
O projetista elaborava os diagramas, depois eles eram verificados, e então tudo isso tinha de ser fisicamente montado e verificado na instalação.
As gerações seguintes de proteção reduziram gradualmente essa complexidade.
Os relés eletromecânicos deram lugar aos estáticos, depois surgiram os terminais microprocessados. A IEC 61850 permitiu substituir boa parte das ligações por fios por troca digital.
A próxima pergunta lógica surgiu há cerca de uma década: se as medições analógicas e os sinais binários já estão disponíveis pelo barramento de processo, é obrigatório cada bay ter o seu próprio terminal de computação?
Assim surgiu o conceito de proteção e controle centralizados — CPC (Centralized Protection and Control).
As unidades de interface permanecem junto ao equipamento primário. Elas recebem medições, estados e comandos. E os algoritmos de proteção e controle são transferidos para uma plataforma de computação centralizada de nível de estação.
Nas palavras de Das, isso pode ser visto como a próxima geração no desenvolvimento dos complexos de proteção.
«Quando, em 2013, escrevemos um artigo sobre um complexo de proteção em servidor, muitos olhavam para ele como uma fantasia disparatada. Hoje, nos estandes desta sessão, a proteção funciona justamente em servidores».
Mas a centralização resolve apenas parte da tarefa.
As funções já estão reunidas numa plataforma de computação comum, porém o software ainda pode permanecer fortemente ligado à plataforma de hardware específica do fabricante.
O passo seguinte é separar uma coisa da outra.
As funções à parte, a plataforma de hardware à parte
É justamente nisso que consiste a ideia de independência da funcionalidade em relação à plataforma de hardware — FIH (Functionality Independent of Hardware).
O princípio básico é simples: a troca da plataforma de computação não deve exigir uma reformulação substancial das funções aplicadas de proteção.
Claro, independência absoluta não existe. Para uma nova plataforma podem ser necessários drivers, verificação de compatibilidade, ajuste do ambiente de execução.
Mas o próprio algoritmo de proteção não deve ter de ser criado de novo cada vez apenas porque o fabricante do processador descontinuou uma geração antiga ou o hardware do servidor mudou.
É nisso que consiste a mudança fundamental do ciclo de vida.
Hoje o terminal de proteção é, na prática, um produto único: os algoritmos de proteção, o processador, o sistema operacional, as interfaces de rede, a fonte de alimentação e o gabinete são fornecidos em conjunto.
Quando a parte de hardware fica obsoleta, muitas vezes é preciso trocar o terminal inteiro.
Num complexo virtualizado, a função aplicada e a plataforma de computação começam a viver ciclos de vida distintos.
Para o setor de energia isso é especialmente importante. O equipamento primário é operado por décadas, ao passo que as plataformas de computação evoluem muito mais rápido.
Como resultado, ao longo da vida útil do equipamento primário podem se suceder várias gerações de meios de computação de proteção.
Com a nova arquitetura, trocar a cada vez a própria função de proteção já não é obrigatório.
Os ensaios podem aumentar, e o trabalho na instalação, diminuir
À primeira vista parece que a virtualização deveria reduzir o volume de ensaios.
Das fez uma ressalva importante: é mais correto colocar de forma bem diferente.
Pode-se fazer até mais ensaios — mas transferir boa parte deles da instalação para o laboratório.
Uma aplicação de software pode ser exaustivamente verificada independentemente de uma instalação específica.
Se depois muda apenas a plataforma de computação, enquanto o código da própria função de proteção permanece o mesmo, o volume completo de ensaios funcionais da aplicação já não precisa necessariamente ser repetido diretamente na subestação.
O grosso da verificação de uma nova plataforma pode ser feito de antemão.
Isso potencialmente muda de forma séria o próprio processo de substituição de equipamento.
Hoje, a troca de um terminal muitas vezes significa um projeto, aprovações, retirada de operação, montagem, configuração e um volume completo de verificações.
Num complexo de proteção definido por software, a troca da plataforma de hardware pode, no futuro, tornar-se uma operação bem mais rotineira.
Mas, junto com isso, surge uma questão organizacional fundamental: quem dá a garantia de todo o complexo e como se distribui a responsabilidade entre os participantes?
A discussão voltou a ela depois das palestras.
O que exatamente a virtualização oferece
A terceira palestra — de David MacDonald, coordenador do grupo de trabalho CIGRE B5.84 sobre dispositivos de proteção virtualizados — foi dedicada diretamente à virtualização.
A principal diferença de um complexo virtualizado em relação a um centralizado comum não está apenas no uso de um servidor.
Entre as funções aplicadas e a plataforma de hardware surge uma camada de virtualização, que permite separar as aplicações de software do hardware de servidor específico e isolá-las umas das outras.
Para as máquinas virtuais, o elemento básico dessa camada é o hipervisor — um recurso de software que permite executar simultaneamente várias máquinas virtuais isoladas num único servidor físico.
As funções aplicadas de proteção podem ser executadas em máquinas virtuais separadas. Outra abordagem é a conteinerização, quando várias aplicações usam um sistema operacional comum, mas se isolam umas das outras por meios de software. Também é possível uma variante combinada — por exemplo, alocar aplicações conteinerizadas dentro de uma máquina virtual.
Para complexos em que se prevê o uso de aplicações de diferentes fabricantes, as máquinas virtuais são especialmente interessantes graças à separação mais rígida dos ambientes de software.
Uma função de proteção virtual isolada pode ser implantada, ensaiada ou atualizada independentemente de outras funções que rodam no mesmo servidor.
É justamente essa possibilidade que cria as premissas para complexos em que aplicações de diferentes fabricantes possam funcionar numa plataforma de computação comum.
Num complexo centralizado tradicional há bem menos liberdade: as funções estão reunidas, mas toda a solução permanece um complexo único de software e hardware de um só fornecedor.
A plataforma de hardware não desaparece
Aqui é importante não cair numa armadilha terminológica.
A independência da plataforma de hardware não significa que qualquer servidor sirva para a proteção.
As exigências para a plataforma de computação permanecem extremamente sérias.
É preciso considerar o desempenho do processador e da memória, as interfaces de rede, a redundância de alimentação e de discos, as condições de operação, a compatibilidade eletromagnética, os meios de gestão remota, o esquema de redundância e as exigências de confiabilidade.
Além disso, para cada dispositivo virtual é preciso definir os recursos de computação necessários e as características da rede virtual.
Ou seja, a virtualização não elimina o projeto de engenharia da parte de hardware.
Ela muda outra coisa: a plataforma de hardware deixa de determinar a própria funcionalidade aplicada da proteção.
É uma distinção importante.
Dois modelos de redundância
Para um complexo de proteção em servidor podem ser usadas diferentes abordagens de redundância.
A mais óbvia — dois servidores independentes nos quais rodam simultaneamente instâncias idênticas das proteções. Cada um é capaz de emitir o seu próprio comando de abertura.
Uma variante mais complexa — um cluster de vários servidores.
Nesse caso, um grupo de nós é gerido como um único sistema de computação. Na falha de um servidor, as suas aplicações podem ser reiniciadas automaticamente em outro nó.
Para tomar decisões sobre o estado dos participantes do cluster, usa-se um número ímpar de nós — por exemplo, três ou cinco. Isso permite determinar a maioria e excluir o nó com falha.
Também é possível migrar uma máquina virtual de um servidor físico para outro.
E aqui surge uma das características fundamentais da nova arquitetura: o que passa a ser redundado não é necessariamente o próprio dispositivo físico, mas a capacidade de executar a função.
Para um complexo de proteção tradicional, esses dois conceitos praticamente coincidiam.
Para um virtualizado — já não.
Microssegundos: onde a virtualização encontra o tempo real
Contudo, um complexo de proteção em servidor impõe à infraestrutura de computação exigências muito diferentes das dos sistemas de informação comuns.
Não basta garantir um tempo médio curto de execução da função.
A proteção requer um tempo de reação previsível e uma dispersão limitada dos atrasos mesmo em condições desfavoráveis.
Os sistemas operacionais comuns são, antes de tudo, otimizados para o uso eficiente dos recursos, e não para um determinismo temporal rígido.
A própria virtualização também pode introduzir atrasos adicionais: um pacote de rede passa por várias camadas de software antes de chegar à aplicação de proteção.
Para encurtar esse caminho e reduzir os atrasos, usam-se mecanismos especiais de acesso direto e acelerado às interfaces de rede — em particular, PCI passthrough, SR-IOV e DPDK.
Uma análise detalhada dessas tecnologias é tema de um material à parte. O que importa aqui é outra coisa: num complexo de proteção virtualizado, o caminho de rede e a forma de entrega dos dados à aplicação tornam-se parte do projeto de engenharia tanto quanto a escolha do processador, a alocação dos recursos de computação ou o ajuste do funcionamento em tempo real.
Mas a principal conclusão de MacDonald não foi sobre a escolha de uma tecnologia específica.
O determinismo não se pode simplesmente declarar. É preciso medi-lo e confirmá-lo por ensaios.
Como é construída a plataforma aberta SEAPATH
Como exemplo ilustrativo de arquitetura, MacDonald examinou a plataforma aberta LF Energy SEAPATH.
Aqui os dispositivos virtuais de proteção situam-se sobre um conjunto de ferramentas padrão de virtualização e de gestão da infraestrutura de computação.
Usam-se Linux com kernel para operação em tempo real, KVM, QEMU e libvirt. Para a rede virtual aplicam-se as ferramentas de software correspondentes, e para construir uma infraestrutura tolerante a falhas — mecanismos de clusterização.
A alocação dos recursos de computação desempenha um papel importante.
Os núcleos do processador podem ser fixados a determinadas tarefas. Leva-se em conta a arquitetura NUMA — a organização do acesso dos processadores à memória principal em plataformas de servidor multiprocessadas. Gerenciam-se as prioridades das threads e o tratamento de interrupções.
Ou seja, o servidor deixa de ser simplesmente «um computador no qual se lançou a proteção».
Ele se torna um ambiente de computação especialmente ajustado para executar funções críticas em tempo real.
Ensaiar uma proteção sem parar as demais
A virtualização oferece possibilidades muito interessantes em conjunto com os mecanismos padrão IEC 61850 Test e Simulation.
Imaginemos que num único servidor rodam os dispositivos virtuais de vários bays.
Um deles precisa ser ensaiado.
Ele pode ser posto em modo de ensaio e receber fluxos SV e GOOSE simulados de um conjunto de ensaio.
Enquanto isso, os dispositivos virtuais vizinhos continuam a trabalhar com os dados reais da instalação.
As mensagens GOOSE de teste são marcadas de forma correspondente, de modo que os dispositivos de atuação que permanecem em modo normal não devem executar os comandos nelas contidos.
Assim, surge a possibilidade de localizar o ensaio de uma função isolada dentro de um complexo em funcionamento.
Para uma arquitetura centralizada tradicional, tal independência de componentes de software isolados é alcançada com muito mais dificuldade.
O determinismo precisa ser provado sob carga
O grupo de trabalho considera também ensaios especiais da plataforma de computação.
Mede-se quanto o tempo real de execução das tarefas difere do esperado.
Tais ensaios são realizados repetidas vezes e sob uma carga criada artificialmente sobre o processador, a memória e o subsistema de rede.
O mais elucidativo é o ensaio de ponta a ponta.
O conjunto de ensaio gera um estímulo, a proteção virtual o processa e retorna um comando GOOSE de abertura.
Mede-se o caminho completo do sinal — do estímulo ao comando de resposta.
E a plataforma de computação é deliberadamente colocada em condições desfavoráveis de disputa por recursos.
É justamente aqui que se torna visível a diferença fundamental entre uma aplicação de servidor comum e uma função de proteção.
Para a proteção, o que importa não é o melhor resultado e nem sequer o médio.
O que importa é a característica garantida nas piores condições previstas.
Cibersegurança: não há benefícios sem novos riscos
A centralização e a virtualização criam ao mesmo tempo novos meios de proteção e novas ameaças.
Por um lado, o isolamento das máquinas virtuais permite limitar a propagação de falhas e as consequências do comprometimento de aplicações isoladas.
Podem-se aplicar boot confiável, verificação de integridade e assinatura das imagens de software, segregação de privilégios, autenticação multifator e criptografia.
Por outro lado, surgem novos componentes críticos: o próprio ambiente de virtualização, o sistema operacional do nó, os meios de gestão centralizada, a cadeia de fornecimento de software.
Além disso, as consequências de um ataque bem-sucedido a uma infraestrutura de servidor comum podem, potencialmente, ser muito maiores em escala do que o comprometimento de um terminal isolado.
Portanto, afirmar que um complexo virtualizado é «mais seguro» por si só seria simples demais.
É mais correto dizer que a virtualização muda o modelo de ameaças e o conjunto de meios de proteção.
Perguntas da plateia: da confiabilidade à responsabilidade
A parte mais interessante do tutorial começou depois da abertura dos microfones.
As perguntas da plateia mostraram bem o quanto mudou o caráter da discussão profissional.
O debate já não era sobre a possibilidade da virtualização em si, mas sobre os seus limites práticos.
«Não estaremos criando um novo ponto único de falha?»
A primeira pergunta natural dizia respeito à confiabilidade.
Numa subestação digital tradicional, dezenas de dispositivos físicos estão distribuídos pelos bays. A falha de um terminal específico costuma ficar localizada num conjunto limitado de funções.
Num complexo virtualizado, boa parte das funções pode depender de apenas alguns servidores.
Não surge um novo ponto único de falha?
A resposta dos palestrantes foi que a infraestrutura de computação pode ser redundada de forma bem mais profunda e econômica do que uma grande quantidade de dispositivos dedicados.
Uma função de proteção pode ter várias instâncias funcionando simultaneamente, alocadas em servidores diferentes. Na falha de um nó, é possível continuar o funcionamento em outro.
Mas os representantes das concessionárias, com razão, chamaram a atenção também para o outro lado.
A falha de um componente comum é, de fato, potencialmente capaz de afetar muitas funções de uma vez.
Por isso, não se pode simplesmente comparar «dois terminais» e «dois servidores».
É necessária uma análise de confiabilidade de toda a arquitetura: servidores, comutadores, placas de rede, fontes de alimentação, ambiente de virtualização, meios de gestão e as próprias aplicações.
A virtualização não elimina a engenharia de confiabilidade tradicional.
Ela apenas oferece outras formas de construir a redundância.
«E quem responde se o software e o servidor forem de fabricantes diferentes?»
Talvez a pergunta mais prática tenha vindo de um representante da Scottish and Southern Electricity Networks (SSEN, Reino Unido) — um operador de redes elétricas do Reino Unido.
Suponhamos que a proteção virtual foi desenvolvida pelo fabricante A.
A plataforma de servidor foi fornecida pelo fabricante B.
O ambiente de virtualização — pelo fabricante C.
A proteção atuou incorretamente.
Para quem o cliente deve ligar?
Essa é uma das tarefas-chave ainda não resolvidas da nova arquitetura.
Os palestrantes observaram que um certo análogo já existe hoje nas subestações digitais com equipamentos de diferentes fabricantes.
Dispositivos de diferentes empresas são unidos por uma rede IEC 61850 comum, mas a responsabilidade pelo complexo como um todo deve, ainda assim, ser atribuída a uma parte específica — o cliente ou um integrador de sistemas designado.
Para um complexo de proteção virtualizado, esse problema só se torna mais evidente.
Por conseguinte, o setor precisa não apenas de padrões técnicos de interfaces.
São necessárias regras de qualificação das plataformas de computação, de compatibilidade das aplicações, de diagnóstico, de ensaios e de distribuição contratual da responsabilidade.
Na prática, trata-se da formação de um novo modelo de operação dos complexos de proteção.
É melhor falar não em independência, mas em libertação de limitações
Uma formulação interessante foi proposta por um participante da discussão do Electricity Supply Board (ESB, Irlanda) — uma empresa de energia irlandesa.
Na opinião dele, a expressão «independência da plataforma de hardware» não descreve com precisão o problema.
Uma função de proteção tradicional não tanto «depende» da plataforma de hardware quanto é limitada por ela.
A vida útil dos algoritmos de proteção muitas vezes é determinada não pela sua obsolescência conceitual.
Falham fontes de alimentação, conversores de tensão, módulos de processador. O fabricante descontinua uma plataforma de hardware específica — e, junto com ela, é preciso trocar todo o dispositivo.
Mesmo que os próprios algoritmos satisfaçam plenamente a concessionária.
A virtualização potencialmente rompe esse vínculo.
A função permanece, e a plataforma de computação pode ser atualizada de forma independente.
Nesse sentido, trata-se, de fato, não da ausência total de dependência de hardware, mas da libertação da funcionalidade aplicada das limitações de uma geração específica de equipamento.
Onde termina a independência da plataforma de hardware
Um representante da Schweitzer Engineering Laboratories (SEL, EUA) — conhecido fabricante de dispositivos e soluções para proteção, automação e controle — levantou uma questão técnica ainda mais interessante.
As funções padrão de proteção podem ser virtualizadas e executadas numa plataforma de servidor padrão.
Mas existem métodos em que o algoritmo está fortemente ligado a equipamento de medição dedicado.
Por exemplo, as proteções por ondas viajantes requerem uma frequência de amostragem extremamente alta.
Em tais casos, transmitir um enorme fluxo de dados para um servidor central pode ser irracional.
Uma das opções é executar tal processamento diretamente na unidade de interface com o processo.
Mas aqui também nem tudo é tão simples.
Se a função usa dados de vários pontos remotos, um cálculo local num único dispositivo já não resolve a tarefa.
No fim, a discussão levou a uma conclusão mais importante do que a ideia de «transferir tudo para o servidor»: a virtualização não significa a centralização obrigatória de absolutamente todas as funções.
Diferentes algoritmos podem ser executados em diferentes níveis.
Funções que usam exclusivamente dados locais e requerem atraso mínimo podem permanecer junto ao processo.
Funções que usam informação de vários bays — ser executadas em nível de subestação.
Funções de sistema — num nível ainda mais alto.
Ou seja, o futuro pode não ser totalmente centralizado, mas antes um complexo de proteção definido por software hierarquicamente distribuído, em que o local de execução de cada função é escolhido conforme os seus requisitos.
E quanto à média tensão?
Uma questão à parte dizia respeito às redes de distribuição.
Nas classes de alta tensão, um terminal de proteção é um elemento comparativamente caro. Na média tensão, o custo dos dispositivos individuais é substancialmente menor.
O sentido econômico da virtualização se mantém ali?
Os palestrantes acham que sim.
Os modernos conjuntos de manobra recebem cada vez mais meios digitais integrados de medição e controle. No futuro, a unidade de interface com o processo pode tornar-se parte do próprio aparelho de manobra.
E as funções de proteção, nesse caso, são adicionadas por software.
O resultado é mais um nível de separação dos ciclos de vida: a aquisição do equipamento primário se separa da aquisição e do posterior desenvolvimento das funções de proteção e automação.
São justamente as subestações de distribuição em massa que, no futuro, podem se tornar uma das maiores áreas de aplicação dos complexos de proteção definidos por software.
No fim das contas
O mais elucidativo no tutorial não foi dito a partir dos slides.
Durante todo o bloco de discussão aberta, praticamente ninguém perguntou: «Para que serve, afinal, a proteção virtualizada?»
As perguntas foram outras.
Como garantir o determinismo exigido? Como redundar a infraestrutura de servidor? Como ensaiar uma função isolada sem afetar as demais? O que deixar diretamente junto ao processo e o que transferir para o servidor? Como muda a cibersegurança? E, por fim, quem responde pelo resultado se a aplicação, o ambiente de virtualização e a plataforma de hardware forem fornecidos por empresas diferentes?
Para uma tecnologia que, há apenas uns dez anos, muitos percebiam como um conceito bastante ousado, esse é, talvez, o melhor indicador de maturidade.
A proteção realmente começa a deixar o «ferro».
Mas o principal desafio da etapa seguinte já não é provar a possibilidade fundamental da virtualização.
O setor terá de aprender a projetar, qualificar, ensaiar e operar a proteção como um complexo definido por software.
E, a julgar pelo que os especialistas debateram no CIGRE 2026, essa transição já começou.