R-GOOSE e R-SV: quando a IEC 61850 sai da subestação

Na IEC 61850, o GOOSE tornou-se um dos mecanismos-chave para troca rápida entre dispositivos eletrônicos inteligentes. É o GOOSE que permite aos IEDs de proteção, dispositivos de automação, controladores de bay e outros IEDs trocar entre si eventos: atuações de proteção, intertravamentos, posições de equipamentos de manobra, comandos de desligamento, etc.

Mas o GOOSE clássico tem uma limitação arquitetônica fundamental: é uma mensagem de camada de enlace Ethernet. Funciona perfeitamente dentro de uma rede local da subestação, mas não foi projetado para ser roteado por redes IP comuns.

Quando a troca precisa ser organizada não apenas dentro de uma subestação, mas entre objetos distantes do sistema elétrico, surge a necessidade de outro mecanismo — Routable GOOSE, ou R-GOOSE.

GOOSE clássico: rápido, local, dentro da subestação

O GOOSE trabalha no modelo publisher/subscriber: um dispositivo publica a mensagem, e um ou vários dispositivos assinantes a utilizam.

Usos típicos do GOOSE:

• transmissão de sinais de desligamento;
• intertravamentos entre IEDs;
• lógicas de proteção de falha de disjuntor, proteção de barras, transferência automática;
• troca de posições de disjuntores e seccionadores;
• e outros.

A principal vantagem do GOOSE é a alta velocidade e uma «sobrecarga» de protocolo mínima. A mensagem é transmitida diretamente sobre Ethernet, no nível L2. Isso torna o GOOSE conveniente para tarefas em que milissegundos importam.

Mas isso também é sua limitação: o GOOSE comum não é roteável através de redes IP. Sua área natural de uso é a rede tecnológica local da subestação.

Por que surgiu o R-GOOSE

Com a evolução das subestações digitais ficou claro que esse tipo de troca é necessário não apenas dentro de um único objeto.

Surgiram tarefas em que a mensagem precisa ser entregue de um nó do sistema elétrico a outro, ou simultaneamente a vários nós distantes:

• desligamento remoto / aceleração remota;
• intertravamentos entre objetos;
• esquemas especiais de proteção (SPS);
• e outros.

Para tais cenários o Ethernet local já não é suficiente. É preciso poder transmitir eventos por redes IP, incluindo a infraestrutura WAN da concessionária.

É exatamente aqui que aparece o Routable GOOSE — GOOSE roteável.

O que é o R-GOOSE

O R-GOOSE é a evolução da ideia do GOOSE para redes IP. Se o GOOSE clássico trabalha em nível Ethernet, o R-GOOSE acrescenta a possibilidade de transmissão por uma infraestrutura IP roteável.

Simplificando:

GOOSE — para troca rápida dentro da rede local da subestação. R-GOOSE — para troca por rede IP entre objetos distantes.

Na IEC 61850, as variantes roteáveis de GOOSE e Sampled Values permitem usar o modelo publisher/subscriber não só dentro de uma única rede local, mas em uma infraestrutura de rede mais ampla.

Importante: R-GOOSE não é «GOOSE que apenas vai mais longe». É outro contorno de engenharia: roteamento IP, multicast, latência, jitter, QoS, tolerância a falhas, cibersegurança e gestão de chaves.

E o que é o R-SV

Junto com o R-GOOSE também é considerado um segundo perfil — Routable Sampled Values, ou R-SV.

A lógica é parecida. Sampled Values comuns são transmitidos em uma rede local, por exemplo no process bus de uma subestação digital. Mas algumas tarefas exigem transmitir os dados a longas distâncias.

Em primeiro lugar, isso se refere às tarefas ligadas a medições sincrofasoriais e a funções distribuídas de proteção e automação. Se GOOSE e R-GOOSE são, antes de tudo, eventos, então SV e R-SV são medições, transmitidas periodicamente.

Em outras palavras:

R-GOOSE — eventos roteáveis. R-SV — dados de medição em fluxo ou periódicos, roteáveis.

Na prática o R-GOOSE é discutido e aplicado com mais frequência, porque há mais cenários para entrega remota de eventos — desligamento remoto, intertravamentos, esquemas especiais de proteção — e eles são mais claros para as tarefas aplicadas de proteção e automação.

Exemplo 1. Desligamento remoto em vez de seccionador-aterrador

Um dos cenários ilustrativos para o R-GOOSE é o envio de um comando de desligamento remoto em vez do uso de um seccionador-aterrador.

Em esquemas tradicionais, em subestações de derivação ou em alguns vãos pode ser utilizado um seccionador-aterrador. Sua tarefa é criar um curto-circuito controlado, para que a proteção do lado do alimentador veja com segurança o defeito e desligue a linha.

Essa abordagem funciona, mas do ponto de vista de engenharia parece bastante dura: para desligar a seção defeituosa, na verdade criamos um curto-circuito artificial na rede.

O R-GOOSE permite abordar a mesma tarefa de outra forma. Em vez de criar um curto-circuito artificial, é possível enviar um sinal de desligamento remoto ao disjuntor necessário ou a um grupo de disjuntores por uma rede roteável.

Isso é especialmente importante em redes de distribuição com participação crescente de geração distribuída. Durante um curto-circuito, o afundamento de tensão afeta não só o alimentador defeituoso, mas também os vãos vizinhos. Quanto mais tempo o defeito persistir, maior será o risco de desligamento indevido de consumidores sensíveis ou de objetos de geração distribuída.

O desligamento remoto rápido permite reduzir a duração do afundamento e diminuir o impacto da falha em partes adjacentes da rede. Ou seja, o R-GOOSE aqui é interessante não como «mais um protocolo pelo protocolo», mas como uma forma de implementar uma lógica de desligamento mais limpa e rápida, sem criar um curto-circuito adicional.

Exemplo 2. Esquemas especiais de proteção (SPS)

O segundo cenário importante são os esquemas especiais de proteção.

Esses esquemas frequentemente trabalham não dentro de uma única subestação, mas no nível de um trecho da rede ou do sistema elétrico. Para tomar a decisão, podem precisar de sinais de pontos diferentes: estado das linhas, sobrecargas, estado da geração, posição dos disjuntores, eventos de falha, parâmetros do regime.

Nessas tarefas importa não só receber o sinal, mas entregá-lo em um tempo definido. Se o evento ocorreu em um objeto e a ação de controle precisa ser executada em outro, o GOOSE local comum já não basta.

O R-GOOSE pode ser usado como transporte para uma troca rápida de eventos entre objetos de SPS. Por exemplo:

• transmissão do fato de desligamento de uma linha;
• envio de comando de corte de carga;
• envio de comando de limitação de geração;
• disparo de uma ação de controle pré-definida;
• troca de sinais entre vários nós de um esquema SPS.

Em tais sistemas, os requisitos de latência, redundância de canais, cibersegurança e diagnóstico são especialmente importantes. Não se pode simplesmente dizer: «a mensagem vai por IP, então tudo funciona». É preciso provar que a rede garante o tempo de entrega exigido em regime normal, em falhas e em comutação de rotas.

Exemplo 3. Medições sincrofasoriais

Outra área de aplicação dos perfis roteáveis IEC 61850 é a transmissão de dados de medições sincrofasoriais.

As medições sincrofasoriais são importantes para o monitoramento distribuído, para a análise de estabilidade, controle de regimes e construção de sistemas WAMS/WAMPAC. Diferentemente das mensagens que carregam informação sobre eventos, esses dados são transmitidos periodicamente e devem ter uma marcação temporal precisa.

Do ponto de vista de engenharia, há uma diferença importante em relação ao desligamento remoto ou aos SPS. Para o monitoramento, a latência de entrega em si pode não ser tão crítica, desde que cada valor tenha uma marcação temporal correta. O sistema pode juntar os dados de diferentes dispositivos para o mesmo instante e depois realizar a análise.

Mas, se os dados sincrofasoriais forem usados não apenas para monitoramento, mas para automação rápida, a latência volta a ser um parâmetro crítico. Nesse caso é preciso considerar não só a precisão do tempo, mas também o tempo de entrega, o jitter, as perdas de pacotes e o comportamento do sistema na degradação dos canais de comunicação.

Camada de rede: L2 vs L3

Do ponto de vista de engenharia, a principal diferença entre GOOSE e R-GOOSE é a camada de rede.

O GOOSE é adequado onde tudo acontece dentro de uma única rede tecnológica. O R-GOOSE é necessário quando a função sai dos limites de uma única subestação e deve trabalhar por uma infraestrutura roteável.

Segurança: por que Secure R-GOOSE é mais importante do que apenas R-GOOSE

Quando o GOOSE permanece dentro da rede tecnológica isolada da subestação, a segurança continua importante: VLAN, controle de acesso, segmentação e outras medidas.

Mas quando a mensagem sai dos limites de uma subestação, a questão da segurança torna-se central.

Para R-GOOSE e R-SV é preciso considerar:

• autenticação da fonte da mensagem;
• integridade dos dados;
• proteção contra substituição;
• proteção contra retransmissão de mensagens antigas;
• gestão de chaves;
• delimitação de zonas de rede;
• firewalls e regras de roteamento;
• monitoramento de anomalias;
• verificação do comportamento na perda de comunicação e degradação do canal.

Na rede local da subestação, um GOOSE publicado por engano já pode causar consequências graves. Em uma rede entre objetos, o preço do erro é ainda maior: a mensagem pode disparar desligamentos, ações de proteção especial ou mudanças de regime simultaneamente em vários objetos.

Por isso o R-GOOSE não pode ser analisado isoladamente das questões de cibersegurança.

Por que o multicast precisa de um modelo de proteção próprio

Para a comunicação cliente-servidor clássica é possível usar o esquema usual: cliente, servidor, TLS, certificados.

Mas GOOSE, R-GOOSE, SV e R-SV operam segundo outra lógica. Trata-se de publisher/subscriber e multicast. Uma única mensagem pode ser destinada a vários assinantes ao mesmo tempo.

Portanto, o modelo de segurança também deve considerar a comunicação em grupo. É preciso definir:

• quem tem o direito de publicar o fluxo;
• quem tem o direito de recebê-lo;
• quais dispositivos integram o grupo de assinantes;
• como as chaves são distribuídas;
• com que frequência são renovadas;
• o que ocorre em caso de comprometimento de um dispositivo;
• como remover um dispositivo do grupo;
• como diagnosticar uma falha de assinatura devida a problemas de segurança.

Em sistemas grandes, sem gestão centralizada de chaves, esse esquema rapidamente se torna ingerenciável. Por isso, para perfis roteáveis seguros, é fundamental a infraestrutura de gestão de chaves e de políticas de acesso.

KDC: por que ele é necessário em Secure R-GOOSE e Secure R-SV

Quando falamos de R-GOOSE e R-SV seguros, é importante entender: não se trata apenas do roteamento de mensagens por uma rede IP. Trata-se de comunicação em grupo segura.

GOOSE, R-GOOSE, SV e R-SV operam segundo o modelo publisher/subscriber. Um dispositivo publica o fluxo, e vários dispositivos podem ser seus assinantes. Isso não é o esquema clássico «cliente — servidor», em que dois participantes estabelecem uma conexão segura entre si. Aqui, uma única fonte deve entregar a mensagem com segurança a um grupo de receptores.

Por isso surge o conceito de Security Group — grupo de segurança. Nele entram o publisher e todos os subscribers que têm direito a receber um fluxo específico.

Por exemplo, para um fluxo Sampled Values esse grupo pode incluir:

• o dispositivo publicador, por exemplo um merging unit (SAMU);
• todos os assinantes que utilizam esse conjunto de medições;
• a infraestrutura responsável pela verificação dos participantes e pela emissão de chaves.

Para o R-GOOSE a lógica é a mesma: ao grupo pertencem o dispositivo que publica o evento e todos os assinantes que precisam recebê-lo e usá-lo em sua lógica.

Para que todos os participantes desse grupo possam verificar a autenticidade das mensagens e, se necessário, decifrá-las, eles precisam de uma chave simétrica comum. O dispositivo ou função que distribui essa chave entre os membros do grupo é chamado de KDC — Key Distribution Center, ou seja, centro de distribuição de chaves.

flowchart TB
    subgraph PKI["Infraestrutura de confiança"]
        PKIICON["🏛️ PKI<br/>emissão e revogação de certificados"]
    end

    KDC["<b>🔐 KDC</b><br/><i>Key Distribution Center</i><br/>• verificação de certificados<br/>• política do grupo<br/>• emissão de chaves simétricas<br/>• rotação (tipicamente 24 h)<br/>• KDA — Key Delivery Assurance"]

    PKIICON -. certificados .-> KDC

    subgraph SG["Security Group · fluxo R-GOOSE / R-SV"]
        direction LR
        PUB["<b>Publisher</b><br/>p. ex., MU / IED / controlador SPS"]
        SUB1["Subscriber 1<br/>IED em SE remota"]
        SUB2["Subscriber 2<br/>dispositivo SPS"]
        SUB3["Subscriber N<br/>WAMS / centro de controle"]
        PUB ==>|"R-GOOSE / R-SV<br/>multicast"| SUB1
        PUB ==>|" "| SUB2
        PUB ==>|" "| SUB3
    end

    KDC -. "<b>PUSH</b><br/>rotação<br/>centralizada de chave" .-> PUB
    KDC -. " " .-> SUB1
    KDC -. " " .-> SUB2
    KDC -. " " .-> SUB3
    SUB1 -. "<b>PULL</b><br/>após reinício<br/>ou dessincronização" .-> KDC

    NOTE["<b>O que é entregue</b><br/>• chave atual<br/>• próxima chave + hora de ativação<br/>• política: algoritmo MAC, cifragem, período de rotação"]
    KDC -.-> NOTE

    style KDC fill:#FDE8E8,stroke:#F56C6C,color:#B71C1C
    style PUB fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style SUB1 fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style SUB2 fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style SUB3 fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style PKIICON fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style NOTE fill:#F4F6FB,stroke:#9aa6c8,color:#3a4566

Por que se utiliza chave simétrica

Em R-GOOSE/R-SV seguros, a autenticação e o controle de integridade da mensagem são obrigatórios. A confidencialidade — ou seja, a cifragem do conteúdo — pode ser aplicada adicionalmente.

A autenticação é feita pela computação de uma assinatura criptográfica especial da mensagem — Message Authentication Code, ou MAC. Em algumas descrições é usado o termo HMAC, quando a assinatura é construída sobre um algoritmo de hash.

A lógica é a seguinte:

1. O publisher compõe a mensagem.
2. É calculado um hash criptográfico sobre o conteúdo da mensagem.
3. Esse hash é protegido com uma chave simétrica.
4. O receptor recebe a mensagem e recalcula o hash pelas mesmas regras.
5. Se o valor calculado coincide com o recebido, a mensagem é considerada autêntica e não modificada.

Ou seja, o assinante pode verificar que a mensagem realmente veio de um membro do grupo e não foi adulterada no caminho.

Se a cifragem for usada, o mesmo material de chave do grupo protege a carga útil da mensagem. Importante: não se cifra a mensagem inteira, mas justamente o payload, para que a infraestrutura de rede possa processar os cabeçalhos necessários.

O que exatamente o KDC faz

O KDC executa várias tarefas.

Primeiro, ele verifica se o dispositivo tem o direito de ser membro do grupo de segurança. Para isso são usados certificados digitais. Os membros do grupo e o próprio KDC devem possuir certificados confiáveis, e a autenticidade do participante é verificada por meio da infraestrutura de chaves públicas — PKI.

Segundo, o KDC emite chaves simétricas para os membros do grupo. Essas chaves são necessárias para a autenticação das mensagens e, se a cifragem estiver habilitada, para a proteção da carga útil.

Terceiro, o KDC gerencia a política de segurança do grupo. A política pode definir:

• qual algoritmo MAC é usado para formar a assinatura criptográfica;
• qual algoritmo de cifragem é aplicado, se a cifragem estiver habilitada;
• com que frequência a chave deve ser renovada;
• se é usado um mecanismo de confirmação de entrega de chaves;
• quando a nova chave deve entrar em vigor.

Quarto, o KDC é responsável pela renovação periódica das chaves. Quanto mais tempo uma única chave for usada no sistema, maior o risco de comprometimento. Por isso as chaves devem ser renovadas regularmente. Nas descrições dos perfis roteáveis seguros, indica-se como período típico de rotação 24 horas. Ao mesmo tempo, aos membros pode ser entregue a chave atual e a próxima chave, o que dá uma margem para a troca segura.

PUSH e PULL: duas formas de entrega de chaves

A entrega de chaves do KDC aos membros do grupo pode ser feita de duas formas: PULL e PUSH.

No modo PULL o próprio dispositivo solicita a chave ao KDC. Isso é necessário, por exemplo, na inicialização do dispositivo, em uma dessincronização de chaves ou se o dispositivo não conseguiu receber corretamente a chave enviada anteriormente. Antes de emitir a chave, o KDC verifica o certificado do dispositivo e seu direito de pertencer ao grupo de segurança correspondente.

No modo PUSH o próprio KDC envia a nova chave aos membros do grupo. Esse modo é útil para atualizações centralizadas de chaves, especialmente em grandes sistemas onde a gestão manual de chaves torna-se inviável.

Na prática, os dois mecanismos são importantes. O PULL permite ao dispositivo se recuperar após uma reinicialização ou problemas com chaves. O PUSH permite ao KDC realizar de forma centralizada a rotação regular de chaves para todo o grupo.

Key Delivery Assurance: por que não basta «trocar a chave»

Em um sistema de TI comum, uma falha na atualização da chave pode levar à perda de acesso ao serviço. No sistema elétrico, as consequências podem ser muito mais graves: se parte dos dispositivos não receber a nova chave, eles podem deixar de aceitar mensagens críticas de R-GOOSE ou R-SV.

Para funções de desligamento remoto ou esquemas de proteção especiais, isso é inadmissível. A troca de chaves não deve bloquear o funcionamento da função principal.

Por isso é usado o mecanismo KDA — Key Delivery Assurance. Seu sentido é que o KDC pode controlar o sucesso da entrega da chave aos membros do grupo. Se a nova chave foi entregue com sucesso a uma porcentagem definida de membros, o KDC envia ao publisher a informação autorizadora, após a qual o publisher pode passar para a nova chave no momento previsto.

Em outras palavras, o KDA serve para que a rotação de chaves não se transforme em causa de falha de uma função tecnológica.

Chave atual e próxima chave

Detalhe prático importante: aos membros podem ser entregues simultaneamente duas chaves — a atual e a próxima.

Isso permite preparar os dispositivos com antecedência para a troca de chave. Na mensagem é indicada não apenas a informação atual da chave, mas também o momento em que a próxima chave deve se tornar ativa. Graças a isso, publisher e subscribers podem passar de forma sincronizada para a nova chave sem ruptura da comunicação segura.

Se os membros possuem a chave atual e a próxima, surge uma margem de tempo que permite suportar uma indisponibilidade temporária do KDC ou uma falha de comunicação com ele.

O que acontece quando o KDC fica indisponível

Pergunta operacional muito importante: o que acontece se o KDC ficar temporariamente indisponível?

Para funções de engenharia, a resposta não deve ser: «tudo parou de funcionar». Se o R-GOOSE é usado para desligamento remoto ou esquemas especiais de proteção, a perda temporária de contato com o KDC não deve bloquear imediatamente a transmissão e a recepção das mensagens tecnológicas.

É por isso que se aplica o esquema com chaves entregues antecipadamente e com período de validade das chaves. Se os participantes já possuem a chave atual e a próxima, eles podem continuar operando dentro da política definida mesmo durante uma indisponibilidade breve do KDC.

Mas isso não significa que o KDC possa ser considerado um elemento secundário. Sua falha deve ser diagnosticada, os eventos devem ser registrados, e a operação deve entender:

• quanto tempo o sistema pode operar sem contato com o KDC;
• quais grupos de segurança já possuem a próxima chave;
• quais dispositivos não receberam a atualização;
• quando começará o risco de perder a comunicação segura;
• como restaurar a sincronização de chaves após o retorno do KDC.

O KDC e o arquivo SCL

Para o engenheiro de IEC 61850 importa que os grupos de segurança não surgem do nada. Os arquivos SCL já contêm informação sobre fluxos, vínculos publisher/subscriber, DataSet, Control Block, endereçamento e assinaturas.

Com base nesses dados é possível determinar quais dispositivos participam de uma troca GOOSE, R-GOOSE, SV ou R-SV específica. Por conseguinte, a informação do SCL pode ser usada como base para a formação de grupos de segurança e da política de acesso.

Este é um ponto importante para a engenharia e a operação: a segurança dos perfis roteáveis deve estar ligada ao modelo de engenharia do objeto, e não configurada à parte «manualmente» sem ligação com o projeto SCD/SCL.

Se a composição dos assinantes mudou no arquivo SCD, isso afeta potencialmente não só o esquema de comunicação, mas também a composição do grupo de segurança. Portanto, as alterações no projeto devem ser acompanhadas pela revisão das políticas do KDC e dos direitos dos participantes.

O que o engenheiro deve verificar ao implantar Secure R-GOOSE

Ao implantar Secure R-GOOSE ou Secure R-SV, o engenheiro deve verificar não apenas a passagem das mensagens, mas toda a cadeia de confiança e de gestão de chaves.

Uma checklist prática pode ser assim:

• estão definidos o publisher e todos os subscribers para cada fluxo seguro;
• para cada fluxo está definido um Security Group;
• é claro quais certificados são usados pelos dispositivos e pelo KDC;
• foi testada a procedure de emissão, renovação e revogação de certificados;
• está definida a política do grupo: algoritmos, rotação de chaves, necessidade de cifragem;
• foram testados os modos PUSH e PULL;
• verificado que o dispositivo recebe a chave após reinicialização;
• verificado o funcionamento durante a indisponibilidade temporária do KDC;
• verificado o mecanismo de rotação de chaves;
• verificado que a troca de chave não bloqueia a função tecnológica;
• eventos do KDC e erros de chaves estão disponíveis para diagnóstico;
• alterações no projeto SCD/SCL estão sincronizadas com os grupos de segurança.

Routable não significa internet pública

O fato de R-GOOSE e R-SV serem roteáveis não significa que devam ser transmitidos pela internet pública não protegida.

R-GOOSE não é «GOOSE através da internet». É um mecanismo para uma infraestrutura IP gerenciada, segura e dimensionada em engenharia do sistema elétrico.

Essa rede deve garantir:

• latência previsível;
• redundância;
• controle de rotas;
• QoS;
• proteção contra acesso não autorizado;
• diagnóstico;
• monitoramento do estado dos canais;
• responsabilidade operacional clara.

Por isso a implantação do R-GOOSE não é apenas uma tarefa de proteção, mas também de arquitetura de rede, segurança da informação e operação.

Latência e desempenho

Para o GOOSE local a métrica principal é o tempo de entrega rápido e previsível dentro da rede tecnológica.

Para o R-GOOSE os requisitos são mais complexos. Além do tempo de entrega da própria mensagem, surgem:

• latências de roteamento;
• processamento de multicast;
• comportamento dos canais WAN;
• redundância;
• possível processamento criptográfico;
• comportamento na degradação da comunicação;
• tempo de recuperação após a comutação de rota.

Para tarefas de monitoramento parte dessas latências pode ser admissível. Para desligamento remoto e esquemas especiais de proteção — não. Aí a latência passa a fazer parte do tempo total de atuação da função.

Por isso, ao projetar R-GOOSE, deve-se começar não pela pergunta «como transmitir a mensagem», mas pela pergunta:

qual o tempo máximo de entrega admissível para esta função?

E só depois disso escolher a arquitetura da rede, os mecanismos de redundância, os requisitos dos canais e os meios de controle.

Diferença prática para o engenheiro

Para o engenheiro de proteção e SCADA, a diferença entre GOOSE e R-GOOSE pode ser formulada assim:

GOOSE — é uma tarefa local na subestação digital. R-GOOSE — é uma tarefa no âmbito do sistema elétrico.

GOOSE exige entendimento de:

• arquivo SCD;
• GOOSE Control Block;
• DataSet;
• VLAN e priority tagging;
• multicast MAC;
• parâmetros stNum, sqNum, timeAllowedToLive;
• flags test, simulation, ndsCom;
• comportamento do assinante na perda ou alteração da mensagem;
• e outros.

R-GOOSE exige tudo isso mais:

• endereçamento e roteamento IP;
• UDP multicast;
• infraestrutura de multicast;
• QoS e cálculo de latências;
• redundância WAN;
• gestão de chaves;
• certificados e grupos de segurança;
• diagnóstico de fluxos seguros;
• e outros.

Onde usar GOOSE e onde usar R-GOOSE

flowchart TB
    START["<b>Que função estamos implementando?</b>"]
    Q1{"A função sai<br/>dos limites<br/>de uma subestação?"}
    Q2{"O que é transmitido:<br/>evento ou<br/>dados periódicos?"}
    Q3{"Latência admissível<br/>para a função<br/>aplicada?"}

    GOOSE["<b>GOOSE</b><br/>Ethernet L2 · multicast<br/>VLAN · priority tagging<br/>SCD: GoCB · DataSet"]
    RGOOSE["<b>R-GOOSE</b><br/>IP / UDP multicast<br/>+ Secure session, KDC<br/>SCD + arquitetura de rede + cibersegurança"]
    RSV_MON["<b>R-SV (monitoramento)</b><br/>medições sincrofasoriais<br/>WAMS / monitoramento distribuído<br/>principal — marca temporal precisa"]
    RSV_AUTO["<b>R-SV (automação)</b><br/>latência, jitter,<br/>perdas — críticos<br/>a WAN deve ser projetada à parte"]

    START --> Q1
    Q1 -- "não, local" --> GOOSE
    Q1 -- "sim, entre objetos" --> Q2
    Q2 -- "evento" --> RGOOSE
    Q2 -- "medições periódicas" --> Q3
    Q3 -- "monitoramento (dezenas–centenas de ms ok)" --> RSV_MON
    Q3 -- "automação rápida" --> RSV_AUTO

    NOTE1["⚠️ R-GOOSE / R-SV ≠ internet pública<br/>é necessária uma infraestrutura WAN gerenciada<br/>com QoS, redundância e controle de rotas"]
    RGOOSE -.-> NOTE1
    RSV_MON -.-> NOTE1
    RSV_AUTO -.-> NOTE1

    style START fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style Q1 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style Q2 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style Q3 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style GOOSE fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style RGOOSE fill:#FBE9E7,stroke:#E64A19,color:#BF360C
    style RSV_MON fill:#EDE7F6,stroke:#7E57C2,color:#311B92
    style RSV_AUTO fill:#FDE8E8,stroke:#F56C6C,color:#B71C1C
    style NOTE1 fill:#F4F6FB,stroke:#9aa6c8,color:#3a4566

O GOOSE comum permanece a solução ótima para funções locais da subestação:

• intertravamentos;
• desligamentos;
• sinais de automação;
• troca entre IEDs de proteção;
• interação entre dispositivos dentro de uma única rede tecnológica;
• substituição de circuitos de cobre dentro do objeto.

O R-GOOSE é necessário onde a função sai dos limites de uma única subestação:

• desligamento remoto entre objetos;
• esquemas especiais de proteção;
• transmissão de eventos entre subestações e usinas;
• interação com objetos remotos de geração distribuída;
• lógica de controle de regime entre objetos.

O R-SV pode ser de interesse para tarefas de transmissão de dados de medição via WAN, especialmente quando se trata de medições sincrofasoriais e monitoramento distribuído.

O que isso muda para a operação das subestações digitais

Para a operação das subestações digitais, o surgimento de R-GOOSE e R-SV significa que a fronteira de responsabilidade do engenheiro se amplia.

Antes bastava entender o que acontece dentro do barramento de estação ou do barramento de processo de uma subestação. Agora, para uma série de tarefas, é preciso entender também a rede entre objetos:

• por quais roteadores passa a mensagem;
• como o multicast está construído;
• quais latências são admissíveis;
• onde estão o publisher e os subscribers;
• como o fluxo é protegido;
• quem gerencia as chaves;
• o que ocorrerá em caso de falha de um canal;
• como o sistema se comportará na degradação da comunicação;
• como registrar e comprovar o funcionamento correto em ensaios.

Isso já não é apenas «subestação digital» no sentido estrito. É a infraestrutura digital de comunicação do sistema elétrico.

Conclusão

O GOOSE permanece o mecanismo básico e eficiente para troca rápida de eventos dentro da subestação digital.

O R-GOOSE estende essa ideia para redes IP roteáveis e permite construir funções entre objetos: desligamento remoto, esquemas especiais de proteção, intertravamentos entre objetos e outros cenários em que um evento de um nó deve chegar de forma rápida e segura a vários assinantes distantes.

O R-SV resolve uma tarefa semelhante para medições, incluindo cenários ligados a medições sincrofasoriais e monitoramento distribuído.

Mas a principal conclusão é outra: R-GOOSE e R-SV não são apenas «GOOSE e SV via IP». São perfis de comunicação roteáveis seguros, que exigem nova disciplina de engenharia: cálculo de latências, projeto de multicast, gestão de chaves, aplicação de mecanismos de cibersegurança e verificação obrigatória do comportamento do sistema em regimes normais e de falha.

O KDC nessa arquitetura não é apenas «um servidor de chaves» em algum lugar da rede. Ele conecta entre si o modelo de engenharia IEC 61850, a composição dos grupos publisher/subscriber, os certificados digitais dos dispositivos, as chaves simétricas, a política de rotação e a prontidão operacional da comunicação segura.

Por isso, ao discutir R-GOOSE, é importante fazer não a pergunta «será possível enviar o GOOSE mais longe?», mas uma totalmente diferente:

qual função estamos implementando, por qual rede ela funciona, qual tempo de entrega é admissível, como o fluxo está protegido e o que acontecerá em caso de falha de comunicação?

Só depois de responder a essas perguntas o R-GOOSE deixa de ser um termo bonito do padrão e passa a ser uma ferramenta de trabalho do sistema elétrico digital.