GOOSE vs Sampled Values: diferenças, tráfego, sincronismo e aplicação no Process Bus

Evento e fluxo contínuo não são a mesma coisa

GOOSE e Sampled Values usam Ethernet multicast no ecossistema IEC 61850, mas carregam informações de naturezas muito diferentes. GOOSE é orientado a mudanças de estado e eventos: trip, pickup, bloqueio, permissivo, posição e sinais lógicos. Sampled Values transporta amostras digitalizadas de grandezas analógicas, como corrente e tensão, em fluxo contínuo. Essa diferença muda banda, sincronismo, comportamento esperado, teste e impacto de uma falha.

Em GOOSE, o aumento temporário de tráfego ocorre quando o estado muda e a mensagem é retransmitida rapidamente, depois o intervalo cresce. Em SV, frames continuam sendo enviados na taxa prevista mesmo sem mudança no processo. Por isso, dimensionar uma rede Process Bus exige contabilizar o fluxo contínuo de cada stream SV, enquanto GOOSE exige atenção especial à latência e às rajadas de retransmissão após eventos simultâneos.

• GOOSE: estado/evento e retransmissão adaptativa.
• SV: amostras contínuas de grandezas analógicas.
• Ambos podem usar VLAN e prioridade, mas com perfis de tráfego diferentes.

Publicadores, assinantes e datasets

Um GOOSE Control Block referencia um dataset com atributos de dados publicados pelo IED. O assinante é configurado para consumir aquele fluxo e associar os membros do dataset às entradas internas de lógica. Alterações de configuração podem mudar ConfRev e precisam ser coerentes entre engenharia e IEDs. O diagnóstico deve confirmar GoCBRef, DatSet, APPID, MAC multicast, VLAN, stNum e sqNum.

Em SV, o publicador é frequentemente uma Merging Unit ou IED com função equivalente, e o assinante pode ser um relé de proteção, medidor ou dispositivo de aquisição. O stream contém amostras identificadas e ordenadas; a aplicação depende de taxa, sincronismo e associação correta das grandezas. Trocar apenas um identificador ou escala pode produzir medições plausíveis, porém erradas, o que torna comissionamento metrológico indispensável.

• Verifique identidade do stream antes de medir desempenho.
• Valide escala e associação de corrente/tensão no SV.
• Em GOOSE, valide dataset e revisão de configuração.

Sincronismo: crítico para SV, importante para a engenharia completa

GOOSE não precisa de sincronismo de fase para representar um estado lógico. O receptor precisa reconhecer sequência, validade temporal e mudança de estado. Já aplicações de SV que combinam amostras de diferentes Merging Units dependem de uma referência temporal consistente. Processos como proteção diferencial, barramento e medição sincronizada podem exigir que amostras sejam alinhadas com precisão muito maior que a necessária para SOE convencional.

Por isso PTP, especialmente o perfil de potência IEC/IEEE 61850-9-3, aparece frequentemente no mesmo projeto que SV. A rede passa a transportar simultaneamente tráfego de processo e sincronismo. Grandmaster, boundary clocks, transparent clocks e qualidade do relógio precisam ser monitorados. Uma rede pode continuar encaminhando SV perfeitamente enquanto o tempo degrada; sem alarme de qualidade temporal, a falha fica invisível até afetar a aplicação.

• Monitore estado e qualidade de PTP, não apenas link Ethernet.
• Teste perda de referência e holdover do relógio.
• Correlacione qualidade temporal com comportamento do assinante SV.

Banda, QoS e redundância

GOOSE costuma consumir pouca banda média, mas seu requisito dominante é latência e previsibilidade em evento. SV pode representar uma parcela significativa da utilização de links, especialmente com vários streams e taxas elevadas. A engenharia deve calcular tráfego por porta, não apenas por switch, considerando replicação multicast, trunks, PRP/HSR quando utilizados e caminhos de espelhamento para diagnóstico.

VLAN e PCP ajudam a separar e priorizar classes de tráfego, mas não substituem capacidade. Prioridade não cria banda; ela define quem espera quando existe contenção. Em redes críticas, teste saturação controlada, failover, perda de link e recuperação. PRP e HSR podem fornecer redundância sem tempo de reconvergência perceptível para a aplicação, mas duplicam tráfego em partes da arquitetura e exigem análise correta do comportamento dos nós.

• Calcule utilização no pior caso por enlace.
• Não use QoS para esconder sobrecarga estrutural.
• Teste redundância com streams reais de GOOSE e SV.

Como analisar no Wireshark

Para GOOSE, observe stNum mudando quando o estado do dataset muda e sqNum evoluindo nas retransmissões do mesmo estado. Verifique TimeAllowedToLive, APPID, VLAN e ConfRev. Intervalos anormais podem indicar congestionamento, perda ou configuração de retransmissão diferente. Compare sempre com a lógica do IED, pois um GOOSE recebido pode ser descartado por configuração incompatível.

Para SV, observe sequência de amostras, identificador do stream, contador de amostras, sincronismo indicado e regularidade temporal. Uma captura em porta SPAN pode perder frames por limitação do próprio espelhamento; para medir perda em Process Bus carregado, TAP ou captura dimensionada para line rate é preferível. O objetivo é separar perda real da rede de perda da ferramenta de captura.

• Use captura com timestamp de alta qualidade quando medir jitter.
• Evite SPAN sobrecarregado para afirmar perda de SV.
• Preserve PCAP e configuração SCL do mesmo teste.

Comissionamento conjunto no Process Bus

Um teste completo deve começar com baseline: medir utilização por VLAN, taxa de frames por stream, latência de GOOSE e estado do PTP. Depois aplique estímulos reais ou de simulador para verificar mudança de stNum em GOOSE e coerência das amostras SV. A seguir provoque falhas de link e de switch dentro de procedimento seguro, verificando se PRP/HSR ou outra redundância mantém os fluxos dentro dos limites do projeto.

Também vale testar erros de engenharia controlados em ambiente de laboratório: ConfRev diferente, stream SV incorreto, perda de sincronismo ou VLAN errada. O objetivo é conhecer como cada IED sinaliza a condição. Alguns geram alarmes claros; outros apenas deixam de usar os dados. Esses testes criam assinaturas de falha que ajudam muito durante troubleshooting futuro e devem entrar no relatório de comissionamento.

Como regra de aceitação, associe cada stream a um requisito mensurável: latência máxima, taxa esperada, prioridade, caminho redundante, origem do tempo e comportamento quando a qualidade degrada. Essa matriz ajuda a evitar testes genéricos de link e transforma o comissionamento em verificação direta da função elétrica.

• Registre baseline de banda e latência.
• Teste falhas de rede e de tempo separadamente.
• Documente alarmes esperados para erro de configuração.