A maioria dos projetos de subestação digital são protótipos de conceito de um único fornecedor e de um único local. A RTE — operadora da rede de transmissão de 2.600 subestações da França — está realizando algo mais complexo: construir uma PACS totalmente digital e multi-fornecedor desde o início, atuando como integradora de sistemas própria e escalando-a em toda a rede. O projeto chama-se R#SPACE. A primeira subestação entrou em operação em Ploeren (63 kV, sul da Bretanha) no final de 2023; em início de 2026, várias outras localizações estão em comissionamento e a fase de ramp-up industrial já começou.

O que torna o R#SPACE incomum não é apenas a tecnologia. É o modelo operacional. A RTE compra IEDs de nível de barramento de um fornecedor, dispositivos de interface de processo de outro, executa a IHM em uma plataforma de virtualização de código aberto que desenvolveu em conjunto, e conecta a automação de nível de estação por meio de PLCs virtuais em contêineres Docker. Nenhum fornecedor único detém o sistema. A RTE detém.

Aqui está a arquitetura, o ecossistema de fornecedores, as realidades de teste e o cronograma de implantação — incluindo as lições difíceis que não aparecem em comunicados de imprensa dos fornecedores.

Por que a RTE construiu o R#SPACE

A geração anterior de PACS da RTE era baseada em modelo chave na mão: um fornecedor, um sistema, flexibilidade limitada após a comissionamento. Alterar uma função de nível de subestação — por exemplo, adicionar um novo esquema de regulação de tensão ou atualizar a gateway de telecontrole — significava voltar ao contratante original. Os custos eram altos e os prazos longos.

Três fatores levaram a RTE a repensar o modelo:

  • A rede francesa está absorvendo uma grande quantidade de geração renovável. Novas exigências de monitoramento (interfaces LPIT via IEC 61869-9, dados de sensores avançados) não podem esperar pelo próximo ciclo completo de atualização da PACS.

  • A manutenção remota tornou-se uma política em toda a empresa. A arquitetura antiga, com suas ferramentas específicas de fornecedor e métodos de acesso proprietários, tornava a administração remota centralizada quase impossível em uma frota mista.

  • A RTE já havia testado o conceito. O projeto demonstrador "Postes Intelligents" [9] — duas subestações totalmente digitais IEC 61850 com barramento de processo e barramento de estação — provou que a tecnologia funcionava, mas expôs lacunas de coordenação: problemas de alinhamento de fasores LPIT, tratamento de sincronização degradada e a complexidade da gestão de arquivos SCL multi-fornecedor. O R#SPACE foi projetado para corrigir o que o "Postes Intelligents" revelou.

A arquitetura de três blocos

O R#SPACE organiza a PACS em três blocos funcionais. A divisão é deliberada — separa o que pode ser virtualizado hoje do que ainda exige hardware dedicado.

flowchart TD
    subgraph SL["Nível de Subestação (Virtualizado)"]
        HMI["HMI / SCADA"]
        GW["Gateway de Telecontrole e\nSupervisão"]
        AUTO["Autômatos de Nível de Subestação"]
        CYBER["Servidores de Segurança Cibernética"]
        STORE["Armazenamento e\nConfiguração"]
    end

    subgraph NET["Nível de Rede"]
        direction LR
        PROC["Rede de Processo\n(Duplicada, PRP)\n+ Sincronização PTP"]
        ADMN["LAN de Administração\nDedicada"]
        PROC ~~~ ADMN
    end

    subgraph BAY["Banco e Nível de Processo"]
        direction LR
        BCU["Unidades de Controle de Banco\n(Proteção + Automação)"]
        SCU["Unidades de Controle de Equipamento de Comutação"]
        PIU["Unidades de Interface de Processo"]
        SAMU["Unidades de Merging Autônomas"]
        BCU ~~~ SCU
        PIU ~~~ SAMU
    end

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

Bloco 1 — Nível de subestação. Este opera na SEAPATH, a plataforma de virtualização de código aberto desenvolvida em conjunto pelo RTE sob a LF Energy. A SEAPATH utiliza o KVM como hipervisor, Corosync/Pacemaker para alta disponibilidade e libvirt para gerenciamento de máquinas virtuais. As funções virtualizadas incluem o HMI local, gateway de telecontrole, servidores de segurança cibernética e autômatos de nível de subestação. Esses autômatos — responsáveis pelo cálculo de alarmes, regulação de tensão e gerenciamento de sobrecarga — executam como PLCs virtuais dentro de contêineres Docker com um ciclo de 10 ms, gerenciando até 30.000 entradas/saídas e 60.000 variáveis [7].

Apenas funções com requisitos de tempo de resposta acima de 100 ms são virtualizadas na Fase 1. As funções de proteção permanecem em hardware dedicado.

Bloco 2 — Rede. Uma LAN duplicada com Protocolo de Redundância Paralela (PRP) transporta todo o tráfego. A sincronização PTP é transmitida através da LAN PRP. Uma LAN física separada trata a administração dos IEDs. A topologia de comutação é simples: 2 comutadores centrais para funções de subestação e bancos comuns, além de 2 comutadores por banco conectados aos centrais em topologia de estrela.

graph TB
    subgraph Central["Comutadores Centrais"]
        CS1["Comutador Central A\n(Para funções de subestação e banco comum)"]
        CS2["Comutador Central B\n(Para funções de subestação e banco comum)"]
    end

    subgraph Bay3["Banco N"]
        B3S1["Comutador do Banco N\nA"]
        B3S2["Comutador do Banco N\nB"]
    end

    subgraph Bay2["Banco 2"]
        B2S1["Comutador do Banco 2\nA"]
        B2S2["Comutador do Banco 2\nB"]
    end

    subgraph Bay1["Banco 1"]
        B1S1["Comutador do Banco 1\nA"]
        B1S2["Comutador do Banco 1\nB"]
    end

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

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

Bloco 3 — Banco e nível de processo. As Unidades de Controle de Banco (BCUs) abrigam proteção e automação de nível de banco. As Unidades de Interface de Processo (PIUs), Unidades de Controle de Equipamento de Comutação (SCUs) e Unidades de Merging Autônomas (SAMUs) gerenciam a interface com o equipamento primário. No piloto de Ploeren, 10 IEDs de nível de processo foram implantados apenas no lado da rede de processo [1].

Separação de rede: VLANs

A RTE optou pela segregação de tráfego baseada em VLAN em vez de filtragem por endereço MAC. A justificativa é a escalabilidade — os filtros por MAC tornam-se inviáveis à medida que o número de barras aumenta. A estrutura de VLANs é a seguinte:

  • Cada barra recebe suas próprias VLANs de SV (Sampled Value) e GOOSE, mantendo o tráfego de valores amostrados de alta taxa confinado.

  • As subscrições entre barras — necessárias para proteção de barras e bloqueios — recebem VLANs separadas.

  • A sincronização PTP e o MMS cada um recebem VLANs dedicadas.

  • A Qualidade de Serviço utiliza os bits de prioridade IEEE 802.1Q (0–7), configurados por IED e descritos no arquivo SCD [2].

Para uma subestação com 6 barras, isso significa um mínimo de 14 VLANs: 6 × SV + 6 × GOOSE + 1 SV inter-barras + 1 GOOSE inter-barras (mais PTP e MMS). Em escala, isso representa um esforço sério de engenharia de rede — mas evita que as tempestades de multicast de SV se propaguem além dos limites das barras.

A RTE como integradora de sistemas

O R#SPACE é multi-fornecedor por construção. A RTE não compra um sistema chave na mão de um único contratante. Em vez disso, define o quadro de interoperabilidade — os modelos de dados IEC 61850, Perfil de Aplicação Básica (BAPs), modelos SCL, requisitos de segurança cibernética — e adquire componentes individuais de acordo com essa especificação. Diferentes fornecedores entregam BCUs (Bay Control Units), IEDs de interface de processo, a plataforma HMI e o runtime de automação de nível de estação. Alguns componentes são desenvolvidos internamente ou colaborativamente por meio de projetos de código aberto.

Engenheiros comissionando cubículos de IED do R#SPACE. Fonte: Straton

O quadro de interoperabilidade vai além dos protocolos de comunicação. Abrange a interoperabilidade operacional (modelos de dados comuns, perfis harmonizados, gestão coordenada da qualidade dos dados) e a interoperabilidade não operacional (configuração SCL top-down, administração de IEDs baseada em API padronizada, cibersegurança coordenada). Cada função do PACS é modelada como um Dispositivo Lógico IEC 61850, e as configurações são descritas usando as classes de objetos de dados ING e ASG [2].

A escala do compromisso da RTE reflete-se nos números de aquisição. O contrato quadro de oito anos para IEDs de nível de barra começa com um lote inicial de 41 BCUs e 92 PIUs. Os volumes máximos previstos no contrato: 2.418 BCUs e 5.390 PIUs [3]. Isso não é um programa piloto.

Cubículos de IED do R#SPACE montados para teste de fábrica. Fonte: Efacec

Testes: o que realmente deu errado

O artigo da CIGRE sobre testes do R#SPACE (Sessão 2024, SC B5) é incomumente franco sobre as dificuldades enfrentadas [4]. A cadeia de testes possui quatro etapas:

  • testes de conformidade de componentes individuais,

  • qualificação do sistema do PACS integrado,

  • testes de aceitação de fábrica (FAT) pelo contratante de montagem,

  • e testes de aceitação no local (SAT).

O laboratório de testes da RTE no local "Transfo", perto de Lyon, inclui bancos de injeção de tensão/corrente, painéis de I/O binários, um servidor em tempo real com capacidades MMS/GOOSE/SV e um emulador central IEC 60870-5-104. Cerca de 60% dos testes de nível de sistema foram automatizados usando scripts em Python.

Três constatações destacam-se:

A maioria das anomalias ocorreu por IED, não entre dispositivos. A expectativa inicial era de que a integração multi-fornecedor fosse a principal fonte de problemas. Na prática, a maioria das questões se relacionava com não conformidades individuais dos IED — dispositivos que não implementavam totalmente seus próprios perfis declarados conforme a IEC 61850.

A convergência do SCL foi dolorosa. Levar o arquivo de Descrição da Configuração do Sistema (System Configuration Description) a um estado em que as ferramentas de todos os fornecedores pudessem analisar e importar levou várias semanas de troca de informações entre a equipe de configuração da RTE e os fornecedores de IED. Este é um problema conhecido de integração IEC 61850, mas o contexto multi-fornecedor o agravou — cada ferramenta SCL do fornecedor tinha interpretações ligeiramente diferentes para casos de borda.

As falhas intermitentes foram as mais difíceis de identificar. Após o sistema passar em todos os testes de qualificação, o monitoramento contínuo detectou falhas aleatórias: alguns IEDs paravam de repetir mensagens GOOSE por períodos prolongados, depois retomavam. A caracterização da causa raiz levou três meses [4]. Este é o tipo de problema que sistemas de um único fornecedor talvez nunca apresentem, pois o ambiente de teste do fornecedor é muito homogêneo.

O plano de implantação

gantt
    title Cronograma de Implantação do R#SPACE
    dateFormat  YYYY
    axisFormat  %Y

    section P&D
    Demonstradores de Postes Inteligentes     :done, pi, 2014, 2017
    Conceito e especificação do R#SPACE       :done, spec, 2017, 2020

    section Desenvolvimento
    Desenvolvimento interno e externo       :done, dev, 2020, 2022
    Pré-integração e FAT                     :done, fat, 2022, 2023

    section Implantação
    Piloto em Ploeren (63 kV)                 :done, pilot, 2023, 2024
    +1 subestação                             :done, y2024, 2024, 2025
    +3 subestações planejadas                :active, y2025, 2025, 2026
    Expansão industrial                       :y2026, 2026, 2030
    Meta de 100 subestações                   :milestone, m1, 2030, 2030

O ritmo é deliberadamente cauteloso. Uma subestação adicionada em 2024, mais três planejadas para 2025. A meta é que 100 subestações operem com o R#SPACE até 2030 [5] — aproximadamente 4% da frota de 2.600 subestações da RTE. A Fase 1 abrange subestações menores: nível de tensão único, número limitado de barras, principalmente 63–90 kV. A Fase 2 abordará subestações multi-tensão, até 400 kV, com topologias complexas de barramentos.

A plataforma SEAPATH, lançada sob licença Apache 2.0 pela LF Energy, atraiu colaboradores além da RTE — incluindo a National Grid Electricity Transmission e a GE Vernova. Cada alteração de código deve passar por mais de 700 testes unitários, testes em tempo real e testes de latência no CI [6]. Este é um nível incomum de rigor para um projeto de código aberto em OT.

O que o R#SPACE significa para a indústria

Três aspectos deste projeto merecem atenção de engenheiros fora da França.

O modelo de integrador de sistemas funciona, mas é caro. A RTE basicamente desenvolveu uma capacidade técnica interna que a maioria das concessionárias terceirizam completamente. A vantagem é a independência: a RTE pode trocar fornecedores, adicionar funcionalidades e atualizar componentes individuais sem renegociar um contrato chave na mão. O custo é uma equipe especializada permanente que abrange modelagem de dados IEC 61850, ferramentas SCL, design de rede, virtualização e cibersegurança. Nem todas as TSOs podem arcar com isso.

A virtualização de fonte aberta para subestações é real. A plataforma SEAPATH não é um projeto teórico. Ela opera tráfego de produção em Ploeren. KVM, Corosync/Pacemaker e contêineres Docker para funções de nível de estação — esta é uma alternativa viável às plataformas SCADA proprietárias, pelo menos para funções onde tempos de resposta de mais de 100 ms são aceitáveis. Se a mesma abordagem poderá eventualmente hospedar funções de proteção (com requisitos inferiores a 4 ms) permanece uma questão em aberto.

A integração multi-fornecedor IEC 61850 ainda é difícil. Apesar de duas décadas de eventos de testes de interoperabilidade, a convergência SCL levou semanas, falhas de repetição GOOSE exigiram meses para diagnosticar, e a maioria dos bugs foram problemas de conformidade por IED. O R#SPACE é um lembrete de que o padrão IEC 61850 permite a interoperabilidade — não a garante. O esforço de engenharia necessário para alcançá-la em escala é substancial.

A RTE planeja compartilhar mais experiências operacionais por meio dos grupos de trabalho IEC TC57 WG10 e CIGRE B5. Para o resto de nós, a questão é se o modelo R#SPACE — TSO como integrador, plataforma de fonte aberta, arquitetura neutra a fornecedores — se tornará a exceção ou o modelo padrão.

Fontes

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

[2] PAC World, " rumo a uma implantação industrial de PACS totalmente digitais na RTE," Edição 74, 2024, https://www.pacw.org/towards-an-industrial-deployment-of-fully-digital-pacs-at-rte

[3] Efacec, "Efacec fortalece contrato estratégico com a RTE para automação de subestações," https://www.efacec.com/news/efacec-strengthens-strategic-contract-with-rte-for-substation-automation/

[4] CIGRE Science & Engineering, No. 35, "Abordagem de testes para o Sistema de Automação e Controle de Proteção R#SPACE da RTE," https://cse.cigre.org/cse-n035/b5-testing-approach-for-rtes-rspace-protection-automation-and-control-system.html

[5] LF Energy, "RTE implementa o SEAPATH da LF Energy para Automação e Controle Virtual de Proteção," https://lfenergy.org/rte-deploys-lf-energy-seapath-for-virtual-protection-automation-and-control/

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

[7] Straton, "A RTE revoluciona a gestão das subestações francesas graças à Straton," https://straton-plc.com/en/rte-revolutionizes-the-management-of-french-substations-thanks-to-straton/

[8] Codra, "Sistema de controle distribuído R#SPACE," https://codra.net/en/news/2020/08/distributed-control-system-rspace/

[9] V. Astier, V. Leitloff, T. Babagana, A. Kurtz Bui, et al., "Design, Test & Commissioning — 'Postes Intelligents'," PAC World Magazine, setembro de 2018, pp. 46–51.