Utilizando CPUs Siemens redundantes com E3 – Parte 2.

1) Introdução

A comunicação entre o Elipse E3 e as redes Siemens se dá através de uma das seguintes opções:

• OPC: o Simatic Net (Siemens) atua como servidor e o E3 como cliente.
• Drivers de comunicação: M-Prot (PPI, MPI, ISOTCP), Prodave, etc.

Este artigo aborda o uso do driver MPI (atualmente substituído pelo M-Prot). O Simatic Net disponibiliza uma aplicação e o E3 se comunica com a rede (utilizando as funções do S7-Functions) através do driver MPI. Esse sistema, assim como o OPC, pode ser usado para qualquer rede Siemens que seja suportada pelo Simatic Net.

Existem outros artigos que ilustram ambas as formas de comunicação, descrevendo a configuração dos drivers, criação dos tags etc, que podem ajudar a entender os passos anteriores à criação da redundância. O presente artigo trata da implementação de um sistema de CPUs redundantes sendo acessadas pelo E3, que mostra os dados de processo independentemente da CPU ativa, com a execução de um simples script.

NOTA: Quando utilizam o meio físico Ethernet, os drivers que usam o IOKit (componente compartilhado utilizado pelos drivers de comunicação da Elipse) já possuem a opção de redundância, basta habilitar o endereço de backup (Backup Address) na aba Ethernet do driver.

2) Solução

Alguns problemas relacionados a redundância, a dinâmica de estados dos PLCs e a estação de supervisão, são:

• Informação do estado da CPU: normalmente é feito através de um tag de status. Quando o valor do tag é verdadeiro (diferente de zero), significa que a CPU está ativa.
• Prioridade de operação: quando ambas as CPUs estão ativas, deve-se verificar se existe prioridade na operação. Existem duas possibilidades: trabalhar com a primeira (ou a última) CPU ativa, ou trabalhar sempre que possível com a mesma CPU (prioritária). No projeto desenvolvido, não existe prioridade.
• Efeito da queda da estação de supervisão: a queda da estação de supervisão não deve interferir nos estados das CPUs, e ao retornar ela deve se conectar a qualquer CPU ativa, mesmo quando houver mudança de estado durante o período de queda.
• Troca de CPU ativa: a parametrização dos tags no E3 contém o endereço do equipamento com o qual é necessário comunicar. No caso do driver MPI, o tag carrega no parâmetro N1 o número da conexão criada no Simatic Net. Fazer com que o mesmo tag se comunique com diferentes CPUs (cada uma a seu tempo) foi o grande problema a ser tratado nesse projeto.

Como pode ser visto no projeto desenvolvido no Step7, a primeira questão foi resolvida com a criação dos tags M18 e M118, que informam o estado de cada CPU.

Como já foi visto, a rede não dispõe de uma CPU prioritária, e a última a entrar em estado de operação será a usada para comunicação. É possível implementar no PLC um dispositivo de segurança para evitar que uma CPU entre em operação quando a outra estiver ativa, mas este tipo de otimização não será visto neste artigo.

Para implementar o retorno da estação de supervisão em caso de queda, foi criado em cada CPU um tag M30, que será escrito sempre que o E3 retornar a aplicação. Esse tag inibe a escrita de estado da CPU por alguns segundos. Nesse tempo, o E3 zera os estados para que ocorra o evento de seleção da CPU ativa (que será descrita posteriormente).

Para o exemplo, o tag M12 será monitorado em ambas as CPUs (uma por vez), simulando o processo e permitindo visualizar a troca de CPU ativa. Nos testes, essa memória foi configurada como 444 na primeira CPU (endereço Profibus igual a 4) e 222 na segunda (endereço Profibus igual a 6).

3) Projeto Teste

O objetivo deste projeto é detectar o comportamento da leitura de tags quando ocorre a variação do estado das CPUs. A tela mostrada na Figura 1 foi construída para visualizar este comportamento.

Os tags usados e as configurações dos tags de comunicação podem ser vistos nas Figuras 2 e 3.

A descrição dos tags ligados ao driver foi feita no item 2 desse documento, exceto pelo tag interno VerificaCPUs. Esse tag será utilizado para fazer a troca de CPUs ativas. Os scripts serão descritos posteriormente nesse documento.

Como descrito no arquivo de ajuda do driver MPI, o parâmetro N1 é utilizado para discriminar o número da conexão de rede, que é configurada no software Simatic Net. A solução adotada para a troca de CPUs foi alterar o valor desse parâmetro N1 para o valor correspondente à CPU ativa.

A vantagem desta abordagem é a manutenção de todos as associações relacionadas a estes tags de comunicação feitas no projeto. Associações em telas, configurações de históricos e de alarmes, entre outras características, são mantidas sem necessidade de modificações. Outras vantagens são:

• Rapidez no desenvolvimento: como o projeto independe da CPU que servirá como fonte dos dados de campo, ele pode ser desenvolvido com foco apenas em sua funcionalidade. A camada de redundância é um passo posterior.
• Controle centralizado de estado das CPUs: facilita a manutenção do projeto como um todo.
• Dimensionamento do servidor: os E3 Servers são dimensionados pelo número de tags lidos simultaneamente. Como os tags são sempre os mesmos, ao mudar apenas o endereço é possível dimensionar um servidor com menor número de tags.
• Facilidade de manutenção do projeto: em caso de modificações na quantidade ou nomes de tags, é mais simples alterar isso em apenas um script, o que torna mais segura qualquer modificação.

Script de retorno do E3

Quando ocorre uma queda do E3, é perdida a informação sobre qual CPU está ativa; mesmo que essa informação seja mantida, é possível que a troca de CPUs ocorra sem que o E3 tenha acesso a essa informação.

Por isso, a escrita nos tags M30 de ambas as CPUs (Figura 4) permite que os valores dos tags de status (M18 e M118) sejam retornados para zero, o que indicaria que nenhuma delas está ativa. Isso é suficiente para que os eventos de mudança de CPU ativa sejam executados de acordo com seus estados.

Script de troca de CPUs

O próximo passo para a solução deste problema é a implementação dos eventos que controlam a troca de CPUs. Para isso, utilize o tag interno VerificaCPUs. Neste tag, crie um novo evento, chamado VerificaCPUs, que monitora se o valor do tag M18 (status de uma CPU) foi modificado (Figura 5).

Neste novo evento, crie o script de controle (Figura 6). Este script monitora o valor do tag; caso seja igual a 1, isto significa que a CPU entrou em operação. O valor desse tag é controlado pela própria CPU. No script mostrado, modifique o parâmetro N1 de cada tag na lista individualmente. Mais adiante, será mostrada uma otimização desse esquema, mas qualquer tag a ser lido nesse esquema redundante deverá ser colocado nesse script, conforme comentário.

Essa mesma sequência deve ser feita para o tag M118 (status da segunda CPU), mas com o valor do parâmetro N1 dos tags sendo igual a 1 (segunda conexão de rede).

Feitas essas implementações, a redundância estará implementado no lado do supervisório, pois qualquer que seja a CPU ativa, o E3 conseguirá trabalhar sem dificuldades.

Otimizações

Uma segunda solução para a troca de CPU ativa, que não necessita a inclusão de todos os tags na lista de troca do parâmetro N1, pode ser vista na Figura 7.

A disposição dos tags redundantes em uma pasta única, conforme visto acima, permite a criação de um script onde, independentemente do número de tags ou das alterações feitas nesses tags, não será necessário mexer nos scripts de troca. A Figura 8 ilustra esse novo script.

Essa troca é a mais aconselhável, mas é necessário organizar os tags antecipadamente de forma a permitir o uso desse script.

4) Conclusão

O uso de equipamentos em redundância é fundamental para a confiabilidade de processos críticos, nas mais diferentes áreas de atuação. Quando é possível ter esses equipamentos em rede, com um esquema de endereçamento que permita a troca rápida entre CPUs, é possível implementar a redundância no E3, sem dificuldades.

Assim como todas as outras ferramentas disponíveis no E3, é possível implementar essa redundância de maneira modular, o que traz grandes vantagens para o desenvolvimento de projetos.

NOTA: O processo descrito neste artigo foi desenvolvido em conjunto pela Elipse Software, Microsel Engenharia (integrador Elipse) e Siemens, para o projeto realizado pela Promon Engenharia, para a UTE-AGPO, situada em Macaé-RJ.