IMPLEMENTAÇÃO DE UM SISTEMA DE SELEÇÃO DE PEÇA USANDO CONCEITOS DE PROGRAMAÇÃO DE SISTEMA DE AUTOMAÇÃO João Alvarez Peixoto* * Mestrando do Programa de Pós-graduação em Engenharia Elétrica - UFRGS Porto Alegre, RS, Brasil Email: joao.peixoto@senairs.org.br Resumo: Uma grande dificuldade no desenvolvimento de projetos é a diferença entre a especificação e o desenvolvimento da aplicação. Ou o projeto é executado pensando na solução e não no problema, ou a especificação não é consistente. Este trabalho apresenta uma implementação que se desenvolve com foco na especificação, desde sua modelagem até sua aplicação. Os modelos partem de uma especificação, modelagem e implementação seguindo a norma IEC61131. Palavra-chave sistemas de automação, CLP, SA-RT, programação, sistemas supervisórios 1 Introdução Este trabalho se propõe a implementar uma aplicação desde sua especificação até sua implementação, buscando uma metodologia de projetos que facilite o entendimento das etapas. O projeto começa com a especificação do problema e um método para descrever tal especificação. Na sequência o problema é descrito na forma de modelagem UML 1, onde os diagramas de caso de uso, classe e sequência apontam os elementos e suas relações destro da aplicação. Na implementação, a tecnologia proposta é utilizar linguagem de programação descrita na IEC61131, considerando que o dispositivo de gerenciamento será um controlador lógico programável CLP 2. Neste ponto o programa tem suas lógicas simuladas em aplicativo ISAGRAF, que edita e simula programas nas linguagens descritas na norma. Para testar o programa o trabalho se encerra com a edição de um sistema supervisório que simule o ambiente da planta especificada. 2 Especificação Diagrama de Contexto O projeto começa com a especificação do problema. Normalmente esta é uma etapa complexa, uma vez que o cliente geralmente possui dúvidas em expressar sua necessidade. Ele nem sempre sabe o que realmente quer. E também surgem problemas quanto a delimitação da especificação, ou seja, o cliente quer mais do que especificou inicialmente. Por isto, descrever a necessidade do cliente na forma textual ajuda para delimitar o problema, mas não ajuda para visualizar as consistências do que é especificado. O ideal é que o cliente fornecesse croquis, animações e descrições detalhadas, como o desenho da aplicação proposta a seguir. 1 UML - Unified Modeling Language ou Linguagem de Modelagem Unificada, é uma linguagem visual utilizada para modelar sistemas computacionais por meio do paradigma de Orientação a Objetos. 2 CLP Controlador Lógico Programável, dispositivo que gerencia dispositivos de automação (sensores, atuadores, displays,...), relacionando entradas e saídas por meio de uma linguagem de programação.
Figura 1: Desenho da aplicação Mas mesmo um desenho detalhado não contempla detalhes da aplicação, como: velocidade da esteira, forma de interação com operador e até mesmo se o transporte será por esteira. A descrição por um diagrama de contexto se propõe a especificar um problema numa linguagem normalizada, clara e que apresente a forma relacional com que os requisitos do projeto se apresentam. A figura 2 mostra o diagrama de contexto do projeto no nível 1. Terminal de Operação Entrada Peça Extrai Indicação Peça L/D sistema Peça na entrada Extrai fim extração sistema L/D Extrai Extrai fim extrai sistema seleção de s Transporte Medição Medir Peça Altura da Transporte L/D Saída Saída pos. medir Peça pos. Figura 2: Diagrama de contexto, 1º Nível Caixa Caixa Peça pos. Nesta figura há a descrição dos elementos terminadores, que gerenciam, sensoram ou atuam no sistema. A simbologia dos elementos é descrita a seguir: Peça na entrada pos. medir Peça pos. Peça pos. Transporte L/D L/D sistema sistema L/D transporte 1 Altura da Medir Peça A Fim transporte Medição da A 3 resp. Comando resp. sequenciador 2 Indicação Peça Extração de Peça Alta Figura 4: Diagrama de contexto, 2º Nível Figura 5: Script de gerenciamento Com a utilização destes diagramas a aplicação torna-se mais clara em termos de especificação. O software utilizado para estas edições foi o Select Yourdon Education Version. A Fim extração 4 A Fim ext. Comando Extração de Peça Baixa 5 Extrai fim extração Saída Saída Extrai Se @IN = L\D sistema = on ativa Transporte Peça aguarda sinal Fim transporte ativa Medição Peça aguarda sinal -- resp. ou -- resp. Se -- resp. = on ativa Extração aguarda sinal -- Fim ext. Se -- resp. = on ativa Extração aguarda sinal -- Fim extração fim extrai 3 Modelagem - Diagrama de Caso de Uso Utilizando o diagrama de caso de uso temos a possibilidade de visualizar os elementos de comando, sensoriamento e atuação, agora chamados de atores e seus relacionamentos casos. Figura 3: simbologia do diagrama de contexto Este diagrama é definido em vários níveis de gerenciamento. A figura 4 mostra o diagrama do segundo nível e a figura 5 apresenta o script de uma sequência de gerenciamento. O modelo de modelagem do projeto por diagrama de caso de uso é apresentado na figura 6.
Já o diagrama de sequência descreve a interação dos eventos no contexto temporal, onde as descrições de eventos concorrentes tornam-se claros. Figura 6: Diagrama de Caso de Uso Nota-se claramente os elementos de entrada e saída de sinais da planta, bem como as ações desejadas entre os relacionamento destes elementos. Este diagrama é concebido a partir do diagrama de contexto, seguindo as especificações. 4 Modelagem - Diagrama de Classes O diagrama de classe possibilita entender melhor o comportamento de cada elemento da aplicação. Também temos o relacionamento entre eles. O diagrama de classe é apresentado na figura 7. Figura 7: Diagrama de Classe. As classes apontam os evento que realizam, com a possibilidade de replicar uma classe, mudando apenas sua instância. 5 Modelagem Diagrama de Sequência Figura 8: Diagrama de Sequência. 6 Implementação utilizando IEC61131 Uma vez determinado a modelagem, vem a etapa da programação do dispositivo de gerenciamento. Para esta aplicação fora escolhido um gerenciamento por Controlador Lógico Programável CLP. Para programar um CLP temos que seguir a norma IEC61131, que descreve linguagens aplicáveis à programação destes dispositivos. Diagrama de Ladder (LD); Diagrama de Blocos de Funções (FBD); Texto Estruturado (ST); Lista de Instruções (IL); Diagrama de Funções Seqüenciais (SFC). Cada uma destas linguagens possui características peculiares que levam a aplicações específicas. Uma linguagem de programação pode ser mais fácil de utilizar em uma aplicação e mais difícil em outra, e assim vale para todas elas. Esta aplicação foi programada em linguagem SFC através do software ISAGRAF, como pode ser visto na figura 9. Este tipo de linguagem possui a facilidade de expressar eventos sequenciais a partir de um
diagrama de estados, onde um estado representa uma ação a ser realizada e uma transição representa uma condição para que o próximo estado seja atingido. O correto seria o teste do programa na planta real, mas neste caso surge outro problema: executar um programa para teste numa planta real é um risco, em função de que não há uma garantia de que o programa irá funcionar e uma ação indevida do programa poderá danificar componentes do sistema de automação. 7 Sistema Supervisório Uma solução para testar o programa sem provocar erros de simulação da planta e sem danificar componentes é uma simulação da planta através de software supervisório 3. Inicialmente fora editado as características da planta num módulo do software ISAGRAF, que foi configurado para receber e emitir sinais ao controlador lógico programável através de variáveis comuns ao sistema. O comportamento da planta em função dos sinais é programado e simulado na tela do sistema supervisório. A figura 11 mostra a planta editada no software ISAGRAF. Figura 10: Diagrama SFC da aplicação. Durante a simulação os estados são plotados, indicando sua execução. A facilidade em acompanhar o fluxo é o ponto fundamental desta linguagem, porém, atividades concorrente são mais difíceis de serem descritas. Em tempo de execução é possível, através dos estados, simular a operação do sistema de automação proposto. Porém, a uma necessidade de entender muito bem o funcionamento da planta para poder simular coerentemente os sinais do programa. Nesta etapa é bastante comum os erros de simulação da planta, o que a priori remete a erro na programação, ao passo que é apenas um evento que está sendo simulado erroneamente. Figura 11: Planta editada no software ISAGRAF Cada elemento possui a propriedade de assumir desenhos distintos em função do valor de uma variável. Cada desenho é um arquivo.ico, ou seja, um desenho do tipo ícone. 3 Os sistemas supervisórios permitem que sejam monitoradas e rastreadas informações de um processo produtivo ou instalação física.
Tomando como exemplo a primeira que entra na esteira, ela possui uma variável que se assumir o valor 1, apresenta o arquivo com desenho da verde, se esta variável assumir o valor 2, o desenho carregado é o da amarela. Já o valor da variável igual a 0 implica em não carregar desenho algum, simulando a ausência de naquela posição. Cada elemento fora editado no software ICOFX, que gera arquivos.ico. A figura 12 mostra a aplicação em tempo de simulação. Para melhorar a apresentação da planta no sistema supervisório, a planta da aplicação foi editada no software Elipse. Neste software a interligação dos sinais, supervisório e CLP, ocorrem pelo compartilhamento de variáveis. Porém, os componentes da planta são editados como figuras bitmap e possuem características de posicionamento na tela sob forma de coordenadas. Assim, para deslocar a na tela basta alterar as coordenadas de posicionamento do elemento, ao passo que no software ISAGRAF era necessário e edição de dois componentes e para simular o movimento retirava-se o desenho de um e acrescentava o desenho em outro componente. A figura 13 mostra a planta editada e simulada no software Elipse. Figura 13: Sistema supervisório Elipse Figura 12: Sistema supervisório do ISAGRAF A planta alimenta a esteira com uma, cuja tamanho (amarela ou verde) é definido aleatoriamente. Este aplicativo funciona bem, porém o fato de ter que gera cada elemento e configurá-lo torna a aplicação trabalhosa. Em contra partida, os teste do programa são realizados de forma visual, sem a possibilidade de erros de simulação da planta. Nesta simulação da planta fora abordado dois conceitos: Sistema supervisório recebendo sinais, simulando o comportamento da planta e retornando sinais de estado; Sistema supervisório gerenciando o sistema. No primeiro caso o sistema supervisório gerado apenas responde aos sinais de entrada com simulações da planta e envia sinais de retorno apontando o estado dos sensores. Para simular a operação do CLP foi utilizado uma planilha Excel, onde as células da planilha são interpretadas como variávies do sistema.
A figura 14 mostra a planilha Excel que gerencia as ações do sistema de automação, sendo estas exibidas no sistema supervisórios, figura 13. Figura 15: Sistema supervisório com gerenciamento dos sinais de entrada e saída. Há também uma tela de relatório para exibir status de contagem das s. Figura 14: Planilha Excel que gerencia o sistema Para entendimento, o conteúdo da célula A8 corresponde ao estado da ESTEIRA. E isto vale para os demais atuadores, sensores, botão e contadores de s. Note que a simulação é estática, apenas responde a estímulos gerenciado através dos dados alterados na planilha Excel. Já o segundo caso elencado utiliza o conceito de que o sistema supervisório gerencia o dispositivos através da troca de informações entre seus elementos. Não é uma aplicação coerente com um sistema real, mas mostra o comportamento desejado. É importante para entender o funcionamento do sistema. A figura 15 mostra a tela de simulação da planta pelo software Elipse, com gerenciamento próprio. Figura 16: Tela de relatório do sistema 8 Conclusões Uma aplicação em que a especificação está bem descrita e numa linguagem de fácil interpretação facilita as etapas do desenvolvimento do projeto. Mas o melhor seria se a partir da especificação descrita pudessem serem gerados os demais diagramas automaticamente. Isto reduziria em muito o tempo e custo de desenvolvimento de sistemas automatizados. A escolha da linguagem de programação adequada é baseada em experiências anteriores. Não há uma linguagem mais adequada, mas há uma linguagem que melhor se aplica a cada aplicação. A edição de sistemas supervisório permitem que a planta seja simulada sem a necessidade o risco de danificação de componentes, além da redução do tempo de elaboração do programa. A edição de sistema supervisório no software Elipse é bem mais amigável que no software ISAGRAF, porém, a o software Elipse
necessida do drive do CLP para correta simulação. Referencial de pesquisa Aula sistemas supervisórios www.ee.pucrs.br/~gacs/new/disciplinas/ci/apos tilas/aula10.pdf <Acesso em 13/05/2010> Aulas da disciplina de Sistemas de Automação ensino.ece.ufrgs.br/moodle/course/index.php <Acesso em 13/05/2010> Apostila sistema supervisório SCADA www.professor.cefetcampos.br/.../scada/super visorio_scada.pdf <Acesso em 15/05/2010> Livro sobre UML www.novateceditora.com.br/livros/uml3/sumari o9788575221495.pdf <Acesso em 16/05/2010>