Termes

O objetivo do desenvolvimento da ferramenta para geração de código foi de auxiliar na tarefa de escrita do código do CLP, de forma a automatizar a transcrição do autômato obtido para o supervisor no código de programação do CLP. Assim, foi desenvolvida uma ferramenta de geração automática de código para o CLP. Esta ferramenta foi desenvolvida, como auxílio de bolsistas do Programa de Educação Tutorial – PET Engenharia Elétrica, que desenvolveram toda interface e as rotinas de geração de códigos tendo como base a metodologia proposta nesse trabalho. Tanto para a organização do programa como para a criação das sub-rotinas, de modo a promover o tratamento do problema da escolha caso

exista. Assim, foi implementado o fluxograma apresentado na seção 5.1.3, que determina quais estados apresentam o problema da escolha e para cada um desses estados, quais são os eventos que fazem parte do problema da escolha e qual a disposição desses eventos. Portanto para cada estado que apresenta o problema da escolha é estabelecido uma solução dependendo da disposição dos eventos envolvidos no problema, conforme apresentado seção 5.1.3.

O CCSSM é um programa no qual, a partir de um arquivo de formato conhecido da Teoria de Controle Supervisório oriundo de uma ferramenta computacional de síntese dos supervisores, como por exemplo, os softwares Grail (REISER et al., 2006; CURY, 2001; GARCIA, 2006), TCT (FENG e WONHAN, 2006) e IDES (RUDIE, 2006), é possível gerar o programa no formato textual, para ser implementado diretamente em CLPs dos modelos ControlLogix® e CompactLogix™ do fabricante Rockwell (ROCKWELL), ou seja, o código final gerado pode ser carregado no software compilador desses CLPs RSLogix™ 5000 para então ser convertido para a linguagem ladder.

No desenvolvimento da ferramenta foi estabelecido que ela deveria possibilitar a inclusão de novas funcionalidades, ou seja, inicialmente seria desenvolvida a solução para um determinado modelo de CLP. Porém com o avanço da ferramenta o objetivo será de gerar códigos para os mais variados modelos de CLPs existentes, além de receber como entrada os mais variados tipos de arquivos, provenientes dos softwares Grail, TCT e IDES, que são os software mais utilizados no meio acadêmico, para modelagem da planta e geração dos supervisores.

Com base nos requisitos apresentados anteriormente, foi estabelecido que a ferramenta de programação do software de geração de código deveria ser aberta, ou seja, qualquer usuário deveria ter acesso ao código fonte, assim foi escolhida a linhagem de programação C# (também conhecido como C Sharp).

Para atender aos diferentes tipos de arquivos de entrada, foi estabelecido que a ferramenta deveria converter o formato desses arquivos em um único formato, tendo assim sempre um mesmo ponto de partida para desenvolver o gerador de código.

Como cada modelo de CLP apresenta um formato específico de arquivo para que possa ser importado pelo compilador do mesmo, foi estabelecido que para cada modelo de CLP fosse desenvolvida uma rotina especifica totalmente independente, tendo sempre como entrada um mesmo tipo de arquivo.

A Figura 6.1 apresenta a arquitetura que foi estabelecida para o desenvolvimento da ferramenta. O papel da interface é receber os arquivos provenientes do Grail, TCT ou IDES para então gerar um arquivo único (de extensão CSM). Esse arquivo mantém as informações

dos supervisores sintetizados e o modelamento do sistema produto (SP). Para cada modelo de CLP é desenvolvido um tradutor dedicado, que gera o arquivo a ser importado no CLP tendo como base a metodologia proposta nesse trabalho. Veja que o desenvolvimento do tradutor é facilitado uma vez que o arquivo de entrada (.CSM) estará sempre no mesmo formato.

Figura 6.1. Arquitetura da ferramenta de geração de código CCSSM

A interface da ferramenta de conversão é composta por telas que serão apresentadas a seguir. A tela inicial, representada pela Figura 6.2, possibilita criar um novo projeto ou abrir um projeto já existente, em formato CSM.

Ao criar um novo projeto deve ser informado qual foi o tipo de abordagem utilizada na síntese do supervisor, tendo como opção apenas a abordagem modular local, porém a interface já tem uma previsão, para que possa aceitar a abordagem monolítica também.

Outra informação necessária consiste em informar qual foi a ferramenta utilizada para síntese do supervisor, seja o Grail, TCT ou IDES, visto que cada um deles tem suas vantagens, porém no presente momento apenas está implementada para aceitar arquivos do IDES.

Ao confirmar as opções do arquivo o usuário tem acesso à segunda tela, representada pela Figura 6.3. Nessa tela existem algumas abas, o usuário tem liberdade para percorrer por todas as abas, essa divisão organiza o procedimento de geração do código.

A primeira aba (ver Figura 6.3), denominada de “Supervisors”, é utilizada para adicionar ao projeto os arquivos dos supervisores sintetizados. Deve-se especificar o diretório onde se encontra o arquivo e clicar no botão “Add”. A qualquer arquivo adicionado pode ser removido, basta para isso selecionar o arquivo na lista e clicar no botão “Remove”. À medida que vai se inserindo os supervisores ou se retirando supervisores já adicionados, a lista é atualizada.

Figura 6.3. Inserir os supervisores

A segunda aba, denominada “Product Systems” está apresentada na Figura 6.4, é utilizada para se adicionar ao projeto os arquivos que compõe o sistema produto que modelam a planta física. Da mesma forma, que na aba anterior, deve-se especificar o diretório onde se encontra cada arquivo e clicar no botão “Add”, para se adicionar o modelamento dos subsistemas que compõe o sistema produto e qualquer arquivo adicionado pode ser removido.

Figura 6.4. Inserir sistema produto

A Figura 6.5 apresenta a terceira aba, denominada “Symbols”, onde se tem acesso a novas três abas (ou sub-menu). No primeiro sub-menu, denominado “States” estão listados todos os estados existentes, dos supervisores e do sistema produto que foram adicionados ao projeto. Assim é possível, para cada estado estabelecer um nome para a memória que representa o estado e criar uma descrição, de modo que quando for gerado o programa para o CLP, essa descrição será incluída nos comentários do programa onde esse estado se encontra, facilitando assim o entendimento do programa.

Já no segundo sub-menu, apresentado pela Figura 6.6, denominado “Events”, são listados todos os eventos existentes, sejam eles controláveis ou não controláveis, possibilitando para cada evento inserir uma descrição do que ele representa, e essa descrição será adicionada nos comentários ao longo do programa do CLP.

Outra função dessa tela é que, para cada evento controlável, é possível definir como deverá ser o comportamento das saídas do CLP para transferir à planta os comandos dos eventos que foram gerados no sistema produto, ou seja, pode ser criada uma sub-rotina que, quando o evento é gerado essa sub-rotina é chamada, por outro lado existe a possibilitada de se acionar uma saída digital especifica do CLP. Esta saída poderá ser ligada ou desligada até que outro evento altere o estado dessa saída, ou ainda poderá ser criado um temporizador que mantenha a saída ligada ou desliga por um tempo configurável.

Figura 6.6. Especificação de eventos controláveis

Já para os eventos não controláveis, como se pode ver na Figura 6.7, é possível definir como deverá ser o comportamento da entrada física do CLP para que determinado evento seja sensibilizado no programa. Por exemplo, se determinado evento for o acionamento de um sensor, esse evento será gerado no programa quando o sinal proveniente desse sensor proporcionar na entrada do CLP uma mudança de estado podendo ser, nesse caso, a subida do sinal de nível baixo para nível alto ou poderia ser o contrário de nível alto para nível baixo.

Figura 6.7. Especificação de eventos não controláveis

No último sub-menu, representado pela Figura 6.9, denominado “Output Reseters” é possível estabelecer para cada saída digital que foi mapeada anteriormente e que não está ligada a um temporizador. Ou seja, para todas saídas digitais cuja geração dos eventos apenas liga ou desliga, pode-se estabelecer outro evento ou uma lista de eventos que, quando gerados, alterem o estado desta determinada saída digital.

Por fim na última aba, representada pela Figura 6.9 é possível selecionar para qual modelo de CLP o projeto será convertido, o objetivo é que a ferramenta possa vir a gerar o programa pronto para o CLP, visto que cada modelo de CLP tem suas características com comandos específicos, mas todos no fundo são iguais, principalmente quando se usa apenas os comandos mais simples existentes em todos os modelos de CLP.

Figura 6.9. Seleção do modelo de CLP

Porém, a tecnologia utilizada nos softwares de compilação dos CLPs é fechada, ou seja, os proprietários impedem que usuários possam ter acesso ao código fonte, e também são incompatíveis entre diferentes marcas de CLP. Algumas vezes, até mesmo entre diferentes famílias de uma mesma marca são incompatíveis entre si, de modo a ser impossível gerar um arquivo para uma determinada família de CLP e abrir esse arquivo no compilador de outra família. Assim para solucionar esse problema a ferramenta gera um arquivo em um formato específico para determinada marca de uma determinada família de CLP, descrevendo o programa em um formato textual, de modo que este arquivo possa ser importado pelo compilador, para então poder ser visualizado no formato ladder.

No momento a ferramenta está capacitada a gerar arquivos para o CLP da família ControlLogix® e CompactLogix™ do fabricante Rockwell (ROCKWELL). Ou seja, a ferramenta gera um arquivo na extensão L5X que pode ser aberto pelo compilador RSLogix™ 5000. Esse procedimento será explicado a seguir com o acompanhamento de um estudo de caso.