Elipse Knowledgebase

• OPC: o Simatic Net, da Siemens atua como OPC Server e o E3 entra como OPC Client.
• S7-Functions: o Simatic Net disponibiliza uma "Application" e o E3 se comunica com a rede (usando 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 artigos que explicam as duas formas de comunicação, envolvendo configuração dos drivers, criação dos tags etc. Podem ajudar a entender os passos anteriores à criação da redundância. Esse 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.


2) Solução

Existem alguns problemas quando se pensa em redundância, que são relacionadas com a dinâmica de estados dos PLCs e da estação de supervisão. Alguns deles são:

1 - Informação do Estado da CPU: isso normalmente é feito através de um tag de status. Quando o valor do tag é verdadeiro (diferente de zero), significa que a CPU está ativa.
2 - 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 CPU ativa (ou a última) e trabalhar sempre que possível com a mesma CPU (prioritária). No projeto desenvolvido, não existe prioridade.
3 - 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, devendo ao retornar se conectar a qualquer delas que estiver ativa, mesmo quando houver mudança de estado durante o período de queda.
4 - Troca de CPU ativa: a parametrização dos tags no E3 contém o endereço do equipamento ao 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 (pode ser feito o download no site da Elipse, na seção Exemplos) a primeira questão foi resolvida com a criação dos tags M18 e M118, que informam o estado de cada CPU.

Como citado, a rede não dispõe de uma CPU prioritária, sendo que a última a entrar em estado de operação será a usada para comunicação. Há como implementar no PLC uma segurança para evitar que uma CPU entre em operação quando a outra estiver ativa, mas já começamos a tratar de otimizações.

Para implementar o retorno da estação de supervisão em caso de queda da mesma, 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 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 setada para 444 na primeira CPU (endereço Profibus igual a 4) e 222 na segunda (endereço Profibus igual a 6).


3) Projeto de Teste

A idéia do 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 satisfazer essa necessidade de visualizar o comportamento.


Figura 1: Tela de testes


Os tags usados (pela descrição no item 2 desse documento) e as configurações dos tags de comunicação podem ser vistos nas figuras 2 e 3.


Figura 2: Lista de tags e projeto no Organizer


A descrição de cada um dos tags ligados ao driver foi feita no item 2 desse documento, com exceção do tag interno "VerificaCPUs". Esse tag será usado para fazer a troca de CPUs ativas. Os scripts serão descritos mais adiante nesse documento.


Figura 3: Configuração dos tags


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.

Essa abordagem traz como vantagens a manutenção de todos as associações feitas no projeto, que estejam relacionados a esses tags de comunicação. 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 independe da CPU que servirá como fonte dos dados de campo, é possível desenvolver o projeto preocupado apenas com a sua funcionalidade. A camada de redundância é um passo posterior.
• O controle de estado das CPUs é centralizado. Isso facilita a manutenção do projeto, como um todo.
• Dimensionamento do servidor: Os E3 Servers são dimensionados pelo número de tags que são lidos simultaneamente. Como os tags são sempre os mesmos, mudando somente 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

Ao ocorrer uma queda do E3, será perdida a informação sobre qual CPU está ativa. Ainda que essa informação fosse mantida, seria possível a troca de CPU sem que o E3 conseguisse acesso a essa informação.

Por isso, a escrita nos tags M30 de ambas as CPUs (Figura 4) permite que eu mande os valores dos tags de status (M18 e M118) para zero, o que indicaria que nenhuma delas está ativa. Isso é suficiente para que os eventos de mudança de CPU ativa sejam executados conforme o estado das mesmas. Para verificar o funcionamento das CPUs nesse instante, consulte o projeto respectivo, que está disponível para download.


Figura 4: Script para retorno do E3


Script de Troca de CPUs

O próximo passo para a solução de nosso problema é a implementação dos eventos que controlam a troca de CPUs. Para isso, usaremos o tag interno "VerificaCPUs". Sobre esse tag, deverá ser criado um novo evento, que chamei de "VerificaCPUs", que vai monitorar se o tag M18 (status de uma CPU) teve o valor modificado (Figura 5).


Figura 5: Criação do evento de troca de tags


Sobre esse novo evento, deverá ser criado o script de controle (Figura 6). O script compara se o valor do tag é igual a 1, e se for, a CPU entrou em operação. O valor desse tag é controlado pela própria CPU. No script mostrado, a lista de tags deve ter o parâmetro N1 modificado um a um. Mais adiante, será mostrada uma otimização desse esquema, mas qualquer tag que deva ser lido nesse esquema redundante, deverá ser colocado nesse script, conforme comentário.


Figura 6: Script para troca de endereço dos tags


Essa mesma seqüência deve ser feita para o tag M118 (status da segunda CPU), apenas com a modificação no valor do 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 N1 pode ser vista na Figura 7.


Figura 7: Organização alternativa para os tags redundantes


A disposição dos tags redundantes em uma pasta única, pelo esquema mostrado, permite que se crie 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.


Figura 8: Troca de CPUs independente do número dos tags


Essa troca é a mais aconselhável, mas é necessário antecipadamente organizar os tags 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.

Apenas para ilustrar um caso prático, esse processo foi desenvolvido em conjunto pela Elipse, Microsel Engenharia (integrador Elipse) e Siemens, para o projeto realizado pela Promon Engenharia, para a UTE-AGPO, situada em Macaé-RJ.