Mestre, outstation e endereçamento DNP3

Master e outstation são papéis lógicos, não nomes de equipamentos

Em DNP3, master e outstation descrevem papéis de comunicação. Um servidor front-end do SCADA pode atuar como master para dezenas ou milhares de estações; um relé, RTU, religador ou gateway pode atuar como outstation. Um gateway também pode ser master em uma interface e outstation em outra. Por isso, documentação que escreve apenas “RTU” ou “servidor” sem registrar o papel DNP3 deixa uma ambiguidade importante.

O master normalmente inicia leituras, integridade, sincronismo, habilitação de unsolicited e comandos. A outstation mantém a base de pontos exposta, produz eventos, responde a funções e informa estados internos. Essa relação não significa que a outstation seja passiva: com unsolicited habilitado, ela pode iniciar a entrega de eventos. A engenharia precisa documentar quais serviços são iniciados por cada lado e em que condição.

Endereço DNP3 não é endereço IP

O endereço IP identifica uma interface no domínio IP. O endereço DNP3 aparece dentro do frame do protocolo para indicar Source e Destination lógicos. Em DNP3/TCP, portanto, existem pelo menos dois níveis de endereçamento simultâneos. Um equipamento pode responder ao IP correto e aceitar a porta TCP correta, mas não responder ao request DNP3 se o Destination do frame não corresponder ao endereço lógico configurado.

Essa distinção também evita outro erro: trocar o IP de uma RTU não obriga a trocar seu endereço DNP3, e trocar o endereço DNP3 não altera necessariamente a rota IP. Em migrações, NATs, túneis ou redes redundantes, preservar essa separação reduz falhas difíceis de localizar.

• IP — O que é: endereço da camada de rede. Efeito: determina roteamento e entrega ao host. Validar: ARP, rota, ping quando permitido e PCAP.
• Porta TCP/UDP — O que é: identificador de transporte. Efeito: direciona o fluxo ao serviço. Validar: handshake/fluxo e política de firewall.
• DNP Source — O que é: endereço lógico do remetente no frame. Efeito: identifica quem originou a mensagem DNP3. Validar: captura e configuração local.
• DNP Destination — O que é: endereço lógico do destinatário. Efeito: define qual estação deve aceitar a mensagem. Validar: captura e Device Profile/configuração remota.

Arquiteturas com um master, múltiplas outstations e canais compartilhados

Em serial multiponto, vários equipamentos podem compartilhar o mesmo par ou canal. O endereçamento DNP3 torna possível ao master distinguir as estações. Isso exige disciplina: endereços duplicados podem produzir respostas conflitantes, intermitência ou comportamento aparentemente aleatório. O projeto deve manter uma tabela única de endereços e impedir reutilização não planejada.

Em redes IP, cada outstation pode ter seu próprio IP, mas isso não elimina a necessidade do endereço DNP3. Alguns front-ends usam o par IP/porta para identificar o canal e ainda validam Source/Destination dentro da aplicação. Outros suportam múltiplas estações atrás de gateways. O comportamento exato deve ser confirmado na implementação.

Gateways: quando um ponto atravessa dois domínios de endereçamento

Um gateway DNP3 pode terminar uma sessão como master, processar dados e expor outra sessão como outstation. Nesse caso, endereço e índice de um lado não precisam ser iguais aos do outro. O gateway pode ainda traduzir DNP3 para IEC 60870-5-104, IEC 61850, Modbus ou protocolo proprietário. Cada transformação precisa ser documentada em uma matriz de mapeamento.

A perda de semântica é um risco real. Um evento com timestamp no lado de origem pode virar apenas valor estático no lado de destino se o gateway não preservar a informação. Qualidade, flags e classes também podem ser alteradas. Em troubleshooting, capture os dois lados do gateway para provar se a informação chegou correta e em qual ponto foi transformada.

Redundância de master e a pergunta “quem manda agora?”

Sistemas críticos podem ter front-ends redundantes, centros principal e reserva ou masters com prioridades operacionais diferentes. O protocolo e o equipamento precisam ser avaliados quanto a múltiplas associações, controle de unsolicited, sincronismo, comandos e recuperação após failover. Não basta duplicar IP e esperar que o comportamento seja transparente.

Defina quem pode habilitar unsolicited, quem confirma mensagens, quem realiza time sync e quem possui autoridade de comando em cada estado. Um failover mal projetado pode produzir dois masters concorrendo por controles ou ambos tentando modificar o mesmo serviço. O Device Profile e a documentação do fabricante devem ser consultados para capacidades multi-master.

Diagnóstico de endereçamento sem tentativa e erro

Quando um canal está “conectado” mas não atualiza, faça a leitura em camadas. Confirme IP e porta, depois abra uma captura e identifique o primeiro request DNP3. Registre Source, Destination e Function Code. Se não há resposta, compare os endereços com a configuração da outstation. Se há resposta, veja se o Source/Destination retornam invertidos de forma coerente e se o IIN aponta alguma condição.

Em serial, verifique também se duas estações respondem ao mesmo endereço. Em gateways, capture upstream e downstream. Em redundância, registre qual master estava ativo no instante do problema. O objetivo é substituir a pergunta genérica “por que não comunica?” por uma sequência de evidências reproduzíveis.

Como conferir Source e Destination nos bytes do cabeçalho

No cabeçalho de enlace DNP3, os campos Destination e Source têm 16 bits e aparecem após o Link Control. Cada endereço é transmitido com o byte menos significativo primeiro. Assim, o endereço decimal 100 corresponde a 0x0064 e aparece no quadro como 64 00; o endereço 1 aparece como 01 00. Depois dos dois endereços vem o CRC do cabeçalho. Essa ordem é importante porque procurar diretamente o número decimal na sequência hexadecimal pode levar a uma conclusão errada.

Para validar uma troca, não é necessário repetir toda a pilha do protocolo. Isole o trecho de enlace, converta os dois pares de bytes e compare-os com a tabela de engenharia: no request, Destination deve apontar para a outstation e Source para o master; na resposta, os papéis se invertem. Ferramentas como Wireshark normalmente já decodificam esses campos, mas a leitura dos bytes brutos é uma segunda evidência útil quando há dúvida sobre o dissector, uma captura truncada ou uma implementação proprietária. Registre o valor decodificado e os bytes observados no relatório de comissionamento.