Unsolicited Response no DNP3: confirmação e retries
Entenda Unsolicited Response no DNP3: ENABLE/DISABLE_UNSOLICITED, classes, sequência, confirmação, timeout, retries, event buffer, reconexão e testes em Wireshark.
Sequência lógica de uma Unsolicited Response confirmada
| Etapa | Emissor | Evidência esperada |
|---|---|---|
| 1. Habilitação | Master | ENABLE_UNSOLICITED para classes previstas |
| 2. Mudança | Processo/outstation | evento criado e armazenado |
| 3. Envio | Outstation | Unsolicited Response com evento e sequência |
| 4. Recepção | Master | evento aceito/mapeado |
| 5. Confirmação | Master | CONFIRM DNP3 quando requerido |
| 6. Liberação | Outstation | evento deixa de permanecer pendente conforme implementação |
Sintomas e causas em unsolicited
| Sintoma | Hipóteses | Primeira evidência |
|---|---|---|
| Eventos só chegam no poll | unsolicited não habilitado ou classe fora da seleção | ENABLE_UNSOLICITED e classe do ponto |
| Mesmo evento se repete | confirm ausente/tardio | sequência e CONFIRM no PCAP |
| Tráfego excessivo | deadband pequena, chatter, agrupamento inadequado | eventos por índice e tempo |
| Após reboot não há unsolicited | master não reabilitou serviço | sequência pós-restart |
| Após failover eventos somem | sessão reserva sem política correta | qual master habilita/confirm |
| Overflow durante indisponibilidade | buffer menor que taxa×tempo offline | IIN/log e capacidade do Device Profile |
O que muda quando a outstation pode iniciar a entrega
No polling tradicional, o master pergunta e a outstation responde. Com Unsolicited Response habilitado, a outstation pode iniciar a transmissão de eventos das classes autorizadas sem esperar pelo próximo poll. Isso reduz a latência entre a mudança de processo e a chegada ao SCADA, mas também muda a responsabilidade de recuperação: a outstation precisa manter eventos, controlar sequência, aguardar confirmações quando exigidas e decidir quando retransmitir.
Unsolicited não elimina integrity poll, Class 0 nem a necessidade de coletar eventos pendentes após falhas. Ele é um mecanismo adicional de entrega. Um projeto robusto define o que acontece na inicialização, depois de restart, após perda de sessão, durante failover de master e quando a confirmação não chega.
ENABLE_UNSOLICITED e DISABLE_UNSOLICITED: quem habilita o quê
A IEEE 1815 define funções de aplicação para habilitar e desabilitar unsolicited. O master pode selecionar classes de evento e solicitar que a outstation passe a enviar mudanças espontaneamente. Em muitas arquiteturas, o master desabilita unsolicited durante a sequência de inicialização, realiza integridade/coleta necessária e depois habilita as classes desejadas. O comportamento exato deve ser comparado com o Device Profile e a estratégia do fabricante.
Em uma instalação com master principal e reserva, é essencial saber qual sessão tem autoridade para habilitar unsolicited e qual receberá os eventos. Caso contrário, uma troca de master pode deixar eventos sendo enviados para a sessão antiga ou produzir duas políticas concorrentes.
- ENABLE_UNSOLICITED — O que é: Function Code para autorizar unsolicited nas classes selecionadas. Efeito: permite que a outstation inicie respostas de evento. Validar: request do master, response e primeiro evento espontâneo.
- DISABLE_UNSOLICITED — O que é: Function Code para desabilitar o mecanismo nas classes solicitadas. Efeito: a outstation volta a depender da política de coleta do master para esses eventos. Validar: request/response e ausência controlada de unsolicited após evento de teste.
- Classes habilitadas — O que é: seleção de Class 1/2/3 para unsolicited. Efeito: define quais eventos podem disparar envio. Validar: gerar um evento conhecido de cada classe.
- Sessão autorizada — O que é: master que controla/recebe unsolicited em arquitetura multi-master. Efeito: evita duplicidade ou perda no failover. Validar: teste de troca de master.
Confirmação: por que a outstation precisa saber que o evento foi aceito
Uma Unsolicited Response que requer confirmação não deve ser considerada encerrada apenas porque os bytes saíram da outstation. O master recebe a mensagem e envia a confirmação DNP3 correspondente. Até essa evidência, a outstation precisa manter estado suficiente para decidir sobre retransmissão. A confirmação de aplicação é diferente de ACK TCP: o TCP confirma entrega do fluxo de bytes, enquanto a confirmação DNP3 reconhece a mensagem no contexto do protocolo.
Esse ponto é especialmente importante em troubleshooting. Uma captura pode mostrar TCP sem perda e, ainda assim, repetidas Unsolicited Responses porque o master não confirma corretamente a sequência DNP3. O problema está acima do transporte.
Timeout e retry: dimensionar com RTT real e não por superstição
O timeout de confirmação precisa ser maior que o tempo plausível entre o envio da Unsolicited Response e o retorno da confirmação, incluindo latência, filas e processamento. Em LAN, isso pode ser muito pequeno; em rádio, rede celular ou satélite, o RTT pode variar bastante. Se o timeout é menor que o comportamento normal do canal, a outstation retransmite mensagens que o master ainda estava processando.
O número e intervalo de retries também são parâmetros de disponibilidade, não apenas de “persistência”. Muitos retries em um canal congestionado podem piorar a situação. Poucos retries podem atrasar a entrega até o próximo mecanismo de recuperação. A configuração deve ser testada com atraso e perda controlados quando possível.
- Confirm timeout — O que é: tempo de espera pela confirmação de aplicação. Efeito: controla quando a outstation considera necessário retransmitir. Validar: medir RTT e tempo request→confirm no PCAP.
- Retry count — O que é: quantidade de novas tentativas permitidas pela implementação. Efeito: aumenta chance de entrega, mas pode ampliar tráfego em falha. Validar: simular perda de confirmação e contar retransmissões.
- Retry interval/backoff — O que é: espaçamento entre tentativas quando configurável. Efeito: influencia carga e tempo de recuperação. Validar: cronologia da captura.
- Max/min unsolicited delay — O que é: temporizações de agrupamento disponíveis em algumas implementações. Efeito: balanceiam latência e eficiência. Validar: manual do fabricante e sequência de eventos de teste.
Event buffer e unsolicited são duas partes do mesmo problema
Unsolicited entrega eventos; o event buffer preserva eventos enquanto eles não podem ser entregues. Se a comunicação cai, eventos continuam sendo gerados e precisam caber no buffer. Quando a sessão retorna, a política deve garantir que o backlog seja drenado sem perder a sequência. Uma configuração de unsolicited “rápida” não compensa um buffer incapaz de suportar a indisponibilidade prevista.
Deadband e chatter também interferem diretamente. Um analógico ruidoso ou uma entrada oscilante pode produzir tantos eventos que a outstation entra em ciclo contínuo de unsolicited e confirmações. O diagnóstico deve medir taxa de eventos por índice antes de aumentar timeout ou buffer.
Reconexão e restart: a sequência pós-falha precisa estar documentada
Após restart de outstation ou perda de sessão, o master normalmente executa uma sequência de inicialização. Dependendo da estratégia, isso pode incluir leitura de integridade, coleta das classes pendentes, sincronização de tempo e reabilitação de unsolicited. Se essa sequência falha no meio, o canal pode aparecer online mas permanecer sem eventos espontâneos.
No comissionamento, desligue e religue uma outstation em bancada ou janela autorizada, preserve a captura completa e veja se o master reconhece o restart, reconstrói a base e volta a habilitar unsolicited. Em redundância, repita com failover do master.
Roteiro de captura: como provar que unsolicited está correto
Comece com o sistema em estado conhecido. Capture a sequência de disable/enable durante a inicialização, quando existir. Gere um único evento Class 1 e marque o horário. Identifique a Unsolicited Response, seu objeto, índice, timestamp, qualidade e sequência; em seguida localize a confirmação do master. Repita para as demais classes habilitadas.
Depois remova temporariamente a confirmação em ambiente de teste ou introduza perda controlada. Observe timeout, retry e retenção do evento. Por fim, interrompa a sessão, gere eventos e reconecte. A implementação só está provada quando entrega normal e recuperação têm evidência.
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.
- IEEE 1815-2012 — IEEE Standard for Electric Power Systems Communications—Distributed Network Protocol (DNP3) — IEEE Standards Association. Edição publicada de referência para estrutura, funções, opções interoperáveis e requisitos de conformidade do DNP3.
- IEEE P1815 — Draft Standard for Electric Power Systems Communications—Distributed Network Protocol (DNP3) — IEEE Standards Association. Página oficial do projeto de revisão da norma; útil para acompanhar a evolução do padrão sem substituir a edição publicada aplicável ao equipamento.
- Overview of DNP3 Protocol — DNP Users Group. Visão geral oficial do protocolo e do papel do DNP Users Group como mantenedor do DNP3/IEEE 1815.
- DNP Users Group — Public Documents — DNP Users Group. Documentos públicos, guias, boletins e materiais de implementação e interoperabilidade.
- Understanding DNP3 — Inductive Automation. Material didático complementar sobre conceitos e comportamento de DNP3; não substitui a norma.
- DNP3 — trabalho didático de Redes de Computadores — GTA/UFRJ. Material acadêmico introdutório útil para leitura guiada da arquitetura; deve ser confrontado com IEEE 1815 e documentação atual do fabricante.
- opendnp3 User Guide — Automatak / opendnp3. Guia público de uma implementação amplamente usada, útil para relacionar a norma a parâmetros reais de master e outstation.
- DNP3 Communication Protocol Solutions — Triangle MicroWorks. Referência de implementador para recursos como events, deadbands, unsolicited, time sync, file transfer e ferramentas de teste.
- DNP3 Application Layer Function Codes — Rockwell Automation. Exemplo público de fabricante para Function Codes, incluindo COLD_RESTART, WARM_RESTART e ENABLE/DISABLE_UNSOLICITED.
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.