fast retransmission no GOOSE: parâmetros, ajustes e impactos

Mapa técnico de fast retransmission: quem produz, quem consome e o que pode falhar

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.

No desenho de GOOSE, localize fast retransmission entre origem e destino e marque quais elementos dependem de perda de mensagens, fast retransmission, Ethernet multicast. A definição deve permitir responder quem produz a informação, quem toma a decisão, onde o estado é mantido e qual evidência aparece primeiro quando algo sai do esperado.

A cadeia causal de fast retransmission: o que muda e onde observar

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.

Comece com uma troca mínima conhecida e depois acrescente eventos, exceções, temporização e funções opcionais. Uma sessão estabelecida não é critério suficiente: tipo, endereço, qualidade, sequência e tempo precisam chegar ao destino com a mesma semântica. Neste artigo, acompanhe timeout, perda de mensagens, fast retransmission, Ethernet multicast como uma cadeia causal: condição de entrada → estado interno → decisão → saída → evidência. Esse percurso evita repetir definições e obriga cada bloco do texto a acrescentar um nível novo de explicação.

Parâmetros e campos de fast retransmission: significado, efeito e validação

Os itens abaixo não são apenas nomes de configuração. Para cada parâmetro ou campo, o artigo registra o que ele representa, o efeito prático de um valor/estado incorreto e a evidência usada para confirmar a interpretação. Valores default e faixas exatas que dependem de fabricante ou firmware devem ser confirmados na documentação do equipamento, mas a relação causa → efeito precisa permanecer válida entre implementações.

Ao alterar fast retransmission, mude uma variável por vez e preserve o baseline. Um valor só deve ser considerado adequado quando o efeito esperado aparece na captura, no contador, no log ou no processo e quando a condição degradada continua dentro do requisito.

• subscription — O que é: elemento de engenharia relacionado a fast retransmission dentro de GOOSE; deve ser identificado pela representação real usada no equipamento/protocolo. Efeito: Seu valor ou estado altera a interação com fast retransmission; documente dependências e limite em vez de copiar um valor de outro projeto. Validar: comparar condição normal e uma alteração controlada usando endereço como evidência objetiva.
• VLAN — O que é: identificador 802.1Q do domínio lógico de camada 2; em operação são normalmente usados VIDs de 1 a 4094. Efeito: VID incorreto coloca o frame em outro domínio, fazendo MAC, multicast e gateway parecerem “ausentes”. Validar: capturar tag 802.1Q, conferir PVID/tagging nas portas e tabela MAC da VLAN correta.
• prioridade — O que é: critério e posição usados pelo equipamento para selecionar a política aplicável; muitos produtos usam lógica de primeira regra compatível, mas o comportamento deve ser confirmado no fabricante. Efeito: Regra mais ampla acima de outra específica pode capturar o fluxo e tornar a regra esperada aparentemente “sem efeito”. Validar: verificar rule-id/policy-id no log, hit counter e ordem efetiva após publicação da configuração.
• dataset correto — O que é: elemento de engenharia relacionado a fast retransmission dentro de GOOSE; deve ser identificado pela representação real usada no equipamento/protocolo. Efeito: Seu valor ou estado altera a interação com fast retransmission; documente dependências e limite em vez de copiar um valor de outro projeto. Validar: comparar condição normal e uma alteração controlada usando sequência como evidência objetiva.
• timeout — O que é: temporização que encerra espera, estado ou sessão quando a condição esperada não ocorre dentro do período configurado. Efeito: Valor curto pode derrubar sessões legítimas; valor longo pode manter estado obsoleto e consumir tabela. O número correto depende de RTT, aplicação e política operacional. Validar: medir deltas reais na captura/log, reproduzir ociosidade controlada e observar exatamente quando ocorre expiração/reconexão.
• perda de mensagens — O que é: temporização que encerra espera, estado ou sessão quando a condição esperada não ocorre dentro do período configurado. Efeito: Valor curto pode derrubar sessões legítimas; valor longo pode manter estado obsoleto e consumir tabela. O número correto depende de RTT, aplicação e política operacional. Validar: medir deltas reais na captura/log, reproduzir ociosidade controlada e observar exatamente quando ocorre expiração/reconexão.

Da bancada à operação: um cenário para aplicar fast retransmission

Para implementar fast retransmission em GOOSE, escolha uma função pequena que possa ser repetida sem ambiguidade. Prove primeiro timeout; depois acrescente perda de mensagens; por último force uma condição relacionada a fast retransmission. Em cada etapa registre a mensagem esperada, o estado local e a reação da outra ponta. A sequência incremental reduz drasticamente tentativa e erro em projetos multivendor.

A decisão de engenharia para fast retransmission deve terminar em critérios mensuráveis. Use timeout como primeira evidência de sucesso e perda de mensagens como verificação de consistência; declare quanto tempo pode decorrer e o que deve sobreviver à reconexão. Se a interface do fabricante usa outro nome para fast retransmission, mantenha uma tabela que ligue o rótulo comercial ao conceito do protocolo.

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

Como escolher valores sem copiar configuração de outro projeto

Um parâmetro de fast retransmission só está explicado quando se conhece unidade ou representação, faixa suportada, default quando existir, dependências e consequência observável. Para timeout, perda de mensagens, fast retransmission, compare valor atual, valor pretendido e efeito medido antes/depois.

Em GOOSE, ajustes interagem. Timeout depende de latência e retries; buffers dependem da taxa de eventos e da duração da indisponibilidade; prioridades dependem da rede; políticas de segurança dependem do fluxo real. A escolha precisa ser justificável pelo requisito e pelo teste.

• fast retransmission — timeout: registrar valor, unidade/representação, dependência, efeito e evidência
• fast retransmission — perda de mensagens: registrar valor, unidade/representação, dependência, efeito e evidência
• fast retransmission — fast retransmission: registrar valor, unidade/representação, dependência, efeito e evidência
• fast retransmission — Ethernet multicast: registrar valor, unidade/representação, dependência, efeito e evidência

Critérios objetivos para aceitar fast retransmission em campo

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 a evidência antes do teste de fast retransmission. Para esta categoria, sinais úteis incluem endereço, campo, estado, sequência, timestamp, qualidade. Use estado inicial conhecido, estímulo reproduzível e resultado esperado; quando houver duas pontas, registre as duas, e quando houver gateway/firewall/conversor, registre também a transformação intermediária.

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

Caso bom x caso ruim: isolando a causa em fast retransmission

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 fast retransmission, cruze pelo menos duas fontes de evidência e procure a primeira divergência. Se timeout, perda de mensagens, fast retransmission estão corretos mas o resultado final continua errado, avance para a próxima fronteira do sistema em vez de alterar novamente um parâmetro já comprovado.

• timeout: registre um caso saudável, um caso com falha e a diferença objetiva em estado.
• perda de mensagens: registre um caso saudável, um caso com falha e a diferença objetiva em sequência.
• fast retransmission: registre um caso saudável, um caso com falha e a diferença objetiva em timestamp.
• Ethernet multicast: registre um caso saudável, um caso com falha e a diferença objetiva em qualidade.

fast retransmission: dados exclusivos deste recorte (parâmetros)

Em fast retransmission, 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.

Na lente de parâmetros, fast retransmission só está explicado quando APPID tem unidade/faixa e stNum tem efeito mensurável na captura, log ou processo.

• 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.

fast retransmission: Ethernet multicast, VLAN e prioridade do GOOSE — fast retransmission / parâmetros

Na análise de parâmetros de fast retransmission, VLAN ID precisa ter valor/faixa, unidade ou representação e consequência observável quando sai do esperado. 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 fast retransmission em parâmetros é obter o mesmo resultado em novo teste de VLAN ID, mantendo o ponto de medição e a condição inicial.

Para fast retransmission, não trate Dataset como rótulo: registre o valor efetivo, a origem da configuração e o efeito de uma alteração controlada. No diagnóstico de fast retransmission, 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 fast retransmission, a evidência ligada a Dataset deve ser armazenada com horário, origem e condição de teste, permitindo comparação posterior.

• fast retransmission · parâmetros · VLAN ID: Filtro: eth.type == 0x88b8.
• fast retransmission · parâmetros · VLAN Priority: Confirmar MAC multicast GOOSE, VID/PCP e APPID conforme SCL/projeto.
• fast retransmission · parâmetros · PCP: Validar flooding/filtragem multicast e membership quando o switch implementar mecanismos adicionais.
• fast retransmission · parâmetros · Dataset: Correlacionar perda de GOOSE com counters, congestionamento e filas de prioridade.

fast retransmission: estado GOOSE comprovado pelos campos do frame — fast retransmission / parâmetros

Para fast retransmission, não trate ConfRev como rótulo: registre o valor efetivo, a origem da configuração e o efeito de uma alteração controlada. 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 ConfRev não reproduzir o comportamento esperado em fast retransmission, a hipótese deve ser revista antes de alterar outra camada do sistema.

O parâmetro stNum só é útil neste recorte de fast retransmission quando pode ser comparado entre baseline, condição degradada e recuperação. Para fast retransmission, 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 fast retransmission em parâmetros é obter o mesmo resultado em novo teste de stNum, mantendo o ponto de medição e a condição inicial.

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