GOOSE IEC 61850: Como os IEDs Trocam Sinais em Menos de 4ms

Você já parou para pensar em quanto tempo demora para um relé de proteção saber que tem uma falta no seu transformador?

Em uma subestação analógica tradicional? Uns 40-60 milissegundos. O fio de proteção viaja fisicamente de um ponto ao outro, passa por lógica de relé eletromecânico, e aí dispara.

Em uma subestação digital moderna? Menos de 4 milissegundos.

Parece pouco? Não é. É a diferença entre um curto-circuito isolado rapidinho e um blackout que desliga meia região.

E a "mágica" por trás disso se chama GOOSE — Generic Object Oriented Substation Event.

GOOSE é um protocolo de comunicação que faz uma coisa muito simples, mas muito bem feita: transmitir eventos críticos de proteção em tempo real pela rede Ethernet.

Deixa eu explicar com um exemplo bem concreto.

Imagine que você tem dois relés de proteção (relé A e relé B) e eles precisam "conversar" para coordenar um disparo. Antigamente:

1. Relé A detecta falta

2. Relé A envia sinal por fio físico analógico

3. Esse sinal viaja metros de cabo

4. Relé B recebe o sinal

5. Relé B toma decisão baseado no sinal

Todo esse processo levava tempo. E se o fio quebrasse no meio do caminho? Comunicação perdida.

Com GOOSE:

1. Relé A detecta falta

2. Relé A cria um pacote Ethernet com a informação "falta detectada"

3. Relé A multicasta esse pacote para a rede local

4. Relé B recebe em menos de 4ms

5. Relé B toma decisão

Simples. Rápido. Robusto (porque usa multicast — se um link cair, o pacote toma outro caminho).

Aqui está a pegadinha que muita gente não entende.

GOOSE usa UDP multicast — basicamente, ele grita a mensagem para quem quiser ouvir, não garante que chegou, e se não chegou, paciência, repete de novo em 4ms. Como ele repete constantemente (a cada 4ms em regime normal, mais rápido em falta), mesmo que uma ou duas mensagens se percam, a próxima vem logo.

Isso se chama comunicação confiável sem confirmação — e é o segredo de GOOSE ser tão rápido.

A latência não é 4ms porque GOOSE é "mágico". É 4ms porque ele simplesmente não perde tempo com confirmação.

Quando você configura um GOOSE em um IED, você está basicamente dizendo:

"Quando evento X acontecer (como 'falta detectada = verdadeiro'), transmita um pacote para o endereço MAC FF:FF:FF:FF:FF:FF (multicast) no VLAN Y, contendo esses dados, a cada Z milissegundos."

Deixa eu quebrar:

1. GOOSE Dataset

É a informação que você quer enviar. Exemplo:

• Relay Trip Signal = 1 (disparou)

• Falta Type = Trifásica

• Timestamp = 12345678

2. Report Control Block (RCB)

É o "configurador" de GOOSE. Define:

• Qual dataset vai ser transmitido

• Para qual endereço Ethernet (MAC)

• Em qual VLAN

• Com qual frequência

• Quando será disparado (sempre, só em mudança, etc)

Quando você comissiona um IED novo, você está na verdade configurando RCBs.

3. Multicast Address

O GOOSE não realiza a comunicação de forma unicast entre dois relés específicos. Em vez disso, ele utiliza endereçamento multicast, funcionando como uma transmissão publicada na rede para todos os dispositivos conectados naquele domínio Ethernet. Na prática, isso significa que vários IEDs recebem simultaneamente os mesmos pacotes GOOSE trafegando na rede.

Porém, receber o pacote não significa automaticamente utilizar aquela informação. Para que um relé consiga processar e utilizar uma variável GOOSE em sua lógica interna, ele precisa ser previamente configurado para receber aquele Dataset específico e associar os sinais recebidos as variáveis internas utilizadas na lógica de proteção, bloqueios, permissivos, intertravamentos ou comandos do sistema.

4. Timestamp

Cada pacote GOOSE leva um timestamp sincronizado (via GPS ou IRIG-B). Isso garante que relés conseguem saber quando a mensagem foi gerada, não apenas recebida.

Parece bobagem? Não é. Um timestamp de 1 microsegundo de diferença pode significar desfasamento de proteção de distância.

Aqui vem a parte que impressiona.

4 milissegundos é o tempo máximo de latência que GOOSE pode ter.

Por quê? Porque o padrão IEC 61850 diz que em caso de falta (evento crítico), GOOSE deve transmitir a cada 4ms ou mais rápido.

Vamos comparar com a concorrência:

GOOSE é rápido porque sacrifica confirmação. É o trade-off clássico: velocidade vs. confiabilidade absoluta.

Mas em proteção, você prefere reenviar a mensagem a cada 4ms (assim se perder uma, a próxima chega logo) do que esperar confirmação (que demoraria centenas de ms).

Esse é sempre um ponto de confusão.

GOOSE = eventos booleanos, mensagens de proteção, sinais on/off

• "Trip signal = 1"

• "Falta detectada = verdadeiro"

• "Chave aberta/fechada"

• Latência: < 4ms

Sample Values = ondas de tensão/corrente, dados contínuos, precisão alta

• 80 amostras por ciclo (4.8 kHz)

• Valor de corrente instantâneo = 1250 A

• Valor de tensão instantâneo = 230 kV

• Latência: 20ms (tempo de uma onda completa)

Exemplo real:

Um relé de proteção de distância usa tanto GOOSE quanto Sample Values:

1. Recebe Sample Values da tensão/corrente (para calcular impedância)

2. Quando calcula que há uma falta, dispara um GOOSE (para avisar outros relés)

São complementares, não concorrentes.

1. RCB Name Mismatch

Um erro bem comum em comissionamento.

Você configura no IED um GOOSE chamado "Trip_Signal_RCB_001", mas no relé receptor você coloca "Trip_Signal_RCB_002".

Resultado? O relé fica "esperando" um GOOSE que nunca vai chegar com aquele nome.

Validação: Sempre confira os RCB names na documentação de integração. E capture com Wireshark — o nome aparece em texto claro lá.

2. ACSE ABORT

ACSE é o "aperto de mão" que acontece antes de GOOSE ser transmitido. É quando dois equipamentos dizem "olá, vamos conversar?"

Se ACSE falhar (nome errado, endereço MAC errado, IP wrong), você vê erro "ACSE ABORT" e GOOSE não sai do chão.

Validação: Verificar logs do IED. Mensagem de erro vai conter "OSI-AP-Title mismatch" ou similar.

3. Multicast Flooding

GOOSE usa multicast — imagina bastante GOOSE saindo simultâneo de vários IEDs. Pode sobrecarregar switch de rede. Um "flooding" de multicast consegue matar sua banda.

Solução: Esse é exatamente o motivo de ter uma VLAN dedicada para GOOSE. Multicast fica isolado ali, não afeta nada.

4. Timestamp Dessincronizado

Se relés têm timestamps muito diferentes, GOOSE vira confuso.

Relé A manda GOOSE com timestamp 12:00:00.000001 Relé B recebe às 12:00:00.000005 e pensa "chegou com 4 microsegundos de atraso".

Multiplica por vários relés, somas de atrasos desincronizam proteção.

Solução: Validar sincronismo IRIG-B/GPS. Diferença máxima de 1 microsegundo entre equipamentos.

Erro 1: Confundir GOOSE com Sample Values

"Vou enviar os valores de corrente via GOOSE."

Não. GOOSE é para eventos (trip, falta), não para dados contínuos. Use Sample Values para isso.

Erro 2: Não Separar VLAN

"GOOSE fica na rede geral, junto com supervisório."

Errado. Multicast GOOSE consegue consumir muita banda. Precisa de VLAN dedicada com QoS.

Erro 3: Não Validar Sincronismo

"Configurei GOOSE, deve estar funcionando."

Talvez. Mas se timestamps estão dessincronizados, coordenação fica errada silenciosamente.

Erro 4: RCB Name Errado no Receptor

"Coloquei o RCB do transmissor, tá bom."

Se os nomes não baterem, receptor não vê GOOSE nenhum. Validar com Wireshark.

Erro 5: Não Testar em Comissionamento

"Vou deixar para testar em operação."

Não. Teste tudo em TAF . Em TAC , teste de novo.

Aqui vem um tópico que muita gente evita, mas é absolutamente crítico: segurança de GOOSE.

Porque aquela velocidade de 4ms que é tão boa para proteção legítima? Também é boa para ataques.

Um atacante sofisticado consegue injetar uma mensagem GOOSE falsa na sua rede. Seu relé acha que é legítimo e dispara indevidamente. Resultado? Blackout.

As Ameaças Reais

1. Spoofing (Falsificação de Mensagens) Um atacante envia um pacote GOOSE com dados falsos. Seu relé recebe, pensa que é da fonte legítima, e dispara.

Exemplo: "Trip = 1" falso faz seu relé disparar quando não deveria

2. Ataques de Replay Um atacante captura um GOOSE legítimo com Wireshark, e o retransmite depois.

Exemplo: Captura um "Trip = 1" válido, e repete 5 minutos depois

3. Denial of Service (DoS) Inundação de mensagens GOOSE falsas. Sua rede fica congestionada, pacotes legítimos são perdidos.

Exemplo: 1000 GOOSE por segundo saturam a banda, proteção real fica invisível

4. Man-in-the-Middle (MitM) Um atacante intercepta e modifica GOOSE em trânsito.

Exemplo: Muda "Trip = 1" para "Trip = 0" silenciosamente

Aqui vem o que você deve fazer para não virar vítima:

1. Segmentação de Rede (Novamente)

• VLAN dedicada para GOOSE (isolado de tudo)

• Zonas de segurança conforme IEC 62443 (perímetros de defesa)

• Separação clara entre redes OT (operação) e IT (informação)

2. Controle de Acesso (ACL)

• ACL em switches: apenas portas autorizadas podem enviar GOOSE

• IEEE 802.1X: autenticação baseada em porta (só equipamentos conhecidos podem conectar)

• Princípio do Menor Privilégio: admin tem permissão total, operador tem permissão limitada

3. Monitoramento Contínuo

• IDS/IPS específico para OT (não use IDS de IT, ele não entende GOOSE)

• Baseline de comportamento: quantos GOOSE por segundo são normais? Qual intervalo esperado?

• Alert se desviar: "Recebemos 1000 GOOSE em 5 segundos — anomalia!"

4. Hardening de IED

• Desabilitar serviços desnecessários (SSHv1, Telnet antigo, etc)

• Senhas fortes (não a padrão de fábrica "admin/admin")

• Atualizações de firmware com procedimento controlado

• Portas físicas desabilitadas se não usadas

5. Segurança Física

• Painéis e racks sempre fechados

• Controle de acesso (crachás, registro de visitantes)

• Proibição de laptops/pendrives pessoais na sala

• CFTV monitorando

6. Implementar IEC 62351 A norma IEC 62351 complementa a IEC 61850 com segurança real. Ela define:

• Assinatura Digital (HMAC): cada GOOSE é "assinado" digitalmente, garantindo origem

• Autenticação: receptor valida que é realmente do transmissor

• Integridade: detecta se GOOSE foi modificado em trânsito

• Gestão de Certificados: como distribuir e renovar chaves de assinatura

7. Políticas e Governança

• Plano de resposta a incidentes (testado regularmente)

• Alinhamento com normas: IEC 61850, IEC 62443, IEC 62351, ONS (Brasil), ANEEL

• Treinamento contínuo: todos na equipe sabem o que fazer se detectarem anomalia

• Cultura de segurança: não é "coisa de IT", é responsabilidade de todos

Aqui está o problema:

GOOSE precisa ser rápido (< 4ms) E seguro.

Mas criptografia demora. Validação de assinatura demora. Se você adiciona criptografia, latência sobe. Se sobe demais, coordenação de proteção falha.

É um trade-off brutal.

A solução? Não é fazer GOOSE super criptografado. É fazer defesa em profundidade:

• VLAN separada (barreira 1)

• ACL (barreira 2)

• Monitoramento (barreira 3)

• IED hardened (barreira 4)

• Segurança física (barreira 5)

• IEC 62351 (barreira 6)

Um atacante teria que quebrar 6 barreiras simultaneamente. Muito difícil.

Deixa eu ser claro: se você implementa GOOSE sem segurança, você está literalmente colocando um botão vermelho "ACABE COM MINHA REDE" conectado à internet.

Não é paranoia. É realidade. Ataques a infraestrutura crítica (energy, water, transportation) estão cada vez mais sofisticados.