Tempo no DNP3: timestamps, SOE e sincronização

Em DNP3, “ter hora” não é o mesmo que ter SOE confiável

Sequence of Events depende da hora registrada na origem da mudança, não apenas do relógio do servidor SCADA. Se uma outstation recebe uma entrada às 10:00:00.125 e só consegue entregá-la ao master três segundos depois, um evento com timestamp de origem pode preservar 10:00:00.125. Se o supervisório simplesmente aplicar seu horário de recepção, a sequência entre equipamentos pode ficar errada. Por isso, tempo em DNP3 deve ser tratado como parte da cadeia de medição.

A cadeia inclui fonte de referência, relógio interno da outstation, método de sincronização, precisão e drift, objeto de evento usado, transporte do timestamp, interpretação no master, timezone de apresentação e armazenamento histórico. Um erro em qualquer etapa pode aparecer como “evento atrasado” mesmo quando a comunicação está perfeita.

Formato de tempo: milissegundos desde a época UTC

O tempo absoluto DNP3 é representado em milissegundos a partir de 1970-01-01 00:00:00 UTC em um campo de 48 bits quando o objeto de tempo absoluto é usado. Essa definição é importante porque separa o valor transportado da forma como a interface humana mostra horário local. O timezone não deve ser embutido de forma improvisada no valor do protocolo.

Em projetos brasileiros, por exemplo, o SCADA pode exibir UTC-3, mas a engenharia precisa saber se a outstation e o master tratam o valor DNP3 como UTC conforme esperado e em qual ponto a conversão para horário local ocorre. Problemas de daylight saving histórico, timezone duplicado ou conversão aplicada em duas camadas podem deslocar eventos por horas sem qualquer erro de rede.

IIN Need Time: a outstation dizendo que o relógio precisa de atenção

A outstation pode indicar por IIN que necessita sincronização de tempo. Esse bit é uma pista padronizada para o master iniciar a política configurada. O simples fato de receber Need Time não prova que o relógio está “zerado”; significa que a estação solicita sincronização segundo sua implementação. O intervalo de validade, a precisão do oscilador e a fonte alternativa de tempo influenciam quando essa indicação aparece.

Se Need Time permanece ativo depois de uma tentativa de sincronização, não aumente timeout por reflexo. Verifique se o método é suportado, se o master enviou a sequência correta, se a outstation aceita DNP3 como fonte de hora e se outra fonte — NTP, IRIG-B, GNSS/PTP por meio do equipamento — tem prioridade. Alguns IEDs rejeitam sincronismo DNP3 quando uma fonte superior está ativa.

• IIN Need Time — O que é: indicação interna de necessidade de sincronismo. Efeito: pode acionar rotina de time sync do master. Validar: resposta DNP3 antes/depois da sincronização e relógio local da outstation.
• Clock valid period — O que é: período pelo qual a referência é considerada válida, quando configurável. Efeito: determina quando o equipamento volta a pedir hora. Validar: documentação e observação temporal.
• Fonte de tempo — O que é: origem efetiva do relógio do IED/RTU. Efeito: define autoridade e precisão. Validar: configuração, status do equipamento e teste de perda/retorno da fonte.

Sincronização LAN e non-LAN: por que existem dois procedimentos

Implementações DNP3 distinguem procedimentos de sincronização adequados a diferentes características de transporte. Em LAN, existe um procedimento que usa RECORD_CURRENT_TIME seguido por escrita do objeto de tempo apropriado, permitindo considerar o instante associado à recepção/transmissão. Em aplicações non-LAN, o procedimento pode usar medição de atraso antes da escrita do tempo. A escolha correta precisa ser suportada pelas duas pontas.

O objetivo não é decorar Function Codes, mas entender o problema que eles resolvem: atraso de comunicação influencia o instante em que o relógio remoto é ajustado. Em um enlace de satélite com centenas de milissegundos de RTT, ignorar atraso pode produzir erro muito maior do que em uma LAN local. Em qualquer caso, confirme o comportamento no Device Profile e na implementação usada.

Group 50, Group 51 e tempo associado a eventos

A família Group 50 está associada a objetos de tempo e data. Group 51 é usado para Common Time of Occurrence em representações que combinam um tempo comum com tempos relativos de eventos, economizando bytes quando vários eventos ocorrem próximos. O uso exato das variations deve ser confirmado na norma e no perfil do dispositivo.

Para o engenheiro de campo, a pergunta prática é: o objeto de evento recebido carrega tempo absoluto, tempo relativo vinculado a CTO ou nenhum timestamp? Um analisador de protocolo mostra essa diferença. Se o evento não transporta tempo, o master pode aplicar horário de recepção ou outra política, mas isso não deve ser confundido com timestamp de origem.

SOE: precisão precisa ser especificada como requisito

Não existe valor universal de precisão temporal adequado a todo sistema. Supervisão de processo lento, investigação de proteção e comparação entre IEDs podem exigir ordens de grandeza diferentes. O requisito precisa dizer qual erro máximo é aceitável entre o instante físico e o timestamp registrado, além de como esse erro será medido.

Se dois equipamentos possuem relógios desviados em 300 ms, a ordem de eventos separados por 100 ms pode ser invertida. Nesse caso, ter timestamps com resolução de 1 ms não significa ter precisão de 1 ms. Resolução do campo, precisão da fonte, atraso de captura interna e sincronização são conceitos diferentes.

Como testar tempo DNP3 sem confiar apenas na tela do SCADA

Antes do teste, registre a fonte de tempo de master e outstation e escolha um estímulo observável. Compare o horário local do equipamento, o timestamp dentro do evento DNP3 capturado e o timestamp finalmente gravado no SCADA. Se possível, use uma referência comum para o analisador e os equipamentos. Repita após um período de holdover ou perda proposital da fonte, quando isso for seguro.

Também teste o retorno de um equipamento após reboot. Observe IIN Need Time, a sequência de sincronização e o primeiro evento após o ajuste. O relatório deve indicar offset medido, método usado e tolerância aceita. Uma frase como “hora OK” não é evidência suficiente.