IEC 61850 na prática: SCL, MMS, GOOSE, Sampled Values e PTP lado a lado

IEC 61850 não é um único protocolo

A IEC 61850 é uma série que combina modelo de informação, serviços, engenharia e diferentes mapeamentos de comunicação. Reduzir tudo a 'protocolo 61850' esconde justamente as diferenças que importam no projeto. SCL descreve configuração e engenharia; MMS atende grande parte da comunicação cliente-servidor; GOOSE distribui eventos multicast de baixa latência; Sampled Values transporta amostras; PTP fornece sincronismo de precisão.

Essas peças podem operar simultaneamente no mesmo IED e na mesma infraestrutura Ethernet. Uma falha pode afetar apenas uma delas. Por exemplo, uma ACL pode bloquear sessão MMS enquanto GOOSE em camada 2 continua funcionando; perda de PTP pode degradar sincronismo de SV sem derrubar a porta; SCL desatualizado pode fazer assinante GOOSE rejeitar um fluxo que está fisicamente presente.

• SCL: engenharia/configuração.
• MMS: cliente-servidor.
• GOOSE: eventos multicast.
• SV: amostras multicast.
• PTP: distribuição de tempo.

Station Bus e Process Bus

No Station Bus, é comum encontrar MMS entre IEDs e sistemas de supervisão, além de GOOSE para sinais entre equipamentos. No Process Bus, SV conecta Merging Units e dispositivos de processo aos relés e sistemas de medição, enquanto GOOSE também pode transportar sinais binários de processo. A fronteira não é rígida, mas ajuda a visualizar criticidade e volume de tráfego.

Redes modernas podem usar PRP ou HSR para redundância, VLAN/PCP para separação e prioridade e PTP para sincronismo. Esses mecanismos não fazem parte de uma única 'pilha linear'; eles cooperam. A engenharia precisa desenhar fluxos, multicast, caminhos redundantes e dependências temporais em vez de apenas listar protocolos habilitados.

• Mapeie cada fluxo origem→rede→destino.
• Classifique por latência, banda e criticidade.
• Documente dependência de sincronismo.

SCL como fonte de coerência

SCL liga o modelo lógico à comunicação. Control Blocks, datasets, endereços, APPIDs e associações são definidos e trocados entre ferramentas conforme o processo de engenharia. Sem governança de SCL, alterações locais em um IED criam divergência entre o que a rede faz e o que o projeto acredita que ela faz.

Em comissionamento, compare arquivo SCD com tráfego observado. Se um GOOSE usa APPID diferente, se um dataset mudou ou se um report MMS aponta para objeto inesperado, o problema pode estar no processo de engenharia e não no switch. Versionar SCL permite relacionar cada captura e teste a uma configuração concreta.

• Associe PCAP à versão SCD do teste.
• Evite edição manual não rastreada.
• Mantenha arquivos as-built após alterações.

MMS, GOOSE e SV: três comportamentos de rede

MMS depende de associação cliente-servidor e transporte confiável para serviços de supervisão e controle. GOOSE é multicast em camada 2, com retransmissões e sequência de estados. SV é multicast contínuo e pode gerar grande volume. Colocar os três em uma mesma VLAN sem cálculo de tráfego e políticas pode funcionar em laboratório e falhar durante contingência.

O diagnóstico também muda. Em MMS, siga sessão e serviços. Em GOOSE, siga stNum/sqNum, Control Block e dataset. Em SV, siga amostras, sequência e sincronismo. Uma ferramenta que apenas faz ping confirma IP, mas GOOSE e SV podem operar sem IP. Por isso ping não é teste de saúde completo de uma rede IEC 61850.

• Ping não valida GOOSE ou SV.
• Latência crítica de GOOSE ≠ banda contínua de SV.
• MMS pode falhar mesmo com camada 2 saudável.

PTP e a dimensão temporal

PTP adiciona uma infraestrutura lógica de clocks sobre a mesma rede. Grandmasters, boundary/transparent clocks e endpoints precisam compartilhar profile e domínio coerentes. Em Process Bus, a qualidade de tempo pode ser parte do requisito funcional de proteção. Portanto, alarmes de PTP devem entrar na supervisão e nos testes de redundância.

Uma arquitetura robusta trata rede e tempo como serviços críticos separados. Teste falha de link, falha de switch, falha de grandmaster e perda de GNSS. Observe quais funções permanecem operacionais e quais entram em modo degradado. O resultado deve ser documentado como comportamento esperado, não descoberto durante uma ocorrência real.

• Redundância de rede não garante redundância de tempo.
• Monitore qualidade e identidade do mestre.
• Teste modos degradados explicitamente.

Exemplo de fluxo ponta a ponta em uma função de proteção

Imagine uma Merging Unit publicando SV de corrente, um relé consumindo as amostras e emitindo GOOSE de trip para outro IED. PTP mantém a referência temporal; SCL descreve os streams, datasets e assinaturas. O SCADA recebe estado e reports do relé por MMS. Cinco tecnologias participam da mesma função, mas cada uma ocupa uma responsabilidade específica.

Se o trip não ocorre, a análise segue a cadeia: SV chega correto e sincronizado? a lógica do relé atuou? o GOOSE mudou stNum? o assinante recebeu e aceitou? MMS reportou o estado? SCL corresponde ao que foi carregado? Essa decomposição reduz drasticamente troubleshooting por tentativa.

• SV entrega processo analógico.
• GOOSE entrega evento de proteção.
• MMS leva supervisão ao sistema.
• PTP mantém tempo; SCL mantém coerência de engenharia.

Matriz mental para escolher ferramenta de diagnóstico

Para problema de engenharia, comece pelo SCL e configuração das ferramentas. Para comunicação cliente-servidor, use logs MMS e PCAP TCP. Para proteção peer-to-peer, capture GOOSE na porta correta. Para medições digitais, examine SV e sincronismo. Para problemas de fase/tempo, investigue PTP e grandmaster.

Essa matriz evita o hábito de usar ping como teste universal. Ping é útil para IP, mas não prova operação de multicast em camada 2 nem qualidade temporal. Uma subestação IEC 61850 precisa de métodos de teste tão diversos quanto os serviços que utiliza.

Na documentação final, mantenha uma matriz de dependências funcionais. Para cada proteção ou automação, indique quais streams SV, mensagens GOOSE, reports MMS, fontes PTP e arquivos SCL participam. Essa visão funcional é muito mais útil em uma ocorrência do que uma lista isolada de protocolos suportados pelos equipamentos.

• Escolha a ferramenta pelo serviço.
• Correlacione rede, configuração e processo.
• Não use um único teste como prova de saúde geral.