Utilização de Drivers Kepware com BluePlant

Em processos contínuos um dos requisitos para os sistemas de automação é a alta disponibilidade. Em arquiteturas de automação que utilizam sistema SCADA comunicando com CPs é importante que ambos os níveis possuam disponibilidade. Ou seja, é necessário conseguir com que falhas sejam diagnosticadas sem que o sistema fique indisponível em função destas falhas.

Para esta finalidade os sistemas SCADA e CPs disponibilizam maneiras de configuração redundante. Desta forma os sistemas podem ser duplicados e comunicam entre si detectando falhas e no caso delas acontecerem, as falhas não irão provocar a parada do sistema.

Este documento trata da redundância em sistemas utilizando o recurso de redundância de Servidores com o software SCADA BluePlant utilizando drivers de comunicação da Kepware DNP3 Client e IEC 61850 MMS Client usando topologia Hot-Hot.


Descrição

O software SCADA BluePlant possui a funcionalidade de Redundância de Servidores. A redundância no caso do BluePlant é implementada de forma nativa em uma arquitetura Hot-Standby. Neste caso, como os drivers de comunicação não são nativas do BluePlant, esta redundância não pode ser usado. Por isso a redundância desta NAP utiliza uma arquitetura do tipo Hot-Hot. Neste caso, ambos Servidores configurados permanecem com a comunicação ativa com os dispositivos que podem ser CPs ou outros equipamentos e com as estações Cliente. Um dos servidores é o prioritário e caso as falhas aconteçam, as estações clientes acessam a máquina que não está em falha. Caso seja necessário tratar alguma condição de falha não coberta, então o usuário deverá implementar um script para tomar alguma ação ou a troca de servidor para comunicação.


Definição da Arquitetura de Referência

A arquitetura utilizada nesta documentação é semelhante a da Figura 1.

 

Figura 1. Arquitetura com Servidores BluePlant Redundantes Hot-Hot

No teste realizado desta NAP, a rede de Supervisão e a rede de Aquisição não estavam separadas fisicamente. Desta forma todos os nós da arquitetura estavam conectados na mesma rede física padrão Ethernet.

No caso deste documento o dispositivo na rede de aquisição é uma UTR da Série Hadron Xtorm. O protocolo utilizado para comunicação entre o BluePlant e o Kepware é OPC DA. Os protocolos utilizados para comunicação entre o Kepware e a Xtorm são o DNP3 e IEC 61850. Devido ao fato da redundância ser do tipo Hot-Hot, a configuração dos drivers na Xtorm deve ser duplicada, pois ambos Servidores estão comunicando ao mesmo tempo com ela.

O projeto do BluePlant em anexo a esta NAP, possui tanto drivers nativos (DNP3 Client, IEC 61850 MMS Client, IEC104 Server e MODBUS TCP), quanto drivers da Kepware (DNP3 Client e IEC 61850 MMS Client). Os drivers nativos estão implementados apenas para rodar em aplicações simples, já os drivers da Kepware em aplicações simples e redundantes tipo Hot-Hot.


Material Utilizado no Exemplo

Para a execução deste sistema foram utilizados os seguintes softwares:

  • BluePlant versão bp-2012.1.67
  • MasterTool Xtorm  versão 1.07
  • KEPServerEX versão 5.21.112.0
  • CPU HX3040 da Série Xtorm versão de firmware 1.1.0.12
  • 2 computadores IBM-PC utilizados como Servidores
  • 1 computador IBM-PC utilizado como Cliente

Atenção:

Usando a versão do KEPServerEX versão 5.21.112.0 os comandos IEC 61850 não funcionaram, e para isso a Kepware disponibilizou um path (anexo a esta NAP) KEPServerEXPatch5.21.112.1 para resolver este problema. Esta correção provavelmente irá entrar na próxima versão liberarada pelo fornecedor.


Aplicação da Hadron Xtorm

O projeto em anexo a esta NAP, foi desenvolvido para testar os drivers de comunicação da área Elétrica DNP3 e IEC 61850. Com o BluePlant existe uma comunicação MODBUS TCP, no qual a Xtorm ao receber ou dar um comando, retorna o resultado via MODBUS para conferência do resultado na própria tela do BluePlant.

Para esta NAP, basta abrir o projeto em anexo e carregar na Hadron Xtorm,  não sendo necessário fazer nenhuma alteração. Apenas uma atualização de projeto caso seja aberto em uma versão mais recente do MasterTool Xtorm.


Configurando o Kepware

Para permitir a comunicação entre CP e o software SCADA BluePlant neste exemplo é necessário instalar o KEPServerEX. Na instalação é necessário selecionar o driver DNP3 Client e o driver IEC 61850.


Configuração OPC

Após abrir o projeto do Kepware em anexo, é necessário conferir se a opção "Return initial updates for items in a single call-back" está desmarcada, Figura 2. Para visualizar esta opção, deve-se entrar no menu "File/Project Properties..." Para drivers de comunicação que utilizam o buffer da Kepware, caso esta opção esteja marcada,  haverá perda de eventos. Para maiores informações consulte o help do driver no Kepware.

 

Figura 2. Configuração OPC


Configuração DNP3 Client

Buffer Interno

Um ponto importante para se observar na configuração do driver DNP3 é o buffer interno para cada ponto, como pode ser observado na Figura 3.


Figura 3. Configuração Buffer DNP3 no Kepware

O Tamanho deste buffer deve ser ajustado de acordo com a aplicação. Este Buffer serve para armazenar eventos na indisponibilidade do BluePlant. O tamanho é por ponto de comunicação e caso receba mais do que configurado, descarta o evento mais antigo.


Endereço DNP3

Cada device possui um endereço para comunicação, e devido a solução da redundância ser do tipo Hot-Hot, para cada servidor este campo muda. O projeto em anexo está configurado da seguinte maneira:

- Servidor 1 (Master Address = 5 e Slave Address = 6)

- Servidor 2 (Master Address = 7 e Slave Address = 8)


 

Figura 4. Configuração do endereço DNP3 no Kepware

Isso faz com que o projeto do Kepware seja diferente para cada Servidor. É a única configuração diferente referente ao DNP3.


Mapeamento DNP3

Todo o mapeamento dos tags DNP3 são realizadas de forma manual. Para maiores informações, consulte o help do driver no Kepware, que mostra como realizar cada mapeamento suportado, geralmente respeitando a seguinte nomenclatura:

  • OBJ.VAR.IDX (Objeto, Variação, Index)

Exemplo:

1.2.5.Value  = Objeto 1, Variação 2, Índice 5

Atenção:

Se o IED DNP3 utilizado para comunicar com o BluePlant não for uma Hadron Xtorm devem ser executados procedimentos equivalentes durante a criação do projeto para o IED.


Configuração IEC 61850 MMS Client

Para a configuração do driver IEC 61850 no Kepware, é necessário observar alguns detalhes.


Mapeamento IEC 61850

O mapeamento dos pontos de comunicação pode ser realizados de forma manual, ou automática, fazendo assim a leitura de toda a base de dados disponíveis no IED. 

 

Figura 5. Criação automática dos mapeamentos

Para que o projeto tenha a base de dados atualizada com os dados do IED, basta clicar no botão "Auto Create", que todos os mapeamentos disponíveis no IED são criados. Caso seja um projeto simples, isso pode ser feito sempre, mas caso o projeto seja redundante e queira usar reports, somente pode ser realizado na criação do projeto, pois mais tarde terá que ser realizado uma customização, que será apresentada nas próximas seções.

Buffer IEC 61850

Conforme mostra a Figura 6, é importante configurar o tamanho do buffer para cada atributo reportado. Este parâmetro deve ser ajustado de acordo com cada aplicação.


Figura 6. Configuração do Buffer IEC 61850


Report IEC 61850

Um ponto importante que deve ser analisado no inicio do projeto é escolher qual Report deseja assinar para receber os eventos. Quando é instanciado o driver e realizado a leitura automática de toda a base de dados do IED, todos os Reports são disponibilizados. Para o driver da Kepware, se ele tiver mapeado o Report, então ele assina automaticamente. Lembrando que para cada Report é permitido apenas um cliente conectado. 

No caso da redundância do tipo Hot-Hot, na aplicação da UTR Xtorm deve haver uma replicação de Reports. Portanto o projeto do MasterTool Xtorm possui dois reports, uma para cada um dos Servidores. Cada Servidor deve assinar apenas um desses Reports. Isso faz com que o projeto do Kepware seja diferente para cada Servidor. Apesar disso o projeto do BluePlant será o mesmo para ambos servidores.


Figura 7. Configuração do Report

A Figura 7 mostra a alteração que deve ser realizada nos projetos para cada servidor. Para que no BluePlant fique totalmente transparente a comunicação independente de qual servidor esteja rodando, é necessário fazer com que o tag OPC dos reports seja o mesmo em cada um dos projetos do Kepware, somente alterando o endereço do ponto de comunicação. 

O ponto "A" da imagem, ilustra o TAG que foi importado como "Servidor1" e foi renomeado para um nome Genérico de "ServidorX". Já no ponto "B" da imagem, o nome deve ser  mantido como "Servidor1" para o projeto que roda no Servidor 1, e deve ser alterado para "Servidor2" no projeto que roda no Servidor 2. Atente que esse é o nome do Report que foi dado no projeto da Xtorm. Então é fundamental que o nome do report seja de fácil interpretação.

Além dos Reports, todo o mapeamento do LLN0 deve ser revisado conforme mostra a Figura 8.


Figura 8. Configuração do LLN0

No LLN0 do projeto no Kepware, deve-se apenas deixar os mapeamentos relacionados ao Report que se deseja assinar, deletando todos os outros pontos relacionados aos outros Reports. Também deve-se renomear ao tags na coluna "Tag Name", de forma que fique um nome genérico independente do servidor que estará rodando a aplicação (Tag OPC). Na coluna "Address", deve ser ajustada conforme o servidor que irá rodar a aplicação. Nesta imagem está a configuração do Servidor 1, mas caso seja a do servidor 2, deve-se renomear apenas o endereço substituindo o valor "1" por "2", para que fique exatamente com o nome do Report conforme foi configurado no IED.

Atenção:

Se o IED IEC 61850 utilizado para comunicar com o BluePlant não for uma Hadron Xtorm devem ser executados procedimentos equivalentes durante a criação do projeto para o IED.


Projeto com o BluePlant

O projeto em anexo a esta NAP, foi desenvolvido para testar os drivers de comunicação da área Elétrica DNP3 e IEC 61850, tanto nativo quanto usando driver Kepware OPC. Em cada tela de teste implementada, é informado o retorno tanto do driver local quanto do driver usado do Kepware. 

Atenção:

Driver nativo do BluePlant está implementado para funcionar apenas em modo simples, ao rodar em modo redundância alguns eventos podem não funcionar corretamente.

 

Figura 9. Exemplo IEC 61850


Configurando a Redundância de Servidores

Como o a redundância é para ser do tipo Hot-Hot, então a opção de redundância deve estar desabilitada. Em ambos os servidores deve rodar a mesma aplicação.

 

Figura 10. Configuração da Redundância de Servidores

Para questões não referentes aos drivers de comunicação, ainda não foram criados scripts e telas para controlar a redundância tipo Hot-Hot, no que tange a:

  • Sincronização de Banco de Dados;
  • Sincronização de Projeto;
  • Sincronização de Telas;
  • Controle para switchover nos clientes;


Executando a Aplicação

Antes de executar a aplicação a mesma deve ser copiada para os dois servidores. Para executar o projeto, selecionar, no menu "Run" de cada Servidor a opção "Startup" e pressionar o botão "Run Startup" que irá iniciar o Runtime onde a aplicação pode ser testada.

A Figura 11 apresenta uma linha de comando. Esta mesma linha de comando pode ser executada através de um atalho (*.bat), onde o caminho do projeto e o endereço IP deve ser atualizado. Esse (*.bat) deve ser executado em ambos servidores.


Figura 11. Server Command Line

Para visualizar a aplicação em um Client remoto, a Figura 12 apresenta a linha de comando. Esta mesma linha de comando pode ser executada através de um atalho (*.bat).

Figura 12. Client Command Line


Testando e Depurando

A aplicação descrita até o momento permite o funcionamento dos servidores do BluePlant como redundantes. O projeto está anexo a este documento. 


DNP3

Para testar o driver DNP3, basta entrar nas telas de cada grupo e executar o comando que deseja testar. Os comandos de Classe 0 podem demorar até um minuto e os demais devem ser instantâneos.


Objetos DNP3

Segue abaixo tabela dos objetos DNP3 testados nesta aplicação.

Obj.

Var

Descrição

1

1

Binary Inputs - Packed format

1

2

Binary Inputs - With flags

2

1

Binary Input Event - Without time

2

2

Binary Input Event - With absolute time

2

3

Binary Input Event - With relative time

12

1

Control relay output block

20

1

Counter – 32-bit with flag

20

2

Counter – 16-bit with flag

20

5

Counter – 32-bit without flag

20

6

Counter – 16-bit without flag

21

1

Frozen counter – 32-bit with flag

21

2

Frozen counter – 16-bit with flag

21

9

Frozen counter – 32-bit without flag

21

10

Frozen counter – 16-bit without flag

22

1

Counter Event - 32-bit with flag

22

1

Counter Event - 16-bit with flag

30

1

32 Bits Analog Input

30

2

16 Bit Analog input with flag

30

3

32 Bits Analog Input without flag

30

4

16 Bit Analog input without flag

32

1

32 Bits Analog Input change event

32

2

16 Bit Analog change event without flag

32

3

32 Bit Analog change event with flag

32

4

16 Bit Analog change event with flag

40

2

16 Bit Analog output

41

1

32Bit Analog output Status

41

2

16Bit Analog output Status


Troughput DNP3
Para testar o troughput DNP3, foi desenvolvido uma tela de historiador, conforme pode ser visto na Figura 13.
 
Figura 13. Historiador

Na aplicação e nos mapeamentos, estão configurados 500 pontos digitais para eventos. No canto superior esquerdo, é possível configurar a quantidade de pontos (Qtd Pontos), a quantidade de eventos que será gerada por cada ponto (Qtd Repetições), e o tempo que cada ponto permanece ligado e desligado. Ao pressionar no botão (DISPARA), é gerado a avalanche de eventos. 
Para conferir o resultado, abaixo da tela do historiador é permitido colocar filtros de tempos para acesso ao banco de dados, possibilitando assim apenas verificar os eventos gerados na avalanche.
 
Figura 14. Exemplo Avalanche DNP3

Na figura acima há um exemplo de avalanche DNP3, no qual foi gerado 10 eventos. Os eventos aparecem duplicados, pois foram recebidos tanto pelo driver local quanto pelo driver do Kepware.

Para medir o troughput do driver de comunicação, é necessário monitorar a fila de eventos da UCP HX3040 e de cada Server DNP3 na Xtorm. Para este teste, foi desabilitado o driver no BluePlant e no Kepware e foram gerados 2000 eventos para um mesmo ponto.

Figura 15. Troughput DNP3

Após ter terminado de gerar os 2000 eventos, ambos os drivers foram reiniciados e em 1 segundo todo o histórico foi lido da fila do DNP3. Note que a fila da UCP não baixou devido a não ter reiniciado o driver do Servidor 2. Isso foi feito de propósito para chamar a atenção de que se um Servidor estiver fora e ocorrerem mais de 4500 eventos, a fila da UCP irá estourar e ficará gerando diagnóstico de estouro da fila.
Ao final deste teste, ao consultar o historiador do BluePlant, possui apenas 2200 eventos para este único ponto. Sendo 2000 eventos do driver nativo e 200 do driver da Kepware. Esse fato ocorre devido a configuração do tamanho do buffer ser de 200 eventos por ponto, conforme configurado na Figura 3. Para cada projeto deve-se avaliar o tamanho necessário. Se repetir este mesmo teste configurando para que 500 pontos sejam alterados num laço de 4 repetições, gerando novamente um total de 2000 eventos, todos estarão na base de dados do historiador sem problemas.
O troughput tanto do driver proprietário quanto do Kepware é cerca de 2000 eventos por segundo. 

IEC 61850
Para testar o driver IEC 61850, basta entrar nas telas de cada grupo e executar o comando que deseja testar. Os comandos devem ser instantâneos.

Logical Nodes
Segue abaixo tabela dos Logical Nodes testados nesta aplicação.

Logical Node (LN)

Data Object (DO)

Data Attribute (DA)

Acesso

XCBR

BlkOpn

stVal

Leitura

XCBR

Pos

stVal

Leitura

PDIF

OpCntRs

stVal

Leitura

ATCC

TapChg

valWTr

Leitura

ATCC

TapPos

valWTr

Leitura

GGIO

IntIn

stVal

Leitura

GGIO

ISCSO

Oper.ctlVal

Escrita

GGIO

SPCSO

Oper.ctlVal

Escrita

GGIO

SPCSO

Oper.ctlVal

Escrita

MMXU

Hz

mag.f

Leitura


Troughput IEC 61850
Para testar o troughput IEC 61850, foi desenvolvido uma tela de historiador, conforme pode ser visto na Figura 13.
Na aplicação e nos mapeamentos, está configurado 1 ponto digital para evento. No canto superior esquerdo, é possível configurar a quantidade de eventos que será gerada por cada ponto (Qtd Repetições), e o tempo que o ponto permanece ligado e desligado. Ao pressionar no botão (DISPARA), é gerado a avalanche de eventos. 
Para conferir o resultado, abaixo da tela do historiador é permitido colocar filtros de tempos para acesso ao banco de dados, possibilitando assim apenas verificar os eventos gerados na avalanche.

 
Figura 16. Exemplo Avalanche IEC 61850

Na Figura 16 tem um exemplo de avalanche IEC 61850, no qual foi gerado 10 eventos. Os eventos aparecem duplicados, pois foram recebidos tanto pelo driver local quanto pelo driver do Kepware.

Para medir o troughput do driver de comunicação, é necessário monitorar a ocupação do buffer interno (de 0 a 100, em %, aplicável somente para Buffered Reports) na Xtorm.
(DG_IEC_61850_Server.tReportControlBlock. tReportControlBlock[n].byOccupation)
Para este teste, foi desabilitado o driver no BluePlant e no Kepware e foram gerados 400 eventos para um mesmo ponto, pois 400 eventos desse tipo de ponto ocupam 98% do buffer da Xtorm.

Figura 17. Troughput IEC 61850

Após ter terminado de gerar os 400 eventos, ambos os drivers foram reiniciados e em 200 ms todo o buffer foi lido da fila do IEC61850. Note que o buffer do Servidor 2 não baixou devido a não ter reiniciado o driver do Servidor 2. Isso foi feito de propósito para chamar a atenção de que se um Servidor estiver fora e ocorrerem mais eventos que o buffer suporta, poderá haver perda de eventos.
Ao final deste teste, ao consultar o historiador do BluePlant, o mesmo possui apenas 500 eventos para este único ponto. Sendo 400 eventos do driver nativo e 100 do driver da Kepware. Esse fato ocorre devido a configuração do tamanho do buffer ser de 100 eventos, conforme configurado na Figura 6. Para cada projeto deve-se avaliar o tamanho necessário. Se repetir este mesmo teste, aumentando o tamanho do buffer para 400, gerando novamente um total de 400 eventos, todos estarão na base de dados do historiador sem problemas.
O troughput tanto do driver proprietário quanto do Kepware para um ponto digital, pela medição feita é cerca de 2000 eventos por segundo.

ARQUIVO BAIXAR
Projeto Português

Ficou com dúvidas? Então clique no botão abaixo e fale com a gente!

ENVIE SUA DÚVIDA

Esta publicação foi relevante para você? Avalie o material para que possamos continuar melhorando.

Clique para gravar a avaliação
Gostou? Então compartilhe



Assine nossa newsletter e saiba tudo sobre automação!

Receba novidades sobre o mercado da automação, nossas soluções e as ações mais recentes envolvendo a Altus diretamente no seu e-mail.