IEC 104 t0, t1, t2, t3, k e w: como dimensionar e diagnosticar a sessão

Primeiro entenda I, S e U antes dos timers

IEC 104 usa TCP, mas adiciona controle próprio no APCI. I-frames carregam ASDUs e usam N(S)/N(R); S-frames confirmam recebimento sem ASDU; U-frames controlam STARTDT, STOPDT e TESTFR. Os temporizadores e janelas existem para impedir que uma sessão fique indefinidamente em estado incompleto e para limitar quantos I-frames podem permanecer sem confirmação.

Quando alguém aumenta todos os timers para “parar timeout”, perde justamente a capacidade de detectar problema. O objetivo é escolher valores compatíveis com latência e carga reais, mantendo detecção de falha dentro do requisito operacional.

t0, t1, t2 e t3 em linguagem operacional

t0 está associado ao estabelecimento da conexão. t1 limita espera por confirmação de uma APDU enviada; por isso precisa ser maior que atrasos normais do caminho e processamento, mas não tão grande que uma sessão quebrada demore a ser detectada. t2 controla quanto uma estação pode adiar uma confirmação quando recebeu I-frames e ainda não atingiu o limiar de janela. t3 é usado para supervisão em períodos de inatividade, tipicamente provocando TESTFR.

A relação entre t1 e t2 é importante: a confirmação do receptor precisa ocorrer antes que o transmissor conclua que houve falha. Em links de alta latência ou congestionados, meça distribuição de RTT; em LAN rápida, timers enormes podem esconder travamentos por minutos.

k e w: janelas que limitam mensagens não confirmadas

k limita quantos I-frames um transmissor pode manter sem confirmação. w define um limiar de I-frames recebidos que leva o receptor a enviar confirmação. Eles participam do controle de fluxo acima do TCP e precisam ser coerentes com buffers, carga e implementação das duas pontas.

Durante diagnóstico, acompanhe N(S) e N(R). Se N(S) avança e N(R) não acompanha, localize o ponto em que as confirmações deixam de evoluir. Se o problema aparece apenas em rajadas, suspeite de janela, processamento, filas ou rede antes de aumentar k indefinidamente.

Comissionamento dos timers e janelas

Faça baseline sem carga e sob rajada controlada de eventos. Registre RTT TCP, intervalo entre I-frames, S-frames, TESTFR e qualquer reconexão. Depois simule perda temporária e confirme quanto tempo o sistema leva para declarar falha e recuperar STARTDT. O resultado precisa atender à filosofia de supervisão.

Documente os valores nas duas pontas e a justificativa. Quando fabricantes usam nomes diferentes na interface, mapeie o nome comercial para t0/t1/t2/t3/k/w no documento de engenharia. Isso reduz erros em futuras substituições e upgrades.

Como dimensionar sem copiar defaults: use latência, janela e comportamento observado

Os temporizadores e janelas precisam formar um conjunto coerente. Comece medindo o round-trip em condição normal e degradada, depois observe quanto tempo a aplicação e a rede podem legitimamente levar para reconhecer uma APDU. t1 precisa permitir a confirmação dentro do pior cenário esperado sem esconder uma sessão realmente travada. t2 deve possibilitar confirmação atrasada antes de atingir t1; t3 supervisiona o período ocioso e se relaciona ao uso de TESTFR. t0 atua no estabelecimento da conexão. Os valores exatos devem seguir o perfil aplicável e a documentação das duas pontas, mas a justificativa de engenharia deve estar ligada às medições do caminho.

As janelas k e w controlam quantas APDUs I podem ficar sem confirmação e quando o receptor deve reconhecer tráfego acumulado. Se k é grande demais para a capacidade de buffers e w/t2 são incompatíveis, uma rajada pode aumentar fila e tempo de recuperação. Se os limites são excessivamente pequenos em um caminho com latência variável, a sessão pode produzir confirmações/reconexões desnecessárias. No comissionamento, gere uma sequência contínua de eventos, acompanhe N(S) e N(R), meça quando aparecem S-frames e compare com k, w e temporizadores configurados nas duas pontas.

• Medir RTT normal e degradado antes de justificar t1/t2.
• Confirmar que t2 permanece coerente com t1 e a política de ACK.
• Observar TESTFR e o comportamento associado a t3 durante ociosidade.
• Gerar rajada e acompanhar N(S), N(R), I-frames e S-frames em relação a k/w.
• Testar perda temporária para distinguir timeout de aplicação de retransmissão TCP.

Leitura da captura: diferenciar timeout IEC 104 de comportamento TCP

Quando a sessão cai, não conclua que t1 ou t3 estão incorretos olhando apenas a mensagem do SCADA. No PCAP, separe primeiro o estado TCP: SYN/SYN-ACK, retransmissões, RST, zero window e perda de segmento pertencem ao transporte. Depois acompanhe APDUs IEC 104, números N(S)/N(R), S-frames, STARTDT/STOPDT/TESTFR e os intervalos entre eles. Um atraso causado por retransmissão TCP pode empurrar a aplicação para um timeout; aumentar t1 pode esconder o sintoma sem remover a perda da rede.

Para validar k e w, crie uma rajada reproduzível de ASDUs e acompanhe quantos I-frames ficam pendentes antes do reconhecimento. Marque o momento em que surge S-frame e compare a configuração das duas pontas. Se uma implementação possui limites diferentes, a janela efetiva pode ser determinada pelo comportamento mais restritivo. Registre também CPU/fila do front-end e do RTU/gateway, porque o receptor pode atrasar ACK de aplicação mesmo quando a rede entrega os segmentos rapidamente. Esse cruzamento impede que toda lentidão seja tratada como “problema de link”.