IMPLEMENTAÇÃO DE SISTEMAS DE CONTROLE … DE MANUFATURA... · supervisor para a máquina de Mealy...

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, 89219-600, 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, 89223-100, Joinville, SC, Brasil

E-mails: [email protected], [email protected]

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 automa-ton of the supervisor obtained by the Supervisory Control Theory. This machine may be simplified further in order to have a re-duced 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 Ma-chines, 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 Controla-dor Lógico Programável (CLP) usando linguagem Ladder. Um sistema de manufatura é apresentado para exemplificar essa me-todologia. 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 Esta-do, 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 efica-zes 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 evo-lução de estado depende da ocorrência de eventos discretos assíncronos no tempo (Cassandras e Lafor-tune, 1999).

A Teoria de Controle Supervisório (TCS) de Ramadge e Wonham (1989) é uma metodologia bas-tante conhecida e apropriada para a síntese de contro-ladores para SEDs. Entretanto, apesar de sua reco-nhecida 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 supervi-só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 im-portante 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 in-termé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

proposta. Primeiro é realizada a síntese de um super-visor 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 es-tados. 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 al-guma outra unidade de processamento).

Síntese do Supervisorusando a TCS

Modelo das Plantas Especificações

Obtenção daMáquina de Estados

Simplificação daMáquina de Estados

Geração de Códigopara Controlador

Figura 1. Metodologia Proposta

3. Algoritmo Para Gerar a Máquina de Estados

A máquina de estados obtida com o algoritmo pro-posto 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 esta-rá completa quando todos os dados de entrada forem processados. O algoritmo é mostrado na figura 3.

ENQUANTO Lista de Estados > 0

Cria Estado Inicial(Planta, Supervisor e Desabilitações = 0)

Cria Lista de Estados

PARA Lista de Trasições FAÇA

Estado já existe?

No

Yes

Sc Evoluiu?

Não

Sim

Lê Estado

Cria Lista de Transições

Ev. Não-Controláveis da Planta (Gu)

Ev. Não-Controláveis do Supervisor (Su)

Desabilitações

Ev. Controláveis da Planta (Gc)

Ev. Controláveis do Supervisor (Sc)

Cria um Novo Estado

Não Faz Nada

Adiciona Estado na Lista de Estados

Máquina de Estados

Fim

Fim

Figura 3. Algoritmo para Obtenção da Máquina de Estados

Os dados de entrada para o algoritmo são os au-tô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ão-controlá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 es-tados iniciais dos dados de entrada. Essa informação compõe o ponto de partida da máquina, representan-

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 é cria-da 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 pro-cessamento iterativo até que todas as transições se-jam 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ão-controláveis e por Gc a parte da planta cujas transi-ções se devem a eventos controláveis. De forma se-melhante, 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ão-controláveis que criam evoluções de estado em Gu e Su. A combinação de mais do que um evento não-controlá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 proi-bidos de ocorrer, os remanescentes podem dar ori-gem às ações. As ações válidas para um dado estado são os eventos controláveis que não estão desabilita-dos 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 es-tado é 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ão-controláveis, Gu e Su obtidos a partir da TCS evolu-em. O mesmo ocorre para a parte controlável na o-corrência de uma ação. Esta metodologia é consisten-

te com a definição de máquina de Mealy, onde as saídas (ações) dependem do estado atual e das entra-das 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.

M1 B1 M2 B2 M3a1 b1 a2 b2 a3 b3

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 con-sideradas 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ão-controláveis que correspondem ao fim de operação das máquinas são representados por bx. O compor-tamento discreto das máquinas é modelado pelo au-tômato da figura 5.

0 1

ax

bx Figura 5. Modelo das Plantas

As especificações de controle para o sistema são restrições de coordenação para evitar overflow (so-brecarga) ou underflow (retirada de peças de um buf-fer 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 mode-la estas especificações é mostrado na figura 6.

0

b x

1

ax+1 Figura 6. Especificações de Controle

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 super-visor monolítico para este problema possui 18 esta-dos 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 mo-mento 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ão-controlável e as ações podem ser devido a mais do que um evento controlável.

M1/a1 M1

M2

b1/a1,a2 M2

Buf 1

b1

M1M3

b2/a3 b1,b3/a1,a2

b3

b1/a1,a2

b2,b3/a3

b3

M1M2M3

M1M3

Buf 2b2

M3Buf 1,2

b1,b2b1

b3/a3

M2M3

Buf 1

b1

b1,b3

b1,b2,b3/a1,a2,a3

b3

b2,b3/a1,a2,a3

b2

b3/a1,a2,a3

b2/a1,a2,a3

b1,b3/a1,a2,a3

b1,b2/a1,a2,a3

a2,a3

a3 a1,a3

a2

a1

a2

a1,a2

1 2

3

4

5

67

8

Figura 7. Máquina de Estados de Mealy

5. Simplificação da Máquina de Estados

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 expo-nencial 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 2n-1, onde n é o número de eventos não-controláveis váli-dos para aquele estado. Desta forma, para sistemas de grande porte, o tamanho de código para uma deter-minada implementação seria afetado significativa-mente para satisfazer essa condição. Uma solução alternativa para isso é considerar uma máquina de estados simplificada onde somente as transições de-vido a um único evento não-controlável são conside-radas. 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.

M1/a1 M1

M2

b1/a1,a2 M2

Buf 1

b1

M1M3

b2/a3

b3

b1/a1,a2

b3

M1M2M3

M1M3

Buf 2b2

M3Buf 1,2

b1

b3/a3

M2M3

Buf 1

b1

b3

b2

b3/a1,a2,a3

b2/a1,a2,a3

a2,a3

a3 a1,a3

a2

a1

a2

a1,a2

1 2

3

4

5

67

8

Figura 8. Máquina de Estados Simplificada

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 exe-cuçã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 ob-serva 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 con-trole. 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 mode-lados 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 empre-gada na prática (Malik, 2002).

Sinais elétricos dos sensores

Sinais elétricos para os atuadores

Supervisor

Planta

Eventos Não-controláveis

Eventos Controláveis

Unidade de Controle

Processo a Controlar

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 apresenta-do 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 relati-vos à implementação da máquina de estados em CLP, cujo ciclo de execução do programa obedece ao se-guinte 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 ter-mina 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 repre-sentam os eventos não-controláveis (transições) en-quanto as variáveis ax (ações) representam os even-tos 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. Ou-tras 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 rese-tadas não são mostradas na figura 10.

Entradas: as variáveis de transição bx serão ati-vadas 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ão-controlá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 correspon-dente Planta i é setada para evitar que a ação corres-pondente 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 trata-mento especial necessário para as ações, como des-crito 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 corren-te. A figura 12 mostra a parte inicial desse bloco para o sistema de manufatura.

Desabilitações: este bloco é responsável por de-sabilitar 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 seta-das 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 so-mente 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 exe-cução.

Start

P S

Estado 1

S

a1

Figura 10. Bloco de Inicialização

P

I1

S

b1

P

I2

S

b2

P

I3

S

b3

Figura 11. Bloco de Entradas

Estado 1

S

Estado 2b1

R

Estado 1

R

b1

S

Planta 1

S

a1

S

a2

Estado 2

S

Estado 3b1

R

Estado 2

R

b1

S

Planta 1

Estado 2

S

Estado 4b2

R

Estado 2

R

b2

S

Planta 2

S

a3

Figura 12. Parte Inicial do Bloco de Transições/Ações

Estado 3

R

a1

Estado 7

Estado 8

Estado 1

R

a2

Estado 4

Estado 6

Estado 8

Estado 1

R

a3

Estado 2

Estado 3

Figura 13. Bloco de Desabilitações

a3 Q3Planta 3

R

Planta 1

R

Planta 2

R

Planta 3

a2 Q2Planta 2

a1 Q1Planta 1

Figura 14. Bloco de Saídas

7. Conclusões

Este artigo apresenta um algoritmo para transformar o autômato de um supervisor obtido a partir da Teo-ria de Controle Supervisório (TCS) em uma máquina de estados finita, sua simplificação e conseqüente implementação em linguagem Ladder para Controla-dores 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, res-pectivamente. Este trabalho serve como ponto de partida para o desenvolvimento de ferramentas auto-máticas para geração de código e de uma metodolo-gia similar à apresentada aqui, mas baseada na Teoria de Controle Modular Local (Queiroz e Cury, 2002), abordagem que explora a natureza modular do siste-ma a ser controlado, criando supervisores específicos para partes específicas da planta modelada.

Agradecimentos

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. 2nd 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. 3305-3310.

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. 1045–1079.

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):81-98.

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.

UMA ABORDAGEM EVOLUTIVA ADAPTATIVA PARA O PROBLEMA DE

SEQUENCIAMENTO EM UMA MAQUINA COM PENALIDADES POR

ANTECIPACAO E ATRASO DA PRODUCAO

Fabio Fernandes Ribeiro∗, Marcone Jamilson Freitas Souza†, Sergio Ricardo de Souza∗

∗Centro Federal de Educacao Tecnologica de Minas GeraisCEFET/MG – Campus II

CEP: 30.510-000 – Belo Horizonte – MG – Brasil

†Universidade Federal de Ouro Preto - ICEBCampus Universitario – UFOP

CEP 35.400-000 – Ouro Preto – MG – Brasil

Emails: [email protected], [email protected], [email protected]

Abstract— This paper deals with the Single Machine Scheduling Problem with Earliness and Tardiness Penal-

ties, 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. Compu-

tational 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 maquina com penalidades por anteci-

pacao e atraso da producao, considerando janelas de entrega e tempo de preparacao de maquina dependente da

sequencia de producao. Em vista da complexidade combinatoria do problema, um metodo evolutivo adaptativo

e proposto para resolve-lo. Este metodo baseia-se nos princıpios do Algoritmo Genetico Classico, sendo que o

operador de cruzamento e escolhido dentre cinco operadores implementados, em funcao da qualidade das solucoes

produzidas em buscas pregressas. Testes computacionais mostram a efetividade do algoritmo proposto.

Palavras-chave— Algoritmos Geneticos, GRASP, Metaheurısticas, Reconexao por caminhos, Sequenciamento

em uma maquina

1 Introducao

O problema de programacao da producao objetode estudo deste trabalho e relativo ao sequenci-amento em uma maquina com minimizacao daspenalidades por antecipacao e atraso da produ-cao (Single Machine Scheduling for MinimizingEarliness and Tardiness Penalties), denominadoPSUMAA. No problema abordado, considera-se aexistencia de janelas de entrega e tempos de pre-paracao de maquina dependentes da sequencia deproducao. O objetivo e determinar a sequenciana qual as tarefas serao processadas numa deter-minada maquina, durante um perıodo de tempo,e o momento em que elas serao processadas, demodo a minimizar os custos por antecipacao ouatraso na entrega. Para a resolucao deste pro-blema, um Algoritmo Genetico Adaptativo e pro-posto. A populacao inicial deste algoritmo e ge-rada aplicando-se a fase de construcao GRASP(Feo and Resende, 1995), tendo como funcao guiacinco regras de despacho (Montevechi et al., 2002):Tardiness Due Date (TDD), Earliest Due Date(EDD), Shortest Processing Time (SPT), WeightShortest Processing Time (WSPT) e Longest Pro-cessing Time (LPT). O cruzamento utiliza ummetodo adaptativo baseado na qualidade dos in-divıduos gerados por cada operador crossover aolongo da evolucao, ou seja, apos um certo numerode geracoes (no caso, cinco), o fator de escolha

do operador a ser aplicado e atualizado de acordocom a qualidade dos indivıduos formados por cadaum deles nas geracoes anteriores.A populacao so-brevivente e composta pelos cinco melhores indivı-duos refinados desses operadores, pelo melhor in-divıduo encontrado ate entao e por 89 indivıduosescolhidos por elitismo. Outros cinco indivıduossao escolhidos aleatoriamente da geracao correntee submetidos a mutacao, por meio de troca en-tre duas tarefas, para assegurar a diversidade dapopulacao. A populacao evolui ate que o criteriode parada seja atingido. A Reconexao por Ca-minhos (Glover, 1996) e tambem aplicada a cadacinco geracoes, e foi implementada caminhando-sedo melhor indivıduo produzido pelo algoritmo ateentao em direcao ao melhor indivıduo produzidopor cada operador crossover. O restante deste tra-balho esta estruturado como segue. Na Secao 2 efeita uma breve apresentacao de trabalhos relaci-onados. As caracterısticas do problema estudadosao detalhadas na Secao 3. Na Secao 4 e descrito oAlgoritmo Genetico Adaptativo desenvolvido pararesolucao do PSUMAA abordado. Na Secao 5 saoapresentados e discutidos os resultados computa-cionais. A Secao 6 conclui o trabalho.

2 Trabalhos relacionados

O PSUMAA pertence a classe de problemas NP-difıceis, uma vez que uma versao simplificada dele,o problema de sequenciamento que tem o atraso

total como criterio de otimizacao, e NP-difıcil (Duand Leung, 1990).(Lee and Choi, 1995) usaram Al-goritmos Geneticos (AG) para a resolucao do pro-blema com datas de entrega distintas. Esses au-tores desenvolveram um algoritmo especıfico, decomplexidade polinomial, para determinar a dataotima de conclusao de processamento de cada ta-refa da sequencia produzida pelo AG. (Wan andYen, 2002) trataram o PSUMAA considerando ja-nelas de entrega, ao inves de datas de entrega.Em (Gomes Jr. et al., 2007) trata-se o PSUMAAmais generico, considerando alem das janelas deentrega, tambem tempos de setup dependentesda sequencia. Esses ultimos autores desenvolve-ram uma formulacao de programacao matematicapara o problema, bem como um algoritmo heurıs-tico para resolver problemas-teste de dimensoesmais elevadas. Segundo (Matias, 2008), o con-trole dos parametros e operadores dos AlgoritmosGeneticos durante a sua execucao e de fundamen-tal importancia, pois permite um ajuste automa-tico em tempo de execucao. Este autor proposuma tecnica de adaptacao automatica dos prin-cipais operadores dos Algoritmos Geneticos base-ada no desempenho do algoritmo e na distribuicaodos indivıduos da populacao no espaco de busca.A tecnica estudada permite ao Algoritmo Gene-tico ajustar o valor dos operadores, de forma aprivilegiar aqueles que podem produzir resultadosmelhores em um determinado momento da busca.

3 Problema de sequenciamento abordado

O problema objeto deste trabalho e o de sequenci-amento em uma maquina (PSUMAA), com tempode preparacao dependente da sequencia de produ-cao e janelas de entrega. Considera-se que umamaquina deve processar um conjunto de n tarefase que cada tarefa possui um tempo de processa-mento Pi, uma data inicial Ei e uma data final Ti,desejadas para o termino do processamento. Alemdisso, a maquina executa no maximo uma tarefapor vez e, uma vez iniciado o processamento deuma tarefa, a mesma devera ser finalizada, naosendo permitida a interrupcao do processamento.Admite-se que todas as tarefas estejam disponı-veis para processamento na data 0. Considera-se,tambem, que quando uma tarefa j e sequenciadaimediatamente apos uma tarefa i, sendo estas per-tencentes a diferentes famılias de produtos, e ne-cessario um tempo Sij para a preparacao da ma-quina. Tempos de preparacao de maquina nulos(Sij = 0) levam a produtos da mesma famılia.

Considera-se, ainda, que a maquina nao ne-cessita de tempo de preparacao inicial. Permite-se, neste trabalho, tempo ocioso entre a execu-cao de duas tarefas consecutivas. Considera-se,alem disso, que tarefas devem ser finalizadas den-tro da janela de tempo [Ei, Ti], denominada janelade entrega. Caso a tarefa seja finalizada antes deEi, ha, entao, uma penalizacao por antecipacao.

Caso a tarefa seja finalizada apos Ti, entao ocor-rera uma penalizacao por atraso. As tarefas queforem finalizadas dentro da janela de entrega naoproporcionarao nenhum custo. Por fim, admite-seque custos unitarios por antecipacao e atraso daproducao sejam dependentes das tarefas, ou seja,cada tarefa i possui um custo unitario de anteci-pacao αi e um custo unitario de atraso βi. O ob-jetivo do problema e a minimizacao do somatoriodos custos de antecipacao e atraso da producao.

4 Metodologia heurıstica

4.1 Representacao de um indivıduo

Um indivıduo (sequencia de tarefas) e represen-tado por um vetor v de n genes (tarefas). A po-sicao de cada gene indica sua ordem de producao.Por exemplo, no indivıduo v = {7, 1, 5, 6, 4, 3, 2},a tarefa 7 e a primeira a ser processada e a tarefa2, a ultima.

4.2 Avaliacao dos indivıduos

Todos os indivıduos da populacao sao avaliadospela propria funcao objetivo do problema, dadapela equacao (1), onde sao considerados maisadaptados aqueles que obtiverem o menor valor.

min Z =

n∑

i=1

(αiei + βiti) ; (1)

4.3 Construcao de uma populacao inicial

A populacao inicial do Algoritmo Genetico Adap-tativo (AGA) proposto e gerada aplicando-se afase de construcao GRASP (Feo and Resende,1995), tendo como funcao guia cinco regras de des-pacho (EDD, TDD, SPT, WSPT e LPT). Paracada construcao (GRASP + Regra de despacho)sao gerados 200 indivıduos. Em seguida, estes saoordenados, do melhor para o pior segundo a fun-cao de avaliacao. A populacao inicial e, entao,composta pelos 100 melhores indivıduos gerados.

4.3.1 Regras de despacho

Na regra de despacho EDD, as tarefas sao orde-nadas tendo em vista a data de inıcio da janela deentrega. As tarefas com datas de inıcio mais pro-ximas sao processadas antes daquelas com datasde inıcio maiores. Pela regra de despacho TDD, astarefas tambem sao ordenadas com base na datade inıcio da janela de entrega, porem, aquelas comdatas de inıcio mais tardias sao processadas antesdaquelas com datas de inıcio mais cedo. A regrade despacho SPT constroi a sequencia de tarefasordenando-as de modo que a tarefa com tempo deprocessamento mais curto seja processada antesdaquela com tempo de processamento mais longo.Na regra WSPT utiliza-se basicamente a mesmalogica do SPT, porem, levando-se em consideracaoum peso que e atribuıdo a cada tarefa, em funcaoda sua prioridade de atendimento. As tarefas sao,entao, ordenadas a partir da ordem crescente pon-derada da razao entre os tempos de processamento

e a sua prioridade de processamento. Finalmente,a regra de despacho LPT elabora a sequencia detarefas, criando uma ordem tal que a tarefa comtempo de processamento mais longo seja proces-sada antes daquela com o tempo de processamentomais curto, ou seja, as tarefas com processamentomais longo sao as primeiros a serem processadas.A escolha dessas regras e associada ao seu baixocusto computacional (Montevechi et al., 2002).

4.3.2 Fase de construcao GRASP

O procedimento de construcao segue as ideias dafase de construcao do algoritmo GRASP (Feo andResende, 1995). Neste procedimento, um indivı-duo e formado gene a gene, de acordo com umcriterio g de selecao. Para estimar o benefıcio dainsercao de cada gene (tarefa), utiliza-se uma dasregras de despacho descritas na secao anterior, re-gra essa que e escolhida de forma aleatoria, mase fixa durante toda a construcao. A cada inser-cao, os proximos genes candidatos a formarem oindivıduo sao colocados em uma lista de candida-tos, respeitando o criterio de selecao. Os melho-res candidatos sao, entao, colocados em uma ListaRestrita de Candidatos (LRC). A seguir, um des-ses candidatos e escolhido randomicamente e colo-cado no indivıduo em construcao. O procedimentoe encerrado quando todos os genes sao alocados,situacao na qual o indivıduo esta completamenteformado. Um parametro γ, 0 ≤ γ ≤ 1, e utili-

Algoritmo AGA(maxger,numind,aaa );1 t← 0;2 Gere a populacao inicial P (t);3 Avalie P (t);4 enquanto (t ≤ maxger) faca5 t← t + 1;6 Gere P (t) a partir de P (t− 1);7 enquanto (i ≤ numind) faca8 i← 1;9 cross ←Numero aleatorio ate 100;10 se (cross ≤ probcrossover) faca11 Selecionar indivıduo;12 Cruzar;13 fim-se;14 Avaliar P (t);15 fim-enquanto (i ≤ numind) faca16 Definir a populacao sobrevivente;17 se (t mod 5 = 0) faca18 Atualizar probabilidade de escolha

de cada operador (p(Oi));19 Executar Busca local;20 Aplicar Reconexao por Caminhos;21 fim-se;22 fim-enquanto;fim AGA;

Figura 1: Pseudocodigo do Algoritmo GeneticoAdaptativo

zado para controlar o tamanho da LRC. Empirica-mente, foram gerados preliminarmente 10.000 in-divı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 en-volvendo 20 tarefas e as cinco regras de despa-cho, cada qual escolhida aleatoriamente em cadaexecucao, o melhor comportamento foi observadopara γ = 0, 20.

4.4 Algoritmo genetico adaptativo aplicado aoPSUMAA

A Figura 1 apresenta o pseudocodigo do Algo-ritmo Genetico Adaptativo (AGA) proposto. Asfases desse algoritmo sao, a seguir, detalhadas.

Metodo de selecao de indivıduos Apos aavaliacao de toda a populacao, os indivıduos saoselecionados por meio do metodo da roleta, cujoprincipal objetivo e permitir que os indivıduosmais adaptados tenham maior probabilidade deserem selecionados. Para este problema, a apti-dao dos indivıduos (fitness) e uma funcao lineardecrescente com relacao a funcao de avaliacao.

Cruzamento Apos a avaliacao de toda a po-pulacao, os indivıduos sao selecionados para re-producao atraves do metodo de selecao de indivı-duos ja descrito. Os operadores crossover utili-zados sao o One Point Crossover (OX), o Simi-lar Job Order Crossover (SJOX), o Relative JobOrder Crossover (RRX), o Based Order UniformCrossover (BOUX) e o Partially Mapped Crosso-ver (PMX) por apresentarem alta eficiencia parao PSUMAA (Lee and Choi, 1995). A probabili-dade de escolha de um operador crossover especı-fico varia de acordo com a qualidade das solucoesproduzidas em geracoes passadas. Assim, sejamOi, i = 1, · · · , 5, os cinco operadores crossover.Inicialmente, cada operador crossover Oi tem amesma probabilidade de ser escolhido, no caso,p(Oi) = 1/5. Seja f(s∗) a melhor solucao encon-trada ate entao e Ai o valor medio das solucoesencontradas por cada operador Oi desde a ultimaatualizacao. Caso o operador nao tenha sido esco-lhido nas ultimas cinco geracoes, faz-se Ai = 1.Seja qi = f(s∗) = Ai e p(Oi) = qi/

∑5j=1 qj ,

i = 1, · · · , 5. Observe que quanto melhor a so-lucao, maior o valor de qi e, portanto, maior aprobabilidade p(Oi) de se escolher o operador Oi.Logo, durante a evolucao do algoritmo, o melhoroperador tem sua chance de escolha incrementada.Este procedimento foi inspirado no algoritmo Re-active GRASP (Prais and Ribeiro, 2000).

Busca Local O metodo de busca local aplicadoe a Descida Randomica, que utiliza dois tipos demovimento para explorar o espaco de busca: atroca da ordem de processamento de duas tare-fas da sequencia de producao e a realocacao deuma tarefa para outra posicao na sequencia deproducao. Para uma dada solucao, seleciona-se

aleatoriamente duas tarefas, trocando-as de posi-cao. Se esse novo vizinho for melhor que o an-terior segundo a funcao de avaliacao, ele e aceitoe passa a ser a solucao corrente; caso contrario,outro vizinho e escolhido aleatoriamente. Se du-rante MRDmax nenhuma melhor solucao for ge-rada, entao passa-se a usar movimentos de realo-cacao. Havendo melhora com este tipo de movi-mento, retorna-se a utilizacao de movimentos detroca; caso contrario, encerra-se a busca local de-corridas MRDmax iteracoes sem melhora. Essemetodo foi escolhido por apresentar alta eficienciacomputacional, pois nao requer a exploracao detoda a vizinhanca (Mladenovic and Hansen, 1997).Reconexao por Caminhos A Reconexao porCaminhos (Path Relinking) e um procedimentoque integra estrategias de intensificacao e diver-sificacao durante o processo de busca (Rossetti,2003). Ele gera novas solucoes explorando traje-torias que ligam solucoes de alta qualidade. Dadoum par de solucoes, comeca-se a busca com umadelas, dita solucao base, e chega-se a outra, ditasolucao guia, adicionando-se gradualmente atribu-tos da solucao guia a solucao base. No problemaem questao, durante o processo evolutivo forma-seum grupo com os cinco melhores indivıduos obti-dos por cada operador crossover. Periodicamente(a cada cinco geracoes), aciona-se a Reconexao porCaminhos, tendo-se, como solucao base, o melhorindivıduo encontrado pelo algoritmo ate entao e,como solucao guia, cada um dos melhores indivı-duos formados por cada operador crossover. Oprocedimento aplicado e a Reconexao por Cami-nhos Regressiva Truncada (Truncated BackwardPath Relinking), no qual interrompe-se a buscaquando 75% dos atributos da solucao guia foreminseridos na solucao base. A escolha deste me-todo e justificada pela sua eficiencia e pelo baixocusto computacional (Rossetti, 2003). Considera-se como atributo a posicao da tarefa na sequen-cia de producao. Para cada tarefa candidata ainsercao, aplica-se o modulo de Busca Local des-crito anteriormente, nao permitindo a movimen-tacao da tarefa candidata. A tarefa efetivamenteinserida e aquela que produzir o melhor valor paraa funcao de avaliacao.Sobrevivencia de indivıduos A populacaosobrevivente e composta por indivıduos maisadaptados, selecionados por elitismo, pela melhorsolucao gerada por cada um dos operadores cros-sover e pela melhor solucao produzida pela me-todo ate entao.Criterio de parada Como criterio de parada,adota-se o numero maximo de geracoes.

5 Resultados computacionais

O Algoritmo Genetico Adaptativo proposto foiimplementado em linguagem C, utilizando o am-biente C++ Builder 5. Seus parametros sao apre-sentados na Tabela 1. Os testes computacio-nais foram realizados em um computador Pentium

Core 2 Duo 2,1 GHz, com 4 GB de memoria RAM,sob plataforma Windows Vista. Os problemas-teste utilizados sao os de (Gomes Jr. et al., 2007)e envolvem numero de tarefas n igual a 8, 9, 10, 11,12, 15, 20, 25, 30, 40, 50 e 75. Sao 12 problemas-teste para cada numero de tarefas, totalizando 144problemas-teste. Cada problema-teste foi resol-vido 30 vezes pelo metodo proposto, com exce-cao daqueles envolvendo 75 tarefas, os quais fo-ram resolvidos apenas 20 vezes, tendo MRDmax= 2 × n, por demandar maior tempo computa-cional. A Tabela 2 mostra os resultados obtidos

Tabela 1: Parametros do AGAParametros Valores

Parametro γ construcao GRASP 0,20

Iteracoes da Busca Local (MRDmax) 7× n

Geracoes do AG Adaptativo (maxger) 100

Probabilidade de cruzamento 80%

Taxa de mutacao 5%

para o AGA, bem como reproduz os de (Gomes Jr.et al., 2007), por apresentar os melhores resultadospara este tipo de problema ate a presente data. Aprimeira coluna mostra o numero de tarefas en-volvidas; a segunda e terceira colunas mostramo quanto as solucoes medias de cada algoritmo(AGA e (Gomes Jr. et al., 2007), respectivamente)desviaram da melhor solucao conhecida referentea cada problema-teste; nas duas ultimas colunasmostra-se o quanto as melhores solucoes geradaspor tais algoritmos desviaram das melhores solu-coes conhecidas. O Desvio e calculado pela ex-pressao Desvio = (RMed−MR)/MR, sendo RMedo resultado medio obtido pela aplicacao do respec-tivo algoritmo e MR e o melhor resultado conhe-cido de cada problema-teste.

Nas tabelas 3, 4, 5 e 6 sao apresentados os re-sultados detalhados para os problemas-teste comnumero de tarefas iguais a 12, 15, 20, 25, 30, 40,50 e 75 tarefas. A coluna “Instancia” apresenta onumero do problema-teste testado; a coluna“GAP(%)” apresenta o desvio medio em relacao as solu-coes medias; a coluna “GAP MS (%)” apresenta odesvio medio em relacao a melhor solucao conhe-cida para o problema.

Tabela 2: Resultados do AGA# Desvio sol. media Desvio solucao

Tarefas AGA Gomes Jr. AGA Gomes Jr.

8 0,00 0,03 0,00 0,00

9 0,15 0,06 0,00 0,00

10 0,24 0,02 0,00 0,00

11 0,03 0,12 0,00 0,00

12 0,07 0,21 0,00 0,00

15 0,76 1,47 0,00 0,00

20 0,73 1,65 0,00 0,00

25 1,02 2,32 0,00 0,00

30 1,60 3,34 0,00 -0,20

40 2,15 4,38 0,25 -0,18

50 3,72 6,13 0,60 -0,28

75 4,59 10,89 1,48 -0,56

Para problemas-teste envolvendo acima dedoze tarefas, os desvios das solucoes medias do al-

goritmo proposto foram sempre menores que aque-les de (Gomes Jr. et al., 2007). Este fato mostraa robustez do AGA, uma vez que produz solucoesfinais com uma menor variabilidade. Para proble-mas envolvendo 30 tarefas, o AGA gerou a melhorsolucao conhecida em todas as execucoes, ao passoque no algoritmo de (Gomes Jr. et al., 2007) houveum desvio de 0,20%. Para os problemas-teste en-volvendo 40, 50 e 75 tarefas, o AGA produziu so-lucoes melhores que as de (Gomes Jr. et al., 2007).Para as instancias de 12 e 15 tarefas, apresentadosna Tabela 3, o AGA apresentou um desvio medioem relacao a melhor solucao encontrada 48% me-nor do que o algoritmo de (Gomes Jr. et al., 2007).

Tabela 3: Resultados para 12 e 15 tarefas# GAP (%) GAP MS (%)

Instancia AGA Gomes Jr. AGA Gomes Jr.1201 0,00 0,56 0,00 0,001202 0,07 0,10 0,00 0,001203 0,11 0,21 0,00 0,001204 0,07 0,04 0,00 0,001205 0,00 0,00 0,00 0,001206 0,00 0,00 0,00 0,001207 0,39 0,35 0,00 0,001208 0,00 0,00 0,00 0,001209 0,14 1,25 0,00 0,001210 0,10 0,06 0,00 0,001211 0,00 0,00 0,00 0,001212 0,00 0,00 0,00 0,001501 0,00 0,00 0,00 0,001502 1,10 2,93 0,00 0,001503 0,00 3,89 0,00 0,001504 0,00 0,57 0,00 0,001505 0,00 1,68 0,00 0,001506 0,00 0,28 0,00 0,001507 0,23 0,93 0,00 0,001508 7,53 5,23 0,00 0,001509 0,00 0,00 0,00 0,001510 0,24 1,29 0,00 0,001511 0,00 0,81 0,00 0,001512 0,00 0,00 0,00 0,00

Para as instancias envolvendo 20 e 25 tarefas(Tabela 4), o desvio medio em relacao a melhorsolucao encontrado pelo AGA foi 44% menor queo alcancado por (Gomes Jr. et al., 2007). Eminstancias envolvendo 30 e 40 tarefas (5), o AGAapresentou um ganho medio na melhor solucao de0,13% enquanto (Gomes Jr. et al., 2007) apre-sentou piora de 0,19%. Ja em relacao ao desviomedio da melhor solucao encontrada, o resultadoapresentado pelo AGA foi 48% melhor do que osde (Gomes Jr. et al., 2007). Para as maiores ins-tancias, de 50 e 75 tarefas apresentados na Tabela6, os resultados atingidos pelo AGA foram aindamelhores na comparacao com os de (Gomes Jr.et al., 2007). O percentual medio de melhora foide 0,54%, ao passo que (Gomes Jr. et al., 2007)apresentou piora de 0,42%. O desvio medio emrelacao ao melhor resultado foi de 31%.

6 Conclusoes

Este artigo teve seu foco no PSUMAA consi-derando janelas de entrega e tempo de prepa-


Instancia AGA Gomes Jr. AGA Gomes Jr.2001 0,00 0,00 0,00 0,002002 0,37 3,05 0,00 0,002003 0,32 1,04 0,00 0,002004 0,23 1,14 0,00 0,002005 0,38 0,98 0,00 0,002006 4,74 4,52 0,00 0,002007 1,34 3,87 0,00 0,002008 0,21 0,62 0,00 0,002009 0,33 2,09 0,00 0,002010 0,27 1,09 0,00 0,002011 0,40 0,68 0,00 0,002012 0,20 0,72 0,00 0,002501 0,14 0,36 0,00 0,002502 0,22 0,54 0,00 0,002503 0,00 0,12 0,00 0,002504 0,35 0,55 0,00 0,002505 0,69 2,60 0,00 0,002506 0,02 0,21 0,00 0,002507 0,17 1,46 0,00 0,002508 0,17 1,15 0,00 0,002509 0,00 0,27 0,00 0,002510 5,78 11,20 0,00 0,002511 4,19 6,25 0,00 0,002512 0,53 3,09 0,00 0,00

racao da maquina dependente da sequencia deproducao. Para resolve-lo foi proposto um Al-goritmo Genetico Adaptativo, onde a populacaoinicial foi gerada por um procedimento GRASP,utilizando como funcao guia as regras de despa-cho EDD, TDD, SPT, WSPT e LPT. Duranteo processo evolutivo, a populacao passa pelas fa-ses de selecao, cruzamento e mutacao. No cru-zamento, cinco operadores crossover, OX (OnePoint Crossover), SJOX (Similar Job Order Cros-sover), BOUX (Based Order Uniform Crossove),PMX (Partially Mapped Crossover) e RRX (Re-lative Job Order Crossover), sao utilizados, sendoque a escolha de qual operador sera empregadodepende da qualidade das solucoes produzidas emgeracoes passadas. Periodicamente, as melhoressolucoes produzidas por cada operador crossoversao submetidas a busca local e a Reconexao porCaminhos. O procedimento de Reconexao liga amelhor solucao produzidas ate entao a cada umadas melhores solucoes de cada operador. Paratesta-lo, foram utilizados problemas-teste da lite-ratura e, em seguida, os resultados foram compa-rados com os de (Gomes Jr. et al., 2007). Nosproblemas envolvendo ate 30 tarefas, o algoritmoproposto apresentou solucoes de alta qualidade ecom baixo desvio, sempre atingindo o otimo. Jaem problemas de dimensoes maiores (40 a 75 ta-refas), o algoritmo desenvolvido apresentou solu-coes melhores que as desse algoritmo da literatura,alem de apresentar menor variabilidade das solu-coes finais.


Instancia AGA Gomes Jr. AGA Gomes Jr.3001 0,80 2,53 0,00 0,003002 0,08 0,31 0,00 0,003003 0,47 1,93 0,00 0,003004 2,78 4,92 0,00 0,003005 2,03 2,62 0,00 0,003006 0,64 3,36 0,00 0,003007 0,29 1,40 0,00 0,003008 5,89 6,20 0,00 0,003009 0,00 1,43 0,00 0,003010 2,84 4,56 0,00 0,003011 2,18 8,42 0,00 -2,303012 1,18 2,42 0,00 -0,074001 0,35 1,16 0,00 0,004002 0,28 0,81 0,00 0,004003 0,00 0,67 0,00 0,004004 1,62 2,30 0,04 0,004005 1,27 2,45 0,00 0,004006 1,19 3,41 0,00 0,004007 2,51 7,17 1,48 0,004008 2,16 4,03 0,00 0,004009 3,97 6,77 0,00 0,004010 2,95 4,46 0,39 0,004011 5,51 12,57 1,11 -2,174012 3,93 6,79 0,00 0,00

Agradecimentos

Os autores agradecem ao CEFET-MG, CAPES eFAPERJ.

Referencias

Du, J. and Leung, J. Y. T. (1990). Minimi-zing total tardiness on one machine is np-hard, Mathematics of Operations Research15: 483–495.

Feo, T. A. and Resende, M. G. C. (1995). Gre-edy randomized adaptive search procedures,Journal of Global Optimization 6: 109–133.

Glover, F. (1996). Tabu search and adaptive me-mory programming - advances, applicationsand challenges, in R. S. Barr, R. V. Helga-son and J. L. Kennington (eds), ComputingTools for Modeling, Optimization and Simu-lation: Interfaces in Computer Science andOperations Research, Kluwer Academic Pu-blishers, pp. 1–75.

Gomes Jr., A. C., Carvalho, C. R. V., Mu-nhoz, P. L. A. and Souza, M. J. F. (2007).Um metodo heurıstico hıbrido para resol-ver o problema de sequenciamento em umamaquina com penalidades por antecipacao eatraso, Anais do XXXIX Simposio Brasileirode Pesquisa Operacional, Fortaleza, Brazil,pp. 1649–1660.

Lee, C. Y. and Choi, J. Y. (1995). A genetic algo-rithm for job sequencing problems with dis-


Instancia AGA Gomes Jr. AGA Gomes Jr.5001 3,72 5,34 0,13 -0,895002 3,46 6,00 0,56 -1,985003 0,60 1,59 0,00 0,005004 0,00 4,73 0,00 0,005005 0,62 2,33 0,57 0,005006 0,43 1,93 0,00 0,005007 5,27 8,95 0,00 0,005008 1,10 4,04 0,78 0,005009 4,93 9,46 1,77 -0,025010 5,49 5,44 3,33 -0,455011 7,74 11,70 0,00 0,005012 7,63 12,10 0,00 0,007501 4,48 7,40 0,00 0,007502 2,34 7,01 0,00 0,007503 5,84 7,98 0,52 -3,307504 2,04 4,05 0,00 -0,457505 6,90 12,52 0,00 0,007506 2,16 7,09 0,00 0,067507 5,34 11,19 0,00 0,007508 6,67 16,62 0,00 0,007509 3,36 10,65 5,25 -2,847510 3,99 9,13 0,00 0,007511 12,45 24,03 0,00 0,007512 6,45 13,05 0,00 0,00

tinct due dates and general early-tardy pe-nalty weights, Computers and Operations Re-search 22: 857–869.

Matias, P. T. (2008). Avaliacao comparativa dealgoritmos evolutivos com operadores adap-tativos, Dissertacao de mestrado, Programade Engenharia Civil, UFRJ, Rio de Janeiro.

Mladenovic, N. and Hansen, P. (1997). Variableneighborhood search, Computers and Opera-tions Research 24: 1097–1100.

Montevechi, J. A., Turrioni, J. B., Almeida, A. D.,Mergulhao, R. C. and Leal, F. (2002). Ana-lise comparativa entre regras heurısticas desequenciamento da producao aplicada em JobShop, Produto e Producao 6(2): 12–18.

Prais, M. and Ribeiro, C. C. (2000). An appli-cation to a matrix decomposition problem intdma traffic assignment, INFORMS - Jour-nal on Computing 12: 164–176.

Rossetti, I. C. M. (2003). Estrategias sequenciaise paralelas de GRASP com reconexao por ca-minhos para o problema de sıntese de redesa 2 caminhos, Tese de doutorado, Programade Pos-Graduacao em Informatica, PUC-RJ,Rio de Janeiro, Brasil.

Wan, G. and Yen, B. P. C. (2002). Tabu search forsingle machine scheduling with distinct duewindows and weighted earliness/tardiness pe-nalties, European Journal of Operational Re-search 142: 271–281.

PRINCIPIO DA OTIMALIDADE PROXIMA APLICADO AO PROBLEMA DESEQUENCIAMENTO DE TAREFAS EM UMA MAQUINA COM PENALIDADES

POR ANTECIPACAO E ATRASO DA PRODUCAO

Bruno Ferreira Rosa∗, Marcone Jamilson Freitas Souza†, Sergio Ricardo de Souza∗

∗Avenida Amazonas, 7675, CEP 30.510-000Centro Federal de Educacao Tecnologica de Minas Gerais

Belo Horizonte, Minas Gerais, Brasil†ICEB, Campus Universitario, CEP 35.400-000

Universidade Federal de Ouro PretoOuro Preto, Minas Gerais, Brasil

Emails: [email protected], [email protected], [email protected]

Abstract— This work deals with the single machine scheduling problem where a sequence-dependent setuptime is required for the changeover job. In the considered problem, each job has a time window in which thejob 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, ProximateOptimality Principle and Variable Neighborhood Descent to solve it. Computational experiments performed ina set of instances of the literature suggest that the proposed algorithm is able to find good solutions and withlow average divergence.

Keywords— Scheduling single machine, GRASP, Proximate Optimality Principle.

Resumo— Este trabalho trata do problema de sequenciamento em uma maquina, no qual ha um tempo depreparacao dependente da sequencia de producao. No problema abordado, cada tarefa possui uma janela detempo, dentro da qual ela deve ser preferencialmente concluıda. O objetivo e minimizar a soma ponderada dosatrasos e antecipacoes. E proposto um modelo matematico para o problema e tambem um algoritmo heurısticobaseado em GRASP, Princıpio da Otimalidade Proxima e Busca em Vizinhanca Variavel para resolve-lo. Ex-perimentos computacionais realizados em um conjunto de problemas-teste da literatura sugerem que o algoritmoproposto e capaz de encontrar boas solucoes e com baixo desvio medio.

Keywords— Sequenciamento uma maquina, GRASP, Princıpio da Otimalidade Proxima.

1 Introducao

O problema de sequenciamento de tarefas emuma maquina com penalidades por antecipacao eatraso da producao (PSUMAA) consiste em se-quenciar e determinar o momento em que as tare-fas devem ser executas em uma maquina, com oobjetivo de minimizar a soma ponderada das ante-cipacoes e dos atrasos na producao de tais tarefas.Ha antecipacao de uma tarefa quando ela e con-cluıda antes da data desejada para sua entrega eha atraso quando ela e concluıda apos esta data.Em ambas as situacoes sao geradas penalidades.

Segundo Liaw (1999), concluir uma tarefacom atraso pode resultar em multas contratuais,perda de credibilidade da empresa e reducao devendas. Do mesmo modo, concluir uma tarefaantecipadamente pode resultar em custos finan-ceiros extras, pela necessidade de disponibilizarantecipadamente capital, necessidade de espacopara armazenamento ou necessidade de outros re-cursos para manter e gerenciar o estoque (FrancaFilho, 2007).

Com relacao as datas de entrega das tarefas,um caso pouco explorado na literatura e aquele noqual se considera janelas de entrega distintas (dis-tinct due windows). Isto e, ha um determinadoperıodo de tempo associado a cada tarefa, dentro

do qual a tarefa deve ser preferencialmente con-cluıda. Segundo (Wan and Yen, 2002), este casoocorre quando existe tolerancia em torno da datadesejada para a entrega de cada tarefa.

Em um grande numero de aplicacoes doPSUMAA, apos a conclusao de uma tarefa enecessario preparar a maquina para a execucaoda tarefa seguinte (Allahverdi et al., 1999). Istoocorre em industrias que produzem diferentestipos de produtos e em que existe uma troca fre-quente do tipo de tarefa executada na maquina.Este tempo de preparacao (ou tempo de setup)inclui os tempos gastos para trocar as ferramen-tas, preparar o material, limpar a maquina, etc. Amaioria dos trabalhos em problemas de sequencia-mento assume que tais tempos sao independentesda sequencia de producao, isto e, que eles sao des-prezıveis ou podem ser acrescentados aos temposde processamento das tarefas. No entanto, emgrande parte das situacoes praticas, esses tempossao dependentes da sequencia de producao (Guptaand Smith, 2006).

Alguns trabalhos da literatura permitem a in-sercao de tempos ociosos na sequencia de pro-ducao. De acordo com Li (1997), existem casosem que o custo por manter a maquina inativa emais alto que o preco pago pela antecipacao deuma tarefa e, neste caso, vale a pena antecipar

a producao. Outra situacao em que isto ocorree quando a capacidade da maquina e inferior ademanda. No entanto, ha casos em que vale apena manter a maquina parada, mesmo que existauma tarefa disponıvel para ser processada (FrancaFilho, 2007).

O PSUMAA possui muitas aplicacoes prati-cas em industrias metalurgicas, texteis, de tintas,dentre outras. Associado a este grande leque deaplicacoes esta a dificuldade de resolve-lo de formaotima, dado que se trata de um problema NP-difıcil (Allahverdi et al., 1999). Esta uniao entreaplicabilidade e dificuldade de resolucao motivao desenvolvimento de algoritmos eficientes pararesolve-lo.

No presente trabalho e estudado o PSUMAAem sua forma mais generica, isto e, com janelasde entrega distintas, penalidades por atraso e an-tecipacao das tarefas diferentes, tempo de setupdependente da sequencia de producao, sendo per-mitidos tempos ociosos entre as execucoes de tare-fas consecutivas. Esse problema, com todas ascaracterısticas apontadas, tem sido pouco explo-rado na literatura. Destacam-se os trabalhos deGomes Junior et al. (2007) e Souza et al. (2008).No primeiro trabalho, e proposto um modelo deProgramacao Inteira Mista (PLIM) para represen-tar o problema, bem como um algoritmo heurıs-tico baseado em GRASP, Iterated Local Searche Variable Neighborhood Descent - VND. Paracada sequencia de tarefas gerada por esse algo-ritmo, e acionado um procedimento de complex-idade polinomial para determinar a data otimade inıcio de processamento das tarefas na sequen-cia dada, sendo este procedimento uma extensaodaquele proposto por Wan and Yen (2002). Nosegundo trabalho e proposto um algoritmo heurıs-tico baseado em GRASP, VND, Busca Tabu eReconexao por Caminhos. Outros trabalhos cu-jas caracterısticas se aproximam sao os de Wanand Yen (2002), mas que nao consideram a e-xistencia de tempos de preparacao da maquinadependente da sequencia, e o de Bustamante(2007). Este ultimo nao considera a existenciade janelas de entrega. A formulacao de progra-macao matematica proposta tambem exige que ostempos de preparacao satisfacam a desigualdadetriangular.

O presente trabalho inclui a apresentacao deum novo modelo de PLIM para representar oproblema e tambem de um algoritmo heurısticobaseado em GRASP (Feo and Resende, 1995),Princıpio da Otimalidade Proxima - POP (Gloverand Laguna, 1997) e VND (Mladenovic andHansen, 1997) para resolve-lo.

O restante deste trabalho esta organizado doseguinte modo. Na Secao 2, e feita uma descricaodetalhada do problema estudado, enquanto, naSecao 3, e apresentada uma formulacao de progra-macao matematica para representar tal problema.

Na Secao 4 e descrito o algoritmo heurıstico desen-volvido para resolve-lo. Na Secao 5 sao apresenta-dos e discutidos os resultados computacionais. ASecao 6 conclui o trabalho.

2 Descricao do problema

O PSUMAA abordado neste trabalho possui asseguintes caracterısticas: (i) Uma maquina deveprocessar um conjunto I de n tarefas; (ii) A cadatarefa i ∈ I esta associado um tempo de proces-samento Pi, uma janela de entrega [Ei, Ti], den-tro da qual a tarefa i deve ser preferencialmenteconcluıda, um custo αi por unidade de tempo deantecipacao e um custo βi por unidade de tempode atraso. Ha antecipacao de uma tarefa i ∈ Iquando seu processamento e concluıdo antes de Ei

e ha atraso quando seu processamento e concluıdodepois de Ti; (iii) As tarefas que forem concluıdasdentro de suas respectivas janelas de entrega naogeram custo; (iv) A maquina executa no maximouma tarefa por vez e, uma vez iniciado o processa-mento de uma tarefa, nao e permitida a sua inter-rupcao; (v) Todas as tarefas estao disponıveis paraprocessamento na data 0; (vi) Entre duas tarefasi e j consecutivas e necessario um tempo Sij depreparacao da maquina, chamado tempo de setup;(vii) Assume-se que o tempo de preparacao damaquina para o processamento da primeira tarefana sequencia e igual a 0; (viii) E permitido tempoocioso entre a execucao de duas tarefas consecuti-vas.

O objetivo e determinar a sequencia de pro-ducao e as datas de inıcio de producao das tarefas,de forma a minimizar a soma ponderada das an-tecipacoes e dos atrasos.

3 Modelo matematico

O modelo de Programacao Linear Inteira Mista(PLIM) apresentado a seguir e baseado naqueleproposto por Gomes Junior et al. (2007). Para suaapresentacao, sejam si, ei e ti a data de inıcio doprocessamento, o tempo de antecipacao e o tempode atraso da tarefa i ∈ I, respectivamente. A con-trario de Gomes Junior et al. (2007), e utilizadaapenas uma tarefa fictıcia, 0 (zero), para auxiliarna modelagem. A tarefa 0 e sequenciada duasvezes, sendo uma necessariamente na primeira eoutra na ultima posicao. Considera-se que P0 = 0e que S0i = Si0 = 0, ∀ i ∈ I. Deste modo, se com-parado ao modelo daqueles autores, ha reducao de2n+3 variaveis e n+1 restricoes, com n represen-tando o numero de tarefas a serem sequenciadas.

Sejam yij variaveis que determinam a sequen-cia de producao, sendo yij = 1 se a tarefa j for se-quenciada imediatamente apos a tarefa i e yij = 0,caso contrario, ∀ i, j ∈ I ∪ {0} e i 6= j. Considere,ainda, uma constante M de valor suficientemente

min Z =n∑

i=1

(αiei + βiti) (1)

s.a. si + Pi + yij(M + Sij)−M ≤ sj ∀ i ∈ I ∪ {0}, ∀ j ∈ I e i 6= j (2)n∑

j=0, j 6=i

yij = 1 ∀ i ∈ I ∪ {0} (3)

n∑

i=0, i 6=j

yij = 1 ∀ j ∈ I ∪ {0} (4)

si + Pi + ei ≥ Ei ∀ i ∈ I (5)si + Pi − ti ≤ Ti ∀ i ∈ I (6)

si ≥ 0 ∀ i ∈ I ∪ {0} (7)ei ≥ 0 ∀ i ∈ I (8)ti ≥ 0 ∀ i ∈ I (9)

yij ∈ {0, 1} ∀ i, j ∈ I ∪ {0} e i 6= j (10)

A funcao objetivo, representada pela equacao(1), busca a minimizacao da soma ponderada dasantecipacoes e atrasos. As restricoes (2) garan-tem que existe tempo suficiente para executar umatarefa i antes do inıcio da tarefa seguinte j, ouseja, elas garantem que o processamento da tarefaj nao sera iniciado antes do termino do processa-mento da tarefa i. As restricoes (3) e (4) garantemque cada tarefa tera apenas uma tarefa imediata-mente sucessora e uma tarefa imediatamente an-tecessora, respectivamente. As restricoes (5) e (6)definem as antecipacoes e os atrasos, de acordocom as respectivas janelas de entrega de cadatarefa. As restricoes (7), (8), (9) e (10) dizemrespeito ao tipo de variaveis.

4 Algoritmo proposto

O algoritmo heurıstico proposto, denotado porGPV, combina os procedimentos GRASP (Feoand Resende, 1995), Princıpio da OtimalidadeProxima - POP (Glover and Laguna, 1997) e VND(Mladenovic and Hansen, 1997). A Figura 1 ap-resenta seu pseudocodigo.

Algoritmo GPV()1 f? ←∞;2 Iter ← 0;3 enquanto (Iter < GRASPMax) faca

4 Iter ← Iter + 1;5 v0 ← ConstruaSolucao();6 v ← VND1(v0);7 se (f(v) < f?) entao8 v? ← v;9 f? ← f(v);10 Iter ← 0;11 fim-se;12 fim-enquanto;

13 v? ← VND2(v?);

14 Retorne v?;fim GPV

Figura 1: Algoritmo GPV

Ha duas fases neste algoritmo. A primeira(linhas 1 a 12 da Fig. 1) gera uma solucao com

base na metaheurıstica GRASP. A segunda (linha13) consiste em um pos-refinamento da solucaoproveniente da fase anterior. Seu detalhamento eapresentado nas subsecoes seguintes.

4.1 Representacao de uma solucao

Uma solucao (sequencia) para o PSUMAA den tarefas e representada por um vetor v de nposicoes, em que cada posicao i = 1, 2, · · · , n in-dica a ordem de producao da tarefa vi. Por exem-plo, dada a sequencia v = {5, 3, 2, 1, 4, 6}, a tarefa5 e a primeira a ser realizada e a tarefa 6 a ultima.

4.2 Vizinhanca de uma solucao

Para explorar o espaco de solucoes sao usados trestipos de movimentos: troca da ordem de processa-mento de duas tarefas da sequencia de producao,realocacao de uma tarefa para outra posicao dasequencia e realocacao de um bloco com duas oumais tarefas. Esses movimentos definem, respec-tivamente, as vizinhancas NT , NR e NRB .

4.3 Funcao de avaliacao

Como os movimentos utilizados nao geramsolucoes inviaveis, uma sequencia e avaliada pelapropria funcao objetivo, dada pela expressao (1)do modelo de PLIM. Para determinar os valoresde ei e ti, e utilizado o algoritmo de determinacaodas datas otimas de inıcio de processamento (AD-DOIP) proposto por Gomes Junior et al. (2007).

4.4 Construcao de uma solucao

Nesta etapa da primeira fase do algoritmo (linha5 da Fig. 1), uma solucao e formada, tarefa portarefa, de forma parcialmente gulosa, seguindo asideias da fase de construcao do algoritmo GRASP.A cada iteracao desta fase, as tarefas que ainda es-tao fora da solucao sao avaliadas por uma funcaog, que estima o benefıcio associado a sua inclusaona solucao parcial. As tarefas j, que possuemg(j) menor ou igual a gmin + γ(gmax − gmin),γ ∈ [0, 1], sao inseridas em uma Lista Restrita de

Candidatos (LRC). Desta lista e escolhida aleato-riamente uma, a qual e adicionada a solucao par-cial.

Para estimar o benefıcio da insercao de cadatarefa j ainda nao sequenciada, em cada iteracaoi, utiliza-se uma das 4 seguintes funcoes comocriterio de selecao: (1) g1(j) = 2Ej/ max{Ek | k ∈Fi} + 2Tj/ max{Tk | k ∈ Fi} + αj/ max{αk | k ∈Fi} − βj/ max{βk | k ∈ Fi} + Pj/ max{Pk | k ∈Fi} + Si−1,j/ max{Si−1,k | k ∈ Fi}, em que Fi

representa o conjunto das tarefas ainda nao se-quenciadas ate a i-esima iteracao (para i = 1, nolugar de Si−1,j/ max{Si−1,k | k ∈ Fi} e utilizado−media{Skj | k ∈ I e k 6= j}/ max{Skl | k, l ∈I e k 6= l}); (2) g2(j) = Tj ; (3) g3(j) = (αjEj +βjTj)/(αj + βj); (4) g4(j) = Ej .

As funcoes g’s sao utilizadas seguindo-se a or-dem anterior. Nas quatro primeiras iteracoes, ouseja, na primeira vez em que cada funcao g e uti-lizada, faz-se γ = 0. Nas demais iteracoes, γ eselecionado aleatoriamente dentro de um conjuntoΓ, onde Γ e um parametro do metodo.

4.5 POP aplicado ao PSUMAA

Durante a etapa de construcao e aplicado o Princı-pio da Otimalidade Proxima (POP). Este princı-pio e baseado na ideia de que boas solucoes emum nıvel estao proximas de boas solucoes em umnıvel adjacente (Glover and Laguna, 1997). As-sim, antes de se inserir uma nova tarefa na solucaoem formacao, esta e submetida a uma busca local.

A busca local utilizada consiste em uma des-cida randomica em relacao a vizinhanca NR.Dada uma solucao, aleatoriamente escolhe-se umatarefa na sequencia e uma nova posicao para ela.Se a nova sequencia produzir uma solucao com umvalor menor para a funcao objetivo, a nova sequen-cia e aceita e passa a ser a solucao corrente; casocontrario, e testada outra realocacao. A busca einterrompida apos MRDMax realocacoes consecu-tivas sem melhora na funcao objetivo.

4.6 VND1

Na etapa de busca local da primeira fase do al-goritmo (linha 6 da Figura 1), utiliza-se a Buscaem Vizinhanca Variavel (Variable NeighborhoodDescent - VND). Proposto por Mladenovic andHansen (1997), o VND e um metodo de busca lo-cal que consiste em explorar o espaco de buscaatraves de trocas sistematicas de estruturas de vi-zinhancas. Basicamente o procedimento utilizadoconsiste em tres passos: (1) metodo randomicode descida (MRD) com a vizinhanca NT ; (2)MRD com a vizinhanca NR; (3) MRD com a vi-zinhanca NRB . Cada passo e constituido de ite-racoes que geram vizinhos aleatorios com relacaoa respectiva estrutura de vizinhanca. Sempre queuma solucao de melhora e encontrada, volta-se aoprimeiro passo. Quando um dos MRD’s atingeMRDmax iteracoes sem melhora, passa-se para o

passo seguinte. Estando-se no ultimo passo, entaoo procedimento e interrompido e a melhor solucaoencontrada e retornada.

4.7 VND2

Como a solucao proveniente da primeira fase doalgoritmo GPV (linhas 1-12 da Figura 1) nao enecessariamente um otimo local com relacao as vi-zinhancas adotadas, ela e submetida a uma buscalocal mais efetiva, no caso, tambem baseada naBusca em Vizinhanca Variavel (VND2). Nesta,a exploracao do espaco de solucoes e realizadade acordo com os seguintes passos: (1) descidacompleta (DC) com relacao a vizinhanca NT ; (2)DC com relacao a vizinhanca NR; (3) DC na vi-zinhanca NRB . No passo (3), em que sao real-izadas realocacoes de blocos de tarefas, inicial-mente testam-se todas as realocacoes com blocosde duas tarefas possıveis e quando nao for maispossıvel melhorar a solucao com um determinadotamanho de bloco, passa-se a explorar movimen-tos com blocos de tamanho imediatamente maior.Sempre que uma solucao de melhora e encontrada,volta-se ao passo (1). Se em um determinadopasso, todos os vizinhos com relacao a respec-tiva estrutura de vizinhanca nao sao de melhora,passa-se para o passo seguinte. O procedimento einterrompido quando um otimo local com relacaoas tres vizinhancas e encontrado.

5 Resultados computacionais

Foram utilizados para teste os mesmos problemasusados em Gomes Junior et al. (2007). Esta basede dados e constituıda por grupos de problemas-teste de 8 a 75 tarefas e tempos de setup simetri-cos. Cada grupo possui 12 problemas distintosgerados de forma pseudo-aleatoria.

O modelo matematico apresentado na Secao 3foi implementado usando o modelador AMPL e ootimizador CPLEX, versao 10.1, da ILOG. Foramsubmetidos a tal otimizador os problemas com ate12 tarefas, sendo estipulado o limite de 3600 se-gundos para obtencao de cada resultado. Paraos problemas que atingiram esse tempo limite, asolucao encontrada nao e necessariamente otima;porem, e retornado pelo CPLEX um limite infe-rior. Este limite e utilizado para medir a quali-dade da solucao retornada por meio da equacaogapi = (fCPLEX

i − Li)/Li, em que fCPLEXi e Li

representam o valor da solucao e o limite inferiorencontrados pelo otimizador. Deste modo, gapi eigual a zero quando a solucao otima e encontrada.

O algoritmo heurıstico proposto (GPV) foiimplementado em linguagem C usando o ambienteBorland C++ Builder 5. Seus parametros foramcalibrados empiricamente, sendo GRASPMax = 8e MRDMax = 7n para n ≤ 50 e MRDMax = 5npara n = 75. O conjunto Γ utilizado e o mesmode Gomes Junior et al. (2007), ou seja, Γ ={0, 02; 0, 04; 0, 12; 0, 14}. Cada problema-teste foi

executado 30 vezes, exceto aqueles com 75 tarefas,os quais foram executados apenas 10 vezes em vir-tude do maior tempo computacional demandado.

Os resultados obtidos por cada fase do algo-ritmo GPV e pelo algoritmo proposto por GomesJunior et al. (2007) foram comparados por meiodas expressoes impbest

i = (fGJr∗i − fGPV∗

i )/fGJr∗i

(1) e impavgi = (f i − f∗i )/f∗i (2), onde fGJr∗

i e omelhor valor encontrado por Gomes Junior et al.(2007), fGPV∗

i e o melhor valor encontrado pelarespectiva fase do algoritmo proposto, f i e a me-dia dos valores encontrados pela respectiva fasedo algoritmo durante todas as execucoes e f∗i eo valor da funcao objetivo para a melhor solucaoconhecida para o problema-teste i. A expressao(1) mensura o quanto o algoritmo proposto su-perou o melhor resultado encontrado por GomesJunior et al. (2007). Ja a expressao (2) mede avariabilidade media das solucoes encontradas peloalgoritmo em torno da melhor solucao conhecidapara o respectivo problema.

A Tabela 1 apresenta os resultados obti-dos. Nesta tabela, a primeira coluna indica onumero de tarefas em cada grupo. Nas colunas“GPV: Fase 1” sao apresentadas as contribuicoesda primeira fase do algoritmo proposto (linhas 1a 12 da Figura 1), enquanto em “GPV: Fase 2”sao mostradas as contribuicoes relativas a segundafase do algoritmo proposto (linha 13 da Figura 1).Os resultados obtidos pela heurıstica proposta porGomes Junior et al. (2007) sao apresentados nascolunas “Gomes Jr.”. Para um grupo de proble-mas com i tarefas, as colunas “imp

best” apresen-

tam as medias dos impbesti ’s obtidos para os pro-

blemas deste grupo nas respectivas fases do algo-ritmo, as colunas “imp

avg” apresentam as medias

dos impavgi ’s obtidos para os problemas do grupo

nas respectivas fases do algoritmo e as colunas“Tempo” mostram as medias dos tempos (em se-gundos) demandados ate as respectivas fases do al-goritmo. Para os conjuntos de colunas “CPLEX”,a coluna “Tempo” mostra as medias dos tempos(em segundos) demandados por tal otimizador,enquanto a coluna “gap ” mostra as medias dosgapi’s obtidos para os problemas dos respectivosgrupos.

Na Tabela 1 e possıvel observar que o CPLEXfoi capaz de resolver todos os problemas-teste comate 10 tarefas. Para os problemas envolvendo 11e 12 tarefas, este otimizador nao conseguiu en-contrar, dentro do limite de tempo estabelecido,a solucao otima em todos os casos, sendo quepara os problemas-teste com 12 tarefas o gap foide 37,95%. A primeira fase do algoritmo GPVfoi suficiente para encontrar as melhores solucoes,com a variabilidade media de ate 1,60%, em pro-blemas teste com ate 15 tarefas. Para estes pro-blemas, a fase de pos-otimizacao (VND2) reduziua variabilidade media para ate 1,44%. Para osproblemas com ate 12 tarefas, o tempo deman-

dado pelo algoritmo proposto foi muito inferiorao tempo demandado pelo CPLEX, sendo quepara os problemas com 11 tarefas a heurıstica de-mandou um tempo medio de 0,23 segundos, con-tra a media de 2355,90 segundos demandada peloCPLEX. Para os problemas de 20 a 50 tarefas,o algoritmo GPV teve desempenho inferior ao deGomes Junior et al. (2007) em ate 1,06% na mediaem relacao as melhores solucoes encontradas e oimp

avgvariou de 3,08% a 8,01%. Vale observar,

no entanto, que, mesmo sendo testado em umamaquina com menor poder de processamento oalgoritmo GPV demandou menos tempo que o deGomes Junior et al. (2007) nesses grupos de pro-blemas (para o caso com 50 tarefas, esta diferencade tempo e de quase 90%). Apesar de o algoritmoproposto ter demandado uma media de tempoum pouco maior nos problemas com 75 tarefas,em contrapartida, os melhores resultados encon-trados foram, em media, 1,73% melhores. Alemdisso, o imp

avgapresentado para este conjunto foi

de 8,39%, contra 14,10% de Gomes Junior et al.(2007).

6 Conclusoes

Este trabalho tratou o problema de sequencia-mento em uma maquina com penalidades por an-tecipacao e atraso da producao (PSUMAA), con-siderando janelas de entrega distintas e tempo depreparacao da maquina dependente da sequenciade producao. Primeiramente foi proposto um novomodelo matematico para representar o problema,que resultou na reducao de variaveis e restricoesem relacao a um da literatura.

Em seguida, foi proposto tambem um algo-ritmo heurıstico baseado em GRASP, Princıpio daOtimalidade Proxima e Busca em Vizinhanca Var-iavel para determinar a melhor sequencia de pro-ducao. Este algoritmo aciona um procedimento decomplexidade polinomial encontrado na literaturapara determinar as dadas otimas de conclusao dastarefas de cada sequencia gerada.

O otimizador CPLEX 10.1 foi utilizado pararesolver o modelo matematico proposto, sendo omesmo capaz de resolver somente problemas-testecom ate 12 tarefas, mesmo assim, nao em sua to-talidade.

O algoritmo heurıstico desenvolvido foi apli-cado em problemas-teste com ate 75 tarefas. Paraos problemas com ate 12 tarefas, o tempo me-dio demandado pelo algoritmo proposto foi muitomenor que o despendido pelo CPLEX. Para osproblemas com ate 15 tarefas, todas as melhoressolucoes conhecidas foram encontradas e, alemdisso, as medias dos desvios das solucoes finaisem torno das melhores solucoes conhecidas forambaixas. A qualidade das melhores solucoes encon-tradas para os problemas-teste de 20 a 50 tare-fas foram pouco inferiores as de Gomes Junioret al. (2007) e demandaram menor tempo com-

Tabela 1: Comparacao CPLEX × GPV × Gomes Junior et al. (2007).# CPLEX GPV: Fase 1 GPV: Fase 2 Gomes Jr.

Tarefas gap Tempo1 impbest

impavg

Tempo1 impbest

impavg

Tempo1 impavg

Tempo2

(%) (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,07

10 0,00 180,71 0,00 0,04 0,13 0,00 0,04 0,14 0,02 0,11

11 27,80 2355,90 0,00 0,39 0,22 0,00 0,35 0,23 0,12 0,20

12 37,95 2214,73 0,00 0,33 0,31 0,00 0,27 0,32 0,21 0,29

15 - - 0,00 1,60 0,88 0,00 1,44 0,92 1,47 0,94

20 - - -0,06 3,42 3,34 -0,06 3,08 3,51 1,65 4,35

25 - - -0,89 4,22 8,60 -0,89 3,12 9,19 2,32 13,29

30 - - -1,15 7,02 21,85 -0,55 5,01 23,60 3,34 40,07

40 - - -2,40 8,98 75,72 -0,35 5,81 83,84 4,38 155,79

50 - - -4,39 12,45 232,78 -1,06 8,01 261,28 6,20 492,28

75 - - -8,30 19,39 1113,43 1,73 8,39 1448,90 14,10 1368,081AMD Turion(tm) 64 X2 TL-58 1900 MHz, com 2 GB de RAM.

2Athlon XP 64 Bits 3000+ (aproximadamente 2 GHz), com 1 GB de RAM.

putacional, mesmo sendo utilizado um computa-dor de menor poder de processamento. Ja paraos problemas-teste com 75 tarefas, as melhoressolucoes encontradas foram 1,73%, em media,melhores que as daqueles autores. O algoritmoGPV tambem produziu uma media menor paraos desvios das solucoes finais.

Agradecimentos

O primeiro autor agradece ao CEFET-MG pelabolsa de pesquisa e o segundo, a FAPEMIG(Programa Pesquisador Mineiro), ao CNPq (pro-cesso 474831/2007-8) e a FAPERJ (processo E-26/101.023/2007), pelo apoio ao desenvolvimentoda presente pesquisa.

Referencias

Allahverdi, A., Gupta, J. N. and Aldowaisan, T.(1999). A review of scheduling research in-volving setup considerations, Omega: TheInternational Journal of Management Sci-ence 27: 219–239.

Bustamante, L. M. (2007). Minimizacao do custode antecipacao e atraso para o problema desequenciamento de uma maquina com tempode preparacao dependente da sequencia: apli-cacao em uma usina siderurgica., Master’sthesis, UFMG, Belo Horizonte.

Feo, T. A. and Resende, M. G. C. (1995).Greedy randomized adaptive search proce-dures, Journal of Global Optimization 6: 109–133.

Franca Filho, M. F. (2007). GRASP e BuscaTabu aplicados a problemas de programacaode tarefas em maquinas paralelas, PhD the-sis, UNICAMP, Campinas.

Glover, F. and Laguna, M. (1997). Tabu Search,Kluwer Academic Publishers, Boston.

Gomes Junior, A. C., Carvalho, C. R. V., Munhoz,P. L. A. and Souza, M. J. F. (2007). Ummetodo heurıstico hıbrido para a resolucaodo problema de sequenciamento em umamaquina com penalidades por antecipacao eatraso da producao, Anais do XXXIX Simpo-sio Brasileiro de Pesquisa Operacional, SO-BRAPO, pp. 1649–1660.

Gupta, S. R. and Smith, J. S. (2006). Algorithmsfor single machine total tardiness schedulingwith sequence dependent setups, EuropeanJournal of Operational Research 175: 722–739.

Li, G. (1997). Single machine earliness and tardi-ness scheduling, European Joumal of Opera-tional Research 96: 546–558.

Liaw, C.-F. (1999). A branch-and-bound algo-rithm for the single machine earliness andtardiness scheduling problem, Computers &Operations Research 26: 679–693.

Mladenovic, N. and Hansen, P. (1997). Variableneighborhood search, Computers and Opera-tions Research 24(11): 1097–1100.

Souza, M. J. F., Penna, P. H. V. and Goncalves,F. A. C. A. (2008). Grasp, vnd, busca tabu ereconexao por caminhos para o problema desequenciamento em uma maquina com tem-pos de preparacao dependentes da sequenciada producao, janelas de entrega distintas epenalidades por antecipacao e atraso da pro-ducao, Anais do XL Simposio Brasileiro dePesquisa Operacional, pp. 1320–1331.

Wan, G. and Yen, B. P.-C. (2002). Tabu search forsingle machine scheduling with distinct duewindows and weighted earliness/tardinesspenalties, European Journal of OperationalResearch 142: 271–281.

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, 89202-000, 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, 89223-100, Joinville, SC, Brasil

E-mails: [email protected], [email protected], [email protected]

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 il-lustrate 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 im-plementação que soluciona tais problemas. Utiliza-se a abordagem modular local de síntese de supervisores e um problema sim-ples é 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 assu-mido 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 comple-xos. Assim, desenvolver e implementar uma lógica de controle para os sistemas automatizados de manufa-tura atuais não é uma atividade trivial.

A Teoria de Controle Supervisório (TCS) apre-sentada 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 auto-matizados, 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 exten-sõ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 en-tre teoria e prática, neste trabalho apresenta-se uma proposta para a implementação da estrutura de con-trole supervisório em Controladores Lógico Progra-máveis (CLPs). Utiliza-se a abordagem Modular Lo-

cal (Queiroz e Cury, 2000) para a síntese dos super-visores e a implementação em CLP é feita em lingua-gem ladder.

Este tema foi abordado em trabalhos anteriores, dentre os quais se podem citar (Balemi, 1992), (Le-duc, 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 pro-blemas 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 im-plementaçã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 pro-posta 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

2 Considerações sobre a Implementação de Controle Supervisório em CLPs

Na solução de problemas de automação da manufatu-ra por intermédio da TCS modela-se o comportamen-to 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 superviso-res. 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 im-plementação não é trivial e pode levar a alguns pro-blemas, conforme as classes de problemas apresenta-das a seguir (Fabian e Hellgren, 1998).

Causalidade: a TCS assume que todos os even-tos 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 espontaneamen-te 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 even-tos, 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 hou-ver 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 à natu-reza 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 entre-laç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 ge-ração de uma parcela de eventos, a decisão sobre qual será o próximo evento a ser gerado é comparti-lhada 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 im-plementação tem que simultaneamente escolher e transitar; e somente um evento deve ser escolhido”, ou seja, apenas um evento controlável deve ser gera-do 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 var-redura. Assim, pode-se dizer que a comunicação en-tre 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 supervi-sor, 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 (Quei-roz 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

que aquela obtida via solução tradicional, sem a utili-zação da TCS. Assim, se entre dois ciclos de varredu-ra 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 even-tos na planta), aumentando a possibilidade de ocor-rê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 superviso-res é 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 varre-dura todos os eventos não controláveis ocorridos na planta, atualizar os estados dos subsistemas e dos supervisores, definir o conjunto de eventos desabili-tados pelos supervisores, e, finalmente, gerar os e-ventos controláveis habilitados e atualizar os estados dos subsistemas e dos supervisores. A seguir, descre-ve-se em detalhes a metodologia proposta.

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 identi-ficados na leitura das entradas e logo em seguida os supervisores também realizam as transições de esta-dos com os eventos não controláveis. Desta forma se dá prioridade para o tratamento de eventos não con-troláveis, mantendo o sistema produto e os superviso-res em sincronia com a planta.

A partir do estado atual dos supervisores verifi-cam-se quais eventos estão desabilitados pelo conjun-to de supervisores. Assim, da lista de eventos habili-tados se verifica se existe o problema da escolha, havendo esse problema a escolha é feita aleatoria-mente, 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 supervi-sores. 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 uti-lizam-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.

Figura 2. Fluxograma com detalhamento da metodologia.

O fluxograma ilustrado na Figura 2 apresenta de-talhadamente 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 MX (com X = 1,...,6) ligadas por quatro buffers BA, BB, BC e BD, 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.

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

Início

Seta grupo de eventos não controláveis M2 com a informação do grupo M1

Promove as transições de estados do sistema pro-duto com eventos não controláveis ativos em M2

Promove transições de estados em cada supervisor com os eventos não controláveis ativos em M2

Todos os supervisores foram atualizados?

Verifica eventos desabilitados

Seta grupo de eventos não controláveis M2 com a informação do grupo M1

N

S

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

Inicialização dos estados

Trata problema da escolha

Lê entradas e seta grupo M1

4.1 Modelagem da Planta

O comportamento de cada máquina MX (X = 1,..,6) é representado pelo autômato GX da Figura 4. O início de operação é um evento controlável AX, e o final de operação um evento não controlável BX.

Figura 4. Autômato GX, X = 1, ..., 6.

4.2 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 apre-sentados 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 ade-quado (Feng e Wonham, 2006; Reiser et al., 2006) verifica-se que estes supervisores são não-conflitantes e então se tem a garantia de que não exis-te perda de eficiência desta solução em relação à me-lhor solução centralizada (monolítica).

Para facilitar a implementação utilizam-se os su-pervisores reduzidos, ou seja, modelos com um me-nor 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 SRA (Y=1), SRB (Y=3) e SRD (Y=5) e na direita SRC.

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 Sie-mens. 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 blo-co ilustrado no fluxograma da Figura 2. Parte da roti-na 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. Deve-se 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 6. Parte da rotina principal.

O primeiro balão da Figura 7 consiste em um jo-gador 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 jo-gador de autômatos, porém agora com as transições de eventos não controláveis dos supervisores.

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 ba-lão é realizado o tratamento do problema da escolha de eventos controláveis. Esta sub-rotina só deve ser chamada quando necessária.

O quinto balão mostra um jogador de autômatos com os eventos controláveis do sistema produto, as-sim, 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 ocor-rência de um evento não controlável. A função “P” mostrada na Figura 8 garante que o evento não con-trolável será identificado somente no primeiro ciclo de varredura no qual ocorreu a transição do sinal de entrada (borda de subida).

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 G1 (Figura 4) e no supervisor SRA (Figura 5). Esta mesma informação é salva num se-gundo grupo de memórias, chamado aqui de M2, como mostra a Figura 9.

Figura 9. Função “ATUALIZA M2=M1”.

Em um mesmo ciclo de varredura os autômatos podem transitar de estados de acordo com a quanti-dade de eventos não controláveis ocorridos na planta. A informação acerca do estado atual de cada subsis-tema é 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 subsis-temas assíncronos, um evento tratado em um subsis-tema não irá ocorrer em outro, assim não há proble-ma em apagar a informação do evento no momento em que for registrada a sua transição. Já nos supervi-sores, que não são necessariamente assíncronos, pode acontecer de um mesmo evento estar apto a propor-cionar uma transição de estado em mais de um super-visor. 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 sub-rotina “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 ilus-trado 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 superviso-res, como mostrado na Figura 11.

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 estu-do, as máquinas M2 e M4 não podem iniciar ao mes-mo tempo, ou seja, quando o supervisor SRC está no estado 0, os eventos A2 e A3 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 es-colha 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. Pro-põ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” é desabili-tado, garantindo assim uma escolha aleatória.

Figura 12. Função “TRATA ESCOLHA”.

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 proble-ma da escolha envolver mais de um evento, a utiliza-ção de apenas uma memória boleana não será sufici-ente. Neste caso sugere-se a utilização de uma memó-ria numérica para o tratamento do problema.

É importante observar que a metodologia de im-plementação apresentada neste trabalho permite a geração de diversos eventos controláveis num mesmo ciclo de varredura do CLP. Por exemplo, no proble-ma em estudo, o início de operação das máquinas M1 e M3 pode se dar ao mesmo tempo, e assim, ao final de um determinado ciclo de varredura, podem ser gerados os eventos A1 e A3.

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 con-troladores 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 Mo-dular Local para a síntese dos supervisores e a im-plementaçã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 po-de-se comprovar que a metodologia proposta possibi-lita 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 con-trolá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 auto-má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 con-templará as soluções apresentadas no presente traba-

lho. Com esta ferramenta, espera-se contribuir para a diminuição do distanciamento entre teoria e prática existente na área de controle de sistemas automatiza-dos.

Agradecimentos

O segundo autor agradece à FAPESC/CNPq pelo apoio financeiro (Contrato CON04504/2008-7).


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. 2794-2798, 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. 3305-3310.

Feng, L. e Wonham, W. M. (2006) TCT: A Computation Tool for Supervisory Control Synthesis. Proc. of the 8th WODES, pp. 1-6.

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. 103-110.

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):81-98.

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.

AMBIENTE DE CONTROLE HOLÔNICO SOBRE O SIMULADOR ANALYTICE II E COMPARAÇÕES DE POLÍTICAS DE CONTROLE DE M ANUFATURA

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, 3165 - Curitiba/PR, Brasil - CEP 80230-901

[email protected], [email protected], [email protected], [email protected], [email protected]

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 integrati-vo-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

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 meta-modelo 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.

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 semi-passivas) 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 auto-contida e também aberta para outras questões como uso de Product-HLs [4]. Na interpretação do meta-modelo 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].

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 2.

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 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.

5. Comparações Entre Políticas de Controle

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

Figura 7: Equipamentos envolvidos nos testes.

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

Figura 8: As regras hierárquicas usadas.

Este cenário (chamado caso nominal) ocorre

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

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

Assim sendo, conjuntos de Rules prescritas por políticas de controle heterárquicas, hierárquicas e holônicas foram criados e analisados. Analisou-se a eficácia do processo de produção para cada política de controle e o aproveitamento de cada Resource-HL.

O controle hierárquico foi elaborado com um conjunto de regras que respeitavam estritamente a definição das posições de armazenamento para cada tipo de peça. Estas regras deste controle são mostradas na Figura 8.

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

Figura 9: As regras heterárquicas usadas.

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

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

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

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

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

Figura 10: Algumas regras holônicas usadas.

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

Figura 11: Algumas regras holônicas usadas.

6. Conclusão

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

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

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

Agradecimentos

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


[1] Babiceanu, R. F.; Chen F. F.: Development and Applications of Holonic Manufacturing Systems: A Survey. Journal of Intelligent Manufacturing. Vol. 17, Pp.111-131, Springer Science+Business, Inc. Manufactured in Netherlands, 2006. [2] Deen, S.M.: Agent-Based Manufacturing: Advances in the Holonic Approach. Springer, ISBN 3-540-44069-0, 2003. [3] Da Silveira, G.; Borenstein, D.; Fogliatto, F.S.: Mass customization: literature review and research directions. International Journal of Production Economics, 72 (pp1-13), 2001. [4] Simão, J. M.: A Contribution to the Development of a HMS simulation tool and Proposition of a Meta-Model for Holonic Control. Ph.D. Thesis, CPGEI/UTFPR & CRAN-UHP, 2005. [5] Simão, J. M.; Stadzisz, P. C.; Morel, G.: Manufacturing Execution System for Customised Production. Journal of Material Processing Technology, Elsevier, Vol. 179, Issues 1-3, 2006. [6] Simão, J. M.; Stadzisz, P. C.: Inference Process Based on Notifications: The Kernel of a Holonic Inference Meta-Model Applied to Control Issues. IEEE Trans. on Syst. Man and Cybernetics, Part A, Syst. and Humans, Vol. 39, Issue 1, 238-250, 2009. [7] Simão, J. M.; Tacla C.A.; Stadzisz, P. C.: Holonic Control Meta-Model. IEEE Transactions on Systems, Man and Cybernetics. Part A, Systems and Humans. Accepted paper - SMCA07-10-0308.R1, 2009. [8] Simão, J. M.; Stadzisz, P. C.; Künzle, L.A.: Rule and Agent-Oriented Architecture to Discrete Control Applied as Petri Net Players. Frontiers in Artificial Intelligence and Applications ("Advances in Logic, Artificial Intelligence and Robotics" LAPTEC 2003). Vol. 101 (pp. 121-129) IOS Press, Amsterdam - The Netherlands. ISSN: 0922-6389, 2003. [9] Lucca, J.: Modulo de Interface Amigável sobre Meta-modelo de Controle conectado em Ferramenta de Simulação de Sistemas de Manufatura. Relatório de Iniciação Científica. PIBIC/UTFPR, 2008. [10] Lucca, J.; Banaszewski, R. F.; Stadzisz, P. C.; Tacla, C. A; Simão, J. M: Interface sobre Meta-modelo de Controle do Simulador ANALYTICE II e suas Utilizações para Comparações de Políticas de Controle de Manufatura. Resumo Est. no Seminário de Iniciação Cient. e Tecn. (SICITE) - UTFPR, 2008. [10] Deen, S. M.: Agent-Based Manufacturing: Advances in the Holonic Approach, 2003. [11] Mařík, V.: Industrial Application of the Agent-based Technology. Copyright IFAC, 2004. [12] Simão, J. M.; Stadzisz, P. C.: Paradigma Orien-tado a Notificações (PON) – Uma Técnica de Com-posição e Execução de Software Orientado a Notifi-cações. Pedido de Patente ao INPI/Brasil, Número Temporário: 015080004262, 2008. [13] Banaszewski, R. F.: Paradigma Orientado a Notificações: Avanços e Comparações. Dissertação de Mestrado, CPGEI/UTFPR, 2009.

ANALISE SOB RESTRICOES BASEADA EM UM RACIOCINIO ENERGETICOPARA O PROBLEMA DE ESCALONAMENTO TEMPO REAL DE SISTEMAS DE

GERENCIAMENTO DE WORKFLOW

Flavio Felix Medeiros∗, Stephane Julia∗

∗Faculdade de Computacao - Universidade Federal de UberlandiaAv. Joao Naves de Avila, 2160 - Bloco B, Sala 1B - CEP 38400-902

Uberlandia, MG, Brasil

Emails: [email protected], [email protected]

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

Keywords— Workflow management system, Petri Nets, Constraint Programming, Energetic Reasoning

Resumo— O objetivo deste artigo e o de propor um metodo de analise sob restricoes aplicado ao problemade escalonamento tempo real em sistemas de gerenciamento de workflow. O modelo adotado e uma de redede Petri p-temporal com mecanismo de alocacao de recursos hıbridos. O metodo proposto utiliza inicialmenteum mecanismo de propagacao de restricoes temporais baseado nas duracoes dos casos e nos diferentes tipos deroteiros dos processos de workflow. Os diferentes tipos de recursos (discretos e contınuos) sao incorporados aomodelo e uma abordagem baseada em um raciocınio energetico e entao aplicada. O raciocınio energetico consegueidentificar escalonamentos inadmissıveis devido a incapacidade energetica dos recursos envolvidos na execucaodas atividades correspondentes, bem como atualizar as restricoes temporais dos processos a fim de eliminar datasinconsistentes com solucoes de escalonamento. Posteriormente, e aplicado ao conjunto de restricoes modificadasum mecanismo de inferencia especializado, denominado jogador de redes de Petri, que busca obter em temporeal um cenario admissıvel correspondente a uma sequencia especıfica de atividades que respeitem o conjunto dasrestricoes temporais.

Keywords— Sistemas de gerenciamento de workflow, Redes de Petri, Analise sob restricao, Raciocınio E-nergetico

1 Introducao

O proposito de um sistema de gerenciamento deworkflow (Aalst and Hee, 2002) e executar pro-cessos de workflow. Processos de workflow repre-sentam uma sequencia de atividades de uma or-ganizacao que devem ser executadas para tratarcasos especıficos a fim de alcancar um objetivobem definido.

De acordo com (Aalst and Hee, 2002), o usodas redes de Petri na modelagem de workflow temuma serie de vantagens importantes, como o fatode forcar uma definicao precisa dos processos emcontraste com a maioria das tecnicas de diagra-macao informais, como por exemplo o uso de di-agramas de atividades da UML (Dumas and Hof-stede, 2001)

Alguns modelos baseados em redes de Petriforam definidos exclusivamente para a represen-tacao de workflow, como e o caso das Workflow-nets por exemplo (Aalst and Hee, 2002). AsWorkflow-nets possuem apenas um lugar de inıcioe um lugar de termino, sendo que uma ficha nolugar de inıcio representa um caso que precisa ser

tratado e uma ficha no lugar de termino representaum caso que foi tratado. Toda tarefa e associadaa uma transicao e toda condicao e associada a umlugar, sendo que toda tarefa e condicao deve estarem um caminho entre o lugar de inıcio e o lugarde termino.

O problema de escalonamento (Lee and DiCe-sare, 1994) consiste em organizar no tempo umasequencia de atividades considerando restricoestemporais (intervalos temporais) e restricoes deutilizacao de recursos compartilhados necessariospara execucao das atividades. No caso de sistemasde tempo real, varios cenarios (varios casos emum sistema de gerenciamento de workflow) po-dem ser executados simultaneamente e situacoesde conflito que devem ser resolvidas em tempo real(sem mecanismos de retrocesso) podem ocorrer seum mesmo recurso nao-preemptivo for chamadoao mesmo tempo para execucao de atividades quepertencem a cenarios diferentes.

A diferenca fundamental entre o problema deescalonamento tradicional dos sistemas de pro-ducao (Lee and DiCesare, 1994) e o problemade escalonamento em sistemas de gerenciamento

de workflow e a natureza dos recursos envolvidospara tratar as atividades. No caso dos sistemas deproducao, os recursos representam equipamentosfısicos e sao representados por simples fichas (re-cursos do tipo discreto) nos lugares. No caso dossistemas de gerenciamento de workflow, os recur-sos podem representar equipamentos fısicos bemcomo funcionarios humanos. Por exemplo, e pos-sıvel alocar uma enfermeira em um hospital paracuidar de varios pacientes ao mesmo tempo du-rante o seu dia de trabalho. Nesse caso, a en-fermeira nao pode ser vista como uma simplesficha discreta e um modelo baseado em uma redede Petri ordinaria dificilmente podera representartodas as caracterısticas reais que existem em sis-temas de gerenciamento de workflow.

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

Neste trabalho, sera apresentado um metodode analise sob restricoes cujo objetivo sera a cons-trucao de uma base de conhecimento que poderaser integrada a um mecanismo de inferencia es-pecializado, chamado jogador de redes de Petri,que executara em tempo real (sem mecanismo deretrocesso) uma solucao de escalonamento admis-sıvel (que respeite um conjunto de restricoes) nocontexto dos sistemas de gerenciamento de work-flow.

2 Modelo de processo de workflowtemporal com mecanismo de alocacao

de recursos hıbridos

O modelo proposto neste artigo e o mesmo queaquele proposto em (de Oliveira et al., 2008).Trata-se de uma rede de Petri p-temporal com alo-cacao de recursos hıbridos. Neste modelo, a estru-tura de controle segue a mesma que aquelas dasworkflow-net de Aalst (Aalst and Hee, 2002), comos lugares de inıcio, fim e os principais roteirosexistentes nos processos de workflow. Em vez deassociar as tarefas as transicoes, as tarefas sao as-sociadas a lugares especıficos. Assim, os mecanis-mos de alocacao de recursos podem ser facilmentevisualizados nas tarefas.

A seguir as principais caracterısticas destemodelo serao apresentadas.

2.1 Restricoes sob os roteiros

O Servico de reclamacoes apresentado em (Aalstand Hee, 2002) sera utilizado para ilustrar os di-versos tipos de roteiros estudado neste trabalho.No processo do Servico de reclamacoes, primeirouma reclamacao e registrada. Depois, sao con-tactados o cliente que fez a reclamacao e o de-

partamento afetado pela reclamacao. O cliente econtactado com o objetivo de se obter mais in-formacoes. O departamento e informado sobre areclamacao e e questionado sobre uma reacao ini-cial. Essas duas atividades devem ser executadasem paralelo (roteiro paralelo). Depois disso, as in-formacoes sao coletadas e, em sequencia, uma de-cisao e tomada (roteiro sequencial). Dependendoda decisao tomada, ou um pagamento e feito ouuma carta e enviada ao cliente (roteiro alterna-tivo). Por fim, a reclamacao e arquivada.

A figura 1 ilustra os diversos tipos de roteirosdo processo do Servico de reclamacoes. Os lugaresEj com j=0 ate 10 representam lugares de esperaentre as atividades. As atividades sao associadasaos lugares Ai com i=1 ate 8. Em particular, oslugares E0 e E10 representam o inıcio e o fim doprocesso e a ficha em E0 representa um caso a sertratado.

2.2 Restricoes temporais explıcitas

Geralmente, o tempo necessario para a execucaode uma atividade em um processo de workflow enao-determinıstico. Dessa forma, um intervalo detempo pode ser atribuıdo a cada atividade. Deacordo com (de Oliveira et al., 2008), restricoesde tempo explıcitas existentes em sistemas comcaracterısticas de tempo real podem ser especifi-cadas formalmente usando um modelo de rede dePetri p-temporal.

2.2.1 Intervalo estatico

A definicao estatica de uma rede de Petri p-temporal e baseada em intervalos estaticos querepresentam o intervalo de permanencia dasfichas nos lugares do ponto de vista das duracoesdas atividades. Uma ficha pertencente a umlugar p participara da sensibilizacao de umatransicao de saıda de p se ela tiver permanecidola pelo menos durante a duracao especificada pelaborda mınima e no maximo durante a duracaoespecificada pela borda maxima do intervalo.Enquanto a ficha nao alcanca o tempo mınimo nolugar de permanencia onde se encontra, ela ficaindisponıvel para o disparo de outras transicoes.Dentro do intervalo, a ficha fica disponıvel, eapos o limite maximo de permanencia, a ficha setorna morta e nao pode mais disparar nenhumatransicao.

Figura 1: Roteiros

A figura 1 ilustra os intervalos estaticos vin-culados as atividades do Servico de reclamacoes.Para cada tarefa Ai, aparece um intervalo estaticoque especifica a sua duracao mınima e maxima.Em particular, os intervalos estaticos associadosas tarefas Coletar Informacoes em A4 e Arquivarem A8 sao iguais a [0, 0] porque as duracoesdestas sao desprezıveis se comparada com asoutras tarefas do Servico de reclamacoes.

2.2.2 Intervalo de visibilidade

De acordo com (de Oliveira et al., 2008) ocomportamento dinamico de uma rede de Petrip-temporal depende da marcacao da rede e dasituacao temporal das fichas que e dada pelointervalo de visibilidade. Um itervalo de visibi-lidade [(δp)mim, (δp)max] associado a uma fichaem um lugar p de uma rede de Petri p-temporalespecifica a data mınima ((δp)mim) em que aficha se torna disponıvel em p para o disparo deuma transicao de saıda de p (data de inıcio aomais cedo de uma atividade), bem como a datamaxima ((δp)max) apos a qual a ficha se tornaindisponıvel (morta) e nao pode ser utilizadapara o disparo de nenhuma transicao (data deinıcio ao mais tarde de uma atividade).

2.3 Restricoes de alocacao de recursos hıbridos

Alguns dos recursos usados em sistemas de geren-ciamento de workflow podem ser consideradosdo tipo discreto, podendo ser representados porsimples fichas. E o caso geralmente de recur-sos que representam equipamentos fısicos, comouma impressora por exemplo. Outros recursos po-dem ser representados por recursos contınuos. Eo caso geralmente de recursos do tipo humano.Tais recursos sao representados por um numeroreal que representa a disponibilidade de um fun-cionario humano, por exemplo, 100% represen-tando a disponibilidade maxima quando o recursose encontra no estado completamente disponıvel.Da mesma forma, aos pesos dos arcos de saıdas eentradas dos recursos sao atribuıdos valores cor-respondentes a previsao da disponibilidade exigidapara a realizacao da atividade relacionada.

3 Princıpio geral de propagacao derestricoes

3.1 Propagacao de restricoes temporais nosroteiros

O mecanismo de propagacao de restricoes tempo-rais nos roteiros proposto neste artigo foi inicial-mente apresentado em (de Oliveira et al., 2008).Utilizando tecnicas classicas de propagacao de res-tricoes baseadas em grafos sem circuitos e fixandoa data de inıcio de um caso bem como a sua du-racao maxima para ser completado, calcula-se os

intervalos de visibiliade associados aos diversos lu-gares Ej de espera entre as diversas atividades dosroteiros existentes.

A figura 2 ilustra a aplicacao do mecanismo depropagacao de restricoes temporais ao longo dosroteiros do processo do Servico de reclamacoes,considerando 4 casos a serem tratos.

Figura 2: Exempo do mecanismo de propagacaodas restricoes temporais nos roteiros

Na figura 2 (A), as bordas mınimas dos inter-valos de visibilidade associadas ao lugar E0, re-presentam as datas de inıcio de quatro casos aserem tratados pelo processo de workflow. As bor-das maximas dos intervalos de visibilidade associ-adas ao lugar E10 representam as datas de terminoprevistas dos quatro casos, sabendo que a duracaomaxima para tratar cada caso e de 105 unidadesde tempo. Conhecendo as duracoes mınimas emaximas de cada atividade (intervalos estaticos)bem como os roteiros de um processo de work-flow e possıvel aplicar mecanismos de propagacaode restricoes para obter os tempos de espera entreas atividades (intervalos de visibilidade associadosaos lugares de espera) (figura 2 (B)) para cada umdos quatro casos. Por exemplo, o intervalo de vi-sibilidade V1 associado ao lugar E7 significa quea atividade pagar associada ao caso 1 podera seriniciada ao mais cedo na data 45 e ao mais tardena data 90.

3.2 Raciocınio energetico baseado nas restricoesde recursos

A propagacao das restricoes temporais com basena disponibilidade dos recursos leva em conside-racao uma abordagem baseada em um raciocınioenergetico proposto por (Lopez and Esquirol,

1996). Tal abordagem foi utilizada para tratar oproblema do escalonamento de tarefas em sistemasde manufatura utilizando um modelo baseado emgrafos com as atividades associadas aos arcos. Oraciocınio energetico e uma abordagem baseadana relacao entre a energia provida pelos recursose a energia consumida pelas atividades.

No contexto dos sistemas de gerenciamento deworkflow, cada atividade i pode ser caracterizadapor suas duracoes mınimas (Pmini) e maximas(Pmaxi) e devem ser executadas dentro de umajanela de tempo [ri, di], com ri representando o i-nıcio ao mais cedo da atividade e di o final ao maistarde previsto. O conjunto S denota as datas de i-nıcio das atividades consistentes com as janelas detempo [ri, di] e com as restricoes de utilizacao dosrecursos utilizados na realizacao das atividades.

Os mecanismos de propagacao de restricoesque sao de interesse nesse trabalho tem comoobjetivo remover valores inconsistentes de datasde inıcio de atividades a fim de reduzir o conjuntodas possıveis solucoes.

3.2.1 Estudo da Consistencia global

De acordo com (Lopez and Esquirol, 1996)a energia maxima disponıvel que um recursopode prover em uma dada janela de tempo∆ = [S∆, F∆] e definida como: W∆ = A·(F∆ -S∆), onde A e o valor da intensidade energeticaque o recurso em questao disponibiliza paraexecucao das atividades que o utilizam.

Considerando-se uma atividade i, comecandono instante Si e terminando em Fi, considerando-se tambem a intensidade energetica ai que a ativi-dade necessita do recurso e uma dada janela detempo ∆, duas situacoes podem ocorrer para sedefinir a energia requerida por i em ∆:Se ([Si, Fi] ∩ ∆) 6= ∅ entaoW∆

i = ai · [min(Fi, F∆) - max(Si, S∆)].Se ([Si, Fi] ∩ ∆) = ∅ entao W∆

i = 0, onde W∆i

e a energia requerida por i em ∆. Mais generica-mente, pode-se dizer que:W∆

i = ai · max[0, min(Fi, F∆) - max(Si, S∆)].Uma vez que Si (data de inıcio da atividade

i) e uma variavel, W∆i tambem e uma variavel,

podendo ser derivados valores mınimos, levandoem consideracao o intervalo temporal [ri, di].

A energia mınima requerida por uma ativi-dade i ao longo da janela de tempo ∆, chamadaW∆

i , e obtida pela posicao da atividade i que so-brepoem o menos possıvel a janela de tempo ∆:W∆

i = ai · max[0, min (Pmini, F∆ - S∆,ri + Pmini - S∆, F∆ - di + Pmini)].

Considerando W∆, a energia provida pelorecurso em uma dada janela de tempo ∆, e∑n

i=1 W∆i , as energias requeridas pelas atividades

na mesma janela de tempo ∆, pode-se derivar umacondicao de consistencia global necessaria a serrespeitada por qualquer escalonamento em qual-

quer intervalo ∆:∀ ∆,

∑ni=1 W∆

i ≤ W∆ (1)A formula (1) significa que a soma das ener-

gias gastas pelas diversas atividades que utilizamum mesmo recurso em um intervalo de tempo ∆nao sao maiores que a energia total produzidapelo recurso utilizado. Em particular, a par-tir da condicao (1), pode-se extrair a seguinteproposicao: Se ∃∆ tal que

∑ni=1 W∆

i > W∆ entaonao existe um escalonamento admissıvel.

A figura 3 ilustra a disputa pelo recursoR2 (Funcionario reclamacoes) do processo doServico de reclamacoes ilustrado na figura 5 (A).Tal recurso sera envolvido na execucao de dozeatividades distintas.

Figura 3: Mecanismo de alocacao de recurso con-tınuo

A tabela 1 apresenta tais atividades junta-mente com as suas restricoes temporais [ri, di],suas duracoes mınimas (Pmini) e suas intensi-dades energeticas (ai). A restricao temporal ri

e dada pelas bordas mınimas dos intervalos devisibilidade, Pmini pelas bordas mınimas dosintervalos estaticos, di pela soma das bordasmınimas dos intervalos de visibilidade e dasbordas maximas dos intervalos estaticos, e ai

pelos pesos associados aos arcos do modelo dealocacao de recurso contınuo.

Tabela 1: Dados das atividades envolvidascom o recurso R2

i ri Pmini di ai

A2 Caso 1 5 20 50 30

A2 Caso 2 18 20 63 30

A2 Caso 3 23 20 68 30

A2 Caso 4 28 20 73 30

A3 Caso 1 5 25 50 40

A3 Caso 2 18 25 63 40

A3 Caso 3 23 25 68 40

A3 Caso 4 28 25 73 40

A7 Caso 1 45 20 105 50

A7 Caso 2 58 20 118 50

A7 Caso 3 63 20 123 50

A7 Caso 4 68 20 128 50

FONTE: Simulacoes realizadas pelos autores

Considerando como exemplo ilustrativo deaplicacao da consistencia global a atividade A3referente ao Caso 4 escolha-se um ∆ que cubratoda sua janela de execucao: [S∆ , F∆]=[ri , di].Nesse caso tem-se [S∆=28 , F∆=73]. Somando as

energias mınimas necessarias para completa exe-cucao de cada uma das 12 (doze) atividades den-tro do ∆ considerado obtem-se

∑ni=1 W∆

i = 3830.Tal valor e menor que a energia que o recurso R2consegue prover durante esse intervalo estudado(W∆ = 4500). Isso garante que nesse intervalo∆ o recurso R2 consegue fornecer a energia mı-nima necessaria para a completa execucao das 12atividades.

No exemplo do processo do Servico de recla-macoes e possıvel verificar que para as 12 ativi-dades que utilizam o recurso R2, a condicao deconsistencia global e satisfeita. Um resultado con-trario implicaria na impossibilidade de se encon-trar um escalonamento admissıvel sem relaxar al-gumas restricoes de tempo.

As regras de consistencia global nao permitematualizar diretamente as variaveis do conjuntoS (conjunto que contem as datas de inıcio dasatividades) do problema. Para isso, devem serusadas regras de consistencia local.

3.2.2 Estudo da consistencia local

De acordo com (Lopez and Esquirol, 1996),ao considerar uma atividade i, a condicao daconsistencia global (1) pode ser reescrita daseguinte maneira:

∀i, ∀∆, W∆i ≤ W∆ -

∑nj=1,j 6= i W∆

j

Considerando o valor maximo do lado direitoda condicao acima, pode-se derivar o valor ma-ximo para o seu lado esquerdo.

O termo A∆i = W∆ -

∑nj=1,j 6= i W∆

j echamado de energia maxima disponıvel deixadapelas demais atividades no intervalo ∆ para a e-xecucao da atividade i . Qualquer data de inıcioSi da atividade i que leva a um consumo de e-nergia maior do que a energia maxima disponıvelpara a mesma deve entao ser removida.

De acordo com (Hennet, 2002), uma maneirade verificar localmente se o recurso utilizado poruma determinada atividade fornece a energia su-ficiente para sua completa execucao levando emconsideracao A∆

i (energia maxima disponıvel paraatividade i) e efetuar o calculo da duracao max-ima equivalente p∆

i . Tal duracao representa a du-racao maxima de disponibilidade do recurso paraexecucao da atividade i respeitando os gastos en-ergeticos mınimos das outras atividades que uti-lizam o mesmo recurso no intervalo ∆. Dessaforma p∆

i e dada pela razao entre A∆i e a inten-

sidade energetica que i necessita de um recurso:p∆

i = A∆i

ai.

Considerando-se a atividade A3 referente aocaso 4 da figura 3 como exemplo, e possıvel perce-ber que ao adotar um intervalo ∆ igual a duracaomınima de execucao da atividade,∆ = [S∆ = ((δp)mim) , F∆ = ((δp)mim)+Pmini],ou seja, [S∆ = 28 , F∆ = 28 + 30 = 58] e con-siderando a energia maxima disponıvel A∆

i =970

para essa atividade nesse ∆, o valor da p∆i =24.25 e

inferior ao valor da Pmini=25. Neste caso particu-lar, o valor da p∆

i =24.25 significa que o recurso R2consegue fornecer energia para a atividade A3 re-ferente ao caso 4 durante 24.25 unidades de tempo,sendo que a duracao mınima da atividade cor-responde a 30 unidades de tempo, o que cara-cteriza uma inconsistencia local, ja que a duracaode disponibilidade do recurso e inferior a duracaomınima necessaria para a realizacao da atividadecorrespondente. A fim de encontrar uma faixatemporal dentro do intervalo permitido [ri, di]onde a duracao p∆

i seja maior ou igual a Pmini

pode ser feito um deslocamento do ∆ pela direita.

O intervalo ∆ depois de deslocado adireita de acordo com a diferenca entre(Pmini) e (p∆

i ), ou seja, (30 - 24.25 = 5.75)e [S∆=28+5.75 , F∆=58+5.75]=[S∆=33.75 ,F∆=63.75] (figura 4). Fazendo-se o calculoda duracao maxima equivalente levando emconsideracao esse novo ∆ tem-se p∆

i =33.3125.Uma vez que p∆

i > Pmini, a data de inıcio aomais cedo da atividade A3 referente ao caso 4passa a ser 33.75 ∼= 34, conforme ilustrado pelafigura 5 (B). De fato, se a atividade e iniciadana data 28, tem-se a certeza de que uma incon-sistencia relativa ao gasto energetico do recursoenvolvido acontecera e que consequentemente naosera possıvel encontrar um escalonamento querespeite o conjunto das restricoes temporais.

O deslocamento da data de inıcio ao maistarde de uma atividade pode ser feito de modosemelhante porem considerando deslocamentos aesquerda.

Figura 4: Deslocamento do intervalo temporaldelta

Apos a atualicao do intervalo de visibilidadeV4 em E2 relacionado a atividade A3 do caso 4(figura 5 (B)), e necessario aplicar novamente omecanismo de propagacao das restricoes tempo-rais ao longo dos roteiros do processo completodo Servico de reclamacoes. Dessa forma acon-tecem atualizacoes nos intervalos de visibilidadesassociados aos lugares E4, E5, E6, E7, E8, E9 eE10 referente ao caso 4 conforme ilustrado pelafigura 5(B). O raciocınio energetico pode ser apli-cado a cada atividade do processo ate que ne-nhuma alteracao de restricao temporal aconteca.

Figura 5: Aplicacao da abordagem baseada noraciocınio energetico sobre o processo do Servicode reclamacoes

4 Princıpio geral para o escalonamentotempo real

Uma das tecnicas que permite a execucaodinamica das redes de Petri p-temporais eo algoritmo do jogador de rede de Petri p-temporal (de Oliveira et al., 2008), que pode serusado para a resolucao do problema de escalona-mento de sistemas de gerenciamento de workflowem tempo real. Quando o modelo e baseado nomodelo de rede de Petri p-temporal, o algoritmodo jogador deve resolver as situacoes de conflitoem tempo real de forma a nao permitir a possibi-lidade de violacao de restricao temporal que podeser causada pela morte de uma ficha.

O jogador possui um calendario dos eventos(bordas mınimas e maximas de todos os inter-valos de visibilidade) escalonados no tempo. Acada vez que uma borda mınima e alcancada, umaficha torna-se disponıvel. Se essa ficha sensibilizauma transicao e se nao houver conflito efetivo, atransicao e disparada; caso contrario, o conflito eisolado e o mecanismo de tomada de decisoes eativado para verificar se a transicao pode ser dis-parada na data mınima. Se a decisao for o disparo,uma nova marcacao e gerada e novos intervalos devisibilidade sao definidos; caso contrario, e tratadoo proximo evento do calendario. O mecanismode tomada de decisao e basedo na geracao de umgrafo das classes e foi apresentado em (de Oliveiraet al., 2008). Se um limite maximo (borda maximade um intervalo de visibilidade) for atingido, entaoa ficha morre, representando um comportamentonao permitido. Nesse caso, nao havera garantia

de que os prazos de entrega serao respeitados.

5 Conclusao

Ate o presente momento, o escalonamento de sis-temas de gerenciamento de workflow e realizadoessencialmente na forma de execucao de filas deespera com polıticas do tipo FIFO (First In FirstOut). Este trabalho propos uma nova abordagem.

A maior contribuicao deste trabalho concernena melhoria da base de conhecimento que defineo conjunto de restricoes que um jogador de redesde Petri devera respeitar durante a elaboracao deuma solucao de escalonamento em tempo real. Emparticular, a tecnica de filtragem, embasada no es-tudo da consistencia local, garante a remocao dejanelas de tempo inconsistentes com solucoes ad-missıveis de escalonamento. Aplicando o jogadorde redes de Petri a nova base de conhecimentosera entao possıvel melhorar consideravelmente osprazos de entrega de cada caso em relacao a umapolıtica do tipo FIFO.

Um prototipo da abordagem apresentada foiimplementado em linguagem de programacao Vi-sual Prolog.

Referencias

Aalst, W. V. D. and Hee, K. V. (2002). WorkflowManagement: Models, Methods and Systems,The MIT Pres.

de Oliveira, F. F., Julia, S. and Valette, R.(2008). Real time scheduling of workflowmanagement systems based on a p-time petrinet model with hybrid resources, SimulationModelling Practice and Theory 16: 462–482.

Dumas, M. and Hofstede, A. H. M. T. (2001).Uml activity diagrams as a workflow speci-fication language, Proceedings fo the 4th In-ternational Conference on The Unified Mo-deling Language, Modeling Languages, Con-cepts, and Tools pp. 76–90.

Hennet, J. C. (2002). Concepts et outils pour lessystemes de production.

Lee, D. Y. and DiCesare, F. (1994). Schedulingflexible manufacturing systems using petrinets and heuristic search, IEEE Transactionson Robotics and Automation pp. 123–132.

Lopez, P. and Esquirol, P. (1996). Consistencyenforcing in scheduling: A general formula-tion based on energetic reasoning, 5th Inter-national Workshop on Project Managementand Scheduling .

IMPLEMENTAÇÃO DE SISTEMAS DE CONTROLE … DE MANUFATURA... · supervisor para a máquina de Mealy...

Documents

Transcript of IMPLEMENTAÇÃO DE SISTEMAS DE CONTROLE … DE MANUFATURA... · supervisor para a máquina de Mealy...