Timeout no IEC 101: separar silêncio, atraso, quadro inválido e falha de aplicação
Configure e diagnostique timeout IEC 101 considerando baud rate, tamanho do quadro, turnaround, processamento, polling, rádio, gateway e recuperação.
Leitura de um timeout IEC 101
| Evidência | Hipótese principal | Próximo teste |
|---|---|---|
| Nenhum byte | caminho ou RTU indisponível | medir em ambas as pontas |
| Resposta tardia | processamento, fila ou turnaround | linha do tempo |
| Checksum/framing | camada física ou serial | sinal e configuração |
| Endereço diferente | mapping ou duplicidade | isolar estações |
| Negativa válida | função/aplicação | ler controle e ASDU |
Classifique o que chegou antes de aumentar qualquer temporizador.
Timeout é uma conclusão do solicitante
Timeout significa que a resposta esperada não foi reconhecida dentro da janela. Não prova que a RTU ficou silenciosa. A resposta pode ter saído tarde, chegado corrompida, usado endereço diferente, sido retida por buffer ou rejeitada pelo parser. O diagnóstico precisa preservar solicitação, prazo, bytes recebidos e motivo do descarte. Logs que registram apenas “timeout” ocultam justamente a evidência necessária para separar comunicação física, enlace e aplicação.
O mínimo depende do tempo físico
A janela deve ser maior que transmissão da solicitação, turnaround, processamento e transmissão da resposta máxima, com margem para jitter do meio. Baud baixo e quadros longos elevam esse piso. Copiar timeout de Ethernet para rádio serial produz falsos positivos; usar segundos em LAN local pode retardar detecção. Calcule e meça percentis do tempo de resposta em condições representativas, depois estabeleça margem e critério de alarme.
Timeout de frame e de transação são diferentes
Equipamentos podem ter temporizador entre caracteres, espera pela resposta e prazo global de uma função. Um gap excessivo no meio do FT1.2 invalida o quadro mesmo que o último byte chegue antes do timeout global. Da mesma forma, uma GI pode envolver várias ASDUs e término próprio. Documente os temporizadores disponíveis e associe cada alarme ao estado correto. Aumentar o prazo global não corrige quebra entre bytes causada por conversor.
RTU silenciosa não pode monopolizar o ciclo
Em modo não balanceado, a primária consulta várias secundárias. Se cada tentativa aguarda um timeout longo e repete muitas vezes, uma estação indisponível aumenta a latência das saudáveis. Defina retry e política de backoff compatíveis com criticidade. Meça o ciclo com uma, várias e todas as RTUs silenciosas. O sistema deve sinalizar perda, continuar atendendo demais estações e tentar recuperar sem tempestade de solicitações.
Rádio e gateway acrescentam caudas de latência
Acesso ao canal, retransmissão de enlace, PTT, cobertura variável e filas criam tempos não constantes. Gateways serial–IP podem acumular caracteres e enfrentar retransmissão TCP. Use capturas sincronizadas nos dois lados para localizar onde o atraso aparece. Se o percentil alto cresce sob tráfego, investigue capacidade e prioridade; simplesmente alongar timeout pode evitar alarme, mas não restaurar requisito de atualização do processo.
Resposta inválida deve ter contador próprio
Checksum errado, endereço inesperado, função incoerente e frame truncado não devem ser contabilizados apenas como timeout. Esses eventos indicam causas distintas e orientam a correção. Mantenha contadores de bytes, frames válidos, CRC/checksum, framing, respostas tardias e endereços. Uma tendência de quadros inválidos aponta camada física ou configuração; silêncio absoluto aponta caminho, alimentação ou seleção; resposta negativa aponta aplicação.
A recuperação precisa evitar duplicidade
Quando a resposta se perde, repetir um serviço confirmado deve respeitar FCB/FCV e a máquina de estados para não executar duas vezes. Comandos merecem política ainda mais conservadora: timeout não significa que a atuação falhou. Consulte estado e evidências antes de reenviar. Após restart ou reset de link, confirme que ambas as pontas retomam sequência coerente, drenam eventos e não abandonam uma transação antiga como se fosse nova.
Teste controlado define o valor defensável
Meça respostas mínima, típica e máxima; introduza atraso, perda, byte corrompido e estação silenciosa. Observe ciclo, alarmes, retries e retorno. Se o canal usa rádio, repita em condição de carga e cobertura limite autorizada. Registre valor escolhido e suas premissas. Um timeout é bom quando detecta falha no prazo necessário, tolera a variabilidade saudável e permite que o restante do sistema continue operando.
Critério de engenharia e governança
O valor configurado precisa estar ligado a uma política de estado. Defina quantos timeouts consecutivos mudam a qualidade dos pontos, quando o canal é declarado indisponível, quando ocorre reset de enlace e como o alarme é encerrado. Um único timeout pode ser tolerável; vários distribuídos podem indicar degradação; silêncio prolongado exige ação. Evite que timers em cascata se contradigam: a aplicação não deve desistir antes de o gateway concluir sua tentativa, nem aguardar minutos por uma sessão que a camada inferior já encerrou. Em redundância, compare o tempo de detecção com o tempo de failover e impeça dois mestres de assumir simultaneamente. A telemetria deve registrar latência real e respostas tardias para que o ajuste possa ser revisto com dados. Depois de firmware, rádio ou mudança de rota, repita a distribuição de tempos. O timeout defensável é aquele cujo cálculo, medição, alarme e recuperação estão alinhados ao impacto operacional, e não apenas um número que elimina mensagens no log.
Referências técnicas e normas
As explicações do Portal são autorais. Normas e fontes oficiais são priorizadas; materiais acadêmicos e documentação pública de fabricantes complementam a implementação e não substituem a edição normativa aplicável ao projeto.
- IEC 60870-5-104:2006+AMD1:2016 CSV — Network access for IEC 60870-5-101 — IEC. Companion standard consolidado do IEC 104; inclui o corrigendum publicado em 2023.
- IEC 60870-5-101:2003+AMD1:2015 CSV — Basic telecontrol tasks — IEC. Companion standard consolidado do IEC 101 para telecontrole serial.
- IEC 60870-5-1:1990 — Transmission frame formats — IEC. Formatos de quadro e requisitos de integridade usados pela família IEC 60870-5.
- IEC 60870-5-2:1992 — Link transmission procedures — IEC. Procedimentos de transmissão da camada de enlace, especialmente pertinentes ao IEC 101.
- IEC 60870-5-3:1992 — General structure of application data — IEC. Regras para estruturar unidades de dados de aplicação.
- IEC 60870-5-5:1995 — Basic application functions — IEC. Funções básicas de aplicação, incluindo aquisição, comandos e sincronização.
- IEC 60870-5-6:2006 — Guidelines for conformance testing — IEC. Método para ensaios de conformidade dos companion standards IEC 60870-5.
- IEC TS 60870-5-601:2015 — Conformance test cases for IEC 101 — IEC. Casos de ensaio de conformidade para implementações IEC 101.
- IEC TS 60870-5-604:2016 — Conformance test cases for IEC 104 — IEC. Casos de ensaio positivos e negativos para implementações IEC 104.
- IEC TS 60870-5-7:2025 — Security extensions for IEC 101/104 — IEC. Extensões de segurança alinhadas à série IEC 62351 para autenticação, integridade e RBAC.
- Wireshark User’s Guide — Wireshark Foundation. Documentação oficial de captura, filtros, estatísticas e interpretação da interface do analisador.
Continue estudando
Os próximos conteúdos foram escolhidos para formar uma sequência técnica, relacionando fundamento, configuração, diagnóstico e aplicação.