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

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.

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.