Eventos, deadband, buffers e overflow no DNP3

Valor atual e histórico de mudanças são problemas diferentes

DNP3 separa muito bem o estado atual do processo e as mudanças que ocorreram ao longo do tempo. Um valor estático informa a condição presente. Um evento registra uma mudança que a outstation decidiu preservar para entrega ao master. Essa diferença é central quando a comunicação fica indisponível: ao retornar, o estado atual pode parecer normal, mas os eventos contam o que aconteceu durante a interrupção.

Para digitais, cada transição relevante pode gerar evento conforme a configuração. Para analógicos, gerar evento a cada pequena flutuação seria impraticável. É nesse ponto que a deadband entra. Ela reduz eventos de pequenas variações, mas precisa ser escolhida com base no processo e no uso da medida. Uma deadband mal ajustada pode tanto inundar o buffer quanto esconder mudanças importantes.

Deadband: limiar de geração de evento, não filtro cosmético do SCADA

A deadband é normalmente aplicada na origem da geração do evento analógico. Quando a mudança em relação ao valor de referência ultrapassa o critério configurado, a outstation pode criar um novo evento. O detalhe exato — referência usada, unidade, valor absoluto ou percentual e tratamento após geração — depende da implementação e deve ser confirmado no Device Profile e manual do equipamento.

Isso é diferente de um filtro visual no supervisório. Se a outstation não cria o evento, o master não pode reconstruí-lo depois. Por isso, alterar deadband exige conhecimento da variável de processo: faixa nominal, resolução do sensor, ruído esperado, taxa de mudança significativa e necessidade histórica. Em corrente de carga, tensão, temperatura ou pressão, os critérios podem ser completamente diferentes.

• Valor da deadband — O que é: limiar usado para decidir quando uma mudança analógica deve gerar evento. Efeito: controla sensibilidade e taxa de eventos. Validar: varrer o valor em passos conhecidos e observar o ponto exato de geração.
• Unidade da deadband — O que é: forma de interpretação do limiar, dependente da implementação. Efeito: evita tratar “1” como 1 V quando o equipamento usa contagens ou outra escala. Validar: manual/Device Profile e ensaio.
• Valor de referência — O que é: base contra a qual a mudança é comparada. Efeito: altera quando o próximo evento ocorre. Validar: sequência de valores controlada e captura dos eventos.
• Classe do evento — O que é: Class 1/2/3 onde o evento será armazenado. Efeito: define a estratégia de entrega. Validar: poll/unsolicited e captura.
• Timestamp — O que é: hora associada ao evento quando a variation usada a transporta. Efeito: permite SOE. Validar: comparar relógio da outstation, evento e SCADA.

Event buffer: dimensionar para a pior indisponibilidade plausível

O buffer de eventos armazena mudanças ainda não entregues ou confirmadas. Seu dimensionamento deve considerar taxa de eventos e duração máxima de indisponibilidade que o sistema pretende suportar sem perder histórico. Usar somente a média diária é perigoso: uma tempestade, oscilação de contato, defeito intermitente ou distúrbio elétrico pode produzir uma rajada muito acima da média exatamente quando a comunicação está degradada.

Se a outstation possui limites por tipo de ponto ou por classe, isso também precisa entrar no cálculo. Um equipamento pode ter milhares de pontos estáticos e apenas algumas dezenas ou centenas de posições de evento em determinada categoria. O Device Profile e a documentação do fabricante devem informar capacidades. Quando essa informação não estiver clara, o comissionamento precisa incluir um teste controlado.

Overflow: o valor atual pode estar certo e o histórico já estar perdido

Event buffer overflow significa que a capacidade de retenção foi excedida. A consequência mais importante é a perda potencial da sequência completa de eventos. Um operador pode olhar a tela após a reconexão e ver todos os estados atuais corretos, enquanto transições intermediárias desapareceram. Em investigação de atuação, isso pode alterar a conclusão sobre a ordem dos fatos.

A resposta ao overflow não deve ser apenas aumentar o buffer. Primeiro identifique a causa: deadband pequena, chatter de entradas, polling insuficiente, unsolicited mal confirmado, canal indisponível por tempo maior que o previsto ou dimensionamento inadequado. Corrigir o sintoma sem medir a taxa de eventos pode apenas adiar a próxima perda.

Chatter digital: a tempestade de eventos que parece problema de protocolo

Uma entrada digital instável pode alternar rapidamente e consumir o buffer. O DNP3 está apenas registrando o que a lógica de entrada informa. Antes de culpar o protocolo, verifique bounce de contato, alimentação, aterramento, lógica de debounce, estado intermediário do equipamento primário e qualidade do sinal. Em relés e RTUs, filtros de entrada ou temporizações podem existir, mas devem ser usados de acordo com a função de proteção/controle.

A captura ajuda a provar a taxa de eventos, mas a causa pode estar fora da comunicação. Correlacione timestamps DNP3 com logs locais e, quando aplicável, oscilografia. Uma sequência de dezenas de eventos do mesmo ponto em poucos segundos é uma pista de processo ou entrada, não automaticamente de rede.

Como calcular uma margem de buffer útil

Uma estimativa simples começa com taxa máxima de eventos por segundo durante um cenário de estresse multiplicada pelo tempo máximo de indisponibilidade. Depois aplique margem para rajadas e crescimento futuro. Se 50 eventos/s podem ocorrer por 120 s, já existem 6.000 eventos potenciais antes da margem. Esse número deve ser confrontado com a capacidade real da outstation, não presumido.

Quando o equipamento não comporta o cenário, a engenharia pode reduzir a taxa na origem, distribuir classes, ajustar deadband, melhorar disponibilidade do canal ou aceitar explicitamente uma janela de perda. O importante é tornar a limitação conhecida e testada.

Ensaio controlado para provar retenção e recuperação

Em bancada ou janela autorizada, registre o número inicial de eventos, interrompa a comunicação e produza uma sequência conhecida de mudanças. Anote a ordem e os horários. Restabeleça o canal e observe a coleta. Compare quantidade, ordem, timestamps e IIN. Se o sistema usa unsolicited, verifique também as confirmações e o comportamento de reenvio.

Repita o teste aumentando gradualmente a quantidade até perto do limite documentado, sem ultrapassar limites operacionais em produção. O objetivo é saber quanto histórico o sistema realmente preserva e como sinaliza aproximação ou ocorrência de overflow. Essa informação deve entrar no relatório de comissionamento.