DNP3: guia completo para automação elétrica

DNP3 não é apenas uma porta TCP: é um protocolo de telecontrole completo

DNP3, Distributed Network Protocol, é um protocolo de comunicação projetado para supervisão e controle de sistemas distribuídos. Em automação elétrica ele aparece entre centros de operação, front-ends, gateways, RTUs, religadores, controladores e IEDs. A referência normativa central é a IEEE 1815. A primeira ideia que precisa ficar clara é que DNP3 não se resume à porta TCP 20000: o protocolo define funções de aplicação, objetos de dados, eventos, endereçamento, qualidade, tempo, confirmações, comandos e comportamento de uma estação remota diante de condições internas.

Uma integração pode ter Ethernet funcionando, IP alcançável e sessão TCP estabelecida e ainda assim falhar completamente em DNP3. O master pode estar consultando o endereço lógico errado; a outstation pode não suportar a Group/Variation pedida; o ponto pode estar em uma classe de evento não coletada; o comando pode exigir Select Before Operate; ou a resposta pode sinalizar em IIN que a função não é suportada. O diagnóstico profissional separa essas camadas em vez de chamar todo problema de “falha de comunicação”.

Arquitetura: master, outstation e o caminho até o processo

No modelo clássico, o master inicia a maior parte das transações e a outstation disponibiliza informações do processo e executa funções permitidas. Em uma arquitetura real, o master pode ser um front-end SCADA e a outstation pode ser um relé, RTU ou gateway que concentra vários equipamentos. O endereço IP identifica uma interface de rede; o endereço DNP3 identifica logicamente uma estação no protocolo. Esses identificadores pertencem a camadas diferentes e devem ser documentados separadamente.

O fluxo de engenharia deve ser lido de ponta a ponta: variável física ou lógica no equipamento, ponto interno do IED, objeto DNP3 correspondente, índice do ponto, classe de evento, timestamp e qualidade, transporte até o master, mapeamento no banco SCADA e uso pela operação. Se existir gateway, ele precisa ser tratado como equipamento ativo de tradução. O gateway pode mudar índice, qualidade, timestamp, deadband ou tipo de objeto; logo, não é um simples cabo.

• Master: cliente lógico que realiza READ, controles, sincronismo, integridade e gerenciamento da sessão conforme a implementação.
• Outstation: estação lógica que mantém dados estáticos, buffers de eventos, estados internos e serviços DNP3 expostos ao master.
• Ponto: instância de uma informação, normalmente identificada por tipo de objeto e índice.
• Device Profile: documento fundamental para saber o que cada implementação realmente suporta, evitando pressupor que todo equipamento implementa todo o padrão.

Objetos, Group, Variation e índice: onde o dado ganha significado

DNP3 organiza dados por objetos. Group identifica uma família de informação e Variation define uma representação específica daquela família. Um valor binário estático, um evento binário com tempo e um valor analógico com determinada largura ou representação não são “a mesma coisa com nomes diferentes”: cada representação possui estrutura e propósito próprios. O índice identifica qual ponto daquela família está sendo transportado.

Essa estrutura é uma das razões para DNP3 ser eficiente em telecontrole. O master pode solicitar integridade, dados estáticos, eventos ou objetos específicos. A outstation pode transportar apenas as mudanças registradas desde a coleta anterior, preservando timestamp quando o objeto de evento o suporta. Para comissionar corretamente, a tabela de pontos precisa registrar pelo menos índice, significado elétrico, Group/Variation esperado, classe, unidade, escala, deadband quando aplicável e comportamento de qualidade.

Class 0, Classes 1/2/3 e eventos: três conceitos que não devem ser misturados

Class 0 é usada para a visão estática configurada para uma leitura de integridade; Classes 1, 2 e 3 organizam eventos. Atribuir um ponto à Class 1 não significa que seu valor estático deixa de existir, nem que “classe menor é sempre mais rápida”. A prioridade operacional de cada classe é decisão de engenharia e depende de como o master faz polling ou habilita unsolicited.

Evento é uma mudança que a outstation registra para posterior entrega. Em um analógico, deadband determina quando uma mudança suficientemente significativa gera evento, conforme a implementação e o tipo de ponto. O buffer de eventos precisa sobreviver à indisponibilidade esperada do canal. Se o buffer estoura, o valor atual pode continuar correto, mas a sequência histórica de mudanças pode ter sido perdida. Para SOE e análise de ocorrências, essa diferença é decisiva.

Tempo, unsolicited e comandos: onde a integração deixa de ser superficial

DNP3 pode transportar timestamps associados a eventos e possui mecanismos para sincronização de tempo e indicação de necessidade de ajuste. Em aplicações de Sequence of Events, a hora deve ser avaliada como parte da cadeia completa: fonte de tempo, relógio da outstation, precisão, objeto usado, transporte do timestamp e tratamento no SCADA. Corrigir apenas o relógio do servidor não corrige um evento que foi timestampado incorretamente na origem.

Unsolicited Response permite que a outstation envie eventos sem aguardar uma consulta específica. Isso reduz latência de notificação, mas exige engenharia de classes, confirmações, retries, temporizações, buffers e comportamento após reconexão. Em comandos, o projeto deve saber se usa Direct Operate ou Select Before Operate, quais objetos de controle estão disponíveis, quais estados de retorno são aceitos e como intertravamentos locais se relacionam com a ordem remota.

Parâmetros que precisam aparecer na folha de engenharia

Não existe “configuração DNP3” representada por um único campo. A folha de engenharia precisa capturar parâmetros de várias camadas e registrar a origem de cada valor. Defaults de fabricante são ponto de partida, não prova de compatibilidade. Sempre compare master, outstation, rede e Device Profile.

• Endereço DNP3 local/remoto — O que é: identificador lógico de origem e destino. Efeito: endereço divergente impede a transação mesmo com TCP ativo. Validar: captura mostrando Source/Destination e configuração das duas pontas.
• Timeout e retries — O que é: limites de espera e repetição das transações. Efeito: valores agressivos criam retries falsos; valores excessivos atrasam detecção de falha. Validar: RTT real, captura temporal e logs do master.
• Classes de evento — O que é: associação de eventos às Classes 1/2/3. Efeito: determina como o master coleta ou recebe mudanças. Validar: gerar evento conhecido e acompanhar sua chegada e confirmação.
• Deadband — O que é: limiar para geração de evento analógico. Efeito: pequeno demais cria churn; grande demais esconde mudança relevante. Validar: variar o processo em passos conhecidos e observar eventos.
• Event buffer — O que é: capacidade de armazenar eventos ainda não entregues. Efeito: overflow pode destruir histórico. Validar: teste controlado de indisponibilidade e checagem de IIN/logs.
• Unsolicited — O que é: envio espontâneo de eventos pela outstation. Efeito: reduz latência, mas introduz confirmação e retries. Validar: enable/disable explícito, evento de teste e PCAP.
• Time sync — O que é: política de sincronização do relógio remoto. Efeito: afeta SOE e correlação temporal. Validar: comparar fonte, relógio da outstation, timestamp do evento e SCADA.
• Function/Control model — O que é: funções e métodos de controle aceitos. Efeito: determina se um comando será executado, recusado ou exigirá seleção prévia. Validar: Device Profile, resposta DNP3 e teste operacional autorizado.

Roteiro de comissionamento: prove cada camada em vez de procurar apenas “online”

Um bom comissionamento começa pela infraestrutura e avança para a semântica. Primeiro prove meio físico e enlace; depois IP/TCP quando houver; em seguida endereços DNP3, integridade, objetos, eventos, tempo, unsolicited e comandos. Para cada etapa salve evidência. O critério “o ponto apareceu na tela” é fraco porque não prova evento, qualidade, timestamp, recuperação nem controle.

Inclua pelo menos uma condição degradada: interrupção do canal, reboot controlado da outstation, perda de sincronismo ou retorno após indisponibilidade. Verifique se o master reconstrói o estado, coleta eventos pendentes, reconhece IIN, sincroniza tempo quando necessário e reabilita serviços configurados. O comportamento pós-falha é parte da interoperabilidade.

• 1. Registrar firmware, Device Profile, endereços, transporte e parâmetros atuais.
• 2. Provar conectividade física/rede sem ainda concluir que DNP3 está funcional.
• 3. Capturar uma transação válida e conferir Source, Destination, Function Code e resposta.
• 4. Executar integrity poll e confrontar quantidade/tipo de pontos com a lista de engenharia.
• 5. Forçar eventos digitais e analógicos conhecidos e verificar classe, timestamp e qualidade.
• 6. Testar unsolicited quando usado, incluindo confirmação e reconexão.
• 7. Testar controles apenas com autorização e matriz de causa/efeito disponível.
• 8. Salvar PCAP, logs, export de configuração e resultado esperado/obtido para cada caso.