Protocolos / DNP3

Data Link Layer no DNP3: conceito, função e onde se aplica

Data Link Layer no DNP3: conceito, função e onde se aplica. Entenda o mecanismo, os parâmetros relevantes, como validar em campo e quais evidências usar no diagnóstico.

12 min de leituraPublicado em 25/08/2026
Ilustração técnica autoral para Data Link Layer no DNP3: conceito, função e onde se aplica, 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.

DNP3 serial: como ler o quadro e a pilha

Diagrama do quadro DNP3 serial com Start, Length, Link Control, endereços, CRC, User Data e pilha de funções.
Diagrama próprio do Portal da Automação. Use-o como mapa durante configuração, captura e troubleshooting.

Como ler esta figura

Start 0x05 0x64

Delimita o início de um frame DNP3. É a primeira evidência de que o receptor está vendo um quadro com framing DNP3 válido.

Na implementação: Se a sequência não aparece onde deveria, verifique serial, direção TX/RX, conversor e captura antes de mexer em objetos ou polling.

Length

Define o comprimento indicado pelo frame. Tamanho incoerente ou quadro truncado costuma revelar problema abaixo da aplicação.

Na implementação: Compare o valor declarado com os bytes realmente recebidos quando houver timeouts somente em respostas maiores.

Link Control

Indica direção e função da camada de enlace. Não confunda esse campo com o Function Code da camada de aplicação.

Na implementação: Use-o para separar falha de enlace, confirmação e estado de link de uma falha de READ/OPERATE/UNSOLICITED.

Destination / Source

São endereços lógicos DNP3. Eles continuam existindo mesmo quando o transporte é TCP/IP.

Na implementação: Uma conexão TCP pode estar estabelecida e ainda assim não haver resposta de aplicação se os endereços DNP3 não coincidirem.

CRC

Protege o cabeçalho e blocos de dados contra corrupção.

Na implementação: CRC recorrente pede análise de ruído, polaridade RS-485, aterramento, baud/paridade e comportamento de conversores/radios.

User Data

Transporta fragmentos que chegam à aplicação: objetos, eventos, confirmações, comandos e informações internas.

Na implementação: Depois de provar o enlace, é aqui que Group/Variation/Qualifier, classes, IIN e Function Codes passam a dominar o diagnóstico.

Objetos DNP3 frequentes no campo

GroupUsoO que conferir na captura
G1 / G2Binary Input estático / eventoVariation, flags, índice e timestamp do evento quando aplicável.
G10 / G12Binary Output Status / CROBEstado retornado, Function Code de controle e status da operação.
G20 / G22Counter estático / eventoLargura do contador, flags, índice e transição que gerou evento.
G30 / G32Analog Input estático / eventoFormato inteiro/float, flags, deadband e timestamp quando previsto.
G50Time and DateValor temporal, origem do sincronismo e coerência com SOE.
G60Class dataClasses solicitadas, eventos pendentes e relação com IIN1.1–IIN1.3.

Matriz específica — Data Link Layer / fundamentos

Campo/elementoValor ou representaçãoComo fechar a evidência
Source / Destination · fundamentosendereço DNPConfirmar master/outstation corretos.
TCP/UDP 20000 · fundamentostransporte típicoConfirmar porta efetivamente configurada.
Function Code · fundamentosação de aplicaçãoRelacionar request/response e efeito.
Group/Variation + IIN · fundamentosobjeto + estadoExplicar dado e condição da outstation.

A matriz foi escolhida pelo foco “Data Link Layer” e pela lente “fundamentos”; referências normativas e limites de fabricante continuam prevalecendo.

SCADA/IED — campos obrigatórios para “Data Link Layer”

Campo/etapaExemplo de evidênciaFalha concreta
Valor brutocontador/registro/objeto recebidoEscala errada mascarada pela IHM.
Scaling + unidadeganho, offset, EUValor numericamente plausível porém incorreto.
Qualitygood/bad/invalid/blocked/substituted conforme protocoloSCADA exibe dado sem indicar validade.
Source timestamptempo gerado no IED/RTUSOE fora de ordem por relógio ou perda de timestamp.
Receive/display timetempo no FEP/SCADALatência de transporte/processamento.
Command lifecycleenvio, ack, atuação e retornoAck de protocolo sem atuação física.

Mapa técnico de Data Link Layer: quem produz, quem consome e o que pode falhar

A Data Link Layer do DNP3 organiza frames, endereços de origem/destino e detecção de erro. É onde um equipamento identifica para quem o frame é destinado antes de a mensagem chegar à função de transporte e à aplicação.

Para aprender Data Link Layer sem depender de uma tela específica de fabricante, separe função, entradas, saídas e dependências. Em DNP3, os pontos mais próximos deste recorte são autenticação de comando, gerenciamento de chaves, Data Link Layer. O leitor iniciante deve conseguir dizer quem produz a informação e quem a usa; o leitor experiente deve conseguir apontar o limite entre comportamento normal, exceção e implementação particular do equipamento.

A cadeia causal de Data Link Layer: o que muda e onde observar

Confirme Source Address, Destination Address, direção esperada e comportamento de confirmação de enlace quando aplicável. Endereços devem ser únicos dentro do domínio lógico relevante.

Implemente primeiro uma troca mínima e conhecida entre as duas pontas. Depois acrescente eventos, exceções, temporização e funções opcionais. Uma sessão estabelecida não é critério suficiente: o dado precisa manter tipo, qualidade, endereço, sequência e tempo até o destino. Durante o estudo, acompanhe DNP3-SA, autenticação de comando, gerenciamento de chaves, Data Link Layer como uma cadeia causal. Para cada item, pergunte o que o altera, como aparece no tráfego ou no equipamento e qual seria o primeiro sintoma se estivesse incorreto.

  • DNP3-SA — defina primeiro o que representa em DNP3 e qual elemento produz ou consome essa informação; depois identifique em que condição ele muda.
  • autenticação de comando — relacione o valor ou estado ao efeito sobre Data Link Layer; registre também qual campo permite confirmar que a interpretação está correta.
  • gerenciamento de chaves — na configuração, verifique dependências nas duas pontas e evite copiar valor de outro projeto sem comparar topologia, versão e capacidade do equipamento.
  • Data Link Layer — no diagnóstico, associe pelo menos um sintoma de configuração errada e uma evidência que diferencie esse sintoma de falha física ou de rede.
  • Master — no comissionamento, crie um estímulo que faça o item mudar de forma previsível e registre antes/depois, horário e resposta observada.

Da origem ao efeito: sequência e estados de Data Link Layer

O fundamento de Data Link Layer aparece nas transições. Acompanhe uma operação normal do início ao fim e marque quando DNP3-SA e autenticação de comando mudam. Depois repita mentalmente o fluxo com perda de comunicação, reinício ou dado inválido. Essa comparação revela quais campos representam estado e quais apenas transportam informação.

Neste recorte de Data Link Layer, trate DNP3-SA, autenticação de comando e gerenciamento de chaves como três pontos de prova. Explique o que cada um representa, o que deveria acontecer antes e depois de uma mudança e qual evidência seria incompatível com a hipótese inicial. Assim o texto permanece útil para implementação e troubleshooting.

  • Descrever a sequência normal de Data Link Layer
  • Descrever uma exceção sem recorrer a “reiniciar e testar”
  • Identificar o papel de DNP3-SA
  • Identificar o papel de autenticação de comando

Da bancada à operação: um cenário para aplicar Data Link Layer

Para implementar Data Link Layer em DNP3, escolha uma função pequena que possa ser repetida sem ambiguidade. Prove primeiro DNP3-SA; depois acrescente autenticação de comando; por último force uma condição relacionada a gerenciamento de chaves. Em cada etapa registre a mensagem esperada, o estado local e a reação da outra ponta. A sequência incremental reduz drasticamente tentativa e erro em projetos multivendor.

A decisão de engenharia para Data Link Layer deve terminar em critérios mensuráveis. Use DNP3-SA como primeira evidência de sucesso e autenticação de comando como verificação de consistência; declare quanto tempo pode decorrer e o que deve sobreviver à reconexão. Se a interface do fabricante usa outro nome para gerenciamento de chaves, mantenha uma tabela que ligue o rótulo comercial ao conceito do protocolo.

  • Definir uma condição normal de Data Link Layer e salvar a evidência associada a DNP3-SA.
  • Escolher uma única variável relacionada a autenticação de comando e prever o efeito antes de alterar.
  • Repetir o mesmo teste e comparar gerenciamento de chaves nas mesmas medições ou campos.
  • Registrar o critério que permite aceitar, rejeitar ou reverter a configuração de Data Link Layer.

Como demonstrar que Data Link Layer foi implementado corretamente

Capture frames em ambos os sentidos e confirme que a solicitação chega com o destino correto e que a resposta retorna para o endereço esperado.

Defina evidência antes de testar Data Link Layer. Para esta categoria, sinais úteis incluem endereço, campo, estado, sequência, timestamp, qualidade. O teste deve ter estado inicial conhecido, estímulo reproduzível e resultado esperado. Quando houver dois equipamentos, registre os dois lados; quando houver gateway, registre também a transformação intermediária.

  • Validar DNP3-SA em condição normal
  • Forçar uma condição degradada ligada a autenticação de comando
  • Confirmar recuperação sem perder estado, evento ou evidência relevante
  • Salvar configuração, logs/captura e horário do teste como baseline

Árvore de falhas de Data Link Layer: onde procurar antes de alterar parâmetros

Request Link Status repetitivo sem evolução para dados de aplicação pode indicar endereço errado, sessão não inicializada, caminho unidirecional ou dispositivo configurado para outro modo.

Não conclua a partir do sintoma sozinho. Para Data Link Layer, cruze pelo menos duas fontes de evidência e procure a primeira divergência. Se DNP3-SA, autenticação de comando, gerenciamento de chaves estão corretos mas o resultado final continua errado, avance para a próxima fronteira do sistema em vez de alterar parâmetros já comprovados.

  • DNP3-SA: registre um caso saudável, um caso com falha e a diferença objetiva em estado.
  • autenticação de comando: registre um caso saudável, um caso com falha e a diferença objetiva em sequência.
  • gerenciamento de chaves: registre um caso saudável, um caso com falha e a diferença objetiva em timestamp.
  • Data Link Layer: registre um caso saudável, um caso com falha e a diferença objetiva em qualidade.

Data Link Layer: dados exclusivos deste recorte (fundamentos)

Uma captura de Data Link Layer deve mostrar Source/Destination da Data Link, sequência de aplicação, Function Code, Group/Variation, qualifier/range e IIN. Em DNP3 sobre IP, TCP/UDP 20000 é a porta registrada normalmente usada, mas o valor real deve ser confirmado no projeto e na captura.

Nos fundamentos de Data Link Layer, acompanhe a transição que altera Source / Destination e confirme como TCP/UDP 20000 reage antes, durante e depois do evento.

  • Source / Destination: endereço DNP. Confirmar master/outstation corretos.
  • TCP/UDP 20000: transporte típico. Confirmar porta efetivamente configurada.
  • Function Code: ação de aplicação. Relacionar request/response e efeito.
  • Group/Variation + IIN: objeto + estado. Explicar dado e condição da outstation.

Data Link Layer: objeto DNP3 em Group/Variation, qualifier e índice — Data Link Layer / fundamentos

Nos fundamentos de Data Link Layer, trate serial como parte de uma sequência causal: condição inicial, transição, campo alterado e reação do outro lado. O ponto DNP3 só é interpretável quando Group, Variation, qualifier e faixa/índice são lidos em conjunto. Group 1 representa Binary Input estático e Group 2 seus eventos; Group 10 representa Binary Output Status e Group 12 Control Relay Output Block; Group 20/22 tratam Counter estático/evento; Group 30/32 representam Analog Input estático/evento. A Variation define representação e presença de flags/timestamp, portanto dois equipamentos podem “ter o mesmo ponto” e ainda assim discordar do formato aceito. O critério de encerramento para Data Link Layer em fundamentos é obter o mesmo resultado em novo teste de serial, mantendo o ponto de medição e a condição inicial.

O mecanismo de Data Link Layer deve ser lido a partir de keepalive; observe qual estado antecede a mudança e qual confirmação prova que ela terminou. No diagnóstico de Data Link Layer, capture a requisição e a resposta e confira Function Code, Group, Variation, qualifier e range. Object Unknown ou Parameter Error no IIN frequentemente nasce exatamente dessa combinação. Em gateway, preserve uma tabela explícita entre o objeto DNP3 recebido e o tipo/qualidade/timestamp entregue ao SCADA. Para este artigo de Data Link Layer, a evidência ligada a keepalive deve ser armazenada com horário, origem e condição de teste, permitindo comparação posterior.

  • Data Link Layer · fundamentos · serial: Exemplo: G1/G2 separa Binary Input estático de evento; G30/G32 faz o mesmo para Analog Input.
  • Data Link Layer · fundamentos · porta TCP padrão 20000: Conferir se a Variation usada no evento inclui flags e/ou tempo conforme a necessidade de SOE.
  • Data Link Layer · fundamentos · retry: Registrar qualifier e range porque eles definem como índices/contagens são codificados.
  • Data Link Layer · fundamentos · keepalive: Em multivendor, validar objetos efetivamente suportados no Device Profile.

Data Link Layer: valor, qualidade, tempo e ciclo de comando ponta a ponta — Data Link Layer / fundamentos

O mecanismo de Data Link Layer deve ser lido a partir de autenticação de comando; observe qual estado antecede a mudança e qual confirmação prova que ela terminou. Um ponto SCADA não é apenas um valor. Para Data Link Layer, registre endereço/tag de origem, valor bruto, escala/unidade, quality, timestamp de origem, timestamp de recepção e timestamp de apresentação. Deadband deve ser expressa na unidade ou porcentagem definida e testada em torno do limiar; SOE exige preservar a ordem pelo tempo de origem, não pela ordem de chegada ao servidor. Se autenticação de comando não reproduzir o comportamento esperado em Data Link Layer, a hipótese deve ser revista antes de alterar outra camada do sistema.

Para explicar por que Data Link Layer funciona, use Outstation como ponto de partida e siga a mudança até o efeito mensurável no protocolo ou processo. Comandos precisam ser separados em intenção, envio pelo protocolo, confirmação de protocolo, atuação do equipamento e retorno de posição. Em religador/IED/RTU, um “operate success” sem mudança do contato ou telemetria não encerra o teste. Em historian, preserve raw value, quality e source timestamp antes de qualquer agregação. Em alarmes, registre condição de entrada, prioridade, debounce/deadband, ack e retorno ao normal. O critério de encerramento para Data Link Layer em fundamentos é obter o mesmo resultado em novo teste de Outstation, mantendo o ponto de medição e a condição inicial.

  • Data Link Layer · fundamentos · Secure Authentication: Telemetria: raw → scaling → engineering unit → quality → source timestamp → SCADA timestamp.
  • Data Link Layer · fundamentos · DNP3-SA: SOE: comparar timestamp de origem e sequência recebida em uma rajada de eventos.
  • Data Link Layer · fundamentos · autenticação de comando: Comando: request → protocol confirmation → physical action → indication/return.
  • Data Link Layer · fundamentos · gerenciamento de chaves: Historian: validar valor, quality e timestamp antes de compressão/agregação.

Referências técnicas

As explicações do Portal são autorais. Use as fontes oficiais e materiais públicos de implementação abaixo para confirmar edição, escopo, capacidades e comportamento do equipamento utilizado no seu projeto.

Continue estudando

Os próximos conteúdos foram escolhidos pelo mecanismo deste artigo. A ideia é formar uma sequência técnica, não apenas listar páginas do mesmo tema.

Ver todas as trilhas de estudo →