METODOLOGIA DE PROJETO DE SISTEMAS DE AUTOMAÇÃO COM CONTROLADOR LÓGICO PROGRAMÁVEL (CLP)

METODOLOGIA DE POJETO DE ITEMA DE AUTOMAÇÃO COM CONTOLADO LÓGICO POGAMÁVEL (CLP) Edilson eis odrigues Kato Universidade Federal de ão Carlos (UFCar), Brasil Introdução A evolução tecnológica e as exigências cada vez mais complexas dos sistemas de produção, tais como segurança, qualidade e atendimento às necessidades do cliente, fez com que os processos de fabricação e os equipamentos que compõe o chão de fábrica atuassem de forma automática e integrada. Controladores automáticos e com comunicação em rede se tornaram uma necessidade para atender ao planejamento estratégico e ações de gestão bem definidas, considerando a análise de impacto e o retorno de investimento. O Controlador Lógico Programável (CLP) tornou-se parte integrante de sistemas de controle industriais devido a sua estrutura rígida e alta capacidade de processamento [1]. Além disso, possuem diversas características que justificam seu uso difundido no controle industrial [2]: - Alto Nível de confiabilidade: tipicamente 24 horas de operação por dia;. - Alta velocidade de varredura para controle de processo em tempo-real; - Grande número de pontos de entrada/saída para os estados e sinais de controle;. - Manutenção de software a nível de chão de fábrica; - Flexibilidade para modificar o software durante a operação de fábrica, por exemplo, substituir itens da planta ou fazer consertos de emergência. O diagrama Ladder, desenvolvido em 1969, é a linguagem predominante para se programar CLPs [3] [4]. A linguagem Ladder é expressa tipicamente na forma gráfica e assemelha-se a diagramas de lógica elétrica, utilizados por eletricistas para circuitos de relés eletro-mecânicos. Os componentes primários de um programa de lógica Ladder são os contatos, que representam os sinais de entrada no CLP e as bobinas, que representam sinais de controle de saída do CLP[5] Uma dificuldade encontrada com a evolução dos sistemas de controle foi que a estrutura de implantação da lógica de controle, normalmente apresentada de maneira simples para serem implementadas por técnicos, passou a ser ineficiente para a programação de sistemas complexos, tais como os istemas Flexíveis de Manufatura (FM). istemas de automação complexos necessitam de uma modelagem capaz de estabelecer os requisitos e necessidades de uma forma consistente para que o sistema automatico possa ser implantado com sucesso, permitir o acompanhamento do seu desenvolvimento e implementação, descrever etapas claras de validação do sistema implementado e ainda facilitar manutenções ou modificações futuras [6]. Várias ferramentas e técnicas de modelagem tem sido utilizadas para esse fim, tais com cadeias de Markov, teoria das filas, etc. no entanto uma que vem sendo destaque tanto na academia como na indústria é a ede de Petri. ede de Petri (P) ou Petri Net é uma ferramenta gráficas e matemática aplicável à diversos tipos de sistemas. Essa ferramenta descrevem sistemas de processos caracterizados como sendo concorrentes, assíncronos, distribuídos, paralelos, não-determinísticos, e/ou estocásticos. O conceito de P teve origem na dissertação de Carl Adam Petri, submetida em 1962 pela Faculdade de Matemática e Física da Universidade Técnica de Darmstad, no leste Europeu. Ps tem sido propostas para uma grande quantidade de aplicações. Podem ser aplicadas informalmente para algumas áreas ou sistemas que podem ser descritos como diagramas de fluxos, que representam atividades paralelas ou concorrentes. Existem as seguintes áreas promissoras para P: sistemas de softwares distribuídos para modelo e análise, sistemas de banco de dados distribuídos, programas concorrentes e paralelos, sistemas de controle flexível de manufatura, sistemas de eventos discretos, sistemas de memória multiprocessada, sistemas tolerantes a falhas, matriz de VLI e lógica programável, circuitos e estruturas assíncronas, sistemas operacionais e compiladores, sistemas de informações de escritório, linguagens formais e programas lógicos [7]. Uma P é um tipo de grafo direcionado, com um estado inicial chamado de marca inicial M0. Existem dois tipos de nós em P: lugar (place) e transição (transition), que são

interligados por arcos que saem do place para uma transição e de uma transição para um place. Na representação gráfica os places são desenhados como círculos, e transições como barras ou caixas. Os arcos são caracterizados com seus pesos (weight), que são representados como números inteiros, onde um arco com peso k pode ser interpretado como um conjunto de k arcos paralelos. Os rótulos para peso unitário são omitidos [8]. Uma definição formal de P é dada na Figura 1 [7]. A Petri net é uma 5-tupla, PN = (P, T, F, W, Mo) onde: P = {p 1, p 2, -, p m } é um conjunto finito de places, T = {t 1, t 2, -, t m } é um conjunto finito de transições, F c (P x T) U (T x P) é um conjunto arcos (relação de fluxos), W: F {1, 2, 3, - } é uma função de peso, Mo: P {0,1, 2, 3, } é a marca inicial, PnT= e P U T. Uma estrutura de Petri Net N = (P, T, F, W) sem uma marca inicial é denotada por N. Uma Petri Net com uma marca inicial é denotada por (N, Mo). Figura 1 - Definição formal de Petri-Net [7]. O comportamento de muitos sistemas pode ser descrito em termos de sistema de estados e suas mudanças. De fato, na simulação do comportamento dinâmico de um sistema, um estado ou conjunto de marcas de P é modificado de acordo com os disparos das transições, possibilitando a verificação e validação da rede implementada conforme as restrições estabelecidas. Favorecendo a implementação, validação e testes do controlador do sistema, ou seja, da programação CLP. Possibilitando assim o menor número de erros possíveis, evitando-se a perda de tempo e custos adicionais [9]. Este trabalho visa propor uma metodologia de projeto de sistemas de automação, que utilizam o CLP, de maneira a estabelecer o uso de ferramentas de modelagem, principalmente aquelas oriundas da engenharia de software, tais como, a UML (Unified Modeling Language) [10] em conjunto com a ede de Petri associadas aos componentes de programação CLP (lógicas E e OU, contadores, temporizadores e comparadores) para que os custos de implementação e manutenção de um sistema automático possam ser minimizados. Metodologia A metodologia de modelagem, desenvolvimento e implementação da automação de sistemas de produção deve considerar desde a análise de impacto e retorno de investimento, até a especificação de hardware e definição de formas de acompanhamento, verificação e validação dos sistemas. O método proposto requer o uso de ferramentas específicas de desenvolvimento, que se inspira em ferramentas da engenharia de software, principalmente no sentido de obter partes do resultado final, evitando o desenvolvimento de protótipos, utilizando artefatos de UML. Alia-se ainda a técnicas de simulação de P para avaliação de desempenho segundo alternativas e também incorpora características de sistemas holônicos [11], com a preocupação de construção e análise de elementos locais que consideram aspectos globais. Como etapas, certamente contempla atividades de modelagem, implementação, verificação, validação e análise de maneira interativa e iterativa como mostrado na Figura 2. Figura 2 Metodologia de Projeto de Automação com CLP. O detalhamento das tarefas dentro de cada etapa do método é apresentado a seguir. E1 Definição do istema e levantamento de requisitos:

Essa etapa trata das definições das necessidades e identificação do problema a ser abordado, especificando-se o sistema com a ajuda de PU utilizando artefatos da UML tais como os Casos de Uso, o diagrama de Casos de Uso e o diagrama de equência. E2 Formulação do Modelo Conceitual do istema: Deve-se elaborar a partir da especificação funcional do sistema de automação (usando os artefatos da UML da etapa anterior) a modelagem que, além das funcionalidades, deve contemplar todo o intertravamento, utilizando-se das edes de Petri (P). E3 Verificação e validação do modelo do sistema de automação Nessa etapa realiza-se a verificação e validação do modelo do sistema automático, estabelecendo em conjunto com a simulação as metas a serem atingidas com a implementação dessa automação, certamente levando-se em consideração as estratégias e o planejamento da produção. A partir do modelo conceitual em P a dinâmica do sistema é simulada utilizando-se as ferramentas disponíveis [12]. E4 Especificação do hardware e software: Nessa etapa há a definição das características tecnológicas necessárias, isto é, são identificados os tipos e modelos específicos de elementos eletrônicos e mecânicos a serem adquiridos (são estabelecidas as velocidades, os torques, dimensões, alimentação, produtividade, etc.) necessários para atender a automação desejada. ão realizados os projetos mecânico e elétrico (desenhos mecânicos e esquemas elétricos necessários) e deve-se gerar documentos de seqüência de testes e de start-up para a verificação e validação do sistemas ou máquinas automáticos a ser implantados. E5 Programação do Modelo Conceitual no Controlador: É realizada nessa etapa o acompanhamento do desenvolvimento do sistema de automação. A maioria dos CLPs possui a lógica Ladder [13] como padrão de linguagem de programação predominante e na literatura vários autores tratam dessa etapa de conversão do modelo conceitual em redes de Petri para a lógica Ladder, tanto de uma forma automática como semi-automática ou manual [5][14][15][16][17] [18][19][20], embora como a implantação pode ser realizada por terceiros ou mesmo por outros membros de uma equipe, não necessáriamente essa conversão é necessária, ou seja, o acompanhamento da implantação pode ser realizado pelo próprio modelo conceitual em rede de Petri. Deve-se acompanhar a implantação do sistema de automação (envolvendo automação eletro-mecânica e integração em rede) para se aferir a conformidade em relação à especificação em tempo de correção de ações. Deve-se também realizar a verificação e validação do sistema de automação de forma a acompanhar o start-up do sistema, avaliando sua conformidade em relação aos documentos de especificação, os quais deverão ser elaborados e/ou atualizados de acordo com o sistema final entregue. A Figura 2 ilustra a Metodologia de projeto de automação com CLP proposta. Exemplo de aplicação Para explicar mais detalhadamente as etapas da metodologia proposta, um exemplo de aplicação de automação de uma máquina é utilizado. A partir de uma descrição informal do sistema temos que a máquina tem por objetivo o recorte automático de placas de tomadas e interruptores, a matéria prima são placas de madeira pré-preparadas, ou seja, com suas dimensões externas já definidas, podendo ser placa 4x2 e 4x4. Deseja-se que o operador tenha a opção de funcionamento manual, automático e de set-up da máquina para entrar em operação. Devem ser levados em consideração os processos de parada, e emergência. Em uma primeira etapa a especificação do sistema é descrita de uma forma macro utilizando-se os Diagramas de Casos de Uso, um artefato da UML. No Diagrama de Casos de uso são identificadas as funcionalidades e especificadas as interações entre elas e os atores do sistema. No caso, o principal ator do sistema é o operador. A Figura 3 ilustra o Diagrama de Casos de Uso para o exemplo de aplicação de acodo com a especificação do sistema junto ao cliente. Figura 3 Diagrama de Casos de uso do exemplo de aplicação. No Diagrama de Casos de Uso, cada elipsoide é um Caso de Uso específico de funcionamento e em conjunto com o cliente o

desenvolvedor realiza seu detalhamento. É importante relatar e descrever com detalhes cada um dos Casos de Uso, formalizando as decisões de projeto que são tomadas nessa etapa. As Figuras 4, 5, 6, 7, 8 e 9 ilustram os Casos de Uso em detalhes, nesse caso são ilustrados somente os Casos de Uso de curso Normal, mas de acordo com a necessidade podem ser registrados Casos de Uso Alternativos, quantos forem necessários, para poder estabelecer funções alternativas ou reparadoras do sistema. Caso de Uso Posicionamento Inicial 1 ecuar eixo Z 2 ecuar eixo Y 3 ecuar eixo X 4 ecuar pistão de trava de peça 5 ecuar pistão de alimentação 6 ecuar pistão de descarga Figura 4 Caso de Uso de Posicionamento Inicial. Caso de Uso Produção 1 inicio 2 Avança pistão de alimentação 3 ecuar pistão de alimentação 4 Identifica tamanho da placa 5 Avança pistão de trava de peça 6 Avança eixo Z 7 Avança eixo Y 8 Avança eixo X 9 ecua eixo Y 10 ecua eixo X 11 ecua eixo Z 12 ecuar pistão de trava de peça 13 Avança pistão de descarga 14 ecuar pistão de descarga 15 Conta placa Caso de Uso de Produção Contínua 1 inicio usuário solicita produção automática 2 envia comando de início da produção 3 Ativar indicativo de funcionamento em automático Figura 8 Caso de Uso de Produção Contínua. Caso de Uso de Produção Discreta 1 inicio usuário solicita produção de 1 peça por vez 2 envia comando de início da produção 3 Ativar indicativo de funcionamento discreto Figura 9 Caso de Uso de Produção Discreta. A partir do Diagrama de Casos de Uso e dos Casos de Uso levantados junto ao cliente, no processo de formalização da especificação do sistema, utiliza-se outro artefato da UML, o Diagrama de equência para se estabelecer uma sequência temporal de execução das tarefas possíveis. Esse diagrama estabelece a relação entre os atores e os Casos de Uso de forma a explicitar os sinais necessários de integração entre esses elementos de uma maneira formal, sendo necessário sua validação junto ao cliente da especificação levantada anteriormente. Os Diagramas de equência do exemplo de aplicação são ilustrados nas Figuras 10, 11, 12 e 13. A partir dos diagramas de sequência o modelo conceitual poderá ser elaborado e para isso é utilizado a ferramenta de modelagem em redes de Petri. Figura 5 Caso de Uso de Produção. Caso de Uso de Emergência 1 solicita posicionamento inicial 2 Ativar indicativo de emergência ativada Figura 6 Caso de Uso de Emergência. Caso de Uso de Parar 1 Enviar comando de parada para produção contínua 2 Ativar indicativo de parada pelo usuário Figura 10 Diagrama de equência a partir do Caso de Uso de Produção Discreta do Exemplo. Figura 7 Caso de Uso de Parar.

Figura 11 Diagrama de equência a partir do Caso de Uso de Produção Contínua do Exemplo. Figura 12 Diagrama de equência a partir do Caso de Uso de Emergência do Exemplo. Figura 13 Diagrama de equência a partir do Caso de Uso de Parar do Exemplo. A associação de modelos em redes de Petri com a linguagem de programação CLP visa a modelagem de sistemas automáticos baseados em CLPs, isto é, a representação de um sistema a ser automatizado descrito na forma gráfica, em uma representação de fácil entendimento entre as várias partes envolvidas no projeto, facilitando sua especificação e alteração. O projetista passa a modelar o sistema de forma que a abstração das redes de Petri fiquem restritas aos elementos de um CLP, necessários para a execução de um automatismo, isto é, são utilizados conjuntos de lugares e transições para representarem não só as lógicas booleanas básicas como E ou OU, mas também elementos como temporizadores, contadores e comparadores. A utilização da rede de Petri lugar transição, permite uma abstração maior em relação as redes condição evento [7], bastante usadas para a representação do controle dos intertravamentos em termos de lógica booleana, permitindo ao projetista uma maior facilidade na utilização de um número maior de recursos das linguagens de CLP (IEC 1131-3) [13], tais como temporizadores, contadores e comparadores, que não eram explicitamente representados formalmente. Na análise das características comportamentais da rede de Petri, temos que o modelo construído para o sistema deve ser livre de deadlocks (live), os conflitos são dirigidos pelo projetista, e se o sistema for composto por apenas lógicas E e OU (sem os elementos: contador, comparador e temporizador) é limitado a 1 token para os lugares (k=1, (safe). Desta forma para que o modelo do sistema seja adequado para a sua conversão a uma linguagem de programação CLP e as análises de características comportamentais sejam utilizadas, a modelagem de sistemas automáticos envolve a etapa da metodologia de Formulação do Modelo Conceitual e a etapa de Verificação e Validação do modelo conceitual obtido. Na etapa de Formulação do Modelo Conceitual utilizando as redes de Petri lugartransição os lugares são representados por flags, sensores, chaves fim de curso, etc., e atuam diretamente nas transições para realizar uma ação, sem se preocupar com os deadlocks que poderão acontecer na fase de funcionamento do sistema. Na associações das redes de Petri com os componentes da linguagem CLP temos os lugares representando um estado do sistema que pode corresponder, em termos de controle, a um sinal de entrada externo (característico de entradas externas de CLP) ou flags de sinalização interna. inais de entrada externo podem ser associados a flags internos, os quais

poderão ser ou não utilizados para compor outros intertravamentos. Os sinais de entrada e dos flags são representados individualmente por um lugar, tanto na sua forma não negada, quando negada, isto é, as vezes é interessante se trabalhar com a ausência de sinal, condição de segurança, nas entradas do CLP e sua forma negada pode então ser representada possuindo label de identificação diferente. No lugar negado, a marca é colocada indicando que o sinal de entrada está desativado. A capacidade de cada um destes lugares é especificada de acordo com a sua função na representação do elementos do CLP. Estes atributos podem ser descritos utilizando o formato de identificação dos lugares descrito na tabela 2. As transições representam as ações. Elas são constituídas de uma lógica funcional a partir da álgebra Booleana, que analisam os lugares de entrada e realizam atuações no sistema da mesma forma que os comandos de saídas de um CLP. As transições podem tatuar como contadores, temporizadores ou comparadores. O seu formato é representado na tabela 1. Tabela 1 descrição dos lugares e das transições. pi(y;z) ti(y;z) Y Z Y Z I x.x entrada externa; F x.x flag interno; Número atual de marcas do lugar = Q x.x aciona a saída externa; e/ou Q x.x seta a saída externa; e/ou Q x.x reseta a saída externa; C x contador; CMPx comparador; Tx temporizador; Tempo utilizado na análise de desempenho Uma saída do CLP, tais como atuadores, sinalizadores, etc., não pode ser utilizada como um lugar de entrada de uma transição e um lugar de entrada, como sensores, botões, etc., não pode ser utilizado como uma saída de uma transição, isto é, o subconjunto de lugares de entrada de uma transição não podem conter lugares que representem uma saída externa e o subconjunto de lugares de saída de uma transição não pode conter lugares que representem entradas externas. A partir dos elementos descritos nas Tabela 1 e das restrições estabelecidas, são modelados os programas de controle de intertravamentos dos sistemas automáticos. A conversão destes elementos é realizada para as linguagens baseadas em CLP normalizadas [13]. A Figura 14 ilustra as lógicas E e OU na representação em redes de Petri relacionadas com os elementos descritos na tabela 1. A concepção do modelo conceitual é modelada em redes de Petri com diferentes níveis de abstração, isto é, desde o nível mais abstrato, a partir dos casos de uso estabelecidos na etapa anterior, até um nível de detalhamento suficiente para que o projeto do controlador lógico programável seja implementado. A Figura 15 ilustra o modelo em redes de Petri do caso de uso produção no seu nível mais abstrato, nomeado nível 1. O modelo em rede de Petri utiliza os lugares (places) para descrever o estado do sistema e as transições para descrever as ações já objetivando sua aplicação na linguagem do controlador programável. Tipo de lógica E (AND) OU (O) Linguagem CLP (ladder) I0.0 I0.1 Q0.0 I0.0 I0.1 I0.2 Q0.0 epresentação em de de Petri (P) P1(I0.0, 0) P2(I0.1, 0) P1(I0.0, 0) T1( Q0.0; 0) T1(Q0.0; 0) T2(Q0.0; 0) P2(I0.1, 0) P3(I0.2, 0) T3(Q0.0; 0) P4(F0.0; 0) Figura 14 Lógica CLP e representação em rede de Petri. Figura 15 Modelo de nível 1 da rede de Petri do Caso de Uso de Produção do Exemplo. P3

O nivel 2 do modelo em redes de Petri para a modelagem do automatismo pode contemplar os sinais necessários para que o sistema possa interagir com o ambiente de execução do sistema de automação, ou seja os sensores e atuadores. A Figura 16 ilustra o nível 2 do modelo de redes de Petri. P1 T1 P2 T2 P3 T3 P4 T4 P5 T5 P6 T6 P7 T7 inicio Avança pistão de alimentação P9 peça alimentada ecuar pistão de alimentação Identifica tamanho da placa P10 sensor tipo de peça peça identificada P11 Trava peça identificada P12 peça travada Executa usinagem na peça P13 fim de usinagem peça usinada P8 recua pistão da trava da peça P14 sensor pistão recuado peça destravada descarrega a peça P15 peça descarregada contagem de peça sensor pistão recuado sensor peça na máquina sensor trava recuada sensor peça travada sensor peça descarregada Figura 16 Modelo de nível 2 da rede de Petri do Caso de Uso de Produção do Exemplo. A partir da colocação dos elementos sensores, é possível identificar também os atuadores necessários de forma a se estabelecer uma lista de entradas e saídas do sistema. A Figura 17 ilustra a lista de entradas e saídas levantadas a partir dessa especificação. Lista de Entradas e aída I0.0 - ensor pistão de alimentação recuado I0.1 - ensor pistão de alimentação avançado I0.2 - ensor peça na máquina I0.3 - ensor pistão prende peça recuado I0.4 - ensor pistão prende peça avançado I0.5 - ensor tipo de peça (0 - peça 1, 1 - peça 2) I0.6 - ensor fim de usinagem I0.7 - ensor pistão descarrega peça avançado I0.8 - ensor conta descarrega peça recuado I0.9 - ensor conta peça O0.0 - avança/recua pistão de alimentação O0.1 - avança/recua pistão prende peça O0.2 - ativa usinagem peça 1 O0.3 - ativa usinagem peça 2 O0.4 - avança/recua pistão de descarga da peça Figura 17 Lista de entradas e saidas obtida. Um terceiro nível se preocupar com os sinais de realimentação do sistema (feedback) e de integração com os demais níveis, além de nomear os pontos de entrada e saída de forma a facilitar a sua conversão para a linguagem de programação do controlador programável, de forma que fossem estabelecidos todos os sincronismos necessários ao sistema automático. P1 T1 P2 T2 P3 T3 P4 T4 P5 T5 P6 T6 P7 T7 P17 T8 i ni ci o P8 Avança pistão de alimentação O0.0 P9 I0.2 peça alimentada sensor peça na máquina ecuar pistão de alimentação Identifica tamanho da placa O0.0 P10 sensor tipo de peça peça identificada I0.5 P11 sensor trava recuada I0.3 Trava peça identificada O0.1 P12 I0.4 peça travada sensor peça travada Executa usinagem na peça O0.2 ou O0.3 P13 peça usinada recua pistão da trava da peça O0.1 O0.2 ou O0.3 P15 I0.8 peça destravada sensor pistão descarrega peça recuado avança pistão descarrega peça O0.4 peça descarregada P16 contagem de peça INC C0 I0.0 sensor pistão recuado fim de usinagem I0.6 recua pistão descarrega peça O0.4 I0.9 sensor conta peça Figura 18 Modelo de nível 3 da rede de Petri do Caso de Uso de Produção do Exemplo. Em paralelo ao desenvolvimento dos níveis de abstração há a verificação e validação do modelo conceitual obtido, permitindo que seu desenvolvimento ocorra observando-se as características comportamentais e de desempenho do sistema, preparando-o para possível conversão para uma linguagem de um controlador programável com a menor possibilidade de erros possível. Do modo como foi especificada a representação dos elementos em redes de Petri, a conversão do modelo pode ser direta para uma linguagem CLP padrão. Na conversão cada transição é traduzida para uma linha de programação do CLP, onde os lugares especificam os contatos que estabelecem as

condições para a ativação das bobinas (transição). A dinâmica de funcionamento da rede de Petri deve ser representada para a linguagem do controlador programável, isto é, após o disparo de uma transição, as marcas devem ser retiradas dos lugares anteriores à transição e todos os lugares posteriores devem receber marcações. Na prática, um flag é utilizado para habilitar a linha, que é executada e em seguida desabilitada, habilitando-se a próxima. Na verificação e validação do modelo conceitual o funcionamento do sistema é simulado com o apoio da ferramenta de modelagem de redes de Petri, onde os lugares de entrada poderão receber marcas, isto é, estes lugares poderão fazer parte do subconjunto de lugares de saída de uma transição. Fazendo com que o sistema possa dar prosseguimento a sua sequência de funcionamento. Nessa etapa, arcos, lugares e transições poderão ser incorporados no modelo de acordo com a necessidade, com objetivo de estabelecer a dinâmica de funcionamento desejada da rede de Petri. Posteriormente à verificação e validação esses elementos devem ser retirados para a conversão do modelo de controle. ão analisadas as sequências de funcionamento do modelo. Estas sequências deverão ser elaboradas para a operação normal do sistema tanto quanto para operações adversas, de acordo com perguntas do tipo e se... A principal características comportamental das redes de Petri analisada nas sequências de funcionamento é a ausência ou não de deadlocks (liveness). De forma que os conflitos são dirigidos pelo projetista. Outras características importantes analisadas são a reversibilidade e a limitabilidade do sistema (boundedness), caracterizando o sistema como de recuperação automática e sem estouros (overflow) respectivamente. A partir do modelo conceitual verificado e validado, pode-se realizar a sua conversão para a linguagem de CLP desejada, procurando nessa conversão se estabelecer a dinâmica de funcionamento da rede de Petri do modelo final a ser implementado no CLP. A Figura 19 ilustra a conversão do modelo de nível de abstração mais baixo, ilustrado na Figura 17 para a linguagem de programação CLP de diagrama de contatos (Ladder). As etapas de Especificação do Hardware e oftware ficam facilitadas a partir da especificação da lista de entradas e saídas do sistema de automação. O tipo de CLP, tipo de sensores e atuadores vão depender das necessidades estabelecidas pelo cliente e pelo modelo conceitual proposto. Com o hardware e software especificados de acordo com as necessidades do sistema, o programa do CLP convertido a partir do modelo conceitual mais detalhado obtido pode ser implantado no campo. Na implantação, qualquer alteração realizada em função de recursos tecnológicos ou limitações em campo da programação CLP deverá ser relatada e documentada no modelo conceitual de forma a ser discutida e validada, ou seja, deve ser rediscutida em função de uma possível limitação no funcionamento do sistema. P1 I0.0 O 0.0 P2 0.1 I 0.2 O 0.0 P3 I 0.0 I0.2 I 0.3 I 0.5 Q 0.1 P3 P4 P4 I0.2 I 0.4 Q 0.2/3 Figura 19 Programação CLP do Exemplo. A documentação final obtida do sistema de automação implantado deverá ser consistente com o modelo conceitual desenvolvido em redes de Petri de forma que qualquer alteração e manutenção possa ser facilmente identificada e realizada por profissionais capacitados. P1 P2 P2 P3 P4 P5 P5 I 0.6 O 0.2/3 P6 P6 I0.4 I 0.8 Q 0.4 P7 0.1 I 0.9 O 0.4 P5 P6 P7 P8 I0.8 C 0 P7 P8 P8 P1 T1 T2 T3 T4 T5 T6 T7 T8

esultados O principal resultado do estudo foi a proposta de uma metodologia de planejamento, modelagem e implantação de sistemas automáticos de manufatura. O desenvolvimento e detalhamento da metodologia foi exemplificada no projeto de automação de uma máquina, onde o estudo de caso permitiu a identificação e esclarecimento de todas as etapas da metodologia proposta. O nível de detalhamento na modelagem proporcionou a implementação do programa do controlador em um CLP e mostrou-se eficiênte com seu funcionamento e em conformidade com o modelo conceitual levandado. Discussão e Conclusões A modelagem do sistema utilizando-se os artefatos da UML (Diagramas de Casos de Uso, Casos de Uso e Diagrama de equência) e edes de Petri permite uma representação do sistema a ser implementado de forma clara e consistente, através de suas formas de representação e níveis de refinamento. A proposta mostrou-se eficaz quanto à modelagem e implementação do sistema, principalmente em relação à documentação e ao acompanhamento da implantação. O acompanhamento e verificação frente ao sistema implementado e o planejado, permite que se estabeleça um sistema automático o mais correto possível sem reconstrução de parte ou totalidade do sistema, o que geraria custos adicionais desnecessários. As ferramentas de simulação de sistemas discretos passam a ser utilizadas de maneira efetiva e fundamental para a especificação e principalmente para a verificação e validação dos sistemas a serem implementados. O método cobre de maneira eficiente e clara todas as etapas do desenvolvimento de um sistema de manufatura, levando-se em conta todos os elementos e análises necessários à implementação de um automatismo. eferências [1]Taholakian, A.; Hales, W. M. M., (1997), PN PLC: A methodology for designing, simulating and coding PLC based control systems using Petri nets, International Journal of Production esearch v.35 n.6. p. 1743-1762 [2]Troy, D., McQueen, M., (1996) A development environment for batch process control, Computers In Industry v.31 p. 61-84. [3]Gayman, D.J., (1998) An old favorite gets new standards, Manufacturing Engineering, january, p. 55-58. [4]Otter, J. D., (1988), Programmable Logic Controllers: Operation, Interfacing and Programming, New York: Prentice-Hall. [5]Bender D. F., Combemale B., Crégut X., Farines J. M., Berthomieu B., Vernadat F.. (2008). Ladder Metamodeling and PLC Program Validation through Time Petri Nets. Model Driven Architecture-Foundations and Applications, ECMDA, Berlin-Germany. pp. 121-136. [6]Hrúz B., Zhou M. C.. (2006). Modeling and control of discrete-event dynamic systems with Petri nets and other tools. pringer. [7]Murata, T., (1989) Petri Net: Properties, analysis and applications, Proceedings of the IEEE, v. 77, n.4, p. 541-579. [8]David., Alla H.. (2005). Discrete, continuous, and hybrid Petri nets. pringer. [9]Viswanadham, N, Narahari, Y.; Johnson, T. L., (1990) Deadlock Prevention and Deadlock Avoidance in Flexible Manufacturing ystems Using Petri Net Models, IEEE Transactions on obotics and Automation, v. 6, n. 6, p. 713 723. [10]Larman, C. (2001), Applying UML and Patterns: an Introduction to Object-oriented Analysis and Design and the Unified Process. Prentice Hall PT. [11]Balasubramanian,.; Zhang, X. e Norrie, D.H. (2000), Intelligent Control for Holonic Manufacturing ystems. Proc. Inst. Mech. Engrs., v. 214 part B. [12]Petri Net Tools and oftware, http:// www. informatik. uni- hamburg. de /TGI/ PetriNets/ tools/ acesso em 23/06/2014. [13]IEC International Electrotechnic Commission, (1992), Programmable Controllers, Part 3: Programmable Languages, Publication 1131-1. [14]D'ouza, K. A.; KATHO, s. K., (1994) A survey of Petri net applications in modeling controls for Automated Manufacturing systems, Computers in Industry v. 24, p. 6-16. [15]Venkatesh, K.; Zhou, M.; Caudill,., (1994) Comparing Ladder Logic Diagrams and Petri

Nets for equence Controller Design through a Discrete Manufacturing ystem, IEEE Transactions on Industrial Electronics, v.41, n.6, p. 611-619. [16] Lee G.B., Lee J.. (2002). Constructing Petri Net tate Equation for Ladder Diagram. Journal of Intelligent ystems. v.12, n.2, p. 69-92.. [17]Lee G. B., Zandong H., Lee J.. (2004). Automatic generation of ladder diagram with control Petri Net. Journal of Intelligent Manufacturing. v.15, n.2, p.245-252. [18]Venkateswaran P.., Bhat J., Meenatchisundaram. (2009). Formalism for fuzzy automation Petri nets to ladder logic diagrams. APN Journal of Engineering and Applied ciences.v.4, n.10, p.83-92. [19]Liu Y. (2009). A Petri net-based ladder logic diagram design method for the logic and sequence control of photo mask transport. Proc. of the 5th Int. Conf. on Emerging Intelligent Computing Technology and Applications. p. 774-783. [20]Gomaa M. M. (2011). Petri Net to Ladder Logic Diagram Converter and a Batch Process Control. APN Journal of Engineering and Applied ciences. v.6, n.2, p.67-72. Contato Prof. Dr. Edilson eis odrigues Kato, Departamento de Computação, Universidade Federal de ão Carlos (DC-UFCar). kato@dc.ufscar.br