Distributed Network Protocol (DNP ou DNP3 ou DNP 3.0) é um protocolo de comunicação empregado em sistemas de controle, supervisão e aquisição de dados (SCADA) e em sistemas de monitoramento remoto. Sua ampla utilização se deve ao fato de ser um protocolo de padrão aberto, permitindo que qualquer fabricante desenvolva equipamentos DNP3 compatíveis com outros dispositivos DNP3. Ele conquistou uma ampla adoção nos setores de Energia Elétrica e Água, e também desempenha um papel importante nos setores de Gás e Petróleo.
O protocolo DNP3 foi desenvolvido em 1990 pela Westronic (agora GE Harris) e publicado em 1993. Naquela época, os padrões IEC 60870-5 estavam em destaque, sendo os mais reconhecidos o IEC 60870-5-101 para comunicação ponto a ponto de link serial mestre-escravo e o IEC 60870-5-104 para redes TCP. Embora o processo de padronização do IEC 60870-5 estivesse em andamento, o DNP3 tornou-se especialmente popular nos Estados Unidos e na Ásia, embora tenha sido menos adotado na Europa, onde o IEC 60870-5 era amplamente utilizado.
O DNP3 é baseado em um Modelo de Objeto. Esse modelo reduz a necessidade de mapeamento de bits de dados, comum em outros protocolos menos orientados a objetos. Além disso, diminui a disparidade de monitoramento de status e paradigmas de controle, que são frequentemente encontrados em protocolos que não possuem objetos predefinidos.
Os defensores desses protocolos alternativos argumentariam que qualquer objeto necessário pode ser “construído” a partir de objetos existentes. No entanto, ter objetos predefinidos torna o DNP3 mais confortável em termos de estrutura de design e implantação para engenheiros e técnicos de SCADA.
O DNP3 é normalmente usado entre mestres localizados centralmente e remotos distribuídos. O mestre fornece a interface entre o gerente da rede humana e o sistema de monitoramento. O remoto (RTUs e dispositivos eletrônicos inteligentes) fornece a interface entre o mestre e o(s) dispositivo(s) físico(s) sendo monitorado(s) e/ou controlado(s).
O mestre e o remoto usam uma biblioteca de objetos comuns para trocar informações. O protocolo DNP3 contém recursos cuidadosamente projetados. Esses recursos permitem que ele seja usado de forma confiável mesmo em mídia que pode estar sujeita a interferência ruidosa.
O protocolo DNP3 é um protocolo polling. Quando a estação mestra se conecta a um remoto, uma pesquisa de integridade é executada. As pesquisas de integridade são importantes para o endereçamento DNP3 porque retornam todos os valores armazenados em buffer para um ponto de dados e também incluem o valor atual do ponto.
Como um protocolo SCADA inteligente e robusto, o DNP3 oferece muitos recursos.
O DNP3 foi projetado principalmente para linhas seriais (assim como IEC 101), mas também pode ser usado em redes IP quando agrupado em pacotes TCP ou UDP. Quanto aos padrões IEC, o IEC 101 é usado encapsulado em UDP ou TCP (por exemplo, por conversão usando servidores seriais Moxa NPort) e o IEC 104 é projetado diretamente para redes TCP.
A implementação DNP3 no processo D2000 COM suporta os seguintes tipos de linhas.
O protocolo DNP3 pode ser usado em comunicações ponto-a-ponto e ponto-a-multiponto (por exemplo, barramento RS-485) com uma estação mestre (principalmente SCADA) e várias estações escravas (na terminologia DNP3, elas são chamadas de outstation e são PLC, RTU ou outros IEDs – Dispositivos Eletrônicos Inteligentes). Nota: O DNP3 suporta o envio de alterações espontâneas por outstations usando a função do aplicativo Unsolicited Response (130). Se houver várias estações no ônibus, pode haver colisões ao usar esta funcionalidade.
As estações mestre e escrava são identificadas por um número de 2 bytes de 0 a 65.519. Endereços mais altos são reservados para broadcasts, para “autoendereço” ou para extensões futuras.
Os protocolos IEC-101 e IEC-104 são apenas para comunicação ponto a ponto – um mestre, um escravo. Existe um chamado “endereço comum de ASDU” que mapeia para um endereço de estação (1 ou 2 bytes para IEC-101 e 2 bytes para IEC-104) em D2000.
O DNP3 usa 27 códigos de funções básicas para trocar informações entre mestres (pense em centro de controle) e remotos (pense em pátio de bombas). Alguns desses códigos de função permitem que um mestre solicite e receba informações de status de um controle remoto. Outros códigos de função permitem que um mestre determine ou ajuste a configuração de um controle remoto.
Vários códigos de função são definidos para um mestre DNP3 para controlar o próprio controle remoto ou equipamento co-localizado com o controle remoto. Um código de função é fornecido para permitir que o controle remoto responda autonomamente com uma mensagem não solicitada a eventos específicos que ocorrem em seu espaço de instalação. Aqui estão exemplos de quais códigos de função podem habilitar.
Como você pode ver, a maioria das mensagens são enviadas pelo mestre DNP3 para a remota DNP3. No entanto, como a Mensagem Não Solicitada pode ser iniciada por um controle remoto, ela normalmente é usada para relatar alarmes. Isso notifica o mestre DNP3 assim que ocorrer uma condição de alarme, ao invés de esperar pela próxima requisição.
Certifique-se de entender a principal limitação de todos os alertas não solicitados (“assíncronos”): não há função “manter vivo”. Para protocolos polled (“síncronos”), o gerenciador pesquisa o agente. Isso garante que um agente desabilitado seja prontamente identificado no próximo ciclo de polling.
Compare isso com o que acontece em um protocolo de mensagem não solicitada: um agente desativado permanece em silêncio. Esse silêncio é idêntico a um agente ativo relatando que “não tenho problemas agora”. É por isso que, sempre que possível, você deve procurar um mestre DNP3 que tenha alguma capacidade de consultar rotineiramente o status dos agentes. Isso mitiga uma das principais ameaças do uso do DNP3.
O protocolo DNP3 permite incluir objetos em uma das quatro classes.
De acordo com o padrão, a solicitação de leitura (chamada solicitação de pesquisa) de dados da Classe 0 retorna os valores atuais para objetos de todas as classes da Classe 0-3. A solicitação de dados da classe 1-3 retorna eventos (alterações de valor) da classe apropriada.
Portanto, na implementação do DNP3, suportamos quatro parâmetros de estação para configurar independentemente quatro tipos de solicitações de votação. Por exemplo, em uma configuração particular, uma solicitação de Poll para Classe 1-3 pode ser gerada a cada 10 segundos e uma chamada “pesquisa de integridade” – solicitação de votação para Classe 0, retornando os valores atuais de objetos em todas as Classes 0-3 , uma vez a cada 10 minutos.
Ambos os protocolos IEC-101 e IEC-104 permitem atribuir objetos a até 16 grupos e contadores a outros 4 grupos. Na prática, até agora foi suficiente enviar uma “interrogação de estação” geral para descobrir os valores atuais de todos os objetos ao estabelecer uma conexão. Posteriormente, apenas as alterações são transmitidas.
A estrutura DNP3 inclui uma biblioteca de objetos que são normalmente usados em sistemas SCADA. Esta biblioteca está disponível para download para membros do DNP Users Group (visite dnp.org para mais informações). Esses objetos incluem coisas como entradas binárias que são usadas para relatar características de equipamentos que possuem dois estados: energia ligada ou desligada, um painel de acesso aberto ou fechado, etc. Outro objeto comum é uma entrada analógica usada para relatar características que têm uma gama de valores: velocidade do exaustor entre 40 e 400 RPM, potência principal entre 110 e 128 VAC.
Essa biblioteca facilita para o fabricante projetar o respondedor remoto DNP3 para usar esses objetos comuns para relatar aos mestres upstream. Também facilita para os mestres integrar os dados coletados das remotas e apresentá-los para a tomada de decisão.
Sem essa estrutura de objetos comuns, os fabricantes devem desenvolver seu próprio modelo para relatar o status e fornecer capacidade de controle. Esses modelos, frequentemente bastante diferentes uns dos outros, devem então ser ‘compilados’ nos mestres e geralmente convertidos em algum tipo de objeto comum para gerenciamento eficiente. Outra ferramenta frequentemente encontrada nessas estruturas mais ‘abertas’ é uma interface proprietária ou módulo de tradução para acessar e controlar o controle remoto.
Os objetos da biblioteca DNP3 são divididos em Grupos e Variações. Por exemplo, o grupo de entrada analógica tem seis variações para fornecer inteiros de 16 ou 32 bits ou valores de ponto flutuante com ou sem um bitmap de status. O grupo de eventos analógicos tem oito variações para fornecer valores inteiros de 16 ou 32 bits ou valores de ponto flutuante com um bitmap de status e com ou sem carimbo de data/hora. Observe que o grupo Analog Event não inclui variações sem um bitmap de status.
Os protocolos básicos de telemetria serial, como o TBOS, são orientados a bytes, com um único byte trocado para se comunicar. Protocolos de telemetria serial expandida, como TABS, são orientados a pacotes com pacotes de bytes trocados para se comunicar. Os pacotes contêm um cabeçalho, dados e bytes de soma de verificação. O DNP3 também é orientado a pacotes e usa a estrutura de pacotes (tamanhos dos elementos em bits) mostrada na figura ilustrada abaixo.
Estrutura do Pacote DNP3
O mestre envia uma solicitação de leitura para um objeto ou objetos e a resposta do controle remoto contém as informações solicitadas, se disponíveis. O mestre envia um comando Operate para produzir as ações de saída associadas à referência de objeto selecionada. O controle remoto envia uma mensagem não solicitada quando ocorre um evento específico.
A figura anterior mostra o formato do pacote de mensagens. A unidade de dados de serviço de aplicativo DNP3 (ASDU) é digna de nota especial para o ajuste de conteúdo inteligente que é controlado pelos campos de tamanho de índice e qualificador. Esse design torna os dados do aplicativo disponíveis em um número impressionantemente flexível de configurações ou totalmente omitidos, se desejado.
A última seção enfocou a estrutura das mensagens DNP3 e ilustrou as primeiras camadas da mensagem. A camada de aplicativo combina um ASDU, um objeto empacotado em si mesmo, com um bloco de informações de controle de protocolo de aplicativo (APCI) para criar uma unidade de dados de protocolo de aplicativo (APDU). A camada de transporte divide o APDU em segmentos com um tamanho máximo de 16 bytes e os empacota com um cabeçalho de controle de transporte de 8 bits e separadores CRC de segmento de 16 bits em um quadro de transporte. A camada de enlace adiciona um cabeçalho às informações de controle e endereçamento para preparar o pacote para entrega a um destino específico. Essas camadas podem ser mapeadas para o modelo de quatro camadas com a camada de Internet omitida. Se o transporte serial for usado, a montagem do pacote é concluída e colocada na mídia de transporte para entrega.
Se o pacote for enviado por uma LAN/WAN, as três camadas DNP3 serão agrupadas na camada de Aplicativo. O pacote montado é encapsulado no Protocolo de Controle de Transporte (TCP) pela camada de transporte, que por sua vez é encapsulado no Protocolo de Internet (IP) pela camada da Internet. O User Datagram Protocol (UDP) também pode ser usado, mas apresenta alguns problemas adicionais relacionados à entrega confiável em redes congestionadas. A quarta camada é a camada de interface de rede onde o pacote montado é realmente conectado a algum tipo de mídia de transporte (por exemplo, par trançado de cobre, RG58 coaxial ou fibra). Embora esse modelo multicamadas possa parecer um pouco confuso, ele efetivamente isola as tarefas de comunicação e, por fim, auxilia no projeto e na implementação de uma rede.
Para ilustrar a função desse modelo em camadas, vamos examinar uma única solicitação de leitura DNP3 em uma LAN.
Estrutura do Pacote DNP3
Uma mensagem DNP3 passa pelas camadas de protocolo tanto no gerenciador quanto no agente. Cada camada aborda uma tarefa de comunicação específica.
O mestre DNP3 deseja saber o estado atual da alimentação da remota e prepara uma mensagem de solicitação de leitura para o objeto apropriado. Depois de passar por todas as três camadas DNP3, a mensagem é passada para a camada de Transporte TCP/UDP. A camada de Transporte adiciona um bloco de dados que identifica a porta mestre da qual a solicitação é enviada e a porta na qual espera que o processo DNP3 remoto esteja ouvindo as mensagens. O pacote assim formado é então passado para a camada IP. Aqui, um bloco de dados contendo os endereços IP e de acesso à mídia do mestre e do remoto é adicionado antes que todo o pacote montado seja passado para a camada de interface de rede. A camada de interface de rede verifica o acesso e a disponibilidade da mídia e coloca o pacote na mídia para transmissão.
Depois de passar por pontes e roteadores, com base nas informações de IP, o pacote finalmente chega ao remoto. Aqui ele passa pelas mesmas quatro camadas exatamente na ordem oposta à do mestre. Primeiro, ele é retirado da mídia pela camada de interface de rede. Depois de confirmar que o pacote está intacto e válido, a camada de interface de rede simplesmente o passa para a camada IP. A camada IP verifica o acesso à mídia e o endereço IP e os passa para a camada TCP/UDP, onde a porta de destino é verificada para aplicativos conectados. Se um aplicativo estiver escutando na porta de destino, o pacote será passado para a camada de aplicativo. Se a aplicação de escuta for o processo DNP3 remoto, a requisição Read é passada por suas três camadas para validar a requisição e identificar quais informações precisam ser coletadas.
DNP3 suporta Autenticação Segura usando uma chave pré-compartilhada por ambas as partes. Isso permite que o mestre verifique se está realmente se comunicando com uma estação externa específica e a estação externa pode verificar se o mestre está autorizado a usar os serviços da estação externa. Se o mestre solicitar a funcionalidade que o outstation considera privilegiado, o outstation iniciará a verificação de identidade.
Além da autenticação segura, o protocolo DNP3 não implementa criptografia de dados ou outros recursos de segurança, os protocolos IEC não possuem segurança integrada e a autenticação segura atualmente não é suportada no processo D2000 KOM.
Se a comunicação com a estação DNP3 estiver funcional, o processo D2000 KOM pode fornecer a lista de objetos recebidos e seus valores. Além disso, pode enviar solicitações de leitura de objetos para todos os grupos suportados. Isso é útil para configurar tags de comunicação: basta selecionar uma linha específica da lista de objetos e o grupo e o índice apropriados serão inseridos na configuração do tag de comunicação.
A coluna Origem também é exibida, indicando como o valor veio.
A implementação atualiza continuamente a coluna Valor para que o usuário veja os valores instantâneos dos objetos.
Sua maior variabilidade e capacidade de expressão fazem com que valha a pena investigá-lo. Em outros aspectos (por exemplo, para controle de consistência de dados superdimensionados ou complicações com camada de pseudo-transporte), o design de protocolos IEC pode ser mais benéfico. No entanto, para implantar o D2000 fora da Europa, o suporte DNP3 é imprescindível.
INOVEX DIGITAL. Todos os direitos reservados.