retransmissão no GOOSE: conceito, função e onde se aplica

retransmissão: da definição ao uso real

GOOSE retransmite rapidamente após mudança de estado e aumenta gradualmente o intervalo até um heartbeat de estado estável. Isso entrega baixa latência sem exigir tráfego máximo permanente.

Para aprender retransmissão sem depender de uma tela específica de fabricante, separe função, entradas, saídas e dependências. Em GOOSE, os pontos mais próximos deste recorte são VLAN, prioridade, dataset correto. O leitor iniciante deve conseguir dizer quem produz a informação e quem a usa; o leitor experiente deve conseguir apontar o limite entre comportamento normal, exceção e implementação particular do equipamento.

O que acontece por dentro quando retransmissão entra em ação

Documente tempos mínimos/máximos suportados e verifique se a classe de desempenho da aplicação é atendida. QoS e arquitetura devem suportar rajadas simultâneas após eventos de sistema.

Implemente primeiro uma troca mínima e conhecida entre as duas pontas. Depois acrescente eventos, exceções, temporização e funções opcionais. Uma sessão estabelecida não é critério suficiente: o dado precisa manter tipo, qualidade, endereço, sequência e tempo até o destino. Durante o estudo, acompanhe subscription, VLAN, prioridade, dataset correto como uma cadeia causal. Para cada item, pergunte o que o altera, como aparece no tráfego ou no equipamento e qual seria o primeiro sintoma se estivesse incorreto.

• subscription — defina primeiro o que representa em GOOSE e qual elemento produz ou consome essa informação; depois identifique em que condição ele muda.
• VLAN — relacione o valor ou estado ao efeito sobre retransmissão; registre também qual campo permite confirmar que a interpretação está correta.
• prioridade — na configuração, verifique dependências nas duas pontas e evite copiar valor de outro projeto sem comparar topologia, versão e capacidade do equipamento.
• dataset correto — no diagnóstico, associe pelo menos um sintoma de configuração errada e uma evidência que diferencie esse sintoma de falha física ou de rede.
• timeout — no comissionamento, crie um estímulo que faça o item mudar de forma previsível e registre antes/depois, horário e resposta observada.

Mecanismo de retransmissão: campos, estados e transições que importam

O fundamento de retransmissão aparece nas transições. Acompanhe uma operação normal do início ao fim e marque quando subscription e VLAN mudam. Depois repita mentalmente o fluxo com perda de comunicação, reinício ou dado inválido. Essa comparação revela quais campos representam estado e quais apenas transportam informação.

A engenharia de retransmissão deve partir do comportamento e não da tela de configuração. Use subscription para localizar a origem, VLAN para acompanhar a transição e prioridade para confirmar o resultado. Descreva também um sintoma de valor incorreto e qual captura, contador, medição ou log diferencia essa hipótese das demais.

• Descrever a sequência normal de retransmissão
• Descrever uma exceção sem recorrer a “reiniciar e testar”
• Identificar o papel de subscription
• Identificar o papel de VLAN

retransmissão em projeto real: como decidir sem copiar configuração

Imagine uma integração nova em que retransmissão precisa funcionar entre equipamentos de fabricantes diferentes dentro de GOOSE. Comece por uma transação mínima e observável nas duas pontas. Acompanhe subscription, VLAN e prioridade, além de endereço/identidade, sequência e tempo. Depois introduza uma única exceção — perda do enlace, reinício, evento pendente ou função não suportada — e observe qual estado muda primeiro. Esse exercício mostra se a interoperabilidade existe no mecanismo ou apenas na condição ideal.

O aceite de retransmissão precisa responder quem inicia a transação, qual resposta confirma subscription, como VLAN se comporta em exceção e qual log ou captura prova prioridade. Esses critérios tornam o artigo útil tanto na configuração inicial quanto anos depois, quando outra equipe precisar comparar a ocorrência com o baseline.

• Definir uma condição normal de retransmissão e salvar a evidência associada a subscription.
• Escolher uma única variável relacionada a VLAN e prever o efeito antes de alterar.
• Repetir o mesmo teste e comparar prioridade nas mesmas medições ou campos.
• Registrar o critério que permite aceitar, rejeitar ou reverter a configuração de retransmissão.

Do “online” à prova técnica: validação de retransmissão

Meça os intervalos entre frames antes e depois de uma mudança. Faça o teste com tráfego de fundo para verificar se filas não atrasam as primeiras retransmissões.

Defina evidência antes de testar retransmissão. Para esta categoria, sinais úteis incluem endereço, campo, estado, sequência, timestamp, qualidade. O teste deve ter estado inicial conhecido, estímulo reproduzível e resultado esperado. Quando houver dois equipamentos, registre os dois lados; quando houver gateway, registre também a transformação intermediária.

• Validar subscription em condição normal
• Forçar uma condição degradada ligada a VLAN
• Confirmar recuperação sem perder estado, evento ou evidência relevante
• Salvar configuração, logs/captura e horário do teste como baseline

Quando retransmissão dá errado: separar sintoma, causa e efeito

Ausência das retransmissões iniciais aumenta risco de latência/perda; heartbeat ausente leva a timeout. Rajadas anormais podem indicar ponto oscilante ou lógica instável.

Não conclua a partir do sintoma sozinho. Para retransmissão, cruze pelo menos duas fontes de evidência e procure a primeira divergência. Se subscription, VLAN, prioridade estão corretos mas o resultado final continua errado, avance para a próxima fronteira do sistema em vez de alterar parâmetros já comprovados.

• subscription: registre um caso saudável, um caso com falha e a diferença objetiva em estado.
• VLAN: registre um caso saudável, um caso com falha e a diferença objetiva em sequência.
• prioridade: registre um caso saudável, um caso com falha e a diferença objetiva em timestamp.
• dataset correto: registre um caso saudável, um caso com falha e a diferença objetiva em qualidade.

retransmissão: dados exclusivos deste recorte (fundamentos)

Em retransmissão, GOOSE deve ser comprovado por EtherType 0x88B8, MAC multicast 01-0C-CD-01-00-00…01-0C-CD-01-01-FF, APPID, stNum, sqNum, ConfRev e TimeAllowedToLive. Quando 802.1Q é usado, registre VID e PCP até a porta do subscriber.

Nos fundamentos de retransmissão, acompanhe a transição que altera APPID e confirme como stNum reage antes, durante e depois do evento.

• APPID: 16 bits. Confirmar fluxo configurado.
• stNum: estado. Incrementa quando DataSet muda.
• sqNum: retransmissão. Cresce no mesmo estado e evidencia gaps.
• ConfRev / TAL: revisão / validade. Comparar SCL e expiração no subscriber.

retransmissão: Ethernet multicast, VLAN e prioridade do GOOSE — retransmissão / fundamentos

Nos fundamentos de retransmissão, trate ConfRev como parte de uma sequência causal: condição inicial, transição, campo alterado e reação do outro lado. GOOSE opera diretamente sobre Ethernet com EtherType 0x88B8. Endereços multicast reservados para GOOSE usam a faixa 01-0C-CD-01-00-00 a 01-0C-CD-01-01-FF. Quando 802.1Q é usado, VID e PCP precisam ser coerentes com o projeto; PCP ocupa 3 bits no tag VLAN e deve ser tratado em conjunto com filas/QoS dos switches. O critério de encerramento para retransmissão em fundamentos é obter o mesmo resultado em novo teste de ConfRev, mantendo o ponto de medição e a condição inicial.

O mecanismo de retransmissão deve ser lido a partir de stNum; observe qual estado antecede a mudança e qual confirmação prova que ela terminou. No diagnóstico de retransmissão, verifique MAC destino, VLAN ID, PCP, APPID e entrega na porta do subscriber. “Frame visto no trunk” não prova que ele chegou ao IED. Use port mirroring/contadores multicast e, quando possível, captura no ponto mais próximo do assinante. Para este artigo de retransmissão, a evidência ligada a stNum deve ser armazenada com horário, origem e condição de teste, permitindo comparação posterior.

• retransmissão · fundamentos · ConfRev: Filtro: eth.type == 0x88b8.
• retransmissão · fundamentos · TAL: Confirmar MAC multicast GOOSE, VID/PCP e APPID conforme SCL/projeto.
• retransmissão · fundamentos · TimeAllowedToLive: Validar flooding/filtragem multicast e membership quando o switch implementar mecanismos adicionais.
• retransmissão · fundamentos · stNum: Correlacionar perda de GOOSE com counters, congestionamento e filas de prioridade.

retransmissão: estado GOOSE comprovado pelos campos do frame — retransmissão / fundamentos

O mecanismo de retransmissão deve ser lido a partir de heartbeat; observe qual estado antecede a mudança e qual confirmação prova que ela terminou. Nos artigos de estado GOOSE, o quadro precisa ser lido campo a campo. EtherType 0x88B8 identifica GOOSE; APPID identifica o fluxo; stNum muda quando o estado do DataSet muda; sqNum avança nas retransmissões do mesmo estado; ConfRev permite verificar se publisher e subscriber usam a mesma revisão de engenharia; TimeAllowedToLive informa a validade temporal anunciada pelo publisher. Se heartbeat não reproduzir o comportamento esperado em retransmissão, a hipótese deve ser revista antes de alterar outra camada do sistema.

Para explicar por que retransmissão funciona, use Needs Commissioning como ponto de partida e siga a mudança até o efeito mensurável no protocolo ou processo. Para retransmissão, provoque uma mudança conhecida no DataSet e salve uma captura que contenha pelo menos o frame anterior, o primeiro frame após a transição e algumas retransmissões. O padrão esperado é stNum incrementar no novo estado e sqNum reiniciar a sequência e voltar a crescer. Se ConfRev não corresponde ao arquivo SCL implantado, Ethernet, VLAN e multicast podem estar perfeitos e mesmo assim a aplicação rejeitar o fluxo. O critério de encerramento para retransmissão em fundamentos é obter o mesmo resultado em novo teste de Needs Commissioning, mantendo o ponto de medição e a condição inicial.

• retransmissão · fundamentos · retransmissão: Filtro Wireshark: eth.type == 0x88b8; registrar MAC destino, APPID, stNum, sqNum, ConfRev e TimeAllowedToLive.
• retransmissão · fundamentos · fast retransmission: Comparar ConfRev capturado com a revisão no SCD/CID realmente carregado.
• retransmissão · fundamentos · heartbeat: Medir o intervalo das retransmissões rápidas e o heartbeat em regime.
• retransmissão · fundamentos · Test: Na perda de publisher, medir o tempo até TimeAllowedToLive expirar no subscriber.