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 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.
1. 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
2. Criando a aplicação do CP
Este capítulo demonstra como criar um projeto de um CP para se 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 executa o comando do menu Depurar Iniciar.
O projeto criado com este documento está junto do Anexo com o nome RedundanciaBP.project.
3. 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ção Configuraçã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.
4. Criando um Projeto com o BluePlant
Neste capítulo 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 "<
5. 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 criadas 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 às variáveis serão salvas no projeto e elas poderão ser usadas como Tags em outras partes do programa.
6. 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 criada para o projeto 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 serem 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 preenchidos 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.
7. 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.
8. Executando a Aplicação
Antes de executar a aplicação a mesma deve ser copiada para os dois servidores. Para executar o projeto, selecione, no menu "Run" de cada Servidor a opção "Startup" e pressione 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
9. 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.
10. 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.
11. 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.
12. 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.
13. 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
14. 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 para 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.
Comentários
0 comentário
Por favor, entre para comentar.