Protocolos / DNP3 — implementação completa

DNP3 do zero ao comissionamento: mestre, outstation, objetos, classes, tempo e comandos

Roteiro completo para implementar um canal DNP3 novo: arquitetura, device profile, endereços, serial/TCP, pontos, Group/Variation, classes, eventos, time sync, unsolicited, CROB, SBO e testes.

6 min de leitura Publicado em 25/08/2026
Ilustração técnica autoral para DNP3 do zero ao comissionamento: mestre, outstation, objetos, classes, tempo e comandos, destacando o fluxo e os elementos centrais do assunto.
Ilustração técnica autoral do Portal da Automação, criada para o foco específico deste artigo.

Checklist de frame DNP3 para este recorte

CampoPergunta objetivaFalha que ajuda a separar
Source / DestinationOs endereços DNP são os esperados nas duas direções?Endereço trocado, broadcast indevido, resposta de outro equipamento.
Application SequenceA sequência avança e corresponde à transação?Resposta antiga, duplicação ou perda de estado.
Function CodeA ação enviada é a suportada para o objeto?Function Code Not Supported.
Group / Variation / QualifierFormato e range são suportados?Object Unknown / Parameter Error.
IINA resposta carrega condição que exige ação do master?Restart, Need Time, classe pendente, overflow.

1. Defina papéis, transporte e endereços antes dos pontos

Comece desenhando master, outstation, redundância, gateway e caminho. Escolha serial ou IP, registre baud/paridade ou IP/porta e defina Source/Destination DNP únicos. Em TCP, valide primeiro rede e porta 20000; em serial, valide elétrica, pinagem, polaridade e terminação. Não comece o projeto cadastrando milhares de tags antes de provar uma transação simples.

Obtenha o Device Profile ou documentação equivalente de cada equipamento. Ela deve orientar capacidades, subset/perfil, objetos, variations, unsolicited, time sync, controles, file transfer e segurança. Interoperabilidade começa por comparar capacidades explícitas das duas pontas.

2. Modele pontos com semântica, não só índice

Para cada ponto registre Group, Variation estática e de evento, índice, classe, flags, unidade, scaling, deadband e origem do timestamp. Um analógico não é apenas “30.x”: a variation muda largura, representação e presença de flags. O gateway deve preservar o que for operacionalmente relevante.

Defina Class 0 para reconstrução de estado e Classes 1/2/3 para eventos conforme prioridade da aplicação. Depois force mudanças conhecidas e prove valor estático, geração de evento, timestamp e qualidade. Essa sequência é mais segura que tentar validar tudo ao mesmo tempo.

Fluxo DNP3 entre estação mestre e outstations com polling, eventos e comandos.
Arquitetura de comunicação DNP3 entre sistema mestre e equipamentos remotos. Fonte: Portal da Automação · Conteúdo autoral do portal.

3. Tempo, eventos, unsolicited e comandos

Defina a fonte de tempo e como o master reage ao Need Time. Teste SOE com mudanças em horários conhecidos. Dimensione buffers e deadbands. Decida se unsolicited será usado e com quais classes, delays, confirmações e retries. Teste perda e retorno de comunicação antes de liberar a operação.

Para comandos, escolha Select Before Operate ou Direct Operate conforme filosofia e capacidade. Em CROB, documente pulse/latch, Trip/Close code quando usado, duração, feedback e permissões local/remoto. Teste comando permitido, bloqueado, timeout entre Select/Operate e perda do link entre etapas.

4. Critério de aceite e evidências

O canal só deve ser aceito quando houver evidência de leitura, eventos, integridade, recuperação, sincronismo, controles aplicáveis, restart e comportamento em falha. Capture PCAP, logs, tabela de pontos e versão das configurações. Um print “online” não é critério suficiente.

Finalize com baseline: ciclo de polling, latência, quantidade normal de eventos, ocupação do canal, buffers, retries e contadores de erro. Esse baseline é o que permitirá a um técnico experiente diagnosticar degradação meses depois sem adivinhar como o sistema se comportava quando estava saudável.

Critério de liberação: quando um canal DNP3 pode sair da bancada

Um canal não está pronto porque respondeu a um integrity poll. Antes da liberação, prove separadamente transporte, endereçamento, dados estáticos, eventos, horário e controles. Para cada tipo de ponto, escolha pelo menos um índice conhecido e compare Group/Variation, valor de engenharia, flags, classe e timestamp entre a origem, a captura e o SCADA. Em TCP, registre porta, endereços IP e DNP; em serial, registre baud rate, paridade, stop bits, modo elétrico, pinagem e conversores. O Device Profile deve ser tratado como entrada de engenharia e arquivado junto com a configuração.

Depois execute cenários de exceção. Interrompa a comunicação tempo suficiente para acumular eventos, faça o canal voltar e confirme recuperação sem overflow. Reinicie a outstation em condição controlada e observe IIN, integridade, sincronismo e unsolicited. Para comandos, teste estado permitido, estado bloqueado, Select Before Operate quando usado, expiração e feedback físico ou simulado. Só então registre baseline de captura, tempos de resposta e contadores. Esse pacote de evidências permite que um técnico futuro compare o comportamento de uma falha com o estado de aceite original.

  • Device Profile, firmware, mapa de pontos e endereços arquivados.
  • Class 0 e eventos por classe validados com valores conhecidos.
  • SOE e sincronismo validados por mudança com horário conhecido.
  • Unsolicited/polling e recuperação após indisponibilidade comprovados.
  • CROB/SBO/Direct Operate testados conforme filosofia operacional.
  • PCAP, logs e tempos de resposta guardados como baseline de comissionamento.

Mapa de pontos: o teste precisa provar semântica, não apenas números

Antes de testar centenas de pontos, selecione amostras representativas: um Binary Input com mudança real, um Double Bit quando existir, um Analog Input próximo aos limites de escala, um Counter, um ponto com timestamp e um controle. Para cada um, registre índice DNP3, Group/Variation estática e de evento, classe, unidade, escala, deadband, qualidade e origem do timestamp. Compare o valor no equipamento, no frame e no banco do SCADA. Essa triangulação detecta erros de mapping que um simples “todos os pontos atualizaram” não revela.

Depois valide os limites. Force qualidade inválida ou comunicação com a origem interna quando a bancada permitir; confirme como as flags chegam ao SCADA. Gere mudanças rápidas para verificar deadband, classe e capacidade do event buffer. Nos comandos, separe aceitação DNP3 de execução física: CROB pode ser aceito e a lógica local bloquear a saída. Por isso o relatório deve registrar resposta protocolar, feedback do ponto e estado do equipamento primário. Esse método cria um comissionamento útil para operação e manutenção, não apenas uma lista de telas marcadas como OK.

Feche o ensaio com uma matriz de rastreabilidade. Cada requisito deve apontar para o parâmetro configurado, o caso de teste, a captura ou log que comprova o resultado, o responsável e a condição de aceite. Inclua pelo menos partida a frio, perda e retorno do enlace, indisponibilidade prolongada, fila próxima do limite, troca de master quando houver redundância e tentativa de comando em condição bloqueada. Registre também o que não é suportado pelo equipamento para impedir que uma limitação conhecida reapareça depois como falha. Essa matriz permite repetir o comissionamento após atualização de firmware, substituição de gateway ou mudança de rota sem depender da memória da equipe.

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.

  • Overview of DNP3 Protocol — DNP Users Group. Fonte mantenedora do DNP3/IEEE 1815 para arquitetura, interoperabilidade e documentação pública.
  • DNP Users Group — Public Documents — DNP Users Group. Aplicações públicas, boletins e materiais técnicos para validar comportamento de implementações.
  • 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.

Ver todas as trilhas de estudo →