DNP3 Unsolicited do zero: habilitação, classes, confirmações, retries e recuperação

O que unsolicited muda no modelo de comunicação

Sem unsolicited, o master descobre eventos principalmente perguntando por eles. Com Unsolicited Response habilitado, a outstation pode iniciar o envio de eventos das classes configuradas. Isso reduz a latência de notificação, mas cria responsabilidades: a outstation precisa decidir quando agrupar e transmitir, o master precisa aceitar e confirmar quando requerido, e ambos precisam recuperar corretamente após perda de comunicação.

Unsolicited não elimina Class 0 ou a necessidade de política de integridade. O objetivo não é substituir todo polling, mas permitir entrega orientada a evento. Uma engenharia madura define quais classes podem gerar unsolicited, quais pontos pertencem a cada classe e o que ocorre quando o canal fica indisponível.

Enable/Disable, classes, confirmação e retry

O master pode usar ENABLE_UNSOLICITED e DISABLE_UNSOLICITED para controlar o comportamento da outstation conforme sua capacidade. A configuração precisa casar com as classes 1, 2 e 3 usadas pelos pontos. Depois do enable, gere um único evento conhecido e verifique a Unsolicited Response, sua sequência e a confirmação correspondente.

Timeout de confirmação e número de retries devem ser dimensionados com a latência do enlace. Em rádio, satélite ou rede congestionada, valores agressivos geram retransmissões desnecessárias; valores excessivos retardam recuperação. Meça RTT e comportamento real antes de ajustar. Se há dois masters, documente qual deles habilita, confirma e assume unsolicited durante failover.

Event buffer, deadband e agrupamento

O buffer precisa suportar a taxa de eventos durante a maior indisponibilidade plausível, não apenas o tráfego médio. Analógicos com deadband pequena podem gerar churn e consumir fila rapidamente. Pontos digitais oscilantes também podem produzir tempestades. Ajustar deadband é parte de engenharia de processo: grande demais esconde mudança útil; pequena demais cria ruído operacional e carga.

Alguns equipamentos oferecem atraso mínimo/máximo ou agrupamento antes de transmitir unsolicited. O objetivo é equilibrar latência com eficiência. Para proteção ou estado crítico, a tolerância pode ser curta; para variáveis menos urgentes, pequeno agrupamento reduz overhead. Documente a intenção em vez de copiar um default.

Teste de recuperação que realmente prova a implementação

Habilite unsolicited, gere eventos e depois interrompa o canal por um período controlado. Durante a falha, provoque mudanças suficientes para usar a fila sem excedê-la. Ao retornar, confirme ordem, timestamp, duplicatas, confirmações e limpeza da fila. Repita próximo ao limite para conhecer o comportamento de overflow.

Se os eventos só aparecem depois de um poll, verifique se o enable foi aceito, se a classe está correta e se a outstation está configurada para iniciar unsolicited. Se a mesma mensagem repete, procure confirmação ausente. Se o SCADA mostra valor atual correto mas faltam transições, investigue event buffer/overflow antes de culpar qualidade do link.

Reconexão, duplicidade e perda: o cenário que separa configuração boa de configuração frágil

O teste decisivo de unsolicited acontece quando a comunicação deixa de ser perfeita. Gere eventos conhecidos, interrompa o caminho antes da confirmação e observe o que a outstation preserva. Depois restabeleça o enlace e acompanhe se há retransmissão, confirmação, entrega dos eventos pendentes e eventual execução da política de integridade. O objetivo é distinguir duplicidade aceitável e detectável de perda silenciosa. O SCADA precisa ser capaz de reconciliar o estado atual com a sequência de eventos sem transformar uma reconexão em tempestade de alarmes.

Em arquiteturas com master primário e secundário, documente quem habilita unsolicited e como a outstation trata sessões simultâneas ou a troca de controlador. Um failover mal projetado pode deixar unsolicited desabilitado, produzir confirmações pela sessão errada ou manter eventos na fila até o próximo poll. Para dimensionar retries e timeouts, use a latência medida no pior caminho operacional, incluindo rádio, LTE, satélite ou VPN. Para dimensionar buffer, use taxa de eventos de contingência multiplicada pelo maior período plausível de indisponibilidade, acrescentando margem e considerando deadband dos analógicos.

• Testar perda antes da confirmação e confirmar a política de retry.
• Testar reconexão com eventos pendentes e comparar SOE com a origem.
• Testar failover de master sem assumir que enable/confirm será preservado.
• Verificar overflow e alarmes do buffer durante uma rajada controlada.
• Comparar tráfego com e sem agrupamento/deadband para justificar os valores.

Agrupamento, confirmação e carga: como ajustar para o enlace real

Unsolicited não significa necessariamente “um pacote para cada mudança”. Implementações podem agrupar eventos por classe, quantidade ou janela temporal para reduzir overhead. Em enlace rápido, uma janela muito longa aumenta desnecessariamente a latência percebida; em rádio ou satélite, enviar cada pequena alteração separadamente pode consumir canal e aumentar colisões, filas ou custo. O ajuste precisa considerar a taxa de eventos durante contingência, não apenas a média de um dia normal. Analógicos sem deadband adequado podem dominar o fluxo e mascarar o benefício do mecanismo.

A confirmação também precisa ser observada como uma sequência, e não como checkbox. Identifique o unsolicited transmitido, seu número de sequência, a confirmação esperada e o comportamento se ela não chega. Meça quantas retransmissões ocorrem e em qual intervalo. Depois repita com o pior RTT operacional. Se o master demora mais que o timeout configurado, a outstation pode retransmitir mensagens válidas e aumentar ainda mais a carga. Esse ciclo explica por que simplesmente “aumentar retries” pode piorar um enlace já congestionado.