Redundância de Servidores SCADA 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.


Descrição

O software SCADA BluePlant possui a funcionalidade de Redundância de Servidores. A redundância é do tipo Hot-Standby. Neste caso um dos dois Servidores configurados permanece como Ativo (Hot) comunicando com o os dispositivos que podem ser CPs ou outros equipamentos e com as estações Cliente. Enquanto isso o outro servidor permanece como Reserva (Standby) detectando possíveis falhas. Caso as falhas aconteçam, o Servidor Reserva assume e passa a comunicar com os Clientes e com os Dispositivos.


Definição da Arquitetura de Referência

Este documento tem como objetivo esclarecer a utilização do recurso de redundância de Servidores em um projeto com o software SCADA BluePlant. A arquitetura utilizada nesta documentação é semelhante a da Figura 1.

 

Figura 1. Arquitetura com Servidores BluePlant Redundantes

Contudo no teste realizado 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 os dispositivos na rede de aquisição serão CPs da Série Nexto. O protocolo utilizado para comunicação entre estes dispositivos e os Servidores do BluePlant é o OPC DA através de um OPC Server. Os mesmos passos podem ser utilizados para uma comunicação utilizando outro protocolo de forma análoga.


Material Utilizado no Exemplo

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

  • BluePlant versão bp-2012.1.67
  • MasterTool IEC XE versão 2.05
  • OPC DA Server disponível na versão 2.05 do MasterTool IEC XE
  • CPU NX3030 da Série Nexto versão de firmware 1.5.1.8
  • 2 computadores IBM-PC utilizados como Servidores
  • 1 computador IBM-PC utilizado como Cliente


Criando a aplicação do CP

Este capítulo demonstra como criar um projeto de um CP para comunicar com um software SCADA. Para o teste foi utilizada uma UCP NX3030 que irá comunicar o software SCADA BluePlant através do OPC Server. Para demonstração foi criado um projeto simples através do menu ArquivoNovo Projeto e Selecionando a opção Projeto Padrão MasterTool IEC XE.

Após criado o projeto com auxílio do Wizard do MasterTool IEC XE a POU MainPrg foi aberta e o seguinte código foi criado:

PROGRAM MainPrg

VAR

X : INT;

Y : INT;

Z : INT;

END_VAR


X := X + 1;

Y := Y + 5;

Z := Z + 10;


O código irá incrementar o valor das variáveis criadas que poderão ser monitoradas no software SCADA.

Após a edição da POU MainPrg, foi adicionado ao projeto o objeto Symbol Configuration. Ao abrir o objeto o botão Compilar deve ser pressionado. Após isso as 3 variáveis criadas foram marcadas para serem mapeadas para o OPC Server conforme a Figura 2.

 

Figura 2. Configuração do objeto Symbol Configuration

Uma vez criado o código é necessário fazer a configuração do endereço de IP clicando sobre NET1 da UCP NX3030.

 

Figura 3. Configuração Ethernet da UCP NX3030

Por fim o objeto Device deve ser aberto. Nele um Gateway deve ser adicionado. Pode ser utilizada a configuração padrão sugerida pelo MasterTool IEC XE. Para selecionar o dispositivo onde será carregada a aplicação deve-se clicar duas vezes sobre Gateway. Todos os dispositivos disponíveis irão ser exibidos conforme a Figura 4.

Figura 4. Selecionando o Dispositivo

Basta clicar duas vezes sobre o dispositivo para selecioná-lo. O dispositivo selecionado irá aparecer em negrito. Após isso executar o comando do menu ComunicaçãoLogin. Após carregada a aplicação executar o comando do menu DepurarIniciar.

O projeto criado com este documento está junto do Anexo com o nome RedundanciaBP.project.


Configurando o OPC Server

Para permitir a comunicação entre CP e o software SCADA BluePlant neste exemplo é necessário configurar o OPC Server. Este serviço é disponibilizado em conjunto com o instalador do MasterTool IEC XE. Por isso o MasterTool IEC XE deve ser instalado no Servidor BluePlant Primário e Servidor BluePlant Secundário.

Após a instalação o MasterTool IEC XE deve ser executado como administrador. No MasterTool IEC XE acessar o menu ComunicaçãoConfiguração OPC. A configuração pode ser feita conforme a Figura 5.

 

Figura 5. Configuração OPC

O campo Endereço de IP Ativo deve ser alterado conforme o endereço de IP do CP configurado no capítulo anterior. Esta configuração deve ser idêntica nos dois servidores.


Criando um Projeto com o BluePlant

Neste capitulo será apresentado como criar e configurar uma aplicação no BluePlant para que funcione com Redundância de Servidores e comunique com um CP. Além disso será mostrado brevemente como executar a aplicação nos servidores e nos servidores remotos.

Ao executar o software BluePlant é aberto um ambiente de gerenciamento dos projetos. Neste é possível editar projetos existentes, atualizar licenças ou criar novos projetos. Para a criação de um projeto novo deve-se selecionar a opção "New Project...", que abrirá opções de configuração do projeto a ser criado, como apresentado na Figura 6.

 

Figura 6. Gerenciador de Projetos BluePlant – New Project

O campo "Name" deve ser preenchido com o nome que se deseja dar ao projeto, no caso foi escolhido Redundancia, então o usurário deve clicar em "Create New Project" para que o projeto seja criado e aberto para edição, ou "<


Configuração da Comunicação no BluePlant

Após aberto o ambiente de edição de projetos do BluePlant, o usuário deverá criar os pontos de comunicação para acessar os dados das variáveis criados no CP nos capítulos anteriores. Então deve clicar na opção "Edit", no item "Devices" e então na aba "Channels", pressionar o botão "Create New Channel". Será apresentado a tela conforme Figura 7.

 

Figura 7. Criando um novo Channel

Deve ser escolhido o Protocolo OPCXmlDA – OPC Xml/DA Client. Após a criação do Channel é necessário criar um Node na aba "Nodes" pressionando o botão New. O Node criado deve utilizar o Channel criado anteriormente.

 

Figura 8. Criando um Novo Node

Com o Node criado a configuração da PrimaryStation deve ser realizada na coluna com esse nome no Node que foi criado. A configuração pode ser vista na Figura 9.

 

Figura 9. Configurando a Primary Station

O campo Service URL é o mais importante a ser preenchido. O valor do campo define qual o Servidor OPC será utilizado para comunicação. Neste caso o Servidor é CoDeSys.OPC.DA. Uma vez configurado a Primary Station é possível importar os dados de Points e Tags diretamente do CP. Para isso deve ser pressionado o Botão Import sobre o Node criado. Na tela apresentada basta clicar no botão Refresh para que os dados sejam exibidos conforme a Figura 10.

 

Figura 10. Importando Tags OPC

As variáveis que foram criadas no CP serão listadas assim como duas variáveis usadas para verificação do Status da Comunicação OPC. Ao clicar em Ok o acesso as variáveis serão salvas no projeto e elas poderão ser usadas como Tags em outras partes do programa.


Criando uma Tela para Acesso as Variáveis

Agora o usuário terá de editar a tela em que serão acessados os dados do CP, para isso basta clicar no menu "Draw".

 

Figura 11. Edição da Tela Principal

A Figura 11 apresenta a Tela principal da Aplicação criado para o projeto do BluePlant. Ela possui 7 elementos. 3 destes elementos são Labels com os nomes das variáveis X, Y e Z. Estes elementos são do tipo TextBlock, sendo necessário apenas editar a sua propriedade Text para alterar a sua aparência. Ao lado destes são presentes os elementos numerados de 1 a 3. Eles são do tipo TextBox e serão utilizados para exibir o valor das Tags X, Y e Z respectivamente.

Após inserir o objeto na tela ele deve ser editado clicando duas vezes sobre o mesmo. A tela da Figura 12 será exibida.

 

Figura 12. Edição dos TextBox na Tela Principal

As configurações a serão alteradas estão na configuração de TextIO. Para apresentar o valor da Tag X o campo ObjectName deve ser Tag.PLC01_Application_MAINPRG_X. O mesmo deve ser feito na configuração dos campos para exibir as Tags Y e Z. Contudo os campos devem ser preenchido com os nomes das Tags ser Tag.PLC01_Application_MAINPRG_Y e Tag.PLC01_Application_MAINPRG_Z respectivamente.

O objeto identificado com o número 4 na Figura 11 é um Button e será detalhado no próximo capítulo.


Configurando a Redundância de Servidores

Por fim o usuário terá de editar a configuração de redundância no projeto do BluePlant, para isso basta clicar no menu "Info". Neste menu existe uma aba chamada Redundancy onde será configurada a redundância de servidores.

 

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

A Figura 13 mostra a configuração de redundância. Para permitir o uso da redundância é necessário selecionar a opção Enable configuration. Após isso deve ser definido o endereço de IP do Servidor BluePlant Primário (Primary Server IP) e do Servidor BluePant Secundário (Secondary Server IP). Nestes casos foi utilizada a porta TCP 3101, padrão, em ambos os servidores.

Neste caso a opção Historian Replication foi definida como Alarm and Tag Historian. Isso significa que tanto os alarmes quanto o historiador serão sincronizados entre os servidores. Existem outras opções para sincronizar somente uma destas funcionalidades ou nenhuma delas.


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.

 

Figura 14. Seleção da Execução do Projeto

A execução também pode ser feita através da linha de comando presente no campo Server Command Line da Figura 13. A Figura 15 apresenta a linha de comando. Esta mesma linha de comando pode ser executada através de um atalho (Server.bat) que está anexo a este documento, onde o caminho do projeto e o endereço IP deve ser atualizado.


Figura 15. Server Command Line

Para visualizar a aplicação em um Client remoto, é possível utilizar a linha de comando presente no campo Client Command da Figura 13. A Figura 16 apresenta a linha de comando. Esta mesma linha de comando pode ser executada através de um atalho (Client.bat) que está anexo a este documento.

 

Figura 16. Client Command Line

A Figura 17 apresenta o projeto em execução em um cliente remoto.


Figura 17. Projeto em Execução


Testando e Depurando a Redundância de Servidores

A aplicação descrita até o momento permite o funcionamento dos servidores do BluePlant como redundantes. O projeto anexo Redundancia.tproj está anexo a este documento. Além do que já foi descrito até o momento o projeto também permite verificar o estado da redundância de Servidores assim como manipular o estado dos servidores ou ser útil para diagnosticar alguma falha que venha a acontecer no sistema.


Abrindo a Tela de Status da Redundância de Servidores

Ao botão identificado com o número 4 na Figura 11 que apresenta a Tela Principal foi adicionada uma ação para chamar uma nova tela onde o estado da redundância pode ser verificado. Após inserir o objeto na tela ele deve ser editado clicando duas vezes sobre o mesmo. A tela da Figura 18 será exibida.

 

Figura 18. Botão para Chamar Tela de Redundância

As configurações que serão executadas estão na configuração de Action. Deve ser selecionado em Event a opção MouseLeftButtonDown e a Action deve ser RunExpressions. Na Expressão deve ser colocado Display.REDUNDANCY.open(). A expressão irá abrir a tela chamada REDUNDANCY que está presente no projeto Redundancia.tproj anexo.


Implementação da Tela de Status da Redundância de Servidores

A tela REDUNDANCY foi construída com várias informações de diagnóstico e comandos que podem ser usados para saber como estão os servidores e a aplicação como um todo. Assim como permite comandos de partida e parada de módulos e troca de estados da redundância. Ela é configurada como um diálogo que é exibido e fechado. A Figura 19 apresenta a tela com os principias elementos numerados para referência no restante do capítulo.

 

Figura 19. Tela de Redundância

A tela pode ser separada em 3 grupos de funcionalidades.

  • Informações e comandos dos módulos
  • Informações dos Servidores e da Redundância
  • Comandos

A seguir serão apresentados os grupos e como estes estão implementados.


Informações e Comandos dos Módulos

Os itens identificados na com os números de 1 a 8 são utilizados para representar os seguintes módulos do BluePlant respectivamente: Alarmes, Históricos, Dispositivos, DataSets, Scripts, Relatórios, OPC Server e Extensões. As explicações a seguir serão dadas para o módulo de alarmes (item 1) e se aplicam de forma análoga para o restante.

O primeiro campo é um LabelBox usado para indicar o estado do módulo. A configuração do TextIO usada para este LabelBox é apresentada na Figura 20.

 

Figura 20. Estado do Módulo

A expressão usada para o TextIO está a seguir.

TIf(Info.Module.Alarm.IsPaused,"PAUSADO",TIf(Info.Module.Alarm.IsRunning,"ATIVO","INATIVO"))

A expressão utiliza 2 TIf encadeados. O primeiro parâmetro do TIf é uma expressão Booleana. Caso o resultado da expressão seja verdadeira é retornado o segundo parâmetro do TIf. Caso a expressão seja falsa o terceiro parâmetro do TIf é retornado.

Neste caso, caso Info.Module.Alarm.IsPaused igual a TRUE indica que o módulo de Alarmes está "PAUSADO" e este texto será exibido. Caso contrário será testado Info.Module.Alarm.IsRunning. Se este último for TRUE, então o texto exibido será "ATIVO", mas caso seja FALSE o texto será "INATIVO".

Já os botões que seguem são utilizados respectivamente para partir o módulo, pausar o módulo e parar o Módulo. No Botão de partida é usada a Action SetValue com o Valor 1 no objeto Info.Module.Alarm.IsRunning. No botão de pause é usada a ação de ToggleValue é utilizada no objeto Info.Module.Alarm.IsPaused. Por fim no Botão de parar usada a Action SetValue com o Valor 1 no objeto Info.Module.Alarm.IsRunning.


Informações dos Servidores e da Redundância

Os campos da Figura 19 identificados com os números 9 a 18 e 23 a 26 exibem informações sobre os servidores, o status da redundância, mensagens de erro, etc. Eles são implementados em objetos LabelBox ou TextBlock e cada um possui uma informação diferente dependendo da expressão presente no campo TextOutput de cada um dos itens.

A seguir são apresentadas as descrições de cada um dos campos e expressão utilizada.

9 - Informa se a redundância de Servidores está ativa ou não. A expressão utilizada para expressão no campo é:

TIf(Server.IsRedundancyEnabled,"SIM","NÃO")


10 - Informa qual o nome do Computador que no momento é o computador Ativo na redundância de Servidores. Este é o nome configurado no sistema operacional. A expressão utilizada para expressão no campo é:

Server.ComputerName


11 - Indica o Estado do Computador configurado como Primário na Redundância. A expressão utilizada para expressão isso no campo é:

TIf(Server.IsPrimary,"ATIVO", TIf(Server.IsStandByActive, "RESERVA", "INATIVO"))


12 – Quantidade de eventos a serem sincronizados entre os servidores. A expressão utilizada para expressão no campo é:

Alarm.NumberOfPendentEventsForSaving


13 – Caminho da Aplicação do Servidor. A expressão utilizada para expressão no campo é:

Server.UpdateProjectIPPathName


14 – String com a última mensagem de sincronização entre os Servidores. A expressão utilizada para expressão no campo é:

Historian.LastRedundancySyncMessage


15 – Data e hora da última sincronização entre Servidores. A expressão utilizada para expressão no campo é:

Historian.LastRedundancySyncTimestamp


16 – String com a última mensagem de erro de sincronização entre os Servidores. A expressão utilizada para expressão no campo é:

Historian.LastRedundancySyncErrorMessage


17 – Data e hora do último erro de sincronização entre Servidores. A expressão utilizada para expressão no campo é:

Historian.LastRedundancySyncTimestamp


18 -  String com a última mensagem de erro de armazenamento de Alarme durante sincronização entre Servidores.

Alarm.LastStoredErrorMessage


23 – - Informa qual o nome do Computador que está executando a aplicação como Cliente. Este é o nome configurado no sistema operacional. A expressão utilizada para expressão no campo é:

Client.ComputerName


24 – Quantidade de eventos a serem sincronizados entre os servidores. A expressão utilizada para expressão no campo é:

Server.NumberOfObjectsForSendingToStandBy


25 - Indica o Estado do Computador configurado como Secundário na Redundância. A expressão utilizada para expressão no campo é:

TIf(Server.IsSecondary,"ATIVO", TIf(Server.IsStandByActive, "RESERVA", "INATIVO"))


26 – Quantidade de alarmes a serem sincronizados entre os servidores. A expressão utilizada para expressão no campo é:

Alarm.NumberOfPendentAlarmsForSaving


Comandos

Troca Estado da Redundância (19)

Este comando exibe a tela chamada REDUNDANCIA_TROCA_ATIVO_CMD. Esta tela é do tipo Dialog e tem por objetivo trocar o estado entre os servidores. Ou seja, o Servidor que está como Ativo passa para reserva e vice-versa. No CodeBehind desta tela a Function DialogOnOK deve ser editada como a seguir.

Public Function DialogOnOK() as Boolean

if @Server.IsStandByActive = True And @Server.NumberOfObjectsForSendingToStandBy <= 1000 Then

@Server.SwitchToStandby()

Dim ret As Boolean = @Server.SwitchToStandby()

if ret = True Then

Messagebox.Show("Servidor Reserva Habilitado")

Else

Messagebox.Show("Erro ao Habilitar Servidor Reserva")

End if

Else

if @Server.IsStandByActive = False Then

Messagebox.Show("Esta operação é possível quando o Servidor Reserva estiver ativo")

End IF

IF @Server.NumberOfObjectsForSendingToStandBy > 1000 Then

Messagebox.Show("Esta operação é possível quando não houver objetos pendentes")

End IF

End If

Return True

End Function

Importante salientar que a troca só realizado se o número de objetos pendentes for menor que 1000.


Atualiza Servidor Reserva (20)

Este comando exibe a tela chamada REDUNDANCIA_ATUALIZA. Esta tela é do tipo Dialog e tem por objetivo permitir atualizar a Aplicação do Servidor que está em estado Reserva com a aplicação que está rodando no Servidor Ativo. No CodeBehind desta tela a Function DialogOnOK deve ser editada como como a seguir.

Public Function DialogOnOK() as Boolean

Messagebox.Show("A aplicação no Servidor Reserva será atualizada")

@Server.UpdateProjectOnInactiveServer = TLib.Toggle(@Server.UpdateProjectOnInactiveServer)

Return True

End Function


Encerra Aplicação

Este comando exibe a tela chamada REDUNDANCIA_DIALOG. Esta tela é do tipo Dialog e tem por objetivo permitir encerrar a Aplicação do Servidor. No CodeBehind desta tela a Function DialogOnOK deve ser editada como a seguir.

Public Function DialogOnOK() as Boolean

@Server.Shutdown = True

Return True

End Function


Atualiza Cliente

Este comando permite atualizar a aplicação de um cliente. O botão é necessário configurar a Action do como ToggleValue para o objeto Client.IsProjectChanged. Com isso quando for feita uma Atualização no servidor Ativo o Cliente que está acessando o Servidor poderá ser atualizado para exibir a aplicação atualizada.


ARQUIVO BAIXAR
Projeto Português | English

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.