IMPLEMENTAÇÃO DE SISTEMAS DE CONTROLE SUPERVISÓRIO BASEADOS EM MÁQUINA DE ESTADOS

Transcrição

1 IMPLEMENTAÇÃO DE SISTEMAS DE CONTROLE SUPERVISÓRIO BASEADOS EM MÁQUINA DE ESTADOS MOACYR C. POSSAN JR. (1), ANDRÉ B. LEAL (2)* (1) Whirlpool Latin America, Rua Dona Francisca, 7200, Distrito Industrial, , Joinville, SC, Brasil (2) Grupo de Pesquisa em Automação de Sistemas e Robótica, Dpto. de Eng. Elétrica, Universidade do Estado de Santa Catarina UDESC, Campus Universitário Prof. Avelino Marcante s/n, , Joinville, SC, Brasil s: moacyr_c_possan@whirlpool.com, leal@joinville.udesc.br Abstract This paper presents a new methodology for the implementation of control systems based on the Supervisory Control Theory (SCT). It consists on a technique where an algorithm is proposed to obtain a Mealy finite state machine from an automaton of the supervisor obtained by the Supervisory Control Theory. This machine may be simplified further in order to have a reduced number of state transitions. This machine is a template for the implementation in Programmable Logic Controller (PLC) using Ladder language. A manufacturing system is presented to exemplify such methodology. Besides, another contribution of this work refers to the possibility of treating more than one event in the same scan cycle of the Programmable Logic Controller. Keywords Discrete Event Systems, Supervisory Control Theory, Manufacturing Systems, Modular Local Theory, State Machines, Programmable Logic Controllers, Ladder Language. Resumo Este trabalho apresenta uma nova metodologia para implementação de sistemas de controle baseados na Teoria de Controle Supervisório (TCS). Consiste em uma técnica onde um algoritmo é proposto para, a partir do autômato do supervisor obtido pela Teoria de Controle Supervisório, construir uma máquina de estados de Mealy. Esta máquina pode ser simplificada em seguida para reduzir o número de transições entre estados. Essa máquina serve como base para implementação em Controlador Lógico Programável (CLP) usando linguagem Ladder. Um sistema de manufatura é apresentado para exemplificar essa metodologia. Além disso, outra contribuição deste trabalho refere-se à possibilidade de tratamento de mais de um evento dentro do mesmo ciclo de execução do Controlador Lógico Programável. Palavras-chave Sistemas a Eventos Discretos, Teoria de Controle Supervisório, Sistemas de Manufatura, Máquinas de Estado, Controladores Lógicos Programáveis, Linguagem Ladder. 1. Introdução Nos últimos anos, a indústria tem se defrontado cada vez mais com a necessidade de uso de métodos eficazes para o controle de Sistemas a Eventos Discretos (SEDs), dentre os quais se inclui grande parte dos sistemas de manufatura. Um SED é um sistema de estados discretos dirigido a eventos, isto é, sua evolução de estado depende da ocorrência de eventos discretos assíncronos no tempo (Cassandras e Lafortune, 1999). A Teoria de Controle Supervisório (TCS) de Ramadge e Wonham (1989) é uma metodologia bastante conhecida e apropriada para a síntese de controladores para SEDs. Entretanto, apesar de sua reconhecida importância no meio acadêmico, a TCS não é difundida no âmbito industrial, de forma que, em geral, a resolução de problemas de controle supervisório nas indústrias é feita sem a utilização de um procedimento formal. Na indústria, os projetos são geralmente baseados no conhecimento do projetista, ficando atrelados à sua experiência em programação. Segundo Fabian e Hellgren (1998), um motivo importante para este afastamento entre teoria e prática consiste nas dificuldades encontradas na implementação da solução obtida por intermédio da TCS. Neste trabalho, apresenta-se um algoritmo para transformar o autômato do supervisor obtido por intermédio da TCS em uma máquina de estados finita. Além disso, no intuito de minimizar as dificuldades normalmente encontradas na etapa de implementação da estrutura de controle, é proposta uma metodologia de implementação de controle supervisório para CLPs que se baseia nesta máquina de estados finita. Uma vantagem desta metodologia se comparada com outras encontradas na literatura, como a proposta em (Queiroz e Cury, 2002), consiste na possibilidade de tratamento de diversos eventos em um mesmo ciclo de execução do CLP. Este trabalho está dividido da seguinte forma: na seção 2 apresenta-se uma visão geral da metodologia proposta e a seção 3 apresenta o algoritmo proposto para converter o autômato do supervisor em uma máquina de estados; a seção 4 mostra um exemplo motivador para ilustrar a metodologia proposta, a seção 5 descreve como simplificar esta máquina de estados, enquanto a seção 6 ilustra como implementar a máquina de estados em linguagem Ladder para CLP. Para finalizar, a seção 7 trata das conclusões. 2. Metodologia de Projeto Proposta A figura 1 ilustra uma visão geral da metodologia * Tutor do Programa de Educação Tutorial Grupo PET Engenharia Elétrica da UDESC

2 proposta. Primeiro é realizada a síntese de um supervisor monolítico baseado na TCS. O autômato deste supervisor serve como parâmetro de entrada para o algoritmo de conversão para obter a máquina de estados. A máquina é então simplificada para reduzir o número de transições. A máquina simplificada, por sua vez, representa um modelo para gerar o código para um controlador (CLP, microcontrolador ou alguma outra unidade de processamento). ENQUANTO Lista de Estados > 0 Cria Estado Inicial (Planta, Supervisor e Desabilitações = 0) Cria Lista de Estados Lê Estado Modelo das Plantas Especificações Cria Lista de Transições Síntese do Supervisor usando a TCS Obtenção da Máquina de Estados PARA Lista de Trasições FAÇA Ev. Não-Controláveis da Planta (Gu) Ev. Não-Controláveis do Supervisor (Su) Simplificação da Máquina de Estados Geração de Código para Controlador Desabilitações Ev. Controláveis da Planta (Gc) Ev. Controláveis do Supervisor (Sc) Figura 1. Metodologia Proposta 3. Algoritmo Para Gerar a Máquina de Estados Sim Sc Evoluiu? Não Cria um Novo Estado A máquina de estados obtida com o algoritmo proposto consiste em uma máquina de Mealy (Mealy, 1955). Nesta topologia, uma transição pode ter uma ou mais ações de saída e qualquer ação de saída pode ser usada em mais do que uma transição. As ações de saída estão associadas com as transições e não com os estados, que são passivos. Sendo assim, as ações podem ser associadas com mais do que um estado. Um exemplo simples de uma máquina de Mealy de dois estados é mostrado na figura 2. Partindo do estado 1, a transição 1 faz a máquina ir desse estado para o estado 2 e toma a ação 1; partindo do estado 2, a transição 1 mais a transição 2 faz a máquina ir do estado 2 para o estado 1 e a ação 2 é tomada. Estado 1 Transição 1 / Ação 1 Estado 2 Transição 1, Transição 2 / Ação 2 Figura 2. Exemplo de máquina de Mealy O algoritmo proposto para obter a máquina de estados finita funciona de forma iterativa, varrendo os dados de entrada para obter os estados, transições e ações que compõem esta máquina. A máquina estará completa quando todos os dados de entrada forem processados. O algoritmo é mostrado na figura 3. Estado já existe? No Adiciona Estado na Lista de Estados Fim Fim Yes Máquina de Estados Não Faz Nada Figura 3. Algoritmo para Obtenção da Máquina de Estados Os dados de entrada para o algoritmo são os autômatos da planta e do supervisor e as desabilitações, enquanto os dados de saída são os estados, as transições e as ações que compõem a máquina de estados. No processo de transformação do autômato do supervisor para a máquina de Mealy os eventos nãocontroláveis na TCS equivalem às transições entre os estados, enquanto os eventos controláveis equivalem às ações de saída na máquina de Mealy. A transição entre dois estados na máquina de Mealy pode ocorrer por meio de um ou mais eventos não-controláveis no autômato. Para cada transição, uma ação de saída pode ser gerada ou não. Nesse algoritmo, a inicialização considera os estados iniciais dos dados de entrada. Essa informação compõe o ponto de partida da máquina, representan-

3 do a condição onde a operação do processo físico ainda não começou. O próximo passo é criar uma lista de estados. A lista é necessária para armazenar os estados que vão sendo obtidos iterativamente para serem tratados assim que o tratamento do estado atual é finalizado. A lista consiste em uma estrutura FIFO (First In, First Out). Enquanto ainda existirem estados na lista, haverá um processo iterativo para o seu tratamento. Um loop While é utilizado para esta finalidade. Para cada estado, uma lista de transições é criada com o intuito de tratar todas as transições válidas para aquele estado específico. Para cada transição saindo de um determinado estado, será feito um processamento iterativo até que todas as transições sejam tratadas para todos os estados. Um loop For é utilizado para isto. A fim de criar a lista de transições válidas para cada estado da máquina, é necessário primeiro dividir a planta e o supervisor em duas partes, de acordo com a controlabilidade dos eventos referentes às suas transições de estado. Define-se por Gu a parte da planta cujas transições se dão devido a eventos nãocontroláveis e por Gc a parte da planta cujas transições se devem a eventos controláveis. De forma semelhante, Su é a parte do supervisor cujas transições se dão por eventos não controláveis e Sc a parte cujas transições são devido a eventos controláveis. A lista de transições equivale aos eventos nãocontroláveis que criam evoluções de estado em Gu e Su. A combinação de mais do que um evento nãocontrolável também é considerada uma transição. Após a parte devido a eventos não-controláveis ser tratada, a parte devido a eventos controláveis é processada. Após a ocorrência de uma transição, o estado resultante em Su é analisado para verificar quais eventos controláveis são desabilitados por esse estado. Enquanto os eventos desabilitados estão proibidos de ocorrer, os remanescentes podem dar origem às ações. As ações válidas para um dado estado são os eventos controláveis que não estão desabilitados no supervisor e que causam evolução de estados em Gc e em Sc. Quando uma ação ocorre, o algoritmo verifica se Sc evoluiu. Em caso afirmativo, então os eventos desabilitados para o estado destino são analisados a fim de verificar se alguma outra ação pode ocorrer. Este passo assegura que todas as ações possíveis de ocorrer para uma mesma transição são processadas. Isso significa que mais do que uma ação pode ocorrer para a mesma transição. Caso Sc não tenha evoluído, então um novo estado é criado. Este estado é comparado com os outros estados e, caso já exista, é descartado. Caso contrário, é adicionado à fila de estados para ser tratado posteriormente. Para cada transição devido a eventos nãocontroláveis, Gu e Su obtidos a partir da TCS evoluem. O mesmo ocorre para a parte controlável na o- corrência de uma ação. Esta metodologia é consistente com a definição de máquina de Mealy, onde as saídas (ações) dependem do estado atual e das entradas válidas (transições). Após o término do procedimento de criar uma transição e as ações correspondentes o algoritmo trata as demais transições presentes na fila de transições. Quando todas as transições na fila são tratadas, o algoritmo analisa o próximo estado disponível na fila de estados. Estes processos iterativos são efetuados até que a fila de estados se torne vazia. Isto significa que a máquina de estados finita está completa. 4. Um Exemplo Motivador Com o intuito de demonstrar a metodologia proposta considera-se um sistema de manufatura composto por 3 máquinas e 2 buffers intermediários de capacidade um entre as máquinas, conforme ilustrado na figura 4. As máquinas são representadas por Mi, onde i = 1,2,3 e os buffers são representados por Bj, onde j = 1,2. a1 b1 a2 b2 a3 b3 M1 B1 M2 B2 M3 Figura 4. Sistema de Manufatura A modelagem da planta e das especificações é feita por intermédio de autômatos de estados finitos, seguindo a TCS. Para modelagem da planta, são consideradas apenas as máquinas. Os buffers são levados em conta somente no modelo das especificações. Os eventos controláveis que correspondem ao início de operação das máquinas são representados por ax, onde x = 1,2,3, enquanto os eventos nãocontroláveis que correspondem ao fim de operação das máquinas são representados por bx. O comportamento discreto das máquinas é modelado pelo autômato da figura 5. ax 0 1 bx Figura 5. Modelo das Plantas As especificações de controle para o sistema são restrições de coordenação para evitar overflow (sobrecarga) ou underflow (retirada de peças de um buffer vazio) nos buffers. Estas restrições expressam a idéia de que se devem alternar os eventos bx e ax+1, iniciando-se pelos eventos bx. O autômato que modela estas especificações é mostrado na figura 6. 0 b x ax+1 Figura 6. Especificações de Controle 1

4 O cálculo do supervisor minimamente restritivo e não bloqueante baseia-se num processo iterativo que identifica e elimina maus estados no autômato que modela a linguagem-alvo (Cury, 2001). O supervisor monolítico para este problema possui 18 estados e 32 transições e pode ser obtido com o auxílio da ferramenta Grail (Reiser et al., 2006). Utilizando o algoritmo proposto neste trabalho, obtêm-se, a partir do autômato do supervisor, dados para criar a máquina de estados ilustrada na figura 7, que é composta por 8 estados e 22 transições. Os estados estão nomeados de acordo com as máquinas que estão ligadas em um determinado momento e os buffers que estão cheios. As transições são devido aos eventos não-controláveis e as ações, se houver, são separadas das transições por uma barra (/). Os eventos desabilitados são representados por traços. Observa-se que neste modelo as transições podem ocorrer devido a mais do que um evento nãocontrolável e as ações podem ser devido a mais do que um evento controlável. a2,a3 a2 b1/ /a1 a1,a2 M1 M1 M2 1 2 b3/a3 M1 6 M3 Buf 2 b1 b3 b2,b3/ a3 b2 a2 b1,b3/ a1,a2,a3 b3/ a1,a2,a3 b2/a3 b1/ a1,a2 b1,b2 M1 M3 M1 M2 M3 8 M3 Buf 1,2 b1,b3/ a1,a2 4 5 b1,b2,b3/ a1,a2,a3 b1,b2/ a1,a2,a3 a3 b3 b1 b2/ a1,a2,a3 a1,a2 3 M2 Buf 1 b2,b3/ a1,a2,a3 Figura 7. Máquina de Estados de Mealy b2 a1 b1,b3 5. Simplificação da Máquina de Estados b1 b3 a1,a3 M2 7 M3 Buf 1 A garantia de tratamento de mais do que um evento não-controlável dentro da mesma transição tem a desvantagem de resultar em um crescimento exponencial das transições, de acordo com o número de plantas presentes no modelo e quantas dessas podem ser habilitadas ao mesmo tempo. O número de transições criadas para um dado estado é da ordem de 2 n -1, onde n é o número de eventos não-controláveis válidos para aquele estado. Desta forma, para sistemas de grande porte, o tamanho de código para uma determinada implementação seria afetado significativamente para satisfazer essa condição. Uma solução alternativa para isso é considerar uma máquina de estados simplificada onde somente as transições devido a um único evento não-controlável são consideradas. Transições resultantes da combinação de mais do que um evento não-controlável são removidas do modelo. A figura 8 mostra a máquina simplificada para o sistema de manufatura. Esta máquina ainda possui 8 estados, porém o número de transições foi reduzido para 14, se comparado com o modelo da figura 7. a2,a3 a2 b1/ /a1 a1,a2 M1 M1 M2 1 2 b3/a3 M1 6 M3 Buf 2 b1 b3 b2 a2 b3/ a1,a2,a3 b2/a3 b1/ a1,a2 M1 M3 M1 M2 M M3 Buf 1,2 a3 b3 b1 b2/ a1,a2,a3 a1,a2 b2 3 M2 Buf 1 Figura 8. Máquina de Estados Simplificada a1 b1 b3 a1,a3 M2 7 M3 Buf 1 Esta solução garante economia de espaço em memória para uma implementação em CLP, por e- xemplo. Além disso, essa solução não restringe que mais do que um evento não-controlável seja tratado dentro do mesmo ciclo de execução. Se mais do que um evento não-controlável ocorrer, esses podem ser tratados ou não, dependendo da ordem em que os rungs são implementados em linguagem Ladder. Uma prática comum é nomear os estados da máquina em ordem crescente (1, 2, 3, e assim por diante) à medida que as transições são implementadas nos rungs. Caso um evento resulte em uma transição de um estado menor para um maior (estado 3 para o estado 12, por exemplo), esse evento será tratado; caso um evento resulte em uma transição de estado maior para um menor (estado 8 para o estado 5, por exemplo), o fluxo do programa permitirá que tal e- vento seja tratado somente no próximo ciclo de execução do CLP. 6. Geração de Código para CLPs A TCS considera que todos os eventos são gerados espontaneamente pela planta e que o supervisor observa a cadeia de eventos gerados pela planta e atua na desabilitação de eventos controláveis de modo a evitar qualquer violação nas especificações de controle. A Figura 9-a ilustra o esquema de supervisão proposto por Ramadge e Wonham (RW). Entretanto, na maioria das aplicações práticas os eventos modelados como controláveis correspondem a comandos que, na verdade, devem ser gerados pelo elemento de controle e devem ser enviados para os atuadores, pois eles não ocorrem espontaneamente. A figura 9-b mostra a estrutura de controle normalmente empregada na prática (Malik, 2002).

5 Eventos Não-controláveis Sinais elétricos dos sensores Supervisor Planta Unidade de Controle Processo a Controlar Eventos Controláveis Sinais elétricos para os atuadores Figura 9. (a) Esquema de Supervisão RW (b) Esquema de Controle normalmente empregado na prática. Com a transformação do autômato do supervisor em uma máquina de Mealy, obtém-se um modelo que mais se aproxima da forma do controlador apresentado por Malik (2002), isto é, da estrutura de controle mostrada na figura 9-b. Sendo assim, a geração da lógica de controle para o CLP fica mais intuitiva que aquela obtida a partir de autômatos. A seguir, discute-se sobre alguns aspectos relativos à implementação da máquina de estados em CLP, cujo ciclo de execução do programa obedece ao seguinte funcionamento: leitura das entradas, execução da lógica de controle e escrita nas saídas. Esta característica do CLP obriga que as saídas sejam atualizadas somente no fim do ciclo de execução. Devido a isso, a ativação dos atuadores requer um tratamento especial. Olhando para a estrutura da máquina de estados, pode acontecer que ao final de operação de um equipamento ele pode ser requisitado para um novo início de operação dentro do mesmo ciclo de execução. O CLP não reconhece o processo de fim/início de operação, mantendo sua saída física ativa o tempo inteiro ao longo do mesmo ciclo de execução. A fim de evitar isso, variáveis são necessárias para representar a evolução das plantas e garantir o sincronismo durante a dinâmica do sistema. Estas variáveis são chamadas Planta i, com i variando de 1 até n onde n é o número de plantas no sistema. Esta variável é setada toda vez que um equipamento termina sua operação. Este procedimento garante que o equipamento não seja requisitado para iniciar sua operação novamente dentro de um mesmo ciclo de execução. Ele será ligado somente no próximo ciclo de execução. Assim como no modelo, as variáveis bx representam os eventos não-controláveis (transições) enquanto as variáveis ax (ações) representam os eventos controláveis na implementação. O código Ladder pode ser dividido em cinco blocos: Inicialização, Entradas, Transições/Ações, Desabilitações e Saídas. Inicialização: inicia a máquina de estados para o estado inicial e seta o evento controlável a1 a fim de iniciar o processo, como mostrado na figura 10. Outras variáveis, tais como os demais eventos controláveis ax, os eventos não-controláveis bx e a evolução das plantas Planta i, são resetadas. As variáveis resetadas não são mostradas na figura 10. Entradas: as variáveis de transição bx serão ativadas no controlador somente quando um trigger ocorrer nas entradas correspondentes. Assim, um detector de pulso é necessário para cada entrada a fim de capturar tal evento, como mostra a figura 11. Transições/Ações: o requisito para uma transição ocorrer é a máquina estar em um dado estado e um evento não-controlável válido ocorrer. Caso estes requisitos sejam atendidos, um novo estado é setado e o estado anterior é resetado. O evento nãocontrolável é resetado para garantir que um evento não-controlável seja responsável por somente uma transição durante o ciclo de execução, evitando assim o risco do Efeito Avalanche (Fabian e Hellgren, 1998). Caso uma planta evolua, a variável correspondente Planta i é setada para evitar que a ação correspondente para aquela planta seja tomada durante o mesmo ciclo de execução, sendo tratada somente no próximo ciclo de execução. Isto é devido ao tratamento especial necessário para as ações, como descrito previamente nesta seção. As ações, se houver, são setadas para permitir que a planta correspondente seja ativada no mesmo ciclo de execução ou no próximo ciclo se for proibida de ocorrer no ciclo corrente. A figura 12 mostra a parte inicial desse bloco para o sistema de manufatura. Desabilitações: este bloco é responsável por desabilitar eventos controláveis em cada estado da máquina. Isso significa que se a máquina alcançar um dado estado, os eventos controláveis relativos a este estado não serão permitidos de ocorrer. Isso é feito por intermédio de resetar as variáveis de ações setadas durante as transições. A figura 13 mostra o bloco de desabilitações para o exemplo analisado. Saídas: uma saída será permitida de ocorrer somente se a ação correspondente for tomada e sua variável correspondente Planta i não estiver setada, como mostrado na figura 14. Caso isso aconteça, a bobina Qi que representa a saída física do CLP será ativada. Ainda, no final do programa todas as variáveis Planta i serão resetadas a fim de retornar para uma condição inicial antes de um novo ciclo de execução. Start P Estado 1 Figura 10. Bloco de Inicialização I1 I2 I3 P P P S a1 S b1 S b2 S b3 Figura 11. Bloco de Entradas S

6 Estado 1 b1 Estado 2 S 7. Conclusões Estado 2 Estado 2 b1 b2 Estado 1 R b1 R Planta 1 S a1 S a2 S Estado 3 S Estado 2 R b1 R Planta 1 S Estado 4 S Este artigo apresenta um algoritmo para transformar o autômato de um supervisor obtido a partir da Teoria de Controle Supervisório (TCS) em uma máquina de estados finita, sua simplificação e conseqüente implementação em linguagem Ladder para Controladores Lógico Programáveis (CLPs). O código para efetuar o procedimento de controle é dividido em cinco blocos. Diversos eventos podem ser tratado no mesmo ciclo de execução do CLP dependendo da evolução das transições e das ações requeridas, respectivamente. Este trabalho serve como ponto de partida para o desenvolvimento de ferramentas automáticas para geração de código e de uma metodologia similar à apresentada aqui, mas baseada na Teoria de Controle Modular Local (Queiroz e Cury, 2002), abordagem que explora a natureza modular do sistema a ser controlado, criando supervisores específicos para partes específicas da planta modelada. Estado 2 R b2 Agradecimentos R Planta 2 S a3 S Figura 12. Parte Inicial do Bloco de Transições/Ações Estado 3 a1 R Estado 7 Estado 8 Estado 1 a2 R Estado 4 Estado 6 Estado 8 Estado 1 a3 R Estado 2 Estado 3 Figura 13. Bloco de Desabilitações a1 Planta 1 Q1 a2 Planta 2 Q2 a3 Planta 3 Q3 Planta 1 R Planta 2 R Planta 3 R Figura 14. Bloco de Saídas Os autores agradecem a FAPESC e ao CNPq pelo apoio financeiro (Contrato CON04504/2008-7) e à Whirlpool Latin America pelo incentivo à realização deste trabalho. Referências Bibliográficas Cassandras, C.G; Lafortune, S. (1999). Introduction to Discrete Event Systems. 2 nd Ed. Massachussetts, Kluwer Academic Publishers. Cury, J.E.R. (2001). Teoria de Controle Supervisório de Sistemas a Eventos Discretos. In: V Simpósio Brasileiro de Automação Inteligente (SBAI). Fabian, M. e Hellgren, A. (1998). PLC-based implementation of supervisory control for discrete systems. In: 37th IEEE Conference on Decision and Control, v. 3, pp Malik, P. (2002). Generating controllers from discrete-event models. In: F. Cassez, C. Jard, F. Laroussinie, M. D. Ryan, Proc. of the MOVEP. Mealy, George H. (1955). A Method to Synthesizing Sequential Circuits. Bell Systems Technical Journal. pp Queiroz, M. H. e Cury J. E. R. (2002). Synthesis and implementation of local modular supervisory control for a manufacturing cell. Proc. of 6th WODES. Ramadge, P. J.; Wonham, W. M. (1989). The control of discrete event systems. In: Proceedings of IEEE, Special Issue on Discrete Event Dynamics Systems, 77(1): Reiser, C.; Da Cunha, A.E.C.; Cury, J.E.R. (2006). The Environment Grail for Supervisory Control of Discret Event Systems. In: 8th Intern. Workshop on Discrete Event Systems, Michigan, USA, pp. 1-6.

7 UMA ABORDAGEM EVOLUTIVA ADAPTATIVA PARA O PROBLEMA DE SEQUENCIAMENTO EM UMA MÁQUINA COM PENALIDADES POR ANTECIPAÇÃO E ATRASO DA PRODUÇÃO Fábio Fernandes Ribeiro, Marcone Jamilson Freitas Souza, Sérgio Ricardo de Souza Centro Federal de Educação Tecnológica de Minas Gerais CEFET/MG Campus II CEP: Belo Horizonte MG Brasil Universidade Federal de Ouro Preto - ICEB Campus Universitário UFOP CEP Ouro Preto MG Brasil s: fabiobh@gmail.com, marcone@iceb.ufop.br, sergio@dppg.cefetmg.br Abstract This paper deals with the Single Machine Scheduling Problem with Earliness and Tardiness Penalties, considering distinct due windows and sequence-dependent setup time. Due to the complexity of this problem, an adaptive evolutive method is proposed for solving it. This method is based on Classical Genetic Algorithm being the crossover operator chosen according to the success among five operators in a previous search. Computational results shows the effectiveness of the proposed algorithm. Keywords Genetic Algorithm, GRASP, Metaheuristics, Path Relinking, Single Machine Scheduling Resumo Este trabalho trata do problema de sequenciamento em uma máquina com penalidades por antecipação e atraso da produção, considerando janelas de entrega e tempo de preparação de máquina dependente da sequência de produção. Em vista da complexidade combinatória do problema, um método evolutivo adaptativo é proposto para resolvê-lo. Este método baseia-se nos princípios do Algoritmo Genético Clássico, sendo que o operador de cruzamento é escolhido dentre cinco operadores implementados, em função da qualidade das soluções produzidas em buscas pregressas. Testes computacionais mostram a efetividade do algoritmo proposto. Palavras-chave Algoritmos Genéticos, GRASP, Metaheurísticas, Reconexão por caminhos, Sequenciamento em uma máquina 1 Introdução O problema de programação da produção objeto de estudo deste trabalho é relativo ao sequenciamento em uma máquina com minimização das penalidades por antecipação e atraso da produção (Single Machine Scheduling for Minimizing Earliness and Tardiness Penalties), denominado PSUMAA. No problema abordado, considera-se a existência de janelas de entrega e tempos de preparação de máquina dependentes da sequência de produção. O objetivo é determinar a sequência na qual as tarefas serão processadas numa determinada máquina, durante um período de tempo, e o momento em que elas serão processadas, de modo a minimizar os custos por antecipação ou atraso na entrega. Para a resolução deste problema, um Algoritmo Genético Adaptativo é proposto. A população inicial deste algoritmo é gerada aplicando-se a fase de construção GRASP (Feo and Resende, 1995), tendo como função guia cinco regras de despacho (Montevechi et al., 2002): Tardiness Due Date (TDD), Earliest Due Date (EDD), Shortest Processing Time (SPT), Weight Shortest Processing Time (WSPT) e Longest Processing Time (LPT). O cruzamento utiliza um método adaptativo baseado na qualidade dos indivíduos gerados por cada operador crossover ao longo da evolução, ou seja, após um certo número de gerações (no caso, cinco), o fator de escolha do operador a ser aplicado é atualizado de acordo com a qualidade dos indivíduos formados por cada um deles nas gerações anteriores.a população sobrevivente é composta pelos cinco melhores indivíduos refinados desses operadores, pelo melhor indivíduo encontrado até então e por 89 indivíduos escolhidos por elitismo. Outros cinco indivíduos são escolhidos aleatoriamente da geração corrente e submetidos a mutação, por meio de troca entre duas tarefas, para assegurar a diversidade da população. A população evolui até que o critério de parada seja atingido. A Reconexão por Caminhos (Glover, 1996) é também aplicada a cada cinco gerações, e foi implementada caminhando-se do melhor indivíduo produzido pelo algoritmo até então em direção ao melhor indivíduo produzido por cada operador crossover. O restante deste trabalho está estruturado como segue. Na Seção 2 é feita uma breve apresentação de trabalhos relacionados. As características do problema estudado são detalhadas na Seção 3. Na Seção 4 é descrito o Algoritmo Genético Adaptativo desenvolvido para resolução do PSUMAA abordado. Na Seção 5 são apresentados e discutidos os resultados computacionais. A Seção 6 conclui o trabalho. 2 Trabalhos relacionados O PSUMAA pertence à classe de problemas NPdifíceis, uma vez que uma versão simplificada dele, o problema de sequenciamento que tem o atraso

8 total como critério de otimização, é NP-difícil (Du and Leung, 1990).(Lee and Choi, 1995) usaram Algoritmos Genéticos (AG) para a resolução do problema com datas de entrega distintas. Esses autores desenvolveram um algoritmo específico, de complexidade polinomial, para determinar a data ótima de conclusão de processamento de cada tarefa da sequência produzida pelo AG. (Wan and Yen, 2002) trataram o PSUMAA considerando janelas de entrega, ao invés de datas de entrega. Em (Gomes Jr. et al., 2007) trata-se o PSUMAA mais genérico, considerando além das janelas de entrega, também tempos de setup dependentes da sequência. Esses últimos autores desenvolveram uma formulação de programação matemática para o problema, bem como um algoritmo heurístico para resolver problemas-teste de dimensões mais elevadas. Segundo (Matias, 2008), o controle dos parâmetros e operadores dos Algoritmos Genéticos durante a sua execução é de fundamental importância, pois permite um ajuste automático em tempo de execução. Este autor propôs uma técnica de adaptação automática dos principais operadores dos Algoritmos Genéticos baseada no desempenho do algoritmo e na distribuição dos indivíduos da população no espaço de busca. A técnica estudada permite ao Algoritmo Genético ajustar o valor dos operadores, de forma a privilegiar aqueles que podem produzir resultados melhores em um determinado momento da busca. 3 Problema de sequenciamento abordado O problema objeto deste trabalho é o de sequenciamento em uma máquina (PSUMAA), com tempo de preparação dependente da sequência de produção e janelas de entrega. Considera-se que uma máquina deve processar um conjunto de n tarefas e que cada tarefa possui um tempo de processamento P i, uma data inicial E i e uma data final T i, desejadas para o término do processamento. Além disso, a máquina executa no máximo uma tarefa por vez e, uma vez iniciado o processamento de uma tarefa, a mesma deverá ser finalizada, não sendo permitida a interrupção do processamento. Admite-se que todas as tarefas estejam disponíveis para processamento na data 0. Considera-se, também, que quando uma tarefa j é sequenciada imediatamente após uma tarefa i, sendo estas pertencentes a diferentes famílias de produtos, é necessário um tempo S ij para a preparação da máquina. Tempos de preparação de máquina nulos (S ij = 0) levam a produtos da mesma família. Considera-se, ainda, que a máquina não necessita de tempo de preparação inicial. Permitese, neste trabalho, tempo ocioso entre a execução de duas tarefas consecutivas. Considera-se, além disso, que tarefas devem ser finalizadas dentro da janela de tempo [E i, T i ], denominada janela de entrega. Caso a tarefa seja finalizada antes de E i, há, então, uma penalização por antecipação. Caso a tarefa seja finalizada após T i, então ocorrerá uma penalização por atraso. As tarefas que forem finalizadas dentro da janela de entrega não proporcionarão nenhum custo. Por fim, admite-se que custos unitários por antecipação e atraso da produção sejam dependentes das tarefas, ou seja, cada tarefa i possui um custo unitário de antecipação α i e um custo unitário de atraso β i. O objetivo do problema é a minimização do somatório dos custos de antecipação e atraso da produção. 4 Metodologia heurística 4.1 Representação de um indivíduo Um indivíduo (sequência de tarefas) é representado por um vetor v de n genes (tarefas). A posição de cada gene indica sua ordem de produção. Por exemplo, no indivíduo v = {7, 1, 5, 6, 4, 3, 2}, a tarefa 7 é a primeira a ser processada e a tarefa 2, a última. 4.2 Avaliação dos indivíduos Todos os indivíduos da população são avaliados pela própria função objetivo do problema, dada pela equação (1), onde são considerados mais adaptados aqueles que obtiverem o menor valor. n min Z = (α i e i + β i t i ) ; (1) i=1 4.3 Construção de uma população inicial A população inicial do Algoritmo Genético Adaptativo (AGA) proposto é gerada aplicando-se a fase de construção GRASP (Feo and Resende, 1995), tendo como função guia cinco regras de despacho (EDD, TDD, SPT, WSPT e LPT). Para cada construção (GRASP + Regra de despacho) são gerados 200 indivíduos. Em seguida, estes são ordenados, do melhor para o pior segundo a função de avaliação. A população inicial é, então, composta pelos 100 melhores indivíduos gerados Regras de despacho Na regra de despacho EDD, as tarefas são ordenadas tendo em vista a data de início da janela de entrega. As tarefas com datas de início mais próximas são processadas antes daquelas com datas de início maiores. Pela regra de despacho TDD, as tarefas também são ordenadas com base na data de início da janela de entrega, porém, aquelas com datas de início mais tardias são processadas antes daquelas com datas de início mais cedo. A regra de despacho SPT constrói a sequência de tarefas ordenando-as de modo que a tarefa com tempo de processamento mais curto seja processada antes daquela com tempo de processamento mais longo. Na regra WSPT utiliza-se basicamente a mesma lógica do SPT, porém, levando-se em consideração um peso que é atribuído a cada tarefa, em função da sua prioridade de atendimento. As tarefas são, então, ordenadas a partir da ordem crescente ponderada da razão entre os tempos de processamento

9 e a sua prioridade de processamento. Finalmente, a regra de despacho LPT elabora a sequência de tarefas, criando uma ordem tal que a tarefa com tempo de processamento mais longo seja processada antes daquela com o tempo de processamento mais curto, ou seja, as tarefas com processamento mais longo são as primeiros a serem processadas. A escolha dessas regras é associada ao seu baixo custo computacional (Montevechi et al., 2002) Fase de construção GRASP O procedimento de construção segue as idéias da fase de construção do algoritmo GRASP (Feo and Resende, 1995). Neste procedimento, um indivíduo é formado gene a gene, de acordo com um critério g de seleção. Para estimar o benefício da inserção de cada gene (tarefa), utiliza-se uma das regras de despacho descritas na seção anterior, regra essa que é escolhida de forma aleatória, mas é fixa durante toda a construção. A cada inserção, os próximos genes candidatos a formarem o indivíduo são colocados em uma lista de candidatos, respeitando o critério de seleção. Os melhores candidatos são, então, colocados em uma Lista Restrita de Candidatos (LRC). A seguir, um desses candidatos é escolhido randomicamente e colocado no indivíduo em construção. O procedimento é encerrado quando todos os genes são alocados, situação na qual o indivíduo está completamente formado. Um parâmetro γ, 0 γ 1, é utili- Algoritmo AGA(maxger,numind,aaa ); 1 t 0; 2 Gere a população inicial P(t); 3 Avalie P(t); 4 enquanto (t maxger) faça 5 t t + 1; 6 Gere P(t) a partir de P(t 1); 7 enquanto (i numind) faça 8 i 1; 9 cross Número aleatório até 100; 10 se (cross probcrossover) faça 11 Selecionar indivíduo; 12 Cruzar; 13 fim-se; 14 Avaliar P(t); 15 fim-enquanto (i numind) faça 16 Definir a população sobrevivente; 17 se (t mod 5 = 0) faça 18 Atualizar probabilidade de escolha de cada operador (p (Oi)); 19 Executar Busca local; 20 Aplicar Reconexão por Caminhos; 21 fim-se; 22 fim-enquanto; fim AGA; Figura 1: Pseudocódigo do Algoritmo Genético Adaptativo zado para controlar o tamanho da LRC. Empiricamente, foram gerados preliminarmente indivíduos para cada um dos seguintes valores de γ: 0, 02; 0, 04; 0, 06; 0, 08; 0, 10; 0, 12; 0, 14; 0, 16; 0, 18; 0, 20. Tendo-se como base um problema-teste envolvendo 20 tarefas e as cinco regras de despacho, cada qual escolhida aleatoriamente em cada execução, o melhor comportamento foi observado para γ = 0, Algoritmo genético adaptativo aplicado ao PSUMAA A Figura 1 apresenta o pseudocódigo do Algoritmo Genético Adaptativo (AGA) proposto. As fases desse algoritmo são, a seguir, detalhadas. Método de seleção de indivíduos Após a avaliação de toda a população, os indivíduos são selecionados por meio do método da roleta, cujo principal objetivo é permitir que os indivíduos mais adaptados tenham maior probabilidade de serem selecionados. Para este problema, a aptidão dos indivíduos (fitness) é uma função linear decrescente com relação à função de avaliação. Cruzamento Após a avaliação de toda a população, os indivíduos são selecionados para reprodução através do método de seleção de indivíduos já descrito. Os operadores crossover utilizados são o One Point Crossover (OX), o Similar Job Order Crossover (SJOX), o Relative Job Order Crossover (RRX), o Based Order Uniform Crossover (BOUX) e o Partially Mapped Crossover (PMX) por apresentarem alta eficiência para o PSUMAA (Lee and Choi, 1995). A probabilidade de escolha de um operador crossover específico varia de acordo com a qualidade das soluções produzidas em gerações passadas. Assim, sejam O i, i = 1,, 5, os cinco operadores crossover. Inicialmente, cada operador crossover O i tem a mesma probabilidade de ser escolhido, no caso, p(o i ) = 1/5. Seja f(s ) a melhor solução encontrada até então e A i o valor médio das soluções encontradas por cada operador O i desde a última atualização. Caso o operador não tenha sido escolhido nas últimas cinco gerações, faz-se A i = 1. Seja q i = f(s ) = A i e p(o i ) = q i / 5 j=1 q j, i = 1,, 5. Observe que quanto melhor a solução, maior o valor de q i e, portanto, maior a probabilidade p(o i ) de se escolher o operador O i. Logo, durante a evolução do algoritmo, o melhor operador tem sua chance de escolha incrementada. Este procedimento foi inspirado no algoritmo Reactive GRASP (Prais and Ribeiro, 2000). Busca Local O método de busca local aplicado é a Descida Randômica, que utiliza dois tipos de movimento para explorar o espaço de busca: a troca da ordem de processamento de duas tarefas da sequência de produção e a realocação de uma tarefa para outra posição na sequência de produção. Para uma dada solução, seleciona-se

10 aleatoriamente duas tarefas, trocando-as de posição. Se esse novo vizinho for melhor que o anterior segundo a função de avaliação, ele é aceito e passa a ser a solução corrente; caso contrário, outro vizinho é escolhido aleatoriamente. Se durante MRDmax nenhuma melhor solução for gerada, então passa-se a usar movimentos de realocação. Havendo melhora com este tipo de movimento, retorna-se à utilização de movimentos de troca; caso contrário, encerra-se a busca local decorridas MRDmax iterações sem melhora. Esse método foi escolhido por apresentar alta eficiência computacional, pois não requer a exploração de toda a vizinhança (Mladenovic and Hansen, 1997). Reconexão por Caminhos A Reconexão por Caminhos (Path Relinking) é um procedimento que integra estratégias de intensificação e diversificação durante o processo de busca (Rossetti, 2003). Ele gera novas soluções explorando trajetórias que ligam soluções de alta qualidade. Dado um par de soluções, começa-se a busca com uma delas, dita solução base, e chega-se à outra, dita solução guia, adicionando-se gradualmente atributos da solução guia à solução base. No problema em questão, durante o processo evolutivo forma-se um grupo com os cinco melhores indivíduos obtidos por cada operador crossover. Periodicamente (a cada cinco gerações), aciona-se a Reconexão por Caminhos, tendo-se, como solução base, o melhor indivíduo encontrado pelo algoritmo até então e, como solução guia, cada um dos melhores indivíduos formados por cada operador crossover. O procedimento aplicado é a Reconexão por Caminhos Regressiva Truncada (Truncated Backward Path Relinking), no qual interrompe-se a busca quando 75% dos atributos da solução guia forem inseridos na solução base. A escolha deste método é justificada pela sua eficiência e pelo baixo custo computacional (Rossetti, 2003). Considerase como atributo a posição da tarefa na sequência de produção. Para cada tarefa candidata à inserção, aplica-se o módulo de Busca Local descrito anteriormente, não permitindo a movimentação da tarefa candidata. A tarefa efetivamente inserida é aquela que produzir o melhor valor para a função de avaliação. Sobrevivência de indivíduos A população sobrevivente é composta por indivíduos mais adaptados, selecionados por elitismo, pela melhor solução gerada por cada um dos operadores crossover e pela melhor solução produzida pela método até então. Critério de parada Como critério de parada, adota-se o número máximo de gerações. 5 Resultados computacionais O Algoritmo Genético Adaptativo proposto foi implementado em linguagem C, utilizando o ambiente C++ Builder 5. Seus parâmetros são apresentados na Tabela 1. Os testes computacionais foram realizados em um computador Pentium Core 2 Duo 2,1 GHz, com 4 GB de memória RAM, sob plataforma Windows Vista. Os problemasteste utilizados são os de (Gomes Jr. et al., 2007) e envolvem número de tarefas n igual a 8, 9, 10, 11, 12, 15, 20, 25, 30, 40, 50 e 75. São 12 problemasteste para cada número de tarefas, totalizando 144 problemas-teste. Cada problema-teste foi resolvido 30 vezes pelo método proposto, com exceção daqueles envolvendo 75 tarefas, os quais foram resolvidos apenas 20 vezes, tendo MRDmax = 2 n, por demandar maior tempo computacional. A Tabela 2 mostra os resultados obtidos Tabela 1: Parâmetros do AGA Parâmetros Valores Parâmetro γ construção GRASP 0,20 Iterações da Busca Local (MRDmax) 7 n Gerações do AG Adaptativo (maxger) 100 Probabilidade de cruzamento 80% Taxa de mutação 5% para o AGA, bem como reproduz os de (Gomes Jr. et al., 2007), por apresentar os melhores resultados para este tipo de problema até a presente data. A primeira coluna mostra o número de tarefas envolvidas; a segunda e terceira colunas mostram o quanto as soluções médias de cada algoritmo (AGA e (Gomes Jr. et al., 2007), respectivamente) desviaram da melhor solução conhecida referente a cada problema-teste; nas duas últimas colunas mostra-se o quanto as melhores soluções geradas por tais algoritmos desviaram das melhores soluções conhecidas. O Desvio é calculado pela expressão Desvio = (RMed MR)/MR, sendo RMed o resultado médio obtido pela aplicação do respectivo algoritmo e MR é o melhor resultado conhecido de cada problema-teste. Nas tabelas 3, 4, 5 e 6 são apresentados os resultados detalhados para os problemas-teste com número de tarefas iguais a 12, 15, 20, 25, 30, 40, 50 e 75 tarefas. A coluna Instância apresenta o número do problema-teste testado; a coluna GAP (%) apresenta o desvio médio em relação às soluções médias; a coluna GAP MS (%) apresenta o desvio médio em relação à melhor solução conhecida para o problema. Tabela 2: Resultados do AGA # Desvio sol. média Desvio solução Tarefas AGA Gomes Jr. AGA Gomes Jr. 8 0,00 0,03 0,00 0,00 9 0,15 0,06 0,00 0, ,24 0,02 0,00 0, ,03 0,12 0,00 0, ,07 0,21 0,00 0, ,76 1,47 0,00 0, ,73 1,65 0,00 0, ,02 2,32 0,00 0, ,60 3,34 0,00-0, ,15 4,38 0,25-0, ,72 6,13 0,60-0, ,59 10,89 1,48-0,56 Para problemas-teste envolvendo acima de doze tarefas, os desvios das soluções médias do al-

11 goritmo proposto foram sempre menores que aqueles de (Gomes Jr. et al., 2007). Este fato mostra a robustez do AGA, uma vez que produz soluções finais com uma menor variabilidade. Para problemas envolvendo 30 tarefas, o AGA gerou a melhor solução conhecida em todas as execuções, ao passo que no algoritmo de (Gomes Jr. et al., 2007) houve um desvio de 0,20%. Para os problemas-teste envolvendo 40, 50 e 75 tarefas, o AGA produziu soluções melhores que as de (Gomes Jr. et al., 2007). Para as instâncias de 12 e 15 tarefas, apresentados na Tabela 3, o AGA apresentou um desvio médio em relação à melhor solução encontrada 48% menor do que o algoritmo de (Gomes Jr. et al., 2007). Tabela 3: Resultados para 12 e 15 tarefas # GAP (%) GAP MS (%) Instância AGA Gomes Jr. AGA Gomes Jr ,00 0,56 0,00 0, ,07 0,10 0,00 0, ,11 0,21 0,00 0, ,07 0,04 0,00 0, ,00 0,00 0,00 0, ,00 0,00 0,00 0, ,39 0,35 0,00 0, ,00 0,00 0,00 0, ,14 1,25 0,00 0, ,10 0,06 0,00 0, ,00 0,00 0,00 0, ,00 0,00 0,00 0, ,00 0,00 0,00 0, ,10 2,93 0,00 0, ,00 3,89 0,00 0, ,00 0,57 0,00 0, ,00 1,68 0,00 0, ,00 0,28 0,00 0, ,23 0,93 0,00 0, ,53 5,23 0,00 0, ,00 0,00 0,00 0, ,24 1,29 0,00 0, ,00 0,81 0,00 0, ,00 0,00 0,00 0,00 Para as instâncias envolvendo 20 e 25 tarefas (Tabela 4), o desvio médio em relação à melhor solução encontrado pelo AGA foi 44% menor que o alcançado por (Gomes Jr. et al., 2007). Em instâncias envolvendo 30 e 40 tarefas (5), o AGA apresentou um ganho médio na melhor solução de 0,13% enquanto (Gomes Jr. et al., 2007) apresentou piora de 0,19%. Já em relação ao desvio médio da melhor solução encontrada, o resultado apresentado pelo AGA foi 48% melhor do que os de (Gomes Jr. et al., 2007). Para as maiores instâncias, de 50 e 75 tarefas apresentados na Tabela 6, os resultados atingidos pelo AGA foram ainda melhores na comparação com os de (Gomes Jr. et al., 2007). O percentual médio de melhora foi de 0,54%, ao passo que (Gomes Jr. et al., 2007) apresentou piora de 0,42%. O desvio médio em relação ao melhor resultado foi de 31%. 6 Conclusões Este artigo teve seu foco no PSUMAA considerando janelas de entrega e tempo de prepa- Tabela 4: Resultados para 20 e 25 tarefas # GAP (%) GAP MS (%) Instância AGA Gomes Jr. AGA Gomes Jr ,00 0,00 0,00 0, ,37 3,05 0,00 0, ,32 1,04 0,00 0, ,23 1,14 0,00 0, ,38 0,98 0,00 0, ,74 4,52 0,00 0, ,34 3,87 0,00 0, ,21 0,62 0,00 0, ,33 2,09 0,00 0, ,27 1,09 0,00 0, ,40 0,68 0,00 0, ,20 0,72 0,00 0, ,14 0,36 0,00 0, ,22 0,54 0,00 0, ,00 0,12 0,00 0, ,35 0,55 0,00 0, ,69 2,60 0,00 0, ,02 0,21 0,00 0, ,17 1,46 0,00 0, ,17 1,15 0,00 0, ,00 0,27 0,00 0, ,78 11,20 0,00 0, ,19 6,25 0,00 0, ,53 3,09 0,00 0,00 ração da máquina dependente da sequência de produção. Para resolvê-lo foi proposto um Algoritmo Genético Adaptativo, onde a população inicial foi gerada por um procedimento GRASP, utilizando como função guia as regras de despacho EDD, TDD, SPT, WSPT e LPT. Durante o processo evolutivo, a população passa pelas fases de seleção, cruzamento e mutação. No cruzamento, cinco operadores crossover, OX (One Point Crossover), SJOX (Similar Job Order Crossover), BOUX (Based Order Uniform Crossove), PMX (Partially Mapped Crossover) e RRX (Relative Job Order Crossover), são utilizados, sendo que a escolha de qual operador será empregado depende da qualidade das soluções produzidas em gerações passadas. Periodicamente, as melhores soluções produzidas por cada operador crossover são submetidas à busca local e à Reconexão por Caminhos. O procedimento de Reconexão liga a melhor solução produzidas até então à cada uma das melhores soluções de cada operador. Para testá-lo, foram utilizados problemas-teste da literatura e, em seguida, os resultados foram comparados com os de (Gomes Jr. et al., 2007). Nos problemas envolvendo até 30 tarefas, o algoritmo proposto apresentou soluções de alta qualidade e com baixo desvio, sempre atingindo o ótimo. Já em problemas de dimensões maiores (40 a 75 tarefas), o algoritmo desenvolvido apresentou soluções melhores que as desse algoritmo da literatura, além de apresentar menor variabilidade das soluções finais.

12 Tabela 5: Resultados para 30 e 40 tarefas # GAP (%) GAP MS (%) Instância AGA Gomes Jr. AGA Gomes Jr ,80 2,53 0,00 0, ,08 0,31 0,00 0, ,47 1,93 0,00 0, ,78 4,92 0,00 0, ,03 2,62 0,00 0, ,64 3,36 0,00 0, ,29 1,40 0,00 0, ,89 6,20 0,00 0, ,00 1,43 0,00 0, ,84 4,56 0,00 0, ,18 8,42 0,00-2, ,18 2,42 0,00-0, ,35 1,16 0,00 0, ,28 0,81 0,00 0, ,00 0,67 0,00 0, ,62 2,30 0,04 0, ,27 2,45 0,00 0, ,19 3,41 0,00 0, ,51 7,17 1,48 0, ,16 4,03 0,00 0, ,97 6,77 0,00 0, ,95 4,46 0,39 0, ,51 12,57 1,11-2, ,93 6,79 0,00 0,00 Tabela 6: Resultados para 50 e 75 tarefas # GAP (%) GAP MS (%) Instância AGA Gomes Jr. AGA Gomes Jr ,72 5,34 0,13-0, ,46 6,00 0,56-1, ,60 1,59 0,00 0, ,00 4,73 0,00 0, ,62 2,33 0,57 0, ,43 1,93 0,00 0, ,27 8,95 0,00 0, ,10 4,04 0,78 0, ,93 9,46 1,77-0, ,49 5,44 3,33-0, ,74 11,70 0,00 0, ,63 12,10 0,00 0, ,48 7,40 0,00 0, ,34 7,01 0,00 0, ,84 7,98 0,52-3, ,04 4,05 0,00-0, ,90 12,52 0,00 0, ,16 7,09 0,00 0, ,34 11,19 0,00 0, ,67 16,62 0,00 0, ,36 10,65 5,25-2, ,99 9,13 0,00 0, ,45 24,03 0,00 0, ,45 13,05 0,00 0,00 Agradecimentos Os autores agradecem ao CEFET-MG, CAPES e FAPERJ. Referências Du, J. and Leung, J. Y. T. (1990). Minimizing total tardiness on one machine is nphard, Mathematics of Operations Research 15: Feo, T. A. and Resende, M. G. C. (1995). Greedy randomized adaptive search procedures, Journal of Global Optimization 6: Glover, F. (1996). Tabu search and adaptive memory programming - advances, applications and challenges, in R. S. Barr, R. V. Helgason and J. L. Kennington (eds), Computing Tools for Modeling, Optimization and Simulation: Interfaces in Computer Science and Operations Research, Kluwer Academic Publishers, pp Gomes Jr., A. C., Carvalho, C. R. V., Munhoz, P. L. A. and Souza, M. J. F. (2007). Um método heurístico híbrido para resolver o problema de sequenciamento em uma máquina com penalidades por antecipação e atraso, Anais do XXXIX Simpósio Brasileiro de Pesquisa Operacional, Fortaleza, Brazil, pp Lee, C. Y. and Choi, J. Y. (1995). A genetic algorithm for job sequencing problems with dis- tinct due dates and general early-tardy penalty weights, Computers and Operations Research 22: Matias, P. T. (2008). Avaliação comparativa de algoritmos evolutivos com operadores adaptativos, Dissertação de mestrado, Programa de Engenharia Civil, UFRJ, Rio de Janeiro. Mladenovic, N. and Hansen, P. (1997). Variable neighborhood search, Computers and Operations Research 24: Montevechi, J. A., Turrioni, J. B., Almeida, A. D., Mergulhão, R. C. and Leal, F. (2002). Análise comparativa entre regras heurísticas de sequenciamento da produção aplicada em Job Shop, Produto e Produção 6(2): Prais, M. and Ribeiro, C. C. (2000). An application to a matrix decomposition problem in tdma traffic assignment, INFORMS - Journal on Computing 12: Rossetti, I. C. M. (2003). Estratégias sequenciais e paralelas de GRASP com reconexão por caminhos para o problema de síntese de redes a 2 caminhos, Tese de doutorado, Programa de Pós-Graduação em Informática, PUC-RJ, Rio de Janeiro, Brasil. Wan, G. and Yen, B. P. C. (2002). Tabu search for single machine scheduling with distinct due windows and weighted earliness/tardiness penalties, European Journal of Operational Research 142:

13 PRINCÍPIO DA OTIMALIDADE PRÓXIMA APLICADO AO PROBLEMA DE SEQUENCIAMENTO DE TAREFAS EM UMA MÁQUINA COM PENALIDADES POR ANTECIPAÇÃO E ATRASO DA PRODUÇÃO Bruno Ferreira Rosa, Marcone Jamilson Freitas Souza, Sérgio Ricardo de Souza Avenida Amazonas, 7675, CEP Centro Federal de Educação Tecnológica de Minas Gerais Belo Horizonte, Minas Gerais, Brasil ICEB, Campus Universitário, CEP Universidade Federal de Ouro Preto Ouro Preto, Minas Gerais, Brasil s: brunofazmat@dppg.cefetmg.br, marcone@iceb.ufop.br, sergio@dppg.cefetmg.br Abstract This work deals with the single machine scheduling problem where a sequence-dependent setup time is required for the changeover job. In the considered problem, each job has a time window in which the job must preferably be completed. The objective is to minimize the weighted sum of the tardiness and earliness. A mathematical model is proposed for the problem and also a heuristic algorithm based on GRASP, Proximate Optimality Principle and Variable Neighborhood Descent to solve it. Computational experiments performed in a set of instances of the literature suggest that the proposed algorithm is able to find good solutions and with low average divergence. Keywords Scheduling single machine, GRASP, Proximate Optimality Principle. Resumo Este trabalho trata do problema de sequenciamento em uma máquina, no qual há um tempo de preparação dependente da sequência de produção. No problema abordado, cada tarefa possui uma janela de tempo, dentro da qual ela deve ser preferencialmente concluída. O objetivo é minimizar a soma ponderada dos atrasos e antecipações. É proposto um modelo matemático para o problema e também um algoritmo heurístico baseado em GRASP, Princípio da Otimalidade Próxima e Busca em Vizinhança Variável para resolvê-lo. Experimentos computacionais realizados em um conjunto de problemas-teste da literatura sugerem que o algoritmo proposto é capaz de encontrar boas soluções e com baixo desvio médio. Keywords Sequenciamento uma máquina, GRASP, Princípio da Otimalidade Próxima. 1 Introdução O problema de sequenciamento de tarefas em uma máquina com penalidades por antecipação e atraso da produção (PSUMAA) consiste em sequenciar e determinar o momento em que as tarefas devem ser executas em uma máquina, com o objetivo de minimizar a soma ponderada das antecipações e dos atrasos na produção de tais tarefas. Há antecipação de uma tarefa quando ela é concluída antes da data desejada para sua entrega e há atraso quando ela é concluída após esta data. Em ambas as situações são geradas penalidades. Segundo Liaw (1999), concluir uma tarefa com atraso pode resultar em multas contratuais, perda de credibilidade da empresa e redução de vendas. Do mesmo modo, concluir uma tarefa antecipadamente pode resultar em custos financeiros extras, pela necessidade de disponibilizar antecipadamente capital, necessidade de espaço para armazenamento ou necessidade de outros recursos para manter e gerenciar o estoque (França Filho, 2007). Com relação às datas de entrega das tarefas, um caso pouco explorado na literatura é aquele no qual se considera janelas de entrega distintas (distinct due windows). Isto é, há um determinado período de tempo associado a cada tarefa, dentro do qual a tarefa deve ser preferencialmente concluída. Segundo (Wan and Yen, 2002), este caso ocorre quando existe tolerância em torno da data desejada para a entrega de cada tarefa. Em um grande número de aplicações do PSUMAA, após a conclusão de uma tarefa é necessário preparar a máquina para a execução da tarefa seguinte (Allahverdi et al., 1999). Isto ocorre em indústrias que produzem diferentes tipos de produtos e em que existe uma troca frequente do tipo de tarefa executada na máquina. Este tempo de preparação (ou tempo de setup) inclui os tempos gastos para trocar as ferramentas, preparar o material, limpar a máquina, etc. A maioria dos trabalhos em problemas de sequenciamento assume que tais tempos são independentes da sequência de produção, isto é, que eles são desprezíveis ou podem ser acrescentados aos tempos de processamento das tarefas. No entanto, em grande parte das situações práticas, esses tempos são dependentes da sequência de produção (Gupta and Smith, 2006). Alguns trabalhos da literatura permitem a inserção de tempos ociosos na sequência de produção. De acordo com Li (1997), existem casos em que o custo por manter a máquina inativa é mais alto que o preço pago pela antecipação de uma tarefa e, neste caso, vale a pena antecipar

14 a produção. Outra situação em que isto ocorre é quando a capacidade da máquina é inferior à demanda. No entanto, há casos em que vale a pena manter a máquina parada, mesmo que exista uma tarefa disponível para ser processada (França Filho, 2007). O PSUMAA possui muitas aplicações práticas em indústrias metalúrgicas, têxteis, de tintas, dentre outras. Associado a este grande leque de aplicações está a dificuldade de resolvê-lo de forma ótima, dado que se trata de um problema NPdifícil (Allahverdi et al., 1999). Esta união entre aplicabilidade e dificuldade de resolução motiva o desenvolvimento de algoritmos eficientes para resolvê-lo. No presente trabalho é estudado o PSUMAA em sua forma mais genérica, isto é, com janelas de entrega distintas, penalidades por atraso e antecipação das tarefas diferentes, tempo de setup dependente da sequência de produção, sendo permitidos tempos ociosos entre as execuções de tarefas consecutivas. Esse problema, com todas as características apontadas, tem sido pouco explorado na literatura. Destacam-se os trabalhos de Gomes Júnior et al. (2007) e Souza et al. (2008). No primeiro trabalho, é proposto um modelo de Programação Inteira Mista (PLIM) para representar o problema, bem como um algoritmo heurístico baseado em GRASP, Iterated Local Search e Variable Neighborhood Descent - VND. Para cada sequência de tarefas gerada por esse algoritmo, é acionado um procedimento de complexidade polinomial para determinar a data ótima de início de processamento das tarefas na sequência dada, sendo este procedimento uma extensão daquele proposto por Wan and Yen (2002). No segundo trabalho é proposto um algoritmo heurístico baseado em GRASP, VND, Busca Tabu e Reconexão por Caminhos. Outros trabalhos cujas características se aproximam são os de Wan and Yen (2002), mas que não consideram a e- xistência de tempos de preparação da máquina dependente da sequência, e o de Bustamante (2007). Este último não considera a existência de janelas de entrega. A formulação de programação matemática proposta também exige que os tempos de preparação satisfaçam à desigualdade triangular. O presente trabalho inclui a apresentação de um novo modelo de PLIM para representar o problema e também de um algoritmo heurístico baseado em GRASP (Feo and Resende, 1995), Princípio da Otimalidade Próxima - POP (Glover and Laguna, 1997) e VND (Mladenović and Hansen, 1997) para resolvê-lo. O restante deste trabalho está organizado do seguinte modo. Na Seção 2, é feita uma descrição detalhada do problema estudado, enquanto, na Seção 3, é apresentada uma formulação de programação matemática para representar tal problema. Na Seção 4 é descrito o algoritmo heurístico desenvolvido para resolvê-lo. Na Seção 5 são apresentados e discutidos os resultados computacionais. A Seção 6 conclui o trabalho. 2 Descrição do problema O PSUMAA abordado neste trabalho possui as seguintes características: (i) Uma máquina deve processar um conjunto I de n tarefas; (ii) A cada tarefa i I está associado um tempo de processamento P i, uma janela de entrega [E i, T i ], dentro da qual a tarefa i deve ser preferencialmente concluída, um custo α i por unidade de tempo de antecipação e um custo β i por unidade de tempo de atraso. Há antecipação de uma tarefa i I quando seu processamento é concluído antes de E i e há atraso quando seu processamento é concluído depois de T i ; (iii) As tarefas que forem concluídas dentro de suas respectivas janelas de entrega não geram custo; (iv) A máquina executa no máximo uma tarefa por vez e, uma vez iniciado o processamento de uma tarefa, não é permitida a sua interrupção; (v) Todas as tarefas estão disponíveis para processamento na data 0; (vi) Entre duas tarefas i e j consecutivas é necessário um tempo S ij de preparação da máquina, chamado tempo de setup; (vii) Assume-se que o tempo de preparação da máquina para o processamento da primeira tarefa na sequência é igual a 0; (viii) É permitido tempo ocioso entre a execução de duas tarefas consecutivas. O objetivo é determinar a sequência de produção e as datas de início de produção das tarefas, de forma a minimizar a soma ponderada das antecipações e dos atrasos. 3 Modelo matemático O modelo de Programação Linear Inteira Mista (PLIM) apresentado a seguir é baseado naquele proposto por Gomes Júnior et al. (2007). Para sua apresentação, sejam s i, e i e t i a data de início do processamento, o tempo de antecipação e o tempo de atraso da tarefa i I, respectivamente. A contrário de Gomes Júnior et al. (2007), é utilizada apenas uma tarefa fictícia, 0 (zero), para auxiliar na modelagem. A tarefa 0 é sequenciada duas vezes, sendo uma necessariamente na primeira e outra na última posição. Considera-se que P 0 = 0 e que S 0i = S i0 = 0, i I. Deste modo, se comparado ao modelo daqueles autores, há redução de 2n+3 variáveis e n+1 restrições, com n representando o número de tarefas a serem sequenciadas. Sejam y ij variáveis que determinam a sequência de produção, sendo y ij = 1 se a tarefa j for sequenciada imediatamente após a tarefa i e y ij = 0, caso contrário, i, j I {0} e i j. Considere, ainda, uma constante M de valor suficientemente

15 n min Z = (α i e i + β i t i ) (1) i=1 s.a. s i + P i + y ij (M + S ij ) M s j i I {0}, j I e i j (2) n y ij = 1 i I {0} (3) j=0, j i n i=0, i j y ij = 1 j I {0} (4) s i + P i + e i E i i I (5) s i + P i t i T i i I (6) s i 0 i I {0} (7) e i 0 i I (8) t i 0 i I (9) y ij {0, 1} i, j I {0} e i j (10) A função objetivo, representada pela equação (1), busca a minimização da soma ponderada das antecipações e atrasos. As restrições (2) garantem que existe tempo suficiente para executar uma tarefa i antes do início da tarefa seguinte j, ou seja, elas garantem que o processamento da tarefa j não será iniciado antes do término do processamento da tarefa i. As restrições (3) e (4) garantem que cada tarefa terá apenas uma tarefa imediatamente sucessora e uma tarefa imediatamente antecessora, respectivamente. As restrições (5) e (6) definem as antecipações e os atrasos, de acordo com as respectivas janelas de entrega de cada tarefa. As restrições (7), (8), (9) e (10) dizem respeito ao tipo de variáveis. 4 Algoritmo proposto O algoritmo heurístico proposto, denotado por GPV, combina os procedimentos GRASP (Feo and Resende, 1995), Princípio da Otimalidade Próxima - POP (Glover and Laguna, 1997) e VND (Mladenović and Hansen, 1997). A Figura 1 apresenta seu pseudocódigo. Algoritmo GPV() 1 f ; 2 Iter 0; 3 enquanto (Iter < GRASPMax) faça 4 Iter Iter + 1; 5 v 0 ConstruaSolucao(); 6 v VND 1 (v 0 ); 7 se (f(v) < f ) então 8 v v; 9 f f(v); 10 Iter 0; 11 fim-se; 12 fim-enquanto; 13 v VND 2(v ); 14 Retorne v ; fim GPV Figura 1: Algoritmo GPV Há duas fases neste algoritmo. A primeira (linhas 1 a 12 da Fig. 1) gera uma solução com base na metaheurística GRASP. A segunda (linha 13) consiste em um pós-refinamento da solução proveniente da fase anterior. Seu detalhamento é apresentado nas subseções seguintes. 4.1 Representação de uma solução Uma solução (sequência) para o PSUMAA de n tarefas é representada por um vetor v de n posições, em que cada posição i = 1, 2,, n indica a ordem de produção da tarefa v i. Por exemplo, dada a sequência v = {5, 3, 2, 1, 4, 6}, a tarefa 5 é a primeira a ser realizada e a tarefa 6 a última. 4.2 Vizinhança de uma solução Para explorar o espaço de soluções são usados três tipos de movimentos: troca da ordem de processamento de duas tarefas da sequência de produção, realocação de uma tarefa para outra posição da sequência e realocação de um bloco com duas ou mais tarefas. Esses movimentos definem, respectivamente, as vizinhanças N T, N R e N RB. 4.3 Função de avaliação Como os movimentos utilizados não geram soluções inviáveis, uma sequência é avaliada pela própria função objetivo, dada pela expressão (1) do modelo de PLIM. Para determinar os valores de e i e t i, é utilizado o algoritmo de determinação das datas ótimas de início de processamento (AD- DOIP) proposto por Gomes Júnior et al. (2007). 4.4 Construção de uma solução Nesta etapa da primeira fase do algoritmo (linha 5 da Fig. 1), uma solução é formada, tarefa por tarefa, de forma parcialmente gulosa, seguindo as idéias da fase de construção do algoritmo GRASP. A cada iteração desta fase, as tarefas que ainda estão fora da solução são avaliadas por uma função g, que estima o benefício associado à sua inclusão na solução parcial. As tarefas j, que possuem g(j) menor ou igual a g min + γ(g max g min ), γ [0, 1], são inseridas em uma Lista Restrita de

16 Candidatos (LRC). Desta lista é escolhida aleatoriamente uma, a qual é adicionada à solução parcial. Para estimar o benefício da inserção de cada tarefa j ainda não sequenciada, em cada iteração i, utiliza-se uma das 4 seguintes funções como critério de seleção: (1) g 1 (j) = 2E j / max{e k k F i } + 2T j / max{t k k F i } + α j / max{α k k F i } β j / max{β k k F i } + P j / max{p k k F i } + S i 1,j / max{s i 1,k k F i }, em que F i representa o conjunto das tarefas ainda não sequenciadas até a i-ésima iteração (para i = 1, no lugar de S i 1,j / max{s i 1,k k F i } é utilizado média{s kj k I e k j}/ max{s kl k, l I e k l}); (2) g 2 (j) = T j ; (3) g 3 (j) = (α j E j + β j T j )/(α j + β j ); (4) g 4 (j) = E j. As funções g s são utilizadas seguindo-se a ordem anterior. Nas quatro primeiras iterações, ou seja, na primeira vez em que cada função g é utilizada, faz-se γ = 0. Nas demais iterações, γ é selecionado aleatoriamente dentro de um conjunto Γ, onde Γ é um parâmetro do método. 4.5 POP aplicado ao PSUMAA Durante a etapa de construção é aplicado o Princípio da Otimalidade Próxima (POP). Este princípio é baseado na idéia de que boas soluções em um nível estão próximas de boas soluções em um nível adjacente (Glover and Laguna, 1997). Assim, antes de se inserir uma nova tarefa na solução em formação, esta é submetida a uma busca local. A busca local utilizada consiste em uma descida randômica em relação à vizinhança N R. Dada uma solução, aleatoriamente escolhe-se uma tarefa na sequência e uma nova posição para ela. Se a nova sequência produzir uma solução com um valor menor para a função objetivo, a nova sequência é aceita e passa a ser a solução corrente; caso contrário, é testada outra realocação. A busca é interrompida após MRDMax realocações consecutivas sem melhora na função objetivo. 4.6 VND 1 Na etapa de busca local da primeira fase do algoritmo (linha 6 da Figura 1), utiliza-se a Busca em Vizinhança Variável (Variable Neighborhood Descent - VND). Proposto por Mladenović and Hansen (1997), o VND é um método de busca local que consiste em explorar o espaço de busca através de trocas sistemáticas de estruturas de vizinhanças. Basicamente o procedimento utilizado consiste em três passos: (1) método randômico de descida (MRD) com a vizinhança N T ; (2) MRD com a vizinhança N R ; (3) MRD com a vizinhança N RB. Cada passo é constituido de iterações que geram vizinhos aleatórios com relação à respectiva estrutura de vizinhança. Sempre que uma solução de melhora é encontrada, volta-se ao primeiro passo. Quando um dos MRD s atinge MRDmax iterações sem melhora, passa-se para o passo seguinte. Estando-se no último passo, então o procedimento é interrompido e a melhor solução encontrada é retornada. 4.7 VND 2 Como a solução proveniente da primeira fase do algoritmo GPV (linhas 1-12 da Figura 1) não é necessariamente um ótimo local com relação às vizinhanças adotadas, ela é submetida a uma busca local mais efetiva, no caso, também baseada na Busca em Vizinhança Variável (VND 2 ). Nesta, a exploração do espaço de soluções é realizada de acordo com os seguintes passos: (1) descida completa (DC) com relação à vizinhança N T ; (2) DC com relação à vizinhança N R ; (3) DC na vizinhança N RB. No passo (3), em que são realizadas realocações de blocos de tarefas, inicialmente testam-se todas as realocações com blocos de duas tarefas possíveis e quando não for mais possível melhorar a solução com um determinado tamanho de bloco, passa-se a explorar movimentos com blocos de tamanho imediatamente maior. Sempre que uma solução de melhora é encontrada, volta-se ao passo (1). Se em um determinado passo, todos os vizinhos com relação à respectiva estrutura de vizinhança não são de melhora, passa-se para o passo seguinte. O procedimento é interrompido quando um ótimo local com relação às três vizinhanças é encontrado. 5 Resultados computacionais Foram utilizados para teste os mesmos problemas usados em Gomes Júnior et al. (2007). Esta base de dados é constituída por grupos de problemasteste de 8 a 75 tarefas e tempos de setup simétricos. Cada grupo possui 12 problemas distintos gerados de forma pseudo-aleatória. O modelo matemático apresentado na Seção 3 foi implementado usando o modelador AMPL e o otimizador CPLEX, versão 10.1, da ILOG. Foram submetidos a tal otimizador os problemas com até 12 tarefas, sendo estipulado o limite de 3600 segundos para obtenção de cada resultado. Para os problemas que atingiram esse tempo limite, a solução encontrada não é necessariamente ótima; porém, é retornado pelo CPLEX um limite inferior. Este limite é utilizado para medir a qualidade da solução retornada por meio da equação gap i = (fi CPLEX L i )/L i, em que fi CPLEX e L i representam o valor da solução e o limite inferior encontrados pelo otimizador. Deste modo, gap i é igual a zero quando a solução ótima é encontrada. O algoritmo heurístico proposto (GPV) foi implementado em linguagem C usando o ambiente Borland C++ Builder 5. Seus parâmetros foram calibrados empiricamente, sendo GRASPMax = 8 e MRDMax = 7n para n 50 e MRDMax = 5n para n = 75. O conjunto Γ utilizado é o mesmo de Gomes Júnior et al. (2007), ou seja, Γ = {0, 02; 0, 04; 0, 12; 0, 14}. Cada problema-teste foi

17 executado 30 vezes, exceto aqueles com 75 tarefas, os quais foram executados apenas 10 vezes em virtude do maior tempo computacional demandado. Os resultados obtidos por cada fase do algoritmo GPV e pelo algoritmo proposto por Gomes Júnior et al. (2007) foram comparados por meio das expressões imp best i = (f GJr i f GPV i )/f GJr i (1) e imp avg i = (f i fi )/f i (2), onde fi GJr é o melhor valor encontrado por Gomes Júnior et al. (2007), fi GPV é o melhor valor encontrado pela respectiva fase do algoritmo proposto, f i é a média dos valores encontrados pela respectiva fase do algoritmo durante todas as execuções e fi é o valor da função objetivo para a melhor solução conhecida para o problema-teste i. A expressão (1) mensura o quanto o algoritmo proposto superou o melhor resultado encontrado por Gomes Júnior et al. (2007). Já a expressão (2) mede a variabilidade média das soluções encontradas pelo algoritmo em torno da melhor solução conhecida para o respectivo problema. A Tabela 1 apresenta os resultados obtidos. Nesta tabela, a primeira coluna indica o número de tarefas em cada grupo. Nas colunas GPV: Fase 1 são apresentadas as contribuições da primeira fase do algoritmo proposto (linhas 1 a 12 da Figura 1), enquanto em GPV: Fase 2 são mostradas as contribuições relativas à segunda fase do algoritmo proposto (linha 13 da Figura 1). Os resultados obtidos pela heurística proposta por Gomes Júnior et al. (2007) são apresentados nas colunas Gomes Jr.. Para um grupo de problemas com i tarefas, as colunas imp best apresentam as médias dos imp best i s obtidos para os problemas deste grupo nas respectivas fases do algoritmo, as colunas imp avg apresentam as médias dos imp avg i s obtidos para os problemas do grupo nas respectivas fases do algoritmo e as colunas Tempo mostram as médias dos tempos (em segundos) demandados até as respectivas fases do algoritmo. Para os conjuntos de colunas CPLEX, a coluna Tempo mostra as médias dos tempos (em segundos) demandados por tal otimizador, enquanto a coluna gap mostra as médias dos gap i s obtidos para os problemas dos respectivos grupos. Na Tabela 1 é possível observar que o CPLEX foi capaz de resolver todos os problemas-teste com até 10 tarefas. Para os problemas envolvendo 11 e 12 tarefas, este otimizador não conseguiu encontrar, dentro do limite de tempo estabelecido, a solução ótima em todos os casos, sendo que para os problemas-teste com 12 tarefas o gap foi de 37,95%. A primeira fase do algoritmo GPV foi suficiente para encontrar as melhores soluções, com a variabilidade média de até 1,60%, em problemas teste com até 15 tarefas. Para estes problemas, a fase de pós-otimização (VND 2 ) reduziu a variabilidade média para até 1,44%. Para os problemas com até 12 tarefas, o tempo demandado pelo algoritmo proposto foi muito inferior ao tempo demandado pelo CPLEX, sendo que para os problemas com 11 tarefas a heurística demandou um tempo médio de 0,23 segundos, contra a média de 2355,90 segundos demandada pelo CPLEX. Para os problemas de 20 a 50 tarefas, o algoritmo GPV teve desempenho inferior ao de Gomes Júnior et al. (2007) em até 1,06% na média em relação às melhores soluções encontradas e o imp avg variou de 3,08% a 8,01%. Vale observar, no entanto, que, mesmo sendo testado em uma máquina com menor poder de processamento o algoritmo GPV demandou menos tempo que o de Gomes Júnior et al. (2007) nesses grupos de problemas (para o caso com 50 tarefas, esta diferença de tempo é de quase 90%). Apesar de o algoritmo proposto ter demandado uma média de tempo um pouco maior nos problemas com 75 tarefas, em contrapartida, os melhores resultados encontrados foram, em média, 1,73% melhores. Além disso, o imp avg apresentado para este conjunto foi de 8,39%, contra 14,10% de Gomes Júnior et al. (2007). 6 Conclusões Este trabalho tratou o problema de sequenciamento em uma máquina com penalidades por antecipação e atraso da produção (PSUMAA), considerando janelas de entrega distintas e tempo de preparação da máquina dependente da sequência de produção. Primeiramente foi proposto um novo modelo matemático para representar o problema, que resultou na redução de variáveis e restrições em relação a um da literatura. Em seguida, foi proposto também um algoritmo heurístico baseado em GRASP, Princípio da Otimalidade Próxima e Busca em Vizinhança Variável para determinar a melhor sequência de produção. Este algoritmo aciona um procedimento de complexidade polinomial encontrado na literatura para determinar as dadas ótimas de conclusão das tarefas de cada sequência gerada. O otimizador CPLEX 10.1 foi utilizado para resolver o modelo matemático proposto, sendo o mesmo capaz de resolver somente problemas-teste com até 12 tarefas, mesmo assim, não em sua totalidade. O algoritmo heurístico desenvolvido foi aplicado em problemas-teste com até 75 tarefas. Para os problemas com até 12 tarefas, o tempo médio demandado pelo algoritmo proposto foi muito menor que o despendido pelo CPLEX. Para os problemas com até 15 tarefas, todas as melhores soluções conhecidas foram encontradas e, além disso, as médias dos desvios das soluções finais em torno das melhores soluções conhecidas foram baixas. A qualidade das melhores soluções encontradas para os problemas-teste de 20 a 50 tarefas foram pouco inferiores às de Gomes Júnior et al. (2007) e demandaram menor tempo com-

18 Tabela 1: Comparação CPLEX GPV Gomes Júnior et al. (2007). # CPLEX GPV: Fase 1 GPV: Fase 2 Gomes Jr. Tarefas gap Tempo 1 imp best imp avg Tempo 1 imp best imp avg Tempo 1 imp avg Tempo 2 (%) (s) (%) (%) (s) (%) (%) (s) (%) (s) 8 0,00 3,46 0,00 0,08 0,06 0,00 0,05 0,06 0,03 0,04 9 0,00 68,73 0,00 0,34 0,09 0,00 0,34 0,10 0,06 0, ,00 180,71 0,00 0,04 0,13 0,00 0,04 0,14 0,02 0, , ,90 0,00 0,39 0,22 0,00 0,35 0,23 0,12 0, , ,73 0,00 0,33 0,31 0,00 0,27 0,32 0,21 0, ,00 1,60 0,88 0,00 1,44 0,92 1,47 0, ,06 3,42 3,34-0,06 3,08 3,51 1,65 4, ,89 4,22 8,60-0,89 3,12 9,19 2,32 13, ,15 7,02 21,85-0,55 5,01 23,60 3,34 40, ,40 8,98 75,72-0,35 5,81 83,84 4,38 155, ,39 12,45 232,78-1,06 8,01 261,28 6,20 492, ,30 19, ,43 1,73 8, ,90 14, ,08 1 AMD Turion(tm) 64 X2 TL MHz, com 2 GB de RAM. 2 Athlon XP 64 Bits (aproximadamente 2 GHz), com 1 GB de RAM. putacional, mesmo sendo utilizado um computador de menor poder de processamento. Já para os problemas-teste com 75 tarefas, as melhores soluções encontradas foram 1,73%, em média, melhores que as daqueles autores. O algoritmo GPV também produziu uma média menor para os desvios das soluções finais. Agradecimentos O primeiro autor agradece ao CEFET-MG pela bolsa de pesquisa e o segundo, à FAPEMIG (Programa Pesquisador Mineiro), ao CNPq (processo /2007-8) e à FAPERJ (processo E- 26/ /2007), pelo apoio ao desenvolvimento da presente pesquisa. Referências Allahverdi, A., Gupta, J. N. and Aldowaisan, T. (1999). A review of scheduling research involving setup considerations, Omega: The International Journal of Management Science 27: Bustamante, L. M. (2007). Minimização do custo de antecipação e atraso para o problema de sequenciamento de uma máquina com tempo de preparação dependente da sequência: aplicação em uma usina siderúrgica., Master s thesis, UFMG, Belo Horizonte. Feo, T. A. and Resende, M. G. C. (1995). Greedy randomized adaptive search procedures, Journal of Global Optimization 6: França Filho, M. F. (2007). GRASP e Busca Tabu aplicados a problemas de programação de tarefas em máquinas paralelas, PhD thesis, UNICAMP, Campinas. Glover, F. and Laguna, M. (1997). Tabu Search, Kluwer Academic Publishers, Boston. Gomes Júnior, A. C., Carvalho, C. R. V., Munhoz, P. L. A. and Souza, M. J. F. (2007). Um método heurístico híbrido para a resolução do problema de sequenciamento em uma máquina com penalidades por antecipação e atraso da produção, Anais do XXXIX Simpósio Brasileiro de Pesquisa Operacional, SO- BRAPO, pp Gupta, S. R. and Smith, J. S. (2006). Algorithms for single machine total tardiness scheduling with sequence dependent setups, European Journal of Operational Research 175: Li, G. (1997). Single machine earliness and tardiness scheduling, European Joumal of Operational Research 96: Liaw, C.-F. (1999). A branch-and-bound algorithm for the single machine earliness and tardiness scheduling problem, Computers & Operations Research 26: Mladenović, N. and Hansen, P. (1997). Variable neighborhood search, Computers and Operations Research 24(11): Souza, M. J. F., Penna, P. H. V. and Gonçalves, F. A. C. A. (2008). Grasp, vnd, busca tabu e reconexão por caminhos para o problema de seqüenciamento em uma máquina com tempos de preparação dependentes da seqüência da produção, janelas de entrega distintas e penalidades por antecipação e atraso da produção, Anais do XL Simpósio Brasileiro de Pesquisa Operacional, pp Wan, G. and Yen, B. P.-C. (2002). Tabu search for single machine scheduling with distinct due windows and weighted earliness/tardiness penalties, European Journal of Operational Research 142:

19 PROPOSTA DE IMPLEMENTAÇÃO DE CONTROLE SUPERVISÓRIO EM CONTROLADORES LÓGICO PROGRAMÁVEIS DIOGO L. L. DA CRUZ (1), ANDRÉ B. LEAL (2) *, ROBERTO S. U. ROSSO JR (2), JOSÉ G. DO ROZÁRIO (2), (1) Pollux Automation Avenida Getúlio Vargas, Anita Garibalde, 608, , Joinville, SC, Brasil (2) Grupo de Pesquisa em Automação de Sistemas e Robótica GASR, Universidade do Estado de Santa Catarina UDESC, Campus Universitário Prof. Avelino Marcante s/n, , Joinville, SC, Brasil s: diogollcruz@yahoo.com, leal@joinville.udesc.br, rosso@joinville.udesc.br Abstract This paper addresses the implementation of supervisory control of discrete event systems in Programmable Logic Controllers. It discusses the problems that arise in this type of implementation and presents a proposal for implementation that addresses these problems. It is used the modular local approach to synthesize the supervisors and a simple problem is used to illustrate the proposed methodology. Keywords Discrete-event systems, supervisory control, local modular approach, PLC, Ladder. Resumo Este trabalho aborda a implementação de controle supervisório de sistemas a eventos discretos em Controladores Lógico Programáveis. Discute-se sobre os problemas que surgem neste tipo de implementação e apresenta-se uma proposta de implementação que soluciona tais problemas. Utiliza-se a abordagem modular local de síntese de supervisores e um problema simples é usado de forma a ilustrar a metodologia proposta. Palavras-chave Sistemas a eventos discretos, controle supervisório, abordagem modular local, CLP, Ladder. 1 Introdução Na atualidade, a automação da manufatura tem assumido cada vez mais um papel importante dentro das indústrias e os problemas de controle de sistemas automatizados têm se tornado cada vez mais complexos. Assim, desenvolver e implementar uma lógica de controle para os sistemas automatizados de manufatura atuais não é uma atividade trivial. A Teoria de Controle Supervisório (TCS) apresentada por Ramadge e Wonham (1989) se mostra cada vez mais uma ferramenta adequada no processo de síntese da lógica de controle para sistemas automatizados, pois a mesma garante a obtenção de uma lógica de controle ótima (minimamente restritiva e não bloqueante e que satisfaz às especificações de controle). Muito embora a TCS seja uma ferramenta importante para a solução de problemas de controle de sistemas de manufatura, esta teoria e suas extensões não são difundidas e empregadas em ambientes industriais. O principal motivo para isto reside em algumas dificuldades ainda existentes na síntese de supervisores para sistemas de grande porte. Segundo Fabian e Hellgren (1998), outro motivo importante consiste nas dificuldades encontradas na implementação da solução obtida por intermédio da TCS. Assim, no intuito de diminuir o afastamento entre teoria e prática, neste trabalho apresenta-se uma proposta para a implementação da estrutura de controle supervisório em Controladores Lógico Programáveis (CLPs). Utiliza-se a abordagem Modular Local (Queiroz e Cury, 2000) para a síntese dos supervisores e a implementação em CLP é feita em linguagem ladder. Este tema foi abordado em trabalhos anteriores, dentre os quais se podem citar (Balemi, 1992), (Leduc, 1996), (Hellgren et al, 2002), (Queiroz e Cury, 2002) e (Vieira, 2007). Entretanto, os trabalhos que apresentaram proposta de implementação de controle supervisório em linguagem ladder, apenas um evento é tratado por ciclo de varredura do CLP. Esta estratégia soluciona alguns problemas de implementação apontados na literatura, mas além de não resultar em programas eficientes, pode levar a outros problemas decorrentes do atraso da comunicação entre planta e CLP. Além disso, em alguns destes trabalhos os problemas apontados em (Fabian e Hellgren, 1998) são discutidos, mas não são apresentadas soluções para os mesmos. Uma contribuição da metodologia proposta neste artigo consiste no fato dela possibilitar o tratamento de diversos eventos em um mesmo ciclo de varredura do CLP, sejam estes eventos controláveis ou não. Além disso, a metodologia proposta apresenta uma solução para diversos problemas decorrentes da implementação da TCS em CLPs. O presente artigo está estruturado como segue. Na Seção 2 é feita uma discussão sobre os problemas que surgem na implementação de supervisores em CLPs. Na Seção 3, apresenta-se a metodologia proposta para a implementação e na Seção 4 utiliza-se um estudo de caso simples para ilustrar a aplicação da metodologia proposta. Finalmente, na Seção 5 apresentam-se as conclusões deste trabalho. * Tutor ( bolsista) do Programa de Educação Tutorial Grupo PET Engenharia Elétrica da UDESC

20 2 Considerações sobre a Implementação de Controle Supervisório em CLPs Na solução de problemas de automação da manufatura por intermédio da TCS modela-se o comportamento da planta como um Sistema a Eventos Discretos (SED) e autômatos de estados finitos são usados para descrever a planta, as especificações e os supervisores. Assim, segundo Fabian e Hellgren (1998), na implementação da estrutura de controle supervisório em CLPs deve-se fazer com que o CLP se comporte como uma máquina de estados. Entretanto, esta implementação não é trivial e pode levar a alguns problemas, conforme as classes de problemas apresentadas a seguir (Fabian e Hellgren, 1998). Causalidade: a TCS assume que todos os eventos são gerados espontaneamente pela planta e que os supervisores devem apenas estabelecer as desabilitações dos eventos controláveis a serem gerados pela planta. Porém, na maioria das aplicações práticas os eventos controláveis não são gerados espontaneamente pela planta física, mas são respostas a comandos do CLP. Desse modo, para fins de implementação deve-se responder a questão Quem gera quem? (Fabian e Hellgren, 1998). Para atender fielmente a hipótese de Ramadge e Wonham (1989), a implementação é realizada de acordo com a estrutura de controle proposta por Queiroz e Cury (2002). Nesta estrutura, sub-plantas assíncronas, chamadas de sistema produto (SP), são implementadas no CLP e são responsáveis pela geração dos eventos controláveis. Assim, embora os e- ventos controláveis correspondam a acionamentos na saída do CLP, eles são gerados pela planta (SP) e os supervisores mantêm a função original de apenas estabelecer as desabilitações de eventos controláveis. Sinais e eventos: a TCS considera que a evolução da planta é dirigida pela ocorrência de eventos discretos, os quais são simbólicos, assíncronos e o- correm em instantes discretos do tempo (Fabian e Hellgren, 1998). Por outro lado, o CLP trabalha com sinais booleanos que são sincronamente atualizados a cada ciclo de varredura. Assim, na implementação de supervisores em CLPs é preciso associar as mudanças nos valores destes sinais e a ocorrência de eventos discretos. Entretanto, esta associação pode ocasionar o chamado efeito avalanche e também pode impedir a distinção da ordem de ocorrência de alguns eventos, conforme abordado a seguir. O efeito avalanche ocorre quando a mudança de valor num sinal do CLP é registrada por intermédio de um evento e este provoca a transição indevida de mais de um estado do sistema num mesmo ciclo de varredura do CLP (Fabian e Hellgren, 1998). Ainda, devido à natureza cíclica de execução do programa do CLP, a leitura dos seus sinais de entrada é feita somente no início de cada ciclo de varredura. Assim, se entre uma leitura e outra das entradas houver a mudança de valor de dois ou mais sinais, haverá o registro simultâneo de ocorrência de eventos não controláveis. Note que esta mudança nos sinais pode ser simultânea ou não, mas ela é registrada num mesmo ciclo de varredura. Entretanto, devido à natureza assíncrona dos modelos usados na TCS, não se tem como representar a ocorrência simultânea destes eventos. Assim, para que um supervisor possa ser implementado sem que haja problemas, sua ação de controle deve ser independente dos diferentes entrelaçamentos possíveis de eventos não controláveis. Esta propriedade é chamada de insensibilidade ao entrelaçamento (Fabian e Hellgren, 1998). Escolha: após a ocorrência de uma determinada seqüência de eventos pode haver múltiplas opções para prosseguir no comportamento da planta. Assim, quando o sistema de controle é responsável pela geração de uma parcela de eventos, a decisão sobre qual será o próximo evento a ser gerado é compartilhada entre o sistema a ser controlado e o sistema de controle. De acordo com (Fabian e Hellgren, 1998), no intuito de evitar uma série de problemas, a implementação tem que simultaneamente escolher e transitar; e somente um evento deve ser escolhido, ou seja, apenas um evento controlável deve ser gerado em cada ciclo de varredura do CLP. Entretanto, a solução apontada por aqueles autores claramente prioriza a execução de um evento em detrimento a outro(s), o que, de acordo com (Malik, 2002), pode fazer com que uma parcela do comportamento do sistema deixe de ser realizada e é possível que essa escolha leve ao bloqueio do sistema mesmo tendo-se supervisores não bloqueantes. Sincronização inexata: durante a execução do programa pode haver uma mudança em algum sinal de entrada do CLP e, neste caso, esta mudança só será reconhecida no início do próximo ciclo de varredura. Assim, pode-se dizer que a comunicação entre a planta e o CLP é sujeita a atrasos devidos a a- tualização periódica dos sinais de entrada do CLP (Balemi, 1992). Segundo Fabian e Hellgren (1998), a sincronização inexata pode ser um problema quando uma mudança num sinal de entrada do CLP invalida a ação de controle (escolha feita pelo programa, que corresponde à geração de um evento controlável). Para garantir que este problema não ocorra, deve-se garantir que a linguagem gerada pelo autômato que modela o supervisor, e, conseqüentemente o supervisor, tenha a propriedade de ser insensível ao atraso (Balemi e Brunner, 1992). 3 Proposta de Implementação As propostas de implementação de supervisores em linguagem ladder existentes na literatura, tais como as de (Leduc, 1996), (Hellgren et al, 2002) e (Queiroz e Cury, 2002), por exemplo, apresentam algo em comum, que é tratar um único evento por ciclo de varredura do CLP. Este procedimento é usado para manter a coerência do sistema de controle e evitar o efeito avalanche. Porém, desta forma a dinâmica de atualização/atuação do supervisor fica mais lenta do

21 que aquela obtida via solução tradicional, sem a utilização da TCS. Assim, se entre dois ciclos de varredura houvesse n mudanças nas entradas do CLP, o programa levaria n ciclos de varredura para tratar estas informações (sinalizar a ocorrência destes eventos na planta), aumentando a possibilidade de ocorrência de algum problema decorrente do atraso de comunicação apontado por Balemi e Brunner (1992). A proposta apresentada neste artigo está baseada no fluxograma ilustrado na Figura 1. Grosso modo, utiliza-se a estrutura de controle apresentada por Queiroz e Cury (2002), mas a implementação dos subsistemas do sistema produto (SP) e dos supervisores é feita separando-se estes em blocos de eventos de acordo com a controlabilidade destes. Ao escrever o programa de forma a tratar os eventos na ordem eventos não controláveis desabilitações eventos controláveis, consegue-se tratar num ciclo de varredura todos os eventos não controláveis ocorridos na planta, atualizar os estados dos subsistemas e dos supervisores, definir o conjunto de eventos desabilitados pelos supervisores, e, finalmente, gerar os e- ventos controláveis habilitados e atualizar os estados dos subsistemas e dos supervisores. A seguir, descreve-se em detalhes a metodologia proposta. Sistema Produto Eventos não controláveis Supervisores Eventos não controláveis Desabilitação de eventos controláveis Sistema Produto Eventos controláveis Supervisores Eventos controláveis Figura 1. Fluxograma de implementação. No início de cada ciclo de varredura o sistema produto realiza as transições de estados com todos os eventos não controláveis que acabaram de ser identificados na leitura das entradas e logo em seguida os supervisores também realizam as transições de estados com os eventos não controláveis. Desta forma se dá prioridade para o tratamento de eventos não controláveis, mantendo o sistema produto e os supervisores em sincronia com a planta. A partir do estado atual dos supervisores verificam-se quais eventos estão desabilitados pelo conjunto de supervisores. Assim, da lista de eventos habilitados se verifica se existe o problema da escolha, havendo esse problema a escolha é feita aleatoriamente, conforme explicado mais à frente. Os eventos controláveis que estão habilitados e que são possíveis de ocorrer na planta são gerados no nível do sistema produto e é feita a atualização de estados nos modelos dos subsistemas e dos supervisores. Estes eventos são finalmente mapeados em acionamentos das saídas do CLP e dá-se início a um novo ciclo de varredura. No tratamento dos eventos não controláveis utilizam-se dois grupos de memórias, chamados de M1 e M2. O grupo M1 recebe a informação dos eventos não controláveis identificados na leitura das entradas. Já o grupo M2, que inicialmente recebe a mesma informação de M1, é usado ao transitar de estado no sistema produto e nos supervisores. Início Inicialização dos estados Lê entradas e seta grupo M1 Seta grupo de eventos não controláveis M2 com a informação do grupo M1 Promove as transições de estados do sistema produto com eventos não controláveis ativos em M2 Seta grupo de eventos não controláveis M2 com a informação do grupo M1 Promove transições de estados em cada supervisor com os eventos não controláveis ativos em M2 Todos os supervisores foram atualizados? S Verifica eventos desabilitados Trata problema da escolha Gera os eventos controláveis e atualiza os estados do sistema produto Atualiza os estados dos supervisores a partir dos eventos controláveis gerados Escreve nas saídas Figura 2. Fluxograma com detalhamento da metodologia. O fluxograma ilustrado na Figura 2 apresenta detalhadamente o procedimento proposto, tendo como base teórica o fluxograma da Figura 1. Para facilitar o entendimento, este fluxograma é explicado a partir de um estudo de caso apresentado na próxima seção. 4 Estudo de Caso Seja uma linha de transferência industrial composta por seis máquinas M X (com X = 1,...,6) ligadas por quatro buffers B A, B B, B C e B D, com capacidade de uma peça, dispostas como mostra a Figura 3. Figura 3. Linha de transferência industrial (Queiroz e Cury, 2000). Esse problema foi estudado por Queiroz e Cury (2000) e foi escolhido por ser simples e ao mesmo tempo apresentar os problemas que se quer estudar. N

22 4.1 Modelagem da Planta O comportamento de cada máquina M X (X = 1,..,6) é representado pelo autômato G X da Figura 4. O início de operação é um evento controlável A X, e o final de operação um evento não controlável B X. Figura 4. Autômato G X, X = 1,..., Síntese dos Supervisores Neste trabalho utiliza-se a abordagem modular local de síntese dos supervisores (Queiroz e Cury, 2000). Assim, considerando o conjunto de autômatos apresentados na Figura 4 e as especificações que visam impedir o underflow e overflow de todos os buffers, obtém-se um conjunto de quatro supervisores locais (Queiroz e Cury, 2000). Utilizando um software adequado (Feng e Wonham, 2006; Reiser et al., 2006) verifica-se que estes supervisores são nãoconflitantes e então se tem a garantia de que não existe perda de eficiência desta solução em relação à melhor solução centralizada (monolítica). Para facilitar a implementação utilizam-se os supervisores reduzidos, ou seja, modelos com um menor número de estados, mas com a mesma ação de controle que os originais. Neste trabalho a redução dos supervisores foi feita no TCT (Feng e Wonham, 2006), obtendo-se os supervisores da Figura 5: Na esquerda os autômatos S RA (Y=1), S RB (Y=3) e S RD (Y=5) e na direita S RC. Figura 6. Parte da rotina principal. O primeiro balão da Figura 7 consiste em um jogador de autômatos apenas com as transições dos eventos não controláveis do sistema produto (SP). O segundo balão da Figura 7 também consiste num jogador de autômatos, porém agora com as transições de eventos não controláveis dos supervisores. Figura 5. Autômatos dos supervisores reduzidos. 4.3 Implementação da Estrutura de Controle A implementação da estrutura de controle foi feita em linguagem ladder usando o CLP S7-300 da Siemens. No intuito de melhor organizar o programa do CLP, criou-se uma rotina principal que chama blocos de funções responsáveis pelo tratamento de cada bloco ilustrado no fluxograma da Figura 2. Parte da rotina principal é mostrada na Figura 6. Além da rotina principal e das rotinas de leitura e de escrita, o programa do CLP pode ser dividido em seis partes, chamando-se os blocos de funções na ordem apresentada nos seis balões da Figura 7. Devese ressaltar que em cada balão são tratadas apenas as transições representadas por linhas cheias. Assim, o evento Ax não é tratado no balão 1, mas é tratado no balão 5. Ainda, as transições que não causam mudança de estado (self-loops), não precisam ser tratadas. Figura 7. Ordem de chamada dos autômatos. O terceiro balão consiste na rotina de desabilitações, ou seja, de acordo com o estado atual de todos os supervisores, se determinam quais são os eventos controláveis devem ser desabilitados. No quarto balão é realizado o tratamento do problema da escolha de eventos controláveis. Esta sub-rotina só deve ser chamada quando necessária.

23 O quinto balão mostra um jogador de autômatos com os eventos controláveis do sistema produto, assim, cada evento controlável não desabilitado e apto a ocorrer, levaria à transição do sistema produto e à ativação de uma saída, proporcionando na planta física a ocorrência de um evento controlável. Por fim, no sexto balão temos um jogador de autômatos com os eventos controláveis dos supervisores. No início de cada ciclo de varredura do CLP é realizada a leitura das entradas e a cada transição do sinal de nível baixo para nível alto (borda de subida), em uma determinada entrada é identificada a ocorrência de um evento não controlável. A função P mostrada na Figura 8 garante que o evento não controlável será identificado somente no primeiro ciclo de varredura no qual ocorreu a transição do sinal de entrada (borda de subida). Em um mesmo ciclo de varredura os autômatos podem transitar de estados de acordo com a quantidade de eventos não controláveis ocorridos na planta. A informação acerca do estado atual de cada subsistema é atualizada conforme mostrado na Figura 10. Note que para evitar o efeito avalanche, ao transitar de estado é apagada de M2 a informação do evento que proporcionou tal transição. Como o sistema produto é composto por subsistemas assíncronos, um evento tratado em um subsistema não irá ocorrer em outro, assim não há problema em apagar a informação do evento no momento em que for registrada a sua transição. Já nos supervisores, que não são necessariamente assíncronos, pode acontecer de um mesmo evento estar apto a proporcionar uma transição de estado em mais de um supervisor. Portanto, antes de executar o jogador de autômatos de cada supervisor é necessário atualizar o grupo de memórias M2 com a informação do grupo de memórias M1, o que é feito chamando-se a subrotina ATUALIZA M2=M1 mostrada na Figura 9. Assim, essa sub-rotina deve ser criada em um bloco de função e chamada diversas vezes, conforme ilustrado no fluxograma da Figura 2. Figura 10. Transição do estado 1 para 0 com B1 na planta G1. Após atualizar os estados dos subsistemas de SP e dos supervisores com as transições provocadas por eventos não controláveis, verificam-se quais eventos estão desabilitados pela ação conjunta dos supervisores, como mostrado na Figura 11. Figura 8. Leitura das entradas. A informação da ocorrência do evento é mantida em um grupo de memórias, nomeado no fluxograma de M1, que é atualizado a cada nova varredura. Veja na Figura 8 que a mudança no sinal da entrada I0.0 é registrada na memória M1B1 de forma a sinalizar a ocorrência do evento B1, que está presente no autômato da planta G 1 (Figura 4) e no supervisor S RA (Figura 5). Esta mesma informação é salva num segundo grupo de memórias, chamado aqui de M2, como mostra a Figura 9. Figura 9. Função ATUALIZA M2=M1. Figura 11. Rotina de desabilitações. É possível que dois ou mais eventos controláveis não sejam desabilitados pelos supervisores, levando então ao problema da escolha. No exemplo em estudo, as máquinas M 2 e M 4 não podem iniciar ao mesmo tempo, ou seja, quando o supervisor S RC está no estado 0, os eventos A 2 e A 3 não estão desabilitados, mas não podem ser gerados ao mesmo tempo (ao final de um ciclo de varredura), devendo-se então escolher qual deles será gerado no nível de SP. Neste trabalho, para resolver o problema da escolha e ao mesmo tempo garantir que esta escolha não leve o sistema ao bloqueio ou que uma parcela do comportamento do sistema deixe de ser realizada, como apontado em (Malik, 2002), após a rotina de desabilitação é chamada uma rotina que, de maneira aleatória, mantém apenas um evento habilitado. Propõe-se então usar uma memória chamada aqui de INTERCALA que, conforme ilustrado na Figura 6, a cada ciclo de varredura assume um valor diferente (0 ou 1). Como mostra a Figura 12, se a memória INTERCALA assumir o valor 1, o evento A2 é desabilitado, caso contrario o evento A4 é desabilitado, garantindo assim uma escolha aleatória. Figura 12. Função TRATA ESCOLHA.

24 Esse tratamento deve ser criado em um bloco de função que só deve ser chamado quando dois (ou mais) eventos controláveis estão habilitados num estado de um dado supervisor. Além disso, para cada problema de escolha existente nos supervisores deve ser criada uma rotina dedicada. Por fim, se o problema da escolha envolver mais de um evento, a utilização de apenas uma memória boleana não será suficiente. Neste caso sugere-se a utilização de uma memória numérica para o tratamento do problema. É importante observar que a metodologia de implementação apresentada neste trabalho permite a geração de diversos eventos controláveis num mesmo ciclo de varredura do CLP. Por exemplo, no problema em estudo, o início de operação das máquinas M 1 e M 3 pode se dar ao mesmo tempo, e assim, ao final de um determinado ciclo de varredura, podem ser gerados os eventos A 1 e A 3. Na figura 13 apresenta-se a forma de geração de eventos controláveis nos subsistemas do SP. Figura 13. Geração do evento A2. 5 Conclusão Este trabalho aborda a implementação de controle supervisório de sistemas a eventos discretos em controladores lógico programáveis. Discute-se sobre os problemas que surgem neste tipo de implementação e apresenta-se uma proposta de implementação que trata de tais problemas. Utiliza-se a abordagem Modular Local para a síntese dos supervisores e a implementação em CLP é feita em linguagem ladder. A metodologia proposta é empregada na implementação da estrutura de controle supervisório para um problema de uma linha de transferência industrial, que apesar de simples, apresenta os problemas que se quer estudar. Por intermédio de um estudo de caso realizado com apoio do ambiente de programação do CLP pode-se comprovar que a metodologia proposta possibilita o tratamento de diversos eventos num mesmo ciclo de varredura, o que consiste em uma contribuição deste trabalho. Além disso, por intermédio destes testes observou-se a escolha aleatória de eventos controláveis (atendendo a solução apresentada para o problema da escolha) e a não ocorrência dos demais problemas discutidos neste trabalho. Atualmente está em fase de desenvolvimento uma ferramenta computacional para a geração automática da lógica de controle obtida por intermédio da teoria de controle supervisório. Assim, a lógica de controle gerada com auxílio desta ferramenta contemplará as soluções apresentadas no presente trabalho. Com esta ferramenta, espera-se contribuir para a diminuição do distanciamento entre teoria e prática existente na área de controle de sistemas automatizados. Agradecimentos O segundo autor agradece à FAPESC/CNPq pelo apoio financeiro (Contrato CON04504/2008-7). Referências Bibliográficas Balemi, S. (1992). Control of discrete event systems: theory and application, Ph.D. thesis, Swiss Federal Institute of Technology, Switzerland. Balemi, S. e Brunner U.A. (1992). Supervision of discrete event systems with communication delays. In American Control Conference, pp , Chicago, IL, USA. Fabian, M. e Hellgren, A. (1998). PLC-based implementation of supervisory control for discrete systems. In: 37th IEEE Conference on Decision and Control, v. 3, pp Feng, L. e Wonham, W. M. (2006) TCT: A Computation Tool for Supervisory Control Synthesis. Proc. of the 8th WODES, pp Hellgren, A.; Lennartson, B. e Fabian, M. (2002). Modelling and PLC-based implementation of modular supervisory control, Proc. of the 6th WODES. Leduc, R. J. (1996). PLC Implementation of a DES supervisor for a manufacturing testbeb: an implementation perspective, M.A.Sc. Thesis Dept. of Elect. and Comp. Eng., University of Toronto, Canada. Malik, P. (2002). Generating controllers from discrete-event models. In: F. Cassez, C. Jard, F. Laroussinie, M. D. Ryan, Proc. of the MOVEP. Queiroz, M. H. e Cury J. E. R. (2000). Modular supervisory control of large scale discrete event systems. In: Discrete event systems: analysis and control. 1st Ed. Massachusetts: Kluwer Academic Publishers, pp Queiroz, M. H. e Cury J. E. R. (2002). Synthesis and implementation of local modular supervisory control for a manufacturing cell. Proc. of 6th WODES. Ramdge, P. J. G. e Wonham W. M. (1989) The control of discrete event sytems. Procedings of the IEEE, 77(1): Reiser, C.; Da Cunha, A. E. C.; e Cury, J. E. R. (2006) The environment Grail for supervisory control of discrete event systems. Proc. of the 8th WODES. Vieira, A.D. (2007). Método de implementação do controle de sistemas a eventos discretos com aplicação da Teoria de Controle Supervisório. Tese (Doutorado em Eng. Elétrica), UFSC.

25 AMBIENTE DE CONTROLE HOLÔNICO SOBRE O SIMULADOR ANALYTICE II E COMPARAÇÕES DE POLÍTICAS DE CONTROLE DE MANUFATURA JARDEL LUCCA, RONI F. BANASZEWSKI, CESAR A. TACLA, PAULO C. STADZISZ, JEAN M. SIMÃO Laboratório de Sistemas Inteligentes de Produção (LSIP) Programa de Pós-graduação em Engenharia Elétrica e Informática Industrial (CPGEI) Campus Curitiba - Universidade Tecnológica Federal do Paraná - UTFPR Avenida Sete de Setembro, Curitiba/PR, Brasil - CEP jardel188@yahoo.com.br, banaszewski@cpgei.ct.utfpr.edu.br, tacla@utfpr.edu.br, stadzisz@utfpr.edu.br, jeansimao@utfpr.edu.br Abstract - The production tendencies require agile Manufacturing Systems (MS) in which the resources have some integrative and collaborative intelligence and are organized by an advanced control. Thus, the agile MS demands new tools for design and test. In this sense, previous works proposed a control solution related to a MS simulator. This solution was inspired by Rules Based Systems and proposed a new inference solution based upon notification that allows creating varied types of control. However, its prototype state does not provide graphical interface to make easy the creation of these controls. In this context, this paper presents evolutions related to the control solution by the development of a friendly environment. Furthermore, based on this environment, it is carried out comparisons of different control policies on the simulator. Key-words: Manufacturing Systems, Holonic Control, Control Interface, Control Police Comparison. Resumo - As tendências de produção exigem Sistemas de Manufatureiros (SM) ágeis nos quais os recursos têm certa inteligência integrativo-colaborativa e são organizados por um controle avançado. Assim sendo, os SM ágeis exigem novas ferramentas para projetos e testes. Neste sentido, trabalhos anteriores propuseram uma solução de controle usada sobre um simulador de SM. Esta solução foi inspirada em Sistemas Baseados em Regras, originando uma nova forma de inferência baseada em notificações a qual permite criar diversos tipos de controle com características ímpares. Entretanto, o estado de protótipo desta solução não fornece facilidades de interface gráfica para criar estes controles. Neste âmbito, este artigo apresenta evoluções para com esta solução por meio da implementação de um ambiente amigável de desenvolvimento. Ademais, a partir deste ambiente é realizada a comparação de diferentes políticas de controle no simulador. Palavras-chave: Sistemas de Manufatura, Controle Holônico, Interface de Controle, Comparações de Políticas de Controles. 1. Introdução Em vários setores da produção é notória a demanda por qualidade, diversidade e agilidade na produção, o que exige capacidade de se produzir diversos tipos de produtos competitivos em curtos períodos de tempo. Este cenário é evidenciado pela tendência de personalização em massa, na qual clientes terão escolhas personalizadas com preços viáveis [1][2][3]. Decorrentemente, há a tendência de que a produção não seja mais determinada pelos industriais, mas pelos clientes via e-business [3]. Mas para isto é necessário melhorar a integração entre a informática e a automática nos Sistemas de Manufatura (SM), bem como evoluí-los para alcançar agilidade (i.e. tempo de resposta competitivo) frente à produção variada e mesmo personalizada [1][2]. Neste âmbito, surgem os paradigmas ágeis dos SM que visam superar as deficiências dos não ágeis neste novo contexto. Tais paradigmas não ágeis incluem o hierárquico (inflexível, mas controlável) e mesmo o heterárquico (flexível, mas imprevisível) [1][2]. Um paradigma ágil deve encontrar equilíbrio entre hierarquia e heterarquia, mantendo suas vantagens. Entre os paradigmas ágeis, o mais enfatizado é o paradigma holônico, que advém da teoria de sistemas adaptativos [1][2][4][5]. O SM Holônico (SMH) contém entidades inteligentes chamadas de holons, entre os quais os Resource-HLs (e.g. Equipment-HLs) que colaboram para produzir em conformidade com um dado plano de produção (variada) vigente [1][2][4][5][6]. No caso da produção personalizada, também existem os Product-HLs, que negociam com os Resource-HLs para usar seus serviços e mesmo competem por eles baseados em fatores como prioridade de produção [1][2][4]. Como é ilustrado na Figura 1, os holons estão na interface entre informática (determinação do cliente via e-business cf. descrito anteriormente) e automática (planta). Figura 1: Entidades Inteligentes (Holons) em Planta Flexível [4]. Mas muito embora possa prover certa agilidade, apenas a negociação de forma hierárquica entre Resource-HLs e mesmo Product-HLs é incoerente com o paradigma holônico, o qual visa equilíbrio entre hierarquia e heterarquia. Logo, deve existir um Controle Holônico para regular as sociedades de holons (i.e. a holarquia) por meio de regras flexíveis [2][4][5]. Para solucionar esta problemática, em esforços prévios de pesquisa, foi proposta uma solução de Controle Holônico (CH) na forma de um

26 meta-modelo [4][5]. Uma primeira vantagem deste meta-modelo é a possibilidade de conceber holarquias de Resource-HLs com ou sem participação explícita de Product-HLs [4][5][6][7]. O meta-modelo de controle foi inspirado em Sistemas Baseados em Regras (SBR) e implementado sobre um simulador de SM, chamado ANALYTICE II, que é capaz de simular Resource-HLs e mesmo Product-HLs [4]. Nessa solução de controle, relações causais (regras) de controle são tratadas por agentes Rules, compostos por subagentes, que recebem dados factuais dos Resource-HLs e deliberam sobre ações, como a coordenação deles [4][5][6][8]. A inferência das Rules ocorre em uma cadeia de notificações composta pelos seus subagentes, constituindo-se em uma solução de inferência ímpar, conforme detalhado em [4][6]. Isto permite alta reatividade, desacoplamentos, determinismo e resolução de conflitos nas instâncias de controle, dentre outras vantagens [4][5][6]. Mas este meta-modelo foi implementado na forma de um framework e conectado ao ANALYTICE II, ambos desenvolvidos em linguagem C++, de forma que o estado de protótipo desta solução de controle apresenta algumas dificuldades para realização de experimentos. Um exemplo pontual de dificuldade é a criação de regras (conhecimento causal) dos controles, via código de programação, com a instanciação de agentes Rules e seus subagentes a partir do framework. Isto dificulta a utilização da solução por usuários sem uma cultura técnica de computação suficientemente acentuada. Este artigo apresenta um ambiente de desenvolvimento na forma de interfaces amigáveis sobre o framework de controle, detalhado no relatório em [9] e sintetizado no resumo em [10], e sua aplicação na elaboração e comparação de controles. O ambiente se restringe a criação de instâncias de controle orientadas ao processo (i.e. sem participação de Product-HLs) e é validado pela comparação de controles gerados nele com os seus equivalentes elaborados diretamente a partir do framework [9]. Em suma, as Rules (e seus subagentes) que controlam os Resource-HLs são criadas a partir do ambiente de desenvolvimento, permitindo elaborar instâncias de controle em alto nível. Também é apresentado como se dá a utilização do ambiente para a elaboração de controles e quais são as vantagens decorrentes deste. Ademais, usando este ambiente, elaboram-se controles nas abordagens hierárquica, heterárquica e holônica (orientada ao processo), sobre um mesmo SM, a fim de se comparar o desempenho destas abordagens. Isto permite comprovar as vantagens da abordagem holônica em relação às demais abordagens por meio de experimento efetivo, algo que rareia na literatura dos SMH. 2. ANALYTICE II e Controle Holônico (CH) Uma recorrência nas tecnologias de SM é a necessidade de testes e comparações. Uma opção é a simulação que evita riscos e tem um custo menor em relação a sistemas reais [4][5]. Entretanto, isto implica em ter um simulador com certas características essenciais, e.g. alta qualidade, baixo preço e disponibilidade de código fonte [4][5]. Este contexto levou ao desenvolvimento do ANALYTICE II, no LSIP/CPGEI da UTFPR, sendo este uma ferramenta de projeto e simulação de SM. ANALYTICE II foi elaborado visando modularidade, o que inclui a separação de recursos e produtos simulados das entidades de controle por meio de uma rede-virtual. Tais características fazem deste simulador promissor para uma solução realística de controle de SMH, uma vez que há carência disto e de experimentações decorrentes [11]. Neste simulador, os Resource-HLs (e os Product- HLs) são implementados de forma realística, separando suas partes mecatrônica e de software via uma rede virtual (vide Figura 2), o que se constitui em um trabalho relevante e mesmo ímpar [4][5]. Visto que ANALYTICE II é capaz de simular estes holons e que há carência de solução de controle holônico, elaborou-se a supracitada solução de controle [4][5][6][7], a qual consiste em um metamodelo de controle na forma de um framework, conforme mencionado. Figura 2: Resource-HL (controláveis) em ANALYTICE II. [7]. 3. Meta-Modelo de Controle Holônico (CH) O meta-modelo de controle foi aplicado primeiramente a CH orientado ao processo (i.e. sem participação de Product-HLs). Por ser a solução inspirada em SBR, as relações causais do controle podem ser expressas em termos de regras (cf. regra na Figura 3, relativa ao SM da Figura 2) que são tratadas por entidades chamadas Rules, sendo estas também um tipo de holon (cf. Figura 4). A inferência destas Rules é feita por meio de colaborações baseadas em notificações, de forma que os Resource-HLs notificam conhecimento factual para as Rules. Cada Rule notificada delibera a respeito do momento apropriado para a execução de certa ação de controle, tal como a coordenação dos Resource-HLs.

27 Figura 3: Holons Rules [7]. Na verdade, tanto os Resource-HLs quanto as Rules são compostas por subagentes ou subholons conforme apresentado no diagrama de classes em UML na Figura 4. Cada Resource-HL tem Attributes que externam seus estados, bem como Methods que o permite realizar serviços [4][5]. Cada Rule, por sua vez, é composta por uma Condition e uma Action. Cada Condition é ainda composta por um conjunto de Premises e cada Action é ainda composta por um conjunto de Instigations. A colaboração por notificação de todos estes elementos forma uma inferência diferenciada [4][5][6][7]. Figura 4: Diagrama UML dos Holons Notificantes [6]. Em suma, cada vez que um Attribute de um Resource-HL muda de estado, ele notifica apenas as Premises pertinentes. Estas são conhecidas pelo Attribute na formação delas, cada vez que ele é referenciado por cada uma delas. Cada Premise notificada compara, por meio de um operador, o estado deste Attribute com outro valor que pode ser uma constante ou o estado de outro Attribute. Cada Premise que tiver seu estado lógico alterado, notifica sua Condition que realiza seu cálculo causal pela conjunção dos estados lógicos de cada Premise considerada. Se a Condition se considerar verdadeira, ela aprova sua Rule que por sua vez ativa sua Action. A execução da Action é essencialmente o incitar de suas Instigations que ativam Methods de Resource-HLs, os quais podem alterar os estados de seus Attributes. Assim sendo, a inferência acontece em uma cadeia de notificações de holons e subholons. Este tipo de inferência provê vantagens para o CH como a alta reatividade, o desacoplamento dos elementos e a compatibilidade/equivalência com formalismo das redes de Petri [4][5][6][7][8]. Ademais, o fato de cada Rule realizar seu próprio processo de inferência faz desta solução inovadora em relação às abordagens existentes, nas quais as entidades lógico causais são passivas (ou semipassivas) e inferidas por uma máquina de inferência monolítica [6][7]. A solução também permite a criação de mecanismos cooperativos para questões relativas ao determinismo e ao conflito [4]. Além disso, esta abordagem de controle orientada a regras permite a coerência entre a implementação e a expressão do controle, permitindo que os mecanismos de controle possam ser emergidos a partir do conhecimento causal de controle expresso por especialistas nas Rules, inclusive na forma de regras causais textuais, se existir um ambiente de suporte para tal. Havendo este ambiente, comumente denotado como Wizard, os especialistas concentram-se exclusivamente no conhecimento apropriado de controle para explorar as flexibilidades do sistema objetivando agilidade. Em suma, esta solução de CH orientada ao processo trata simultaneamente de um conjunto de questões de controle ainda sendo uma solução autocontida e também aberta para outras questões como uso de Product-HLs [4]. Na interpretação do metamodelo para o uso destes, suas interações com Resource-HLs são organizadas usando Rules aprimoradas que impedem comportamentos impróprios do SM. Essencialmente, as Rules consideram também os interesses ou estados do Product-HLs, cf. [4][7]. Esta solução de controle tem sido aplicada em um conjunto de exemplos em ANALYTICE II que têm apresentado independência da simulação, uma vez que cada sistema de controle não é consciente que os Resource-HLs e Product-HLs são simulados [8]. Entretanto, a solução ou meta-modelo de controle foi implementado na forma de um framework em C++ sob ANALYTICE II, sem um wizard efetivo para facilitar as instanciações. Desta forma, as instâncias de controle eram geradas tecnicamente via código C++ derivando e/ou instanciado a partir do framework, o que acarretava morosidade nas experimentações. 4. Ambiente de Desenvolvimento de Controle No contexto do ANALYTICE II e de seu framework de controle, objetiva-se a elaboração de um ambiente composto por interfaces amigáveis (i.e. um wizard) para facilitar o desenvolvimento de instâncias de controle. Este wizard se faz essencial para atividades de pesquisa em controle sobre ANALYTICE II, uma vez que a instanciação técnica das Rules (i.e. via código) gera morosidade e improdutividade [9].

28 O wizard foi construído e se demonstra funcional para compor Rules em alto nível. A sua interface principal é a janela apresentada na Figura 5, a qual apresenta a mesma regra considerada na Figura 3. Esta regra em questão é relativa aos Resource-HLs de equipamentos de uma célula simulada em ANALYTICE II, apresentada na Figura 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 5: A interface do wizard usada para a criação de uma Rule. Outra interface importante que compõem o ambiente é apresentada na Figura 6, à esquerda. Todas as Rules criadas e Resource-HLs são listadas nela. Ainda, o wizard permite a monitoração de Attributes dos Resource-HLs, por meio da janela apresentada na Figura 6, à direita. 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. Figura 6: Interfaces para listar Resource-HLs, Attributes e Rules. Monitorar os Attributes de um dado Resource-HL significa listá-los, bem como disponibilizar todos os seus valores durante uma dada execução. Na verdade, também há a possibilidade de alteração dos valores destes Attributes em tempo de execução. Este conjunto de funcionalidades provê facilidades na elaboração de controles, permitindo a decorrente realização de experimentos sem a necessidade de que o usuário tenha que determinar a instanciação das Rules e seus respectivos subagentes. Desta forma, o usuário irá concentrar-se somente na determinação das características relacionais e estruturais das Rules. O wizard ainda permite registrar o conteúdo das Rules decorrentes em arquivos, além de permitir que estas sejam excluídas, editadas ou recuperadas. Figura 8: As regras hierárquicas usadas.

29 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. 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. Figura 9: As regras heterárquicas usadas. Figura 10: Algumas regras holônicas usadas.

30 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 metamodelo 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 , Springer Science+Business, Inc. Manufactured in Netherlands, [2] Deen, S.M.: Agent-Based Manufacturing: Advances in the Holonic Approach. Springer, ISBN , [3] Da Silveira, G.; Borenstein, D.; Fogliatto, F.S.: Mass customization: literature review and research directions. International Journal of Production Economics, 72 (pp1-13), [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, [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, [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, , [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 - SMCA R1, [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 ) IOS Press, Amsterdam - The Netherlands. ISSN: , [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, [10] Lucca, J.; Banaszewski, R. F.; Stadzisz, P. C.; Tacla, C. A; Simão, J. M: Interface sobre Metamodelo 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, [10] Deen, S. M.: Agent-Based Manufacturing: Advances in the Holonic Approach, [11] Mařík, V.: Industrial Application of the Agentbased Technology. Copyright IFAC, [12] Simão, J. M.; Stadzisz, P. C.: Paradigma Orientado a Notificações (PON) Uma Técnica de Composição e Execução de Software Orientado a Notificações. Pedido de Patente ao INPI/Brasil, Número Temporário: , [13] Banaszewski, R. F.: Paradigma Orientado a Notificações: Avanços e Comparações. Dissertação de Mestrado, CPGEI/UTFPR, 2009.