ESCALONAMENTO DA DESCARGA E EMBARQUE DE CAMINHÕES EM UM CENTRO DE DISTRIBUIÇÃO USANDO TECNOLOGIA DE AGENTES

Rodrigo de Alvarenga Rosa Universidade Federal do Espírito Santo - Depto Engenharia Elétrica

Campus de Goiabeiras, Depto Engenharia Elétrica – CT II Avenida Fernando Ferrari s\n – Vitória – ES -CEP 29.060-900

rod@ele.ufes.br

Hans Jorg Andreas Schneebeli Universidade Federal do Espírito Santo - Depto Engenharia Elétrica

Campus de Goiabeiras, Depto Engenharia Elétrica – CT II Avenida Fernando Ferrari s\n – Vitória – ES -CEP 29.060-900

hans@ele.ufes.br

Resumo Este artigo apresenta um sistema capaz de gerar o escalonamento de recursos, de forma dinâmica, a fim de fazer a programação das requisições de atendimento (descarga e embarque) de caminhões em um centro de distribuição, CD. O sistema foi implementado como um ambiente multiagentes, composto de agentes competitivos que controlam alguns recursos. À medida que as solicitações são feitas ao centro de distribuição os agentes começam a negociar entre si a fim de alocar todos os recursos necessários, nas datas solicitadas, para poder fazer a operação completa de embarque e/ou descarga dos caminhões. São mostradas as ferramentas utilizadas para o desenvolvimento do sistema e o mecanismo de negociação entre os agentes, bem como os resultados alcançados. Palavras Chave: Logística, Escalonamento, Agentes. Abstract This article presents a computer system able to make the scheduling, dynamically, of the resources needed to make the line up of trucks requesting services (pick up and delivery) at a distribution center. This system was implemented as a society of self-interested agents that negotiate among themselves to achieve the scheduling of the resources needed, at the desired date, to make the complete pick up or delivery requested. It is also shown the tools used to develop the system, the negotiation strategy and the results achieved. Keywords: Logistic, Scheduling, Agents.

Introdução Para o trabalho em questão, um centro de distribuição (CD) é um armazém que tem por

finalidade: 1) Armazenagem; 2) Consolidação; 3) Fracionamento; 4) Combinação. [Ballou, 2001]. Para que tais atividades possam ser realizadas, figura 1, o CD deve receber e expedir carga dos

proprietários da mesma. Para que essas duas atividades possam ser realizadas, é preciso que diversos recursos sejam colocados à disposição da solicitação, dentre eles citamos: empilhadeiras, área de armazéns, área de separação de pedidos, equipamentos de manuseio, embalagens (contêineres e pallets).

O sistema proposto visa fazer a programação de recepção ou expedição de caminhões que vão respectivamente entregar ou buscar mercadorias no CD. Para que essa programação seja feita, o sistema deve fazer para cada recurso o escalonamento do mesmo [Blazewicz et all, 1996].

868

Esse problema se torna ainda mais complexo, pois as solicitações são recebidas de forma dinâmica e podem sofrer alterações de data estimada de recepção ou expedição a qualquer momento. Isso implica que novas solicitações que venham a ser recebidas pelo sistema obriguem o mesmo a fazer um replanejamento das atividades anteriormente planejadas para poder atender as novas solicitações que vão entrar na frente das já previamente agendadas.

O problema de escalonamento dinâmico com restrição de recursos [Blazewicz et all, 1996] aplicado a um centro de distribuição, apresenta algumas características próprias que diferem de outros problemas similares: 1) Para fazer o planejamento, todos recursos necessários devem ser solicitados e alocados de uma única vez, para uma única data, não podendo haver alocação parcial dos recursos; 2) Os recursos são discretos, não divisíveis; 3) Há planejamento e replanejamento à medida que novas solicitações chegam, 5) Os recursos não são consumíveis (eles podem ser usados quantas vezes quiser e não se acabam); 6) Os recursos não são compartilhados.

Para resolver o problema fez-se a opção por usar a tecnologia de agentes. [Kraus, 2001], [Weis, 2000], [Feber, 1999], [Jennings, Sycara, Wooldridge, 1998]. Essa decisão foi baseada nos seguintes fatores: 1) Poucos trabalhos específicos de aplicação real em planejamento industrial sobre a área de alocação foram apresentados, [Parunack, 1999] [Chaib-Draa, 1997] [Sycara et all, 1991]; 3) Problemas combinatoriais de alocação são mais facilmente tratados quando divididos; 4) Os problemas publicados se assemelham em alguns pontos do problema tratado, mas diferem em muitos outros pontos; 5) Testar a viabilidade de uso de agentes para resolver problemas desta classe.

O problema de escalonamento de recursos usando agentes foi tratado em diversos artigos [Graham, 2001], [Kraus, 2001], [Weis, 2000], [Feber, 1999], [Cunha, Belo, 1997], [Chavez, Moukas, Maes, 1997], [Jennings, 1995]. No entanto as particularidades citadas acima levam a procura de uma solução mais adequada para a necessidade do problema tratado.

A tecnologia de agentes ainda apresenta vantagens em quatro aspectos: 1) É baseada em processamento distribuído. Portanto, podendo ser executado em diversas máquinas visando dar maior poder de processamento a um menor custo; 2) Podemos subdividir um grande problema de escalonamento em pequenos problemas, que são tratados por cada agente; 3) Um agente possuindo recursos próprios

Equipamentos

Solicitação Mundo Externo

Área Armazenagem

Docas Caminhões

Embalagem

Área Separação

Figura 1 - Modelo esquemático do problema do CD

869

pode de maneira autônoma, tomar decisões quanto ao escalonamento dos recursos, com pouca ou nenhuma interferência humana; 4) Simplicidade de cada agente, faz com que sejam mais fáceis a implementação e manutenção deles.

Definição do problema tratado

O problema de criar o escalonamento dos caminhões a serem atendidos pelo centro de distribuição pode ser definido como o problema de escalonamento dinâmico com restrição de recursos que é definido matematicamente como [Blazewicz et all, 1996]:

Um conjunto { }t,,t,tτ n21 L= para n tarefas (tasks), Um conjunto { }p,,p,pP m21 L= de m processadores (processors), Um conjunto { }r,,r,rR s21 L= de s recursos (resources) e Um conjunto { }j,,j,jJ q21 L= de q solicitações (jobs). Cada solicitação Jju∈ possui x u

tarefas tug igual a uma e somente uma tarefa τt j∈ . Criar o escalonamento significa alocar recursos do conjunto P e recursos R às tarefas τ a fim

de complementar as solicitações com todas as suas tarefas τ e suas restrições. O problema tratado é definido na literatura como Job Shop, [Blazewicz et all, 1996], onde o numero de tarefas e a seqüência delas é variável para cada solicitação. Como o Job Shop é dinâmico, as tarefas do conjunto τ são dependentes do tempo ( )tτ .

Cada tarefa τt j∈ é caracterizada pelos seguintes dados: 1. Tempo de chegada (ready time ou arrival time) aj , que é o momento que cada tarefa t j está

pronta para iniciar o processamento; 2. Tempo limite de termino (due date) dj , que determina o tempo limite que cada tarefa t j

deve terminar o processamento; 3. Tempo limite máximo de término (Deadline) d~j , que é um tempo real (due date) definitivo

(hard),no qual a tarefa t j deve terminar o processamento; 4. Prioridade w j , que expressa a prioridade de cada tarefa t j e 5. ),,(β ρδλ= , que representa restrições de recursos, sendo Ν∪∈{.}, ρδλ e , o tipo do

recurso, a quantidade disponível dele e requisito (tempo necessário para o seu uso), respectivamente. Os parâmetros aj , dj , d~j e w j são inteiros. Os recursos não são do mesmo tipo, são classificados como renovável (renewable), discreto

(discrete) e assume-se também que todos os recursos necessitados pela tarefa são entregues a ela antes do inicio da mesma (o problema é non-preemptive) e a tarefa devolve os recursos no termino de sua execução. Essas considerações definem uma regra simples para prevenção de deadlocks no sistema [Coffman, Denning, 1973].

Para representar o caso geral de escalonamento será usado o método do gráfico de Gantt [Blazewicz et all, 1996], onde para cada tarefa t j , nj ,1,2,L= , pode-se calcular o tempo de termino (completion time) C j .

O tempo total do escalonamento (makespan) de uma solicitação Jju∈ , C maxu , pode ser calculado como o maior tempo de termino dentre as tarefas tug , qg ,1,2,L= . Assim sendo tem-se o tempo total do escalonamento como { }CmaxC max ugu = , e C maxu será a medida de desempenho do

870

escalonamento da solicitação ju . O escalonamento que tiver sua medida de performance no seu mínimo, pode-se dizer que é um escalonamento ótimo.

A proposta deste trabalho é resolver o problema matemático exposto anteriormente sem fazer uso de modelos matemáticos, usando agentes em ambientes multiagentes, conforme exposto a partir da seção seguinte, deixando para a negociação entre eles conduzir para uma solução do problema. Definição do ambiente multiagente

Não existe um consenso na literatura sobre uma definição do termo agente, existindo diversas

propostas até então. Assim sendo será adotada a definição de Wooldridge [Weis, 2000] que especifica um agente como sendo um programa de computador que está situado em um ambiente e é capaz de tomar ações autônomas nesse ambiente no intuito de alcançar seus objetivos.

No intuito de detalhar mais essa definição, define-se um agente como tendo as seguintes características [Feber, 1999]. O agente: 1) Tem estado virtual, pois não existem no mundo real, são programas de computador. 2) É capaz de executar ações que vão transformar, modificar, o ambiente no qual está inserido, e consequentemente modificando sua tomada de decisão futura. 3) Pode se comunicar com outros agentes, sendo esse o principal meio de interação entre os agentes. A comunicação é o único método de ação que o agente possui. 4) É autônomo, portanto não é conduzido por comandos externos vindos do usuário (ou de outro agente), mas sim por uma série de tendências que o fazem caminhar para a satisfação de seus objetivos individuais. 5) Tem recursos próprios a fim de poder agir e ter autonomia. 6) Apresenta uma representação parcial do ambiente que ele interage.

Por fim agrega-se às características anteriores, as seguintes características [Weis, 2000]: 1) Reação, pois ele tem a capacidade de autonomamente responder às mudanças no ambiente que ele tem conhecimento em função de atender seus objetivos individuais. 2) Pró-ativo, pois ele deve ter o comportamento de tomar ações no intuito de caminhar para a satisfação de seus objetivos individuais. 3) Habilidades Sociais, pois ele deve interagir com outros agentes, no sentido de caminhar para a satisfação de seus objetivos individuais.

Coordenação é a capacidade que o sistema multiagente tem de executar certas atividades em um ambiente compartilhado. O nível de coordenação é medido pela capacidade do sistema multi-agente evitar que sejam feitas atividades desnecessárias, através da redução da disputa dos recursos, evitando os intertravamentos (deadlocks) e mantendo condições de segurança aplicáveis ao sistema [[Huhns e Stephens] in [Weis, 2000]].

Figura 2 – Modelos de Coordenação em um ambiente multiagente

Coordenação

Cooperação Competição

Planos Negociação

Planos distribuídos Plano Centralizado

871

A coordenação, conforme figura 2, pode se dar de duas maneiras: Cooperação e Competição. Entende-se por cooperação a coordenação entre dois agentes que não são contrário um ao outro, isto é, possuem o mesmo objetivo e trabalham para esse objetivo comum. No caso de competição, a coordenação entre dois agentes que possuem objetivos próprios, e que não compartilham o mesmo objetivo, e cada um trabalha para atingir esse seu objetivo próprio. Nesses casos o agente é chamado de egoísta (self-interested) [Jennings, et all, 1998].

No escopo deste trabalho, os agentes são considerados como egoístas (self-interested), pois cada agente tenta melhorar seu estado próprio, sem tentar cooperar com outros agentes. Apesar de tratarmos de agentes egoístas, os mesmos são confiáveis, não tentam enviar mensagens no intuito de enganar o estado de outro agente, assim sendo são agentes honestos que não blefam [Jennings, et all, 1998]. Além disso, os ambientes de agentes serão virtuais e multi-agentes [[Huhns e Stephens] in [Weis, 2000]], pois os agentes interagem entre si de maneira produtiva, através da infra-estrutura que o meio proporciona: 1) Protocolos de comunicação, que permitem aos agentes trocar e entender mensagens; 2) Protocolos de interação, que permitem aos agentes desenvolver conversações suportadas pelos protocolos de comunicação.

No caso do ambiente multiagentes tratado neste trabalho, não existe cooperação, e sim, competição [[Huhns e Stephens] in [Weis, 2000]]. Na negociação entre os agentes, [Jennings, et all, 1998], caso ocorra alguma forma de conflito, o mesmo tem de ser resolvido de maneira descentralizada pelos agentes de duas formas: 1) Racionalidade limitada; 2) Informações incompletas. Além disso, os agentes se comunicam e interagem trocando propostas e contra propostas.

Projeto e Implementação do sistema

O desenvolvimento do modelo da sociedade de agentes baseou-se no ambiente real de operação

de um centro distribuição. O sistema proposto é descrito como uma n-upla (A, R, S, M, F), figura 3, onde: A – Conjunto de

agentes da sociedade de agentes; R – Conjunto de recursos de um agente do sistema; S – Conjunto de solicitações que cada agente recebe; M – Conjunto de mensagens que o sistema recebe e envia para negociar; F – Conjunto de escalonamento de cada recurso e a uma solicitação de um único agente.

Na elaboração do sistema foi elaborada uma interface única que pudesse representar qualquer agente do sistema, tendo-se assim o agente padrão. Foi feita uma implementação única onde a diferença

(A) Conjunto Agentes (F) Conjunto

Escalonamentos(S)

Conjunto Solicitaçõ

es

(M) Conjunto Mensagens

(R) Conjunto Recursos

Figura 3 - Sociedade de Agentes do Problema de Escalonamento do CD

872

entre os agentes é estabelecida através de parâmetros. Com isso foi desenvolvido um agente padrão que recebe e envia somente dois tipos de mensagem: Solicitação e Resposta.

Para implementação do modelo da sociedade de agentes, foi usada a ferramenta DECAF (Distributed Environment Centered Agent Framework) [Graham, 2001]. Essa ferramenta tem três funções: 1) Desenho da arquitetura do agente (plano do agente); 2) Infra-estrutura para a execução de agentes (fluxo de métodos que devem ser executados pelo agente em função do comportamento de cada uma de suas mensagens e métodos); 3) Despachador para envio e recebimento de mensagens.

Como linguagem de comunicação entre os agentes, foi usado o KQML [Finin, 1994], pois é um dos protocolos mais difundidos em termos de protocolo de comunicação entre agentes e é o protocolo nativo do ambiente DECAF.

Como linguagem de programação foi usada a linguagem Java [Eckel, 2002]. Essa escolha se deu por três fatores: 1) Se adapta muito bem a ambientes multiplataformas e distribuídos; 2) Suporta todos os quesitos de orientação a objetos; 3) É nativo do ambiente DECAF, que também é escrito em Java.

Descrição do desenvolvimento do agente padrão

Foi desenvolvido um agente padrão baseado em DECAF para modelar o agente e sua

funcionalidade e um conjunto de classes para suportar as ações do agente.No DECAF foram descritos todos os possíveis métodos para recebimento e tratamento das mensagens. Cada tarefa (task) no DECAF gera a implementação de uma classe Java. Cada ação (action) representa um método dentro desta classe. O fluxo de execução das classes e métodos depende das mensagens chegadas e do resultado de cada ação.

Assim, para o plano DECAF de agentes temos duas entradas externas, mensagens padrão, para os agentes: Sched_RecebeSolicita e Sched_RecebeResposta. Essas entradas serão as únicas maneiras dos agentes receberem solicitações externas e conversarem entre si, hora enviando e recebendo solicitação, hora enviando e recebendo respostas para as solicitações, figura 4.

A mensagem tipo Solicitação é única e padrão. As mensagens do tipo Solicitação têm como função receber todos os dados sobre a solicitação.

Basicamente em todo o sistema de alocação os seguintes dados devem ser informados: 1) Numero da solicitação; 2) Tipo de Operação (recepção ou expedição); 3) Dados do Veículo; 4) Dados da Carga (quantidade, peso, tamanho); 5) Data/hora Estimada de Chegada; 6) Numero de Horas de Operação (Estimada).

As mensagens do tipo Resposta podem ser de três subtipos: Sugestão, Confirmação e Negativa. Para as mensagens de Sugestão temos os seguintes dados: 1) Tipo da Mensagem; 2) Numero da

Solicitação; 3) Data/hora sugerida. Onde Tipo da mensagem é igual a “s”. Essas mensagens são usadas quando o agente não consegue atender a solicitação na data solicitada. Conforme seus recursos e sua agenda ele define uma data mais próxima da solicitada que gere o menor impacto para ele. Nesse ponto ele avisa a todos os solicitados e solicitador essa nova sugestão.

Para as mensagens de Confirmação temos os seguintes dados: 1) Tipo da Mensagem; 2) Numero da Solicitação. Onde Tipo da mensagem é igual a “c”. Essas mensagens são usadas quando o agente consegue negociar com todos seus solicitados uma data comum para atendimento e retorna para o solicitador a confirmação que para ele está tudo certo para esta data.

Para as mensagens de Negativa temos os seguintes dados: 1) Tipo da Mensagem; 2) Numero da Solicitação. Onde Tipo da mensagem é igual a “n”. Essas mensagens são usadas quando o agente não tem recursos suficientes para atender uma certa tarefa, independente da data (por exemplo, uma carga que tenha dimensões maiores do que as portas do armazém). Quando esta mensagem é enviada todos os agentes começam a cancelar essa solicitação até que todos tenham retirado de suas agendas essa solicitação.

873

Fora essa situação os agentes sempre irão propor uma nova sugestão de data, para frente da data solicitada. Mesmo que seja distante da solicitada como no caso real do CD.

O conjunto de classes, escritas em Java, para dar suporte a essas tasks e actions do DECAF, foi encapsulado em uma única interface que é a base para o processo de escalonamento de cada agente.

Neste conjunto de classes estão as definições de como um agente é descrito. Temos como ponto focal duas classes: um pool de solicitações recebidas e um pool de recursos que o agente pode utilizar para executar as tarefas.

Nesse pool de recursos, para cada um recurso, uma agenda está associada. Nessa agenda ficam registradas as solicitações que estão alocadas em um determinado período. Pode-se padronizar esta interface para todos os agentes, pois foram criados arquivos de parâmetros que são carregados assim que o agente inicia.

As relações de conhecimento (acquatainces) são representadas em um arquivo texto, que apresenta todos os agentes para os quais o agente em questão deve enviar solicitações (solicitados) e quais agentes o agente pode receber solicitações (solicitadores). Para ambos, estabelece-se um canal de negociação (troca de mensagens).

Figura 4 - Modelo DECAF da mensagem do tipo Resposta

874

Isso é bastante interessante, pois aliado à padronização das mensagens, que são iguais para todos os agentes, podemos então garantir uma padronização do modelo de agente, que chamamos de Interface de Agente Geral que é a base de todos os agentes do sistema.

Vale ressaltar que cada agente implementado por essa interface, tem conhecimento único e exclusivo de seus recursos, agenda dos recursos, as solicitações recebidas e enviadas, as mensagens enviadas e recebidas o status de negociação (confirmada ou pendente) com os agentes os quais está negociando e nada mais externamente a ele.

Descrição do Sistema do Centro de Distribuição

Para o trabalho em questão, foi estabelecido que um CD para operar necessita dos seguintes

recursos: 1) Docas de recebimento de veículos; 2) Área de separação de pedidos; 3) Área de armazenagem; 4) Embalagem para expedição de carga; 5) Equipamentos para atender as docas, as áreas de armazenagem e as áreas de separação de pedidos.

Foram criados, baseados nos recursos acima descritos, seis agentes: CD, Doca, AreaSepara, AreaArmazena, Embalagem, Equipamento. Onde o agente CD para poder realizar suas tarefas precisa de recursos do agente Doca; O agente Doca para poder realizar suas tarefas precisa de recursos dos agentes AreaArmazena, AreaSepara, e Equipamento; O agente AreaArmazena para poder realizar suas tarefas precisa de recursos do agente Equipamento; O agente AreaSepara para poder realizar suas tarefas precisa de recursos do agente Embalagem e do agente Equipamento; O agente Equipamento e o agente Embalagem não precisam de recursos de nenhum outro agente para poderem concluir suas tarefas.

Figura 5 – Ambiente multiagente para o problema de recepção e expedição de caminhões em um CD As mensagens de solicitação para o problema do CD em especifico (podem ser parametrizadas

conforme o tipo de problema) possuem os seguintes dados: Numero de referência do Solicitador, Tipo de operação, Dados do veiculo, Dados da carga, Data/Hora Estimada de Chegada, Numero de Horas de Operação (Estimada).

Baseado na premissa de necessidade de cada agente foi estabelecido o seguinte fluxo de solicitações: 1) O agente CD recebe solicitação do mundo externo e envia solicitação para o agente Doca; 2) O agente Doca recebe solicitação do agente CD e conforme o tipo de operação envia solicitação para o agente AreaArmazena ou AreaSeparaPátio e para o agente Equipamento; 3) O agente AreaArmazena recebe solicitação do agente Doca e envia solicitação para o agente Equipamento; 3) O agente AreaSepara

Embalagem

Equipamento

AreaArmazena

Mundo Externo

AreaSepara

Doca

CD

875

recebe solicitação do agente Doca e envia solicitação para o agente Embalagem e agente Equipamento; 5) O agente Equipamento recebe solicitação dos agentes Doca, AreaArmazena e AreaSepara e não envia solicitação para nenhum outro agente; 6) O agente Embalagem recebe solicitação do agente AreaSepara e não envia solicitação para nenhum outro agente.

O funcionamento do sistema, tendo em vista a interface ser padrão, se dá de maneira igual para todos os agentes. Ao receber uma mensagem do tipo Solicitação o agente verifica se é possível atender na data solicitada.

Caso seja possível atender na data solicitada ele verifica quais os agentes ele deve solicitar para concluir sua tarefa e então envia uma mensagem do tipo Solicitação para cada um dos agentes. A partir deste ponto ele fica aguardando resposta de confirmação desses agentes solicitados.

Após ele receber a reposta de confirmação de todos os agentes solicitados ele retorna ao solicitador uma mensagem do tipo Resposta de subtipo confirmação que ele pode atender. Caso não seja possível atender a data solicitada, o agente decide qual a data melhor que ele pode oferecer. Nesse caso, ele envia ao solicitador uma mensagem do tipo Resposta de subtipo sugestão com a proposta de uma nova data.

Ele verifica quais os agentes ele deve solicitar para concluir sua tarefa e então envia uma mensagem do tipo Solicitação para cada um dos agentes solicitados com a nova data possível.

A partir deste ponto ele fica aguardando resposta de confirmação desses agentes solicitados. Após ele receber a resposta de confirmação de todos os agentes solicitados ele retorna ao solicitador uma mensagem Resposta de subtipo confirmação que ele pode atender.

Nas duas situações anteriormente apresentadas, pode ser que para atender uma nova solicitação chegada, o agente precise reorganizar sua agenda. Isso se deve ao fato que a inserção de uma nova solicitação pode afetar a data de atendimento, anteriormente acertada, de uma outra solicitação.

Nesses casos, o agente é capaz de verificar quais foram as solicitações afetadas e enviar para seus solicitados e seu solicitador mensagens do tipo Resposta de subtipo sugestão, apresentando a nova data possível para essas solicitações afetadas.

Para decidir quais recursos devem ser alocados à solicitação que esta chegando ou esta sendo alterada o sistema utiliza duas métricas: 1) A somatória de numero de solicitações afetadas; 2) A somatória do tempo de deslocamento, que é a diferença entre a data previamente alocada em relação a data que ira ser alocada, das solicitações afetadas.

Calculam-se os dois valores para cada recurso, e depois decide qual dos recursos tem os menores valores das métricas, sempre, primeiramente pela métrica 1 e se nesse caso for igual compara-se a métrica 2. Decide-se assim quais recursos devem ser alocados para a solicitação, e quais solicitações foram afetadas por essa nova solicitação que chegou.

Para cada um recurso afetado, três ações devem ser executadas: 1) Liberar as reservas da agenda (caso seja uma mensagem do Tipo Resposta subtipo sugestão, se for uma mensagem do Tipo Solicitação não precisa liberar, pois ainda não tem reserva); 2) Fazer novas reservas para a data possível que o agente calculou; 3) Se a data possível for diferente da data solicitada ou sugerida, o agente manda mensagem de sugestão ou uma solicitação alterada para todos os agentes que negociam com ele.

As mensagens do tipo Resposta de subtipo sugestão é que iniciam o processo de negociação entre os agentes. Ao receber uma mensagem deste tipo, o agente analisa se é possível atender e qual o impacto que esse atendimento gera na agenda de seus recursos.

A partir destes dados ele vê se pode atender na data sugerida, e quais são as solicitações que vão ter de ser reprogramadas em função da mudança de data da solicitação já agendada. A partir daí como na solicitação ele envia mensagens do tipo Resposta subtipo sugestão para o solicitador e para os solicitados desta solicitação. Envia também para todas as outras solicitações que foram afetadas pela inserção / alteração da data em questão. Ele envia essas mensagens visando buscar todos os recursos que ele necessita na nova data para a mensagem atual e para todas as outras que foram afetadas.

876

Com isso gera-se uma perturbação no equilíbrio da sociedade de agentes que à medida que os agentes vão trocando mensagens do tipo Resposta subtipo sugestão, eles vão voltando ao equilíbrio até que se chegue a uma nova data comum a todos.

Essa será a nova data de atendimento. Esse momento ocorre quando o agente recebe mensagem de confirmação da data de todos os solicitados e do solicitador. Caso haja alguma nova mudança ou inserção, gera-se uma perturbação na sociedade e começa-se novamente a busca do equilíbrio.

Existem agentes que não precisam solicitar a outros agentes, pois eles possuem tudo para concluir sua tarefa (no caso do CD, o agente equipamento e o agente Embalagem). Neste caso quando recebem uma mensagem do tipo Solicitação ou do tipo Resposta subtipo sugestão ele pode confirmar de imediato caso ele possa atender para o solicitador.

Esse tipo de agente que é o ponto de retorno do sistema, pois a partir dele, podemos ir retornando com as mensagens de confirmação que vão formar as confirmações dos agentes solicitadores destes e essa mensagem de confirmação pode ir subindo e confirmando até o agente que recebe solicitação do mundo externo.

Apresentação dos resultados

Foram realizados diversos testes com dados reais, e comparando-se o resultado com o resultado

obtido na prática, os testes mostraram que o sistema converge para uma solução do problema e que estas são sempre iguais ou melhores que o resultado alcançado por processos manuais e\ou convencionais conseguidos pelos centros de distribuição (CD).

Foram feitas cem execuções do sistema com nove solicitações, tabela 1, cada uma visando testar o sistema. Dessas cem execuções, oitenta e sete delas apresentaram soluções iguais às obtidas na prática para as nove solicitações, podendo ser consideradas como soluções muito boas. As outras treze execuções chegaram a uma solução para as nove solicitações. No entanto para três solicitações das nove das treze execuções, a solução ficou aquém de uma boa solução.

Solicitação Previsão Chegada Caminhão

No Tempo

Dados Caminhão Carga

Dia Mês Ano Hora

Tempo Operação

0 00 seg 12;27,5;Sr C;1;17 01 01 2002 22 17 Hs

1 01 seg 8;15;Tr P;10;5,5 01 01 2002 22 17 Hs

2 03 seg 6;9;Tr P;5;0,5 01 01 2002 21 17 Hs

3 04 seg 12;27,5;Sr C;1;12 01 01 2002 20 77 Hs

4 04 seg 12;27,5;Sr C;1;14 01 01 2002 22 10 Hs

5 04 seg 8;15;Tr P;6;1,5 05 01 2002 08 06 Hs

6 04 seg 8;15;Tr P;4;0,8 05 01 2002 05 03 Hs

7 04 seg 12;27,5;Sr C;1;14 05 01 2002 12 24 Hs

8 04 seg 12;27,5;Sr C;1;20 01 01 2002 09 05 Hs

Tabela 1 - Dados de teste do sistema proposto

877

Isso ocorreu porque a métrica busca a melhor situação para um recurso de cada vez, e às vezes pode ocorrer de ser a melhor opção para o recurso àquela inserção de um novo agendamento, no entanto as solicitações reagendadas poderiam ser mais bem acomodadas se fossem agendadas em outro recurso do agente. Esse caso seria de fácil solução, no entanto geraria alto custo computacional. A solução seria a cada novo agendamento em um recurso analisar todos os outros recursos do agente e reagendar todo, isso seria inviável computacionalmente, e estão sendo analisadas outras soluções computacionalmente mais viáveis.

Uma outra situação, que na prática não deve ocorrer, mas deve ser relatada, tendo em vista o agente não conseguir chegar a solução, diz respeito a falta de recursos reais para atender solicitações simultâneas que devem ser agendadas para a mesma data. Esse caso pode ocorrer no caso de equipamentos que devem atender as docas, a área de separação e área de armazenagem simultaneamente e sistema deveria ser sensível para perceber essa situação e mandar uma mensagem que não é possível atender. Hoje o sistema não consegue dar essa resposta. Essa situação está sendo tratada através de mecanismo de detecção de cenário local ao agente, no qual caso o mesmo cenário ocorra várias vezes, sem mudança, o agente deve abortar as tentativas e negar a solicitação. Sempre a solução deve ser local, sem conhecimento global a fim de preservar a independência e autonomia de cada agente. Esse problema só ocorreu quando forçamos um cenário de teste, no entanto acredita-se que na prática essa situação seja muito remota de acontecer. Conclusões

A utilização de agentes para escalonamento de recursos se mostrou factível e consistente para o

problema de recebimento e expedição de caminhões em um centro de distribuição. As ferramentas DECAF, KQML e Java apresentam robustez suficiente para suportar um sistema

real de alocação de recursos e flexibilidade para poder implementar as soluções que o problema requer. O sistema desenvolvido pode ser distribuído, por diferentes áreas físicas. Sendo interligadas por

rede TCP\IP, permitindo assim que os recursos estejam dispersos geograficamente (por exemplo: dois CDs em duas localidades diferentes trabalhando como se fosse um só) o que é muita das vezes a realidade de várias empresas.

A divisão de um problema complexo de alocação em diversos subproblemas mais simples, cada um tratado por um agente, representa uma alternativa interessante para problemas de alocação. Principalmente devido a sua flexibilidade, podendo ser estendido para tratar de problemas mais complexos.

A substituição de modelos matemáticos rígidos por modelos inteligentes baseados em agentes se mostrou factível, alcançando bons resultados e mostrando ser esse um caminho possível para se resolver o problema de escalonamento dinâmico, sendo essa uma linha de pesquisa que demanda mais estudos e mais testes para consolidá-la como uma boa ferramenta para problemas de escalonamento.

Novos desenvolvimentos e melhorias no sistema, inclusive nas métricas propostas, estão sendo analisadas e implementadas.

Referências Ballou, R., “Gerenciamento da Cadeia de Suprimentos”, 4a Ed. São Paulo: Bookman, 2001 Blazewicz, J., Ecker, K., Pesch, E, Schmidt,W., “Scheduling Computer and Manufacturing Process”, Springer Verlag, Heidelberg, 1996. Chaib-Draa, B. “Industrial Applications of Distributed AI” In Huhns, M., Singh, M. “Readings In Agents”, Morgan Kaufmann Publishers, USA, 1997 Chavez, A. Moukas, A., Maes, P. “Challenger: A Multi Agent System For Distributed Allocation”, ACM, Agents 1997, Conference Procedings.

878

Cunha, A., Belo, O. “Resource Allocation On Agent Meta-Societies”, Oitavo Encontro Português de Inteligência Artificial (EPIA'97), Coimbra, Portugal, 1997. Eckel, B., “Thinking In Java”, 3rd Ed., Prentice Hall PTR, 2002. Feber, J., “Multi Agent Systems An Introduction Do Distributed Artificial Intelligence”, Addison Wesley, 1999. Finin,T., Wiederhold,G. et al., "Specification Of The KQML Agent-Communication Language Plus Example Policies And Architectures", DARPA KSE External Interfaces Working Group Draft., 1994. Graham, J. “Real-Time Scheduling In Distributed Multi Agent Systems”, PhD Thesis, University of Delaware, 2001. Jennings, N. “Controlling Cooperative Problem Solving In Industrial Multi-Agent Systems Using Joint Intentions”, Artificial Intelligence Journal, 75(2):1-46, 1995 Jennings, N., Sycara, K, Wooldridge, M. “A Roadmap Of Agent Research and Development”, Autonomous Agents And Multi-Agents Systems, 1, 7-38, Kluwer Academic Publishers, Boston, 1998. Kraus, S. “Strategic Negotiation In Multi-Agent Environments”, MIT Press, Cambridge, USA, 2001. Parunack, H., “Industrial and Pratical Applications of DAI”, In WEIS, G. (Org), “Multiagent Systems, A Modern Approach to Distributed Artificial Intelligence”. Cambridge, MIT Press, 1999. Shehory, O. Kraus, S., “Methods For Task Allocation Via Agent Coalition Formation”, Elsevier Science, 1998. Sycara, K. Roth, S. , Sadeh-Koniecpol, N., Fox, M. “Resource Allocation in Distributed Factory Scheduling” IEEE Expert, Vol. 6, No. 1, February, 1991, pp. 29-40. Weis, G. “Multiagent Systems, A Modern Approach to Distributed Artificial Intelligence”. Cambridge, MIT Press, 2000.