Comparações Entre Políticas de Controle Depois de feito o wizard sobre o framework, o

próximo passo foi a realização de comparações entre políticas de controle. Para tal, foi considerado parte do SMH apresentado na Figura 7, nomeadamente: (a) o Armazém de 9 posições (Armazem.1); (b) a Mesa de 2 posições (Mesa2P.1); e (c) o Robô Puma transportador (Puma 560.1), conforme Figura 7.

Figura 7: Equipamentos envolvidos nos testes. O Armazém de nove posições comporta peças A e B. As peças tipo A são armazenadas (à priori) nas posições de 1 a 6, transportadas para a posição 1 da Mesa e a partir daí seguem para fresamento. As peças do Tipo B são armazenadas (à priori) nas posições de 7 a 9, transportadas para a posição 2 da mesa e a partir daí seguem para torneamento.

Este cenário (chamado caso nominal) ocorre porque normalmente se produz duas vezes a quantidade de peças A em relação à quantidade de peças B, sendo o processamento de A (fresamento) duas vezes mais rápido que o de B (torneamento). Contudo, conforme as necessidades de produção, esta proporção poderia variar, sendo possível até mesmo a produção de apenas um tipo de peça.

Com as características mencionadas, este sistema permite testar diferentes políticas de controle levando em consideração as permissões de utilização de posições dos Resource-HLs Armazém e Mesa. Tais permissões dependem do conhecimento das Rules, de acordo com as necessidades de produção.

Assim sendo, conjuntos de Rules prescritas por políticas de controle heterárquicas, hierárquicas e holônicas foram criados e analisados. Analisou-se a eficácia do processo de produção para cada política de controle e o aproveitamento de cada Resource-HL. O controle hierárquico foi elaborado com um conjunto de regras que respeitavam estritamente a definição das posições de armazenamento para cada tipo de peça. Estas regras deste controle são mostradas na Figura 8.

Enquanto a produção estava no caso nominal, houve taxas de rendimentos otimizadas. Entretanto, com uma produção mais variada, houve má utilização do Armazém uma vez que as peças tipos “A” e “B” tinham suas posições no Armazém pré-definidas e rígidas. Portanto, foi necessário realimenta-lo com uma freqüência maior do que no caso nominal.

Figura 9: As regras heterárquicas usadas.

Quanto ao controle heterárquico, este é constituído por regras mais simples e livres que analisam só o necessário para sua aprovação sem considerações mais sistêmica. Por isto, este controle bane qualquer tipo de decisão organizada e se torna caótico, pois não há predição das ações das Rules decorrentes. Estas regras estão na Figura 9.

A execução deste controle resultou em uma aparente melhoria na interação entre os equipamentos envolvidos uma vez que o uso do Armazém foi mais extensivo do que para o controle hierárquico. Entretanto, como não havia decisões organizadas, o número de peças produzido era imprevisível, além das peças tomarem rumos inapropriados.

Por fim, o controle holônico foi elaborado com regras que respeitassem a definição dada das posições em produção nominal. Entretanto, em produção variada, permitiu-se a utilização de posições ociosas em relação à destinação original.

Assim sendo, as posições do Armazém eram bem utilizadas uma vez que se diminui a freqüência de realimentação do sistema. Em suma, a diferença do controle holônico é a quantidade e a qualidade de informação considerada nas regras.

Como se pode observar nas Figuras 10 e 11, tanto os conjuntos de espaços do Armazém quanto o tipo de peça a ser contida neles são verificados, o que permite variar o tipo de produto na posição. Desta forma, há o aproveitamento de espaços ociosos, mas mantendo-se a quantidade (ou proporção) desejada de peças de cada tipo.

Finalmente, constatou-se que o controle holônico absorve as características mais vantajosas da hierarquia e da heterarquia, sendo este mais complexo e eficiente, e que em geral o número de regras necessário para representá-lo foi maior.

Figura 11: Algumas regras holônicas usadas.

6. Conclusão

Como premeditado, o ambiente de desenvolvimento de controle foi criado e se demonstrou funcional, de forma que possibilitou a etapa seguinte deste trabalho. Esta etapa consistiu na criação de três instâncias de controle: uma hierárquica, uma heterárquica e uma holônica. Estas instâncias foram objeto de comparação, tendo ficado evidente a preponderância da abordagem holônica perante as demais abordagens.

O ambiente criado resultou em uma evolução da facilidade de composição de controles orientados ao processo, sendo uma contribuição para esta tecnologia de controle e simulação, bem como uma contribuição para potencializar as experimentações decorrentes. A comparação de controles feita é pertinente para demonstrar as afirmativas da literatura referente às vantagens da abordagem holônica em relação às abordagens precedentes. Isto porque há a afirmativa na literatura, mas não há exemplos palpáveis em abundância, sobretudo de controle holônico orientado ao processo.

Por fim, dentre os trabalhos futuros, prevê-se a evolução do ambiente para comportar controle orientado ao produto (i.e. com participação explícita de Product-HLs), bem como a utilização dele para o chamado PON (Paradigma de Programação Orientado a Notificações) criado a partir do meta-modelo de controle em questão [12][13].

Agradecimentos

J. Lucca agradece a Fundação Araucária pela bolsa concebida para este trabalho e ao LSIP/UTFPR pelos recursos disponibilizados.

Referências Bibliográficas

[1] Babiceanu, R. F.; Chen F. F.: Development and Applications of Holonic Manufacturing Systems: A Survey. Journal of Intelligent Manufacturing. Vol. 17, Pp.111-131, Springer Science+Business, Inc. Manufactured in Netherlands, 2006.

[2] Deen, S.M.: Agent-Based Manufacturing: Advances in the Holonic Approach. Springer, ISBN 3-540-44069-0, 2003.

[3] Da Silveira, G.; Borenstein, D.; Fogliatto, F.S.: Mass customization: literature review and research directions. International Journal of Production Economics, 72 (pp1-13), 2001.

[4] Simão, J. M.: A Contribution to the Development of a HMS simulation tool and Proposition of a Meta-Model for Holonic Control. Ph.D. Thesis, CPGEI/UTFPR & CRAN-UHP, 2005.

[5] Simão, J. M.; Stadzisz, P. C.; Morel, G.: Manufacturing Execution System for Customised Production. Journal of Material Processing Technology, Elsevier, Vol. 179, Issues 1-3, 2006. [6] Simão, J. M.; Stadzisz, P. C.: Inference Process Based on Notifications: The Kernel of a Holonic Inference Meta-Model Applied to Control Issues. IEEE Trans. on Syst. Man and Cybernetics, Part A, Syst. and Humans, Vol. 39, Issue 1, 238-250, 2009. [7] Simão, J. M.; Tacla C.A.; Stadzisz, P. C.: Holonic Control Meta-Model. IEEE Transactions on Systems, Man and Cybernetics. Part A, Systems and Humans. Accepted paper - SMCA07-10-0308.R1, 2009. [8] Simão, J. M.; Stadzisz, P. C.; Künzle, L.A.: Rule and Agent-Oriented Architecture to Discrete Control Applied as Petri Net Players. Frontiers in Artificial Intelligence and Applications ("Advances in Logic, Artificial Intelligence and Robotics" LAPTEC 2003). Vol. 101 (pp. 121-129) IOS Press, Amsterdam - The Netherlands. ISSN: 0922-6389, 2003.

[9] Lucca, J.: Modulo de Interface Amigável sobre Meta-modelo de Controle conectado em Ferramenta de Simulação de Sistemas de Manufatura. Relatório de Iniciação Científica. PIBIC/UTFPR, 2008. [10] Lucca, J.; Banaszewski, R. F.; Stadzisz, P. C.; Tacla, C. A; Simão, J. M: Interface sobre Meta-modelo de Controle do Simulador ANALYTICE II e suas Utilizações para Comparações de Políticas de Controle de Manufatura. Resumo Est. no Seminário de Iniciação Cient. e Tecn. (SICITE) - UTFPR, 2008. [10] Deen, S. M.: Agent-Based Manufacturing: Advances in the Holonic Approach, 2003.

[11] Mařík, V.: Industrial Application of the Agent-based Technology. Copyright IFAC, 2004.

[12] Simão, J. M.; Stadzisz, P. C.: Paradigma Orien-tado a Notificações (PON) – Uma Técnica de Com-posição e Execução de Software Orientado a Notifi-cações. Pedido de Patente ao INPI/Brasil, Número Temporário: 015080004262, 2008.

[13] Banaszewski, R. F.: Paradigma Orientado a Notificações: Avanços e Comparações. Dissertação de Mestrado, CPGEI/UTFPR, 2009.

AN ´ALISE SOB RESTRI ¸C ˜OES BASEADA EM UM RACIOC´INIO ENERG´ETICO PARA O PROBLEMA DE ESCALONAMENTO TEMPO REAL DE SISTEMAS DE

GERENCIAMENTO DE WORKFLOW Fl´avio F´elix Medeiros∗, St´ephane Julia∗

∗Faculdade de Computa¸c˜ao - Universidade Federal de Uberlˆandia Av. Jo˜ao Naves de ´Avila, 2160 - Bloco B, Sala 1B - CEP 38400-902

Uberlˆandia, MG, Brasil

Emails: flaviomedeiros.ufu22@yahoo.com.br, stephane@facom.ufu.br

Abstract— The objective of this paper is to propose a method of analysis under constraints applied to the problem of real time scheduling in workflow management systems. The adopted model is a p-time Petri net with hybrid resource allocation mechanism. The proposed method uses originally mechanism of time constraint propagation based on cases duration and different types of routings for workflow processes. The different types of resources (discrete and continuous) are incorporated into the model and an approach based on energetic reasoning is applied. The energetic reasoning can identify unacceptable schedulings due to energetic inability of resources involved in the implementation of related activities, and update the temporal constraints in order to eliminate inconsistent dates with scheduling solutions. On the set of modified constraints is then applied a specialized inference mechanism, called token player, seeking to obtain in real time an admissible scenario corresponding to a specific sequence of activities which respects all the time constraints.

Keywords— Workflow management system, Petri Nets, Constraint Programming, Energetic Reasoning Resumo— O objetivo deste artigo ´e o de propor um m´etodo de an´alise sob restri¸c˜oes aplicado ao problema de escalonamento tempo real em sistemas de gerenciamento de workflow. O modelo adotado ´e uma de rede de Petri p-temporal com mecanismo de aloca¸c˜ao de recursos h´ıbridos. O m´etodo proposto utiliza inicialmente um mecanismo de propaga¸c˜ao de restri¸c˜oes temporais baseado nas dura¸c˜oes dos casos e nos diferentes tipos de roteiros dos processos de workflow. Os diferentes tipos de recursos (discretos e cont´ınuos) s˜ao incorporados ao modelo e uma abordagem baseada em um racioc´ınio energ´etico ´e ent˜ao aplicada. O racioc´ınio energ´etico consegue identificar escalonamentos inadmiss´ıveis devido `a incapacidade energ´etica dos recursos envolvidos na execu¸c˜ao das atividades correspondentes, bem como atualizar as restri¸c˜oes temporais dos processos a fim de eliminar datas inconsistentes com solu¸c˜oes de escalonamento. Posteriormente, ´e aplicado ao conjunto de restri¸c˜oes modificadas um mecanismo de inferˆencia especializado, denominado jogador de redes de Petri, que busca obter em tempo real um cen´ario admiss´ıvel correspondente a uma sequˆencia espec´ıfica de atividades que respeitem o conjunto das restri¸c˜oes temporais.

Keywords— Sistemas de gerenciamento de workflow, Redes de Petri, An´alise sob restri¸c˜ao, Racioc´ınio E-nerg´etico

1 Introdu¸c˜ao

O prop´osito de um sistema de gerenciamento de workflow (Aalst and Hee, 2002) ´e executar pro-cessos de workflow. Propro-cessos de workflow repre-sentam uma sequˆencia de atividades de uma or-ganiza¸c˜ao que devem ser executadas para tratar casos espec´ıficos a fim de alcan¸car um objetivo bem definido.

De acordo com (Aalst and Hee, 2002), o uso das redes de Petri na modelagem de workflow tem uma s´erie de vantagens importantes, como o fato de for¸car uma defini¸c˜ao precisa dos processos em contraste com a maioria das t´ecnicas de diagra-ma¸c˜ao informais, como por exemplo o uso de di-agramas de atividades da UML (Dumas and Hof-stede, 2001)

Alguns modelos baseados em redes de Petri foram definidos exclusivamente para a represen-ta¸c˜ao de workflow, como ´e o caso das Workflow-nets por exemplo (Aalst and Hee, 2002). As Workflow-nets possuem apenas um lugar de in´ıcio e um lugar de t´ermino, sendo que uma ficha no lugar de in´ıcio representa um caso que precisa ser

tratado e uma ficha no lugar de t´ermino representa um caso que foi tratado. Toda tarefa ´e associada a uma transi¸c˜ao e toda condi¸c˜ao ´e associada a um lugar, sendo que toda tarefa e condi¸c˜ao deve estar em um caminho entre o lugar de in´ıcio e o lugar de t´ermino.

O problema de escalonamento (Lee and DiCe-sare, 1994) consiste em organizar no tempo uma sequˆencia de atividades considerando restri¸c˜oes temporais (intervalos temporais) e restri¸c˜oes de utiliza¸c˜ao de recursos compartilhados necess´arios para execu¸c˜ao das atividades. No caso de sistemas de tempo real, v´arios cen´arios (v´arios casos em um sistema de gerenciamento de workflow ) po-dem ser executados simultaneamente e situa¸c˜oes de conflito que devem ser resolvidas em tempo real (sem mecanismos de retrocesso) podem ocorrer se um mesmo recurso n˜ao-preemptivo for chamado ao mesmo tempo para execu¸c˜ao de atividades que pertencem a cen´arios diferentes.

A diferen¸ca fundamental entre o problema de escalonamento tradicional dos sistemas de pro-du¸c˜ao (Lee and DiCesare, 1994) e o problema de escalonamento em sistemas de gerenciamento

de workflow ´e a natureza dos recursos envolvidos para tratar as atividades. No caso dos sistemas de produ¸c˜ao, os recursos representam equipamentos f´ısicos e s˜ao representados por simples fichas (re-cursos do tipo discreto) nos lugares. No caso dos sistemas de gerenciamento de workflow, os recur-sos podem representar equipamentos f´ısicos bem como funcion´arios humanos. Por exemplo, ´e pos-s´ıvel alocar uma enfermeira em um hospital para cuidar de v´arios pacientes ao mesmo tempo du-rante o seu dia de trabalho. Nesse caso, a en-fermeira n˜ao pode ser vista como uma simples ficha discreta e um modelo baseado em uma rede de Petri ordin´aria dificilmente poder´a representar todas as caracter´ısticas reais que existem em sis-temas de gerenciamento de workflow.

Um outro problema vem da incerteza associ-ada ao comportamento dos recursos de tipo hu-mano. Isso torna praticamente imposs´ıvel o c´al-culo de uma solu¸c˜ao de escalonamento previs´ıvel como geralmente acontece no campo da manu-fatura (Lee and DiCesare, 1994).

Neste trabalho, ser´a apresentado um m´etodo de an´alise sob restri¸c˜oes cujo objetivo ser´a a cons-tru¸c˜ao de uma base de conhecimento que poder´a ser integrada a um mecanismo de inferˆencia es-pecializado, chamado jogador de redes de Petri, que executar´a em tempo real (sem mecanismo de retrocesso) uma solu¸c˜ao de escalonamento admis-s´ıvel (que respeite um conjunto de restri¸c˜oes) no contexto dos sistemas de gerenciamento de work-flow.

2 Modelo de processo de workflow temporal com mecanismo de aloca¸c˜ao

de recursos h´ıbridos

O modelo proposto neste artigo ´e o mesmo que aquele proposto em (de Oliveira et al., 2008). Trata-se de uma rede de Petri p-temporal com alo-ca¸c˜ao de recursos h´ıbridos. Neste modelo, a estru-tura de controle segue a mesma que aquelas das workflow-net de Aalst (Aalst and Hee, 2002), com os lugares de in´ıcio, fim e os principais roteiros existentes nos processos de workflow. Em vez de associar as tarefas `as transi¸c˜oes, as tarefas s˜ao as-sociadas `a lugares espec´ıficos. Assim, os mecanis-mos de aloca¸c˜ao de recursos podem ser facilmente visualizados nas tarefas.

A seguir as principais caracter´ısticas deste modelo ser˜ao apresentadas.

2.1 Restri¸c˜oes sob os roteiros

O Servi¸co de reclama¸c˜oes apresentado em (Aalst and Hee, 2002) ser´a utilizado para ilustrar os di-versos tipos de roteiros estudado neste trabalho. No processo do Servi¸co de reclama¸c˜oes, primeiro uma reclama¸c˜ao ´e registrada. Depois, s˜ao con-tactados o cliente que fez a reclama¸c˜ao e o

de-partamento afetado pela reclama¸c˜ao. O cliente ´e contactado com o objetivo de se obter mais in-forma¸c˜oes. O departamento ´e informado sobre a reclama¸c˜ao e ´e questionado sobre uma rea¸c˜ao ini-cial. Essas duas atividades devem ser executadas em paralelo (roteiro paralelo). Depois disso, as in-forma¸c˜oes s˜ao coletadas e, em sequˆencia, uma de-cis˜ao ´e tomada (roteiro sequˆencial). Dependendo da decis˜ao tomada, ou um pagamento ´e feito ou uma carta ´e enviada ao cliente (roteiro alterna-tivo). Por fim, a reclama¸c˜ao ´e arquivada.

A figura 1 ilustra os diversos tipos de roteiros do processo do Servi¸co de reclama¸c˜oes. Os lugares Ej com j=0 at´e 10 representam lugares de espera entre as atividades. As atividades s˜ao associadas aos lugares Ai com i=1 at´e 8. Em particular, os lugares E0 e E10 representam o in´ıcio e o fim do processo e a ficha em E0 representa um caso a ser tratado.

2.2 Restri¸c˜oes temporais expl´ıcitas

Geralmente, o tempo necess´ario para a execu¸c˜ao de uma atividade em um processo de workflow ´e n˜ao-determin´ıstico. Dessa forma, um intervalo de tempo pode ser atribu´ıdo a cada atividade. De acordo com (de Oliveira et al., 2008), restri¸c˜oes de tempo expl´ıcitas existentes em sistemas com caracter´ısticas de tempo real podem ser especifi-cadas formalmente usando um modelo de rede de Petri p-temporal.

2.2.1 Intervalo est´atico

A defini¸c˜ao est´atica de uma rede de Petri p-temporal ´e baseada em intervalos est´aticos que representam o intervalo de permanˆencia das fichas nos lugares do ponto de vista das dura¸c˜oes das atividades. Uma ficha pertencente a um lugar p participar´a da sensibiliza¸c˜ao de uma transi¸c˜ao de sa´ıda de p se ela tiver permanecido l´a pelo menos durante a dura¸c˜ao especificada pela borda m´ınima e no m´aximo durante a dura¸c˜ao especificada pela borda m´axima do intervalo. Enquanto a ficha n˜ao alcan¸ca o tempo m´ınimo no lugar de permanˆencia onde se encontra, ela fica indispon´ıvel para o disparo de outras transi¸c˜oes. Dentro do intervalo, a ficha fica dispon´ıvel, e ap´os o limite m´aximo de permanˆencia, a ficha se torna morta e n˜ao pode mais disparar nenhuma transi¸c˜ao.

A figura 1 ilustra os intervalos est´aticos vin-culados `as atividades do Servi¸co de reclama¸c˜oes. Para cada tarefa Ai, aparece um intervalo est´atico que especifica a sua dura¸c˜ao m´ınima e m´axima. Em particular, os intervalos est´aticos associados `as tarefas Coletar Informa¸c˜oes em A4 e Arquivar em A8 s˜ao iguais a [0, 0] porque as dura¸c˜oes destas s˜ao desprez´ıveis se comparada com as outras tarefas do Servi¸co de reclama¸c˜oes.

2.2.2 Intervalo de visibilidade

De acordo com (de Oliveira et al., 2008) o comportamento dinˆamico de uma rede de Petri p-temporal depende da marca¸c˜ao da rede e da situa¸c˜ao temporal das fichas que ´e dada pelo intervalo de visibilidade. Um itervalo de visibi-lidade [(δ_p)_mim, (δ_p)_max] associado a uma ficha em um lugar p de uma rede de Petri p-temporal especifica a data m´ınima ((δp)mim) em que a ficha se torna dispon´ıvel em p para o disparo de uma transi¸c˜ao de sa´ıda de p (data de in´ıcio ao mais cedo de uma atividade), bem como a data m´axima ((δp)max) ap´os a qual a ficha se torna indispon´ıvel (morta) e n˜ao pode ser utilizada para o disparo de nenhuma transi¸c˜ao (data de in´ıcio ao mais tarde de uma atividade).

2.3 Restri¸c˜oes de aloca¸c˜ao de recursos h´ıbridos Alguns dos recursos usados em sistemas de geren-ciamento de workflow podem ser considerados do tipo discreto, podendo ser representados por simples fichas. E o caso geralmente de recur-^´ sos que representam equipamentos f´ısicos, como uma impressora por exemplo. Outros recursos po-dem ser representados por recursos cont´ınuos. ´E o caso geralmente de recursos do tipo humano. Tais recursos s˜ao representados por um n´umero real que representa a disponibilidade de um fun-cion´ario humano, por exemplo, 100% represen-tando a disponibilidade m´axima quando o recurso se encontra no estado completamente dispon´ıvel. Da mesma forma, aos pesos dos arcos de sa´ıdas e entradas dos recursos s˜ao atribu´ıdos valores cor-respondentes `a previs˜ao da disponibilidade exigida para a realiza¸c˜ao da atividade relacionada.

3 Princ´ıpio geral de propaga¸c˜ao de restri¸c˜oes

3.1 Propaga¸c˜ao de restri¸c˜oes temporais nos roteiros

O mecanismo de propaga¸c˜ao de restri¸c˜oes tempo-rais nos roteiros proposto neste artigo foi inicial-mente apresentado em (de Oliveira et al., 2008). Utilizando t´ecnicas cl´assicas de propaga¸c˜ao de res-tri¸c˜oes baseadas em grafos sem circuitos e fixando a data de in´ıcio de um caso bem como a sua du-ra¸c˜ao m´axima para ser completado, calcula-se os

intervalos de visibiliade associados aos diversos lu-gares Ejde espera entre as diversas atividades dos roteiros existentes.

A figura 2 ilustra a aplica¸c˜ao do mecanismo de propaga¸c˜ao de restri¸c˜oes temporais ao longo dos roteiros do processo do Servi¸co de reclama¸c˜oes, considerando 4 casos a serem tratos.

Figura 2: Exempo do mecanismo de propaga¸c˜ao das restri¸c˜oes temporais nos roteiros

Na figura 2 (A), as bordas m´ınimas dos inter-valos de visibilidade associadas ao lugar E0, re-presentam as datas de in´ıcio de quatro casos a serem tratados pelo processo de workflow. As bor-das m´aximas dos intervalos de visibilidade associ-adas ao lugar E10 representam as datas de t´ermino previstas dos quatro casos, sabendo que a dura¸c˜ao m´axima para tratar cada caso ´e de 105 unidades