UM MODELO DE DESENVOLVIMENTO DE SOFTWARE BASEADO EM REDES DE
PETRI UTILIZADO NO DESENVOLVIMENTO DO GERENTE DE UMA CÉLULA
FLEXí-VEL DE MANUFATURA
AUTORES
Eng. Manuel C. L. Ferreira Braga Prof. Dr.-Ing. Carlos A. Martin
GRUCON - Grupo de Comando Numérico e Automatização Industrial Departamento de Engenharia Mecânica
Universidade Federal de Santa Catarina Florianópolis - SC
RESUMO
Este artigo apresenta o modelo de desenvolvimento de um grupo de tarefas que compõem um Software responsável pelo gerenciamento de uma Célula Flexível de Manufatura. Este modelo é centrado na utilização de uma extensão do modelo clássico de Redes de Petri para a representação formal de sistemas a eventos discretos. Esta extensão do modelo de Redes de Petri é apresentada no artigo. O modelo extendido de Redes de Petri foi utilizado nas fases de representação formal, verificação e implementação destas tarefas. As fer-ramentas de apoio utilizadas ao longo das fases também são apresentadas e discutidas. O uso do paradigma da prototipagem nos testes em separado das tarefas também é abordado. O artigo ainda apresenta uma breve discussão sobre o domínio de aplicação do Software gerado e as razões que levaram
à
adoção do formalismo de Redes de Petri, bem como os resultados obtidos com a utilização do modelo de desenvolvimento apresentado.I SBAI - UNESP - Rio Claro/SP - Brasil
o
Domínio de Aplicação
Uma Célula de Manufatura consiste do agrupamento físico e lógico das unidades que são necessárias e suficientes para a realização de um determinado processo sobre uma certa gama de peças. A natureza dos processos que podem ser realizados por Células de Manufatura é diversa. Os processos mais comuns são os de usinagem, soldagem, pintura, montagem e inspeção. Uma Célula Flexível de Manufatura é uma Célula de Manufatura que apresenta grande flexibilidade, isto é, a capacidade de adaptar-se rapidamente a novas condições impostas pela entrada e/ou cancelamento de ordens de processo no chão-de-fábrica. Esta flexibilidade é alcançada graças aos baixos tempos de preparação das máquinas e pela racionalização do fluxo de materiais (peças e ferramentas) e informações dentro da Célula e entre a Célula e os demais sistemas do chão-de-fábrica. Um ponto no qual as definições de Célula Flexível de Manufatura, divergem diz respeito ao grau de automação da célula. Alguns autores só classificam como Célula Flexível de Manufatura aquelas Células cuja operação é totalmente remota, o que só é alcançado através da total automação do fluxo de informações e de materiais.
Naquelas Células com alto grau de automação, sejam elas flexíveis ou não, é necessário integrar uma série de equipamentos, os quais denominamos, genericamente, de unidades. Nas Células de usinagem e inspeção, as unidades consistem basicamente de máquinas-ferramenta CNC (Tornos, Fresadoras, Centros de Usinagem, etc.), sistemas de transporte e manipulação de peças ou ferramentas (esteiras, manipuladores dedicados, Robôs, etc.) e sistemas de inspeção. Além destes sistemas básicos, podem ser integrados sistemas de identificação (câmeras, leitoras de código de barras, etc.), sistemas de armazenamento de peças ou de ferramentas e sistemas de limpeza de peças. Todas estas unidades pos-suem uma certa capacidade de processamento local, que é dedicada às necessidades de suas aplicações, e também, alguma capacidade de comunicação que permite a sua operação remota. (Lepik-son, 1990)
As unidades de uma Célula automatizada são tipicamente integradas a um computador via uma rede de comunicação. Esta rede de comunicação pode consistir, desde uma simples conexão ponto a ponto baseada em interfaces RS 232-C com topologia do tipo estrela, onde o computador é o nó central, até redes locais convencionais como Ethernet ou Token-Ring ou redes locais apropriadas para o uso no chão-de-fábrica, como Fieldbus ou FIP. O computador ao qual as unidades da Célula estão conectadas assume as funções de um operador, coordenando e monitorando a operação das unidades da Célula. Neste computador, que pode consistir de um microcomputador compatível com o IBM PC ou uma Workstation, executa o Software que efetivamente monitora e coordena a operação das unidades da Célula. A este Software, denominamos de Gerente de Célula, ou simplesmente Gerente.
O Gerente envia para as unidades da Célula programas, parâmetros de configuração e sinais de comando que requerem a execução de ações, enquanto recebe das unidades os seus "status" e a notificação de eventos. O Gerente deve ainda editar relatórios, tratar situações de emergência, gerenciar bancos de dados, manter uma interface com os operadores da fábrica, comunicar-se com outros sis-temas do chão-de fábrica, etc.
As diversas funções atribuídas ao Gerente de uma Célula Flexível de Manufatura permitem antever a complexidade do desenvolvimento de tal Software. Este artigo é um dos resultados da implementação de uma Célula Flexível de Torneamento que involveu o desenvolvimento do seu Gerente. Esta Célula é composta de um Torno CNC, um Robô articulado de 6 eixos e um micrômetro LASER integrados via um protótipo de rede Profibus à um microcomputador compatível com o IBM PC AT. O Gerente de Célula ex-ecuta em ambiente Windows.
A escolha de Redes de Petri
No projeto preliminar do Gerente de Célula foram definidos os módulos que comporiam a ar-quitetura de Software do Gerente, com base na especificação gerada durante a análise de requisitos do Gerente. No projeto detalhado do Gerente, procurou-se definir as estruturas de dados e algoritmos inter-nos a cada módulo, responsáveis pela implementação das funcionalidades associadas a cada módulo. No projeto detalhado, também foi feita a opção pela implementação dos módulos como tarefas que ex-ecutariam sobre um sistema operacional multitarefa. Durante a execução do projeto detalhado,
detectou-se a necessidade de detectou-se adotar uma técnica de repredetectou-sentação formal para repredetectou-sentar as atividades realizadas por certas tarefas e as suas interações com as demais tarefas que compõem o Gerente. Este grupo de tarefas necessitou um tratamento diferenciado das demais em função de suas características. As demais tarefas têm funções clássicas dentro da informática, como a manipulação de estruturas de dados simples, interface com o usuário, inicialização do sistema e gerenciamento de um banco de dados. As atividades associadas a estas funções são seqüenciais e envolvem poucas interações entre as tarefas do Gerente, de tal modo que não foi necessária a adoção de um modelo de desenvolvimento para estas tarefas fora dos moldes convencionais. As características do grupo de tarefas que demandaram o uso do modelo aqui apresentado dizem respeito, sobretudo, ao paralelismo, conflito e sincronização entre as atividades por elas desenvolvidas. A implementação de forma "ad hoc" da lógica que coordena essas atividades teria alto custo e o código fonte gerado seria de difícil manutenção.
A técnica de representação a ser adotada deveria, além de ser formal, ser clara e não dar margem
à
ambigüidades. Ficou definido também que deveria ser possível utilizar ferramentas que permitissem realizar a validação da representação do comportamento destas tarefas, e a geração automática de código a partir da representação na técnica escolhida.A questão do formalismo eliminou de início o uso de técnicas baseadas em DFD (Gane, 1979) e o uso do SADT (Structured Analysis and Design Technique) (Ross, 1977). A incapacidade de expressar claramente as relações de paralelismo, sincronização e conflito impediram o uso de tabelas de estado e do formalismo de máquinas de estado finito (Danthine, 1980). As Redes de Petri (Peterson, 1981), por outro lado, atendem a todos estes requisitos (Rillo, 1989) (Cardoso, 1989): Porém, foi necessário utilizar uma extensão deste modelo que permitisse representar a manipulação de dados pela Rede e a interação da Rede com o ambiente externo, composto pelas demais tarefas.
o
Modelo de Desenvolvimento
o
modelo de desenvolvimento apresentado representa as atividades realizadas ao longo do processo de desenvolvimento de um grupo de tarefas que consistem da implementação de certos módulos do Gerente de Célula. Este modelo não representa atividades anteriores, associadas ao desen-volvimento do Gerente como um todo. Estas etapas dizem respeitoà
análise de viabilidade, análise de requisitos e projeto preliminar do Gerente (Braga 93). O modelo de desenvolvimento deste grupo de tarefas se superpõe às fases de projeto detalhado, implementação dos módulos e testes dos módulos doAnálise de Viabilidade
Análise de Requisitos
Projeto Preliminar
/
Representação em Redes de Petri
Projeto Detalhado
Verificação
I mplementação dos Módulos
Geração de Código
Teste dos Módulos
Prototipagem
Integração
~
Implementação
Testes de Integração
processo de desenvolvimento do Gerente como um todo, conforme ilustra a figura 1.
Figura 1 - Modelo de Desenvolvimento do Gerente x Modelo de Desenvolvimento das tarefas baseado em Redes de Petri
I SBAI - UNESP - Rio Claro/SP - Brasil
A fase de representação. em Rede de Petri consiste da edição. do.s grafo.s da Rede de Petri que rep-resentam o. compo.rtamento. de uma tarefa em um edito.r gráfico. de uso. geral. Os grafo.s editado.s co.nsis-tem da parte-co.ntro.le e da parte-dado.s da Rede de Petri, co.nfo.rme a apresentação. do. próximo. ico.nsis-tem. Nesta fase também é gerado. um dicio.nário. de dado.s que descreve certo.s elemento.s do.s grafo.s da parte dado.s da Rede de Petri.
Na verificação. utiliza-se uma ferramenta que permite a verificação. de certas pro.priedades e a simulação. da evo.lução. da Rede de Petri que mo.dela o. co.mpo.rtamento. de uma tarefa. Esta verificação. é feita apenas so.bre a parte-co.ntrole da Rede de Petri. A verificação. é discutida mais detalhadamente num item a seguir.
A Geração. de Código. é supo.rtada po.r uma ferramenta que gera código. fo.nte em linguagem C a partir de um sistema de regras escrito. numa sintaxe "Lisp-like". A geração. de código. é abo.rdada em maio.r detalhe em o.utro item.
A partir do. código. gerado., é criado. um pro.tótipo. que já tem implementada to.da a lógica da tarefa
à
qual ele está asso.ciado.. Este pro.tótipo. é então. executado. a fim de se detectar algum funcio.namento. fo.ra das especificações. O pro.jetista interage co.m o. pro.tótipo. durante a sua execução. através de janelas que simulam a interação. da tarefa à qual está asso.ciado. o. protótipo. co.m as demais tarefas.
A implementação. da tarefa co.nsiste basicamente da substituição. das primitivas que co.mandam a criação. das janelas no. pro.tótipo. da tarefa pelas primitivas de co.municação. do. ambiente em que a tarefa executa, além da adição. de algumas funções. Uma implementação. tão. simples só é po.ssível pelo. fato. de que as tarefas e o.s seus respectivo.s pro.tótipo.s executam no. mesmo. ambiente e seus fo.ntes estão. numa mesma linguagem.
o
modelo extendido de Redes de Petri
A classe de Redes de Petri utilizada co.nsiste de uma extensão. do. mo.delo. clássico. de Redes de Petri. A extensão. permite a representação. da manipulação. de dado.s pela Rede e da interação. da Rede co.m o. ambiente (Co.urvo.isier, 1982). Estas características adicio.nais vão. de enco.ntro. às necessidades da representação. do. co.mpo.rtamento. das tarefas do. Gerente que seguem o. mo.delo. de desenvo.lvimento. descrito. no. item anterio.r.
Nesta extensão., as transições da Rede de Petri são. acrescidas das no.ções de co.ndições suplementares de tiro. e de ações asso.ciadas ao. disparo. A figura 2 mo.stra parte de um grafo. que repre-senta o. co.mpo.rtamento. de uma das tarefas do. Gerente. Neste grafo., é po.ssível identificar elemento.s que não. aparecem no. grafo. de uma Rede de Petri clássica. As transições deste grafo., além de serem eti-quetadas co.m um "Iabel" que permite a sua identificação. unívo.ca, tem asso.ciadas a si uma expressão. entre parênteses. Esta expressão. co.rrespo.nde às co.ndições suplementares de tiro. e às ações as-so.ciadas ao. disparo de uma transição.. Po.r exemplo., a transição. identificada pelo. "Iabel" t6 tem asso.ciada a si a co.ndição. suplementar de tiro. 04 e as ações 010 e 011, enquanto. que a transição. t9 tem asso.ciada a si uma única ação. 014.
A existência de uma co.ndição. suplementar de tiro. asso.ciada a uma transição. implica que, além de haver um número de fichas suficiente no.s seus lugares de entrada, esta co.ndição. deve ser satisfeita para que a transição. po.ssa ser disparada. Desta fo.rma, para que o. disparo. da transição. t7 o.co.rra, é necessário. que o. lugar "Ro.bô se afasta do. To.rno." po.ssua pelo. meno.s uma ficha e que a co.ndição. suplementar de tiro 05 seja satisfeita. A existência de uma ação. asso.ciada a uma transição. implica que, além da mo.vimentação. de fichas, o. disparo. da transição. causará a execução. desta ação.. O disparo. da transição. t4, po.r exemplo., implicará na retirada de uma ficha de cada um do.s seus três lugares de entrada ("To.rno. livre", "Ro.bô livre" e "Peça no. Armazém de Entrada"), na co.lo.cação. de uma ficha em cada um do.s seus do.is lugares de saída ("Carga de pro.grama no. CNC do. To. mo. " e "Ro.bô retira peça do. Armazém de Entrada") e ainda, na execução. de três açoes (06, 07 e 08).
Os grafo.s, co.mo. o. da figura 2, o.nde é po.ssível identificar as relações de seqüência, paralelismo., sincro.nismo. e co.nflito. entre as atividades representadas, além das condições suplementares de tiro. e ações asso.ciadas às transições, co.mpõem a chamada "parte-co.ntro.le"de uma Rede de Petri. Há um o.utro tipo. de grafo. que co.mpõe a chamada "parte-dado.s" da Rede de Petri. Neste grafo. são. explicitadas as relações entre as co.ndições suplementares de tiro. e ações, que também aparecem no. grafo. da parte-co.ntro.le, e '1lags" e variáveis, que só aparecem neste grafo.. Desta fo.rma, este grafo. identifica quais variáveis e/o.u "flags" têm seus valo.res -avaliado.s a fim de verificar se uma determinada co.ndição. suplementar de tiro. é satisfeita. Do. mesmo. mo.do., este grafo. identifica aqueles '1lags" o.u variáveis que
t8 (Q2.04"0S) Operador coloca peça no Armazém de Entrada (Ql,02'()'l) Identifica peça a ser colocada Armazém de Entrada ~01) Armazém de Entrada livre (06.013) Robô livre Programa carregado noCNCdo (Q4.01(),()11) pronta para Usinagem (Q7.015)
Peça no Tomo usinada
Robô se afasta do Tomo
(Q5.012)
•
Figura 2 - Grafo do modelo extendido de Redes de Petri
são acessados, seja para leitura ou escrita, quando uma certa ação é realizada. A figura 3 ilustra os nós que aparecem neste grafo. O nó "célula-memória" pode representar um ''flag'' ou uma variável. O nó "en-tidade externa" representa, como o próprio nome sugere, uma en"en-tidade externa
à
Rede de Petri que é capaz de acessar as células memória. Desta forma, a interação de uma Rede de Petri com entidades ex-ternas se dá através das células-memória.
O
Condição suplementar de tiroO
AçãoCélula-Memória
,
-l _ _ ) Entidade Externa
Figura 3 - Os elementos do grafo da parte-dados de uma Rede de Petri
A figura 4 representa as relações entre uma entidade externa, um "flag" e uma condição suplemen-tar de tiro. Este grafo indica que uma condição suplemensuplemen-tar de tiro está associada ao estado de um "flag", e que este "flag" tem seu valor definido por uma entidade externa. Já a figura 5 representa as relações entre uma ação, uma variável e uma entidade externa. Segundo este grafo, a ação define o valor de uma variável que é lido por uma entidade externa.
[ SBAI - UNESP - Rio Claro/SP - Brasil
Figura 4 - Grafo exemplo Figura 5 -Grafo exemplo
Além de um grafo, a parte dados de uma Rede de Petri é acompanhada de um dicionário de dados que descreve o significado de cada célula memória e de um documento que descreve as ações e condições suplementares de tiro.
A ferramenta de verificação
Na verificação da representação em Redes de Petri das atividades desenvolvidas por cada tarefa, utilizou-se a ferramenta ARP (Analizador de Redes de Petri) (Maziero, 1990). Tal ferramenta requer que o grafo da Rede de Petri que modela o comportamento de um sistema qualquer seja reescrito numa lin-guagem de entrada do sistema, cuja sintaxe é extremamente simples. Esta ferramenta permite que uma Rede de Petri tenha certas propriedades verificadas, e ainda a simulação interativa da evolução da Rede. Através do ARP foi possível verificar, por exemplo, que o grafo da Rede de Petri, ao qual pertence o trecho mostrado na figura 2, é livre de "deadlocks" e "Iivelocks", é binário e reinicializável. É possível ainda gerar o grafo de marcações acessíveis da Rede e realizar a redução da Rede. O ARP permite também a identificação dos invariantes de lugar e transição de uma Rede.
A ferramenta de geração de código
A ferramenta utilizada na geração de código, chamada SPP (Sistema de Produção Proposicional) (Paladino, 1990), gera código fonte em linguagem C a partir de um sistema de regras escrito numa sin-taxe "Lisp-like". O código fonte em C gerado pelo SPP consiste de um motor de inferência de uso geral e de estruturas de dados que representam as bases de regras e fatos descritos na sintaxe do SPP. Este motor de inferência trabalha sem "backtracking", possui raciocínio não monotônico e encadeamento para frente, além de atender às estratégias clássicas de resolução de conflitos. A estrutura do código fonte em C gerado pelo SPP é totalmente transparente para o projetista, que em momento algum precisa sequer ler este fonte. O sistema de regras, a partir do qual é gerado o código fonte que será utilizado na prototipagem da tarefa e na sua implementação,
é
criado a partir da reescrita do grafo da parte-controle da Rede de Petri que representa o comportamento da tarefa. Por exemplo, quando o grafo da figura 2e
reescrito como um sistema de regras, a transição t6 é reescrita como a seguinte regra na sintaxe do SPP(RULE t6 15
IF (ge "RoboDepositaPecaNoTorno 1)
(eq "04 1)
THEN (concl"RoboDepositaPecaNoTorno (- "RoboDepositaPecaNo Torno 1))
(concl"PecaNoTornoProntaParaUsinagem (+ "PecaNoTornoProntaParaUsinagem 1))
(cone! "RoboSeAfastaDoTorno (+ "RoboSeAfastaDoTorno 1))
(print (010) "Parametro) (print (011) "Parametro) (cone! "Q4 O)
Na regra acima é possível identificar a mesma semântica das Redes de Petri. Porém, aparecem al-guns elementos estranhos que não estão presentes na Rede. Estes elementos aparecem em função do SPP ser um sistema de uso geral. Logo, é natural que apareça algum "overhead" quando se procura utilizar a sua sintaxe para representar um outro modelo como Redes de Petri. Um dos elementos estran-hos à Rede que aparece está associado a uma das estratégias de resolução de conflitos implementadas no motor de inferência inserido pelo SPP no fonte gerado. Este elemento é o número 15, que aparece logo no início da declaração da regra. Este número é uma prioridade associada à regra t6. Os elementos "print" e "Parametro" que aparecem associados às ações 010 e 011 na regra, também são "overheads" em relação à Rede de Petri. Na implementação, as ações associadas às transições da Rede de Petri con-sistem de funções que são codificadas pelo projetista. O "print" que aparece na regra indica que uma função externa deve ser chamada quando a regra
é
aplicada. A expressão "(concIIlQ4 O)" tambémé
um "overhead" necessário para que o sistema de regras tenha um comportamento análogo ao da Rede de Petri.Resultados
A utilização do modelo descrito no desenvolvimento de um grupo de tarefas do Gerente de uma Célula Flexível de Torneamento, atendeu às necessidades levantadas no projeto detalhado do Gerente, conforme discutido no artigo, e também apresentou outros aspectos positivos.
Nenhum erro foi detectado nas tarefas cujo desenvolvimento seguiu o modelo apresentado, durante os testes realizados sobre o Gerente como um todo, após a integração das tarefas. Todos os erros foram detectados durante as fases de verificação da representação em Redes de Petri e de execução do protótipo.
Os testes sobre a lógica de cada tarefa, realizados através da execução dos respectivos protótipos, não são complexos e não demandam muito tempo dos projetistas.
O código fonte em linguagem C gerado pelo SPP não possui chamadas à primitivas do sistema operacional sobre o qual o Gerente executa. Desta forma, este fonte é totalmente neutro, o que facilita a migração do Gerente para outro ambiente.
A documentação gerada ao longo do processo de desenvolvimento adotado é extremamente con-sistente. Esta documentação gerada e a expressividade dos grafos de Redes de Petri tornam as atividades de manutenção de Software bem menos árduas.
Referências
Lepikson, H. A., "Padronização e Interação das Unidades de Fabricação, Inspeção e Manipulação de uma Célula Flexível de Manufatura", Dissertação de Mestrado em Engenharia Mecânica, UFSC, 1990.
Peterson,
J
. L., "Petri Nets
: Theory and Modelling of Systems", Prentice Hall, 1981.Courvoisier, M., Valette, R., "Systemes de Com mande en Temps Réel- Description, Analyse et Realisa-tion", Editions SCM, 1980.
Braga, M. C. L. F., "Uma Proposta de Arquitetura de Software para um Gerente de Célula Flexível de Manufatura e Integração das Unidades da Célula", Dissertação de Mestrado em Engenharia Mecânica, UFSC, 1993.
Rillo, M., "Controle de Sistema de Manufatura por Redes de Petri e Regras de Produção", XXII Con-gresso Nacional de Informática, 1989.
Cardoso, J., Valette,
R.,
"Escolha de uma Classe de Rede de Petri para Descrição de Sistemas Flexíveis de Manufatura", Nota Interna do Laboratório de Controle e Microinformática -Departamento de Engenharia Elétrica, UFSC, 1989.I SBAl -UNESP -Rio Claro/SP - Brasil
Maziero, C. A, "Um Ambiente para a Análise e Simulação de Sistemas Modelados por Redes de Petri", Dissertação de Mestrado em Engenharia Elétrica, UFSC, 1990.
Paladino, A. D. A, "Um Gerador de Programas Para Sistemas de Regras de Produção Visando a Eficiência na Execução", Dissertação de Mestrado em Engenharia Elétrica, UFSC, 1990.
Ross, D. T., "Structured Analysis (SA) : A Language for Communicating Ideas", IEEE Transactions on Software Engineering, vol SE-3, no 1,1977.
Gane, C. P., "Data Design in Structured System Analysis", Infotech State of the Art Report on Data Design, 1980.
Danthine,
