1 INTRODUÇÃO

Inteligência artificial distribuída (DAI) explora como um grupo de sistemas computacionais autônomos e inteligentes (agentes), coordenam seus conhecimentos, objetivos, planos e habilidades com o objetivo de alcançar metas. O método DAI tem se tornado útil para aplicações na qual um método de projeto centralizado seja impróprio ou até mesmo impossível para a realização de uma determinada tarefa.

A tarefa de um testbed para aplicações de DAI é fornecer ao projetista uma aplicação com as ferramentas necessárias para construir agentes, descrever suas interações, construir o ambiente no qual eles estão agindo, e suportar a simulação da aplicação no computador. Os testbeds devem ter as seguintes funcionalidades:

• Produzir e processar eventos

• Variar a complexidade do mundo

• Modelar o custo e qualidade de perceber e efetuar como também medir a qualidade do plano

• Negociar com múltiplos agentes

• Prover uma interface limpa entre os agentes e o mundo do testbed

• Modelar o curso do tempo

• Suportar experimentação controlada

  Neste artigo é descrito o testbed AGenDA , usado para projetar aplicações DAI . Esse testbed está sendo desenvolvido no grupo de pesquisa em multiagente em DFKI. O testbed é formado por dois níveis diferentes: o nível de arquitetura descreve uma metodologia para projetar agentes de forma que ele forneça várias funcionalidades importantes que um agente deve Ter. O nível de desenvolvimento de sistema fornece o básico formalismo de representação do conhecimento, mecanismos de inferências e uma caixa de ferramentas para simulação, que suporta visualização e monitoramento de agentes. O inter-relacionamento entre os dois níveis é ilustrado na figura seguinte.

O nível de arquitetura é provido pela arquitetura de agente InteRRaP. Ela define o controle dentro de um agente como um processo hierárquico, mapeando diferentes classes de situações para diferentes reações, deliberações, ou mecanismos de execuções cooperativas. O nível de desenvolvimento de sistema é coberto pelo sistema MAGSY, o qual fornece um formalismo para representação do conhecimento e um conjunto de mecanismos de inferência. Além disso ele disponibiliza ferramentas que suportam a construção, visualização, avaliação e depuração de cenários DAI .

Duas aplicações têm sido implementadas usando o framework AgenDA: o primeiro sistema é o FORKS (uma aplicação para a interação de robôs). O segundo sistema é o MARS, que modela uma sociedade de agentes (consiste de companhias de transportes e seus caminhões que devem realizar o transporte e entrega de pedidos.

2 O NÍVEL DE ARQUITETURA: InteRRaP

Nesta seção é explicado a idéia fundamental do modelo de agente InteRRaP e sua estrutura funcional básica. A principal idéia do InteRRaP é definir um agente através de um conjunto de camadas funcionais, unida por uma estrutura de controle baseada em comunicação e uma base de conhecimento hierárquica compartilhada. Os elementos básicos para o projeto de agentes são: (1) facilidades na sua interface mundial, (2) padrões de comportamento, (3) planos locais e articulação, bem como (4) planos multiagentes.

A figura seguinte mostra os componentes do modelo de agente InteRRaP e seu interplay.

O InteRRaP consiste basicamente de cinco partes: a interface mundial (WIF), o componente baseado em comportamento (BBC), o componente baseado em plano (PBC), o componente de cooperação (CC), e a base de conhecimento do agente. O WIF permite aos agentes facilidades para percepção, ação e comunicação. O BBC implementa o comportamento reativo e o conhecimento procedural do agente. O PBC contém mecanismos de planejamento, que concebe planos de agentes isolados. Finalmente o CC contém um mecanismo para criar a união desses planos. A base de conhecimento é estruturada hierarquicamente. Ela consiste de três camadas, as quais correspondem basicamente para a estrutura de controle do agente. A camada mais baixa contém fatos que representam o world model do agente bem como representações de ações primitivas e padrões de comportamento. A segunda camada contém o mental model do agente. A terceira camada é composta do social model do agente, que fornece por exemplo, conhecimentos de estratégias para cooperação e crenças sobre metas de outros agentes.

 

3 O NÍVEL DE DESENVOLVIMENTO DE SISTEMA: MAGSY

As funcionalidades como reação, planejamento, e cooperação providas pela arquitetura de agente InteRRaP requer um formalismo para a representação do conhecimento bem como uma classe de mecanismos básicos para projetar inferências neste conhecimento. Além disso eles devem ser complementados por um conjunto de funcionalidades de testbed específicas para simulação e avaliação. Estas funcionalidades são fornecidas pelo ambiente de desenvolvimento de sistema MAGSY.

3.1 REPRESENTAÇÃO DO CONHECIMENTO

MAGSY fornece um mecanismo geral centrado em objeto para a representação do conhecimento. O conhecimento é mantido em uma hierarquia de classe. Objetos de conhecimento são descritos através de uma estrutura de valores de atributos baseada em frame. Os relacionamentos suportados entre as diferentes classes são especializados e generalizados. Relacionamentos entre classes podem ser representadas por regras usando um conjunto de operações (união, interseção, subconjunto e superconjunto. O membro de uma classe de objetos individuais podem ser mudados dinamicamente , assim as regras são aplicadas para manter a consistência. A base do conhecimento é um componente encapsulado que fornece mecanismos necessários para o acesso concorrente.

3.2 MECANISMOS DE INFERÊNCIA BÁSICA

A implementação do MAGSY começou usando uma linguagem baseada em regras para o projeto de cada agente isolado. Recentemente o sistema MAGSY foi redesenhado em cima de uma linguagem orientada a objetos baseada em restrição concorrente. Este mecanismo é usado para avaliar as condições de ativação e monitoramento de padrões de comportamento no BBC dos agentes InteRRaP.

3.3 FUNCIONALIDADES DO TESTBED

A maior funcionalidade do MAGSY é fornecer um ambiente de simulação para aplicações DAI, suportando comunicação, visualização e experimentação. Estas funcionalidades são detalhadas a seguir:

COMUNICAÇÃO: MAGSY mantém uma interface de comunicação coberta por quatro camadas mais baixas do modelo de comunicação OSI/ISO. Ele usa o fluxo de interface port/socket de TCP/IP para trocar mensagens entre agentes. Isto permite distribuir os agentes de uma aplicação em qualquer número de diferentes computadores em uma área de rede local. A camada mais alta usa um pequeno subconjunto da linguagem KQML.

SIMULAÇÃO: As funcionalidades de simulação suportadas pelo MAGSY pode ser dividida em funcionalidades de agentes relacionados, serviços de visualização e monitoramento, e suporte a experimentação. Estes são explicados a seguir:

SERVIÇOS DE AGENTES: O ambiente de simulação MAGSY oferece serviços que permitem criar e configurar diferentes tipos de agentes interativamente ou através de descrições pré-definidas. Agentes podem determinar instruções, e iniciar ou suspender um processo de simulação. MAGSY suporta um simples modelo de tempo baseado em ponto. Além disso, agentes podem ser equipados com diferentes estratégias de cooperação.

VISUALIZAÇÃO E MONITORAMENTO: Uma interface de usuário baseada em OSF/MODIF é usada para visualizar a simulação de aplicações. Atualmente o suporte para visualização do testbed é restrito para uma biblioteca de funções gráficas independentes. Este meio, contudo, é uma quantia reduzida mas ainda considerável de programação necessária para fornecer visualização gráfica para novas aplicações. O mundo de simulação é projetado como um processo separado com interfaces claramente definidas para o módulo de visualização e para os agentes.

O monitoramento de agentes é fornecido por uma ferramenta de localização. Uma interface de comunicação entre o tracer e o agente tem que ser definida. Isto permite mostrar a atividade dos agentes em diferentes camadas da arquitetura InteRRaP.

SUPORTE A EXPERIMENTAÇÃO: MAGSY fornece um módulo estatístico que é capaz de reunir estatísticas de desempenho, tal como o tempo e o custo perdido para a solução de um problema, informações sobre a freqüência de conflitos e sobre os resultados de negociações, via uma interface de comunicação com os agentes. Dados estatísticos são preparados e podem ser mostrados graficamente. Diferentes parâmetros de sistema tais como, a configuração da simulação do mundo, a configuração e o número de agentes podem ser variados, e eventos exogenous (por exemplo, engarrafamento no cenário de transporte) podem ser disparados.

4 REATIVIDADE E DELIBERAÇÃO NA INTERAÇÃO ENTRE ROBÔS

A aplicação FORKS descrita nesta seção, simula um carregamento automatizado de docas. No carregamento de docas, há containers que podem conter diferentes tipos de mercadorias.

Os agentes neste cenário são elevadores com uma extremidade em formato de garfo automatizados que carregam e descarregam caminhões.

É utilizada uma representação baseada em grades para o carregamento de docas.

As ações primitivas dos elevadores são mover de um lugar para outro, andar ao redor, pegar e armazenar mercadorias e comunicar-se com outros agentes. Cada agente tem uma certa faixa de percepção.

4.1 A Interface com o Mundo

A interface para o mundo compreende as facilidades de ação, comunicação e percepção do agente. O componente de ação controla as capacidades de execução do agente. Estas capacidades são muito dependentes do domínio. No caso dos robôs elevadores, são ações como walk-ahead, turn-left, turn-right, put-box, grasp-box.

A unidade de comunicação suporta as facilidades comunicativas dos agentes. Ela controla os componentes físicos para o envio e recebimento de mensagens. Mensagens de saída são transformadas da linguagem interna do agente para um formato de troca de conhecimento (chamada interlíngua) que é entendida por todos os agentes. Logo, mensagens de entrada devem ser transformadas na linguagem local do agente. Esta transformação é feita por um MÓDULO TRADUTOR.

A parte da percepção controla a visão e as facilidades de sentir dos agentes. A implementação concreta deste módulo depende dos tipos de agentes desejados para o modelo.

Neste sistema de simulação cada agente é equipado com uma faixa configurável de percepção (nxm quadrados).

4.2 Integrando Reação e Deliberação

Após a definição da interface com o mundo físico, é necessário definir como a informação que é percebida pelos agentes é processada, como decisões são tomadas baseadas nesta informação e finalmente a execução de ações. No framework InteRRaP, o comportamento local é basicamente determinado por dois componentes e a maneira que eles interagem: o  O COMPONENTE BASEADO EM COMPORTAMENTO (BBC) e O COMPONENTE BASEADO EM PLANO (BPC). Abaixo são descritos ambos componentes através da aplicação FORKS.

O Componente Baseado em Comportamento (BBC)

O BBC implementa o comportamento reativo básico de um agente assim como seu conhecimento procedural. É definido por um conjunto de "padrões de comportamento" e por um mecanismo de controle gerenciador destes padrões.

Padrões de Comportamento (PoB)

PoB são primitivas estruturais do componente baseado em comportamento. Eles incorporam habilidades reativas e conhecimento procedural de um agente. Permite que um agente reaja rapidamente, flexivelmente e freqüentemente evita replanejamentos explícitos, para certos eventos não esperados, fornecendo primitivas para o comportamento baseado em plano de um agente InteRRaP.

Há duas classes básicas de padrões de comportamento:

• Padrões reatores: basicamente são reativos
• Padrões procedurais: mecanismos que não estão representados de uma forma declarativa, mas que são basicamente precedimentos.

Controle

O controle do BBS é implementado em um ciclo de processamento: em cada loop, ele monitora mudanças no modelo do mundo causadas pela percepção e por comandos recebidos dos componentes baseados em plano.

De acordo com o novo estado do mundo, vários Padrões de Comportamento podem ser ativados pois suas condições de ativação foram satisfeitas ou porque eles estavam ativos e não finalizaram sua atividade.

Determinação do Padrão Ativo

É possível considerar que um padrão p possui p.AC, p.TC e p.FC que denotam a ativação, a finalização e a condição de falha de um padrão, respectivamente. Um padrão é chamado ativo em um certo tempo se a condição de ativação é satisfeita, ou se está ativo e não finalizou ou falhou.

Seleção de Padrão

Como somente um padrão tem o controle para inicializar uma ação em um dado momento, temos um modelo seqüencial de execução. Isto requer a seleção de um padrão em cada ciclo do BBC. Um conjunto de mecanismos para resolver o problema de seleção de padrões estão sendo atualmente discutidos.

Execução de Padrão

Finalmente, o PoB que foi selecionado vai ser executado. Este mecanismo de execução fornece um mecanismo de escalonamento de padrões de comportamento com o objetivo de obter alto nível de concorrência de padrões.

Aplicações no FORKS

Padrões para o comportamento reativo básico foram projetados para reconhecer uma nova ordem de transporte, reconhecer quando uma caixa é encontrada, evitar uma colisão, e outros.

PoB procedurais representam ações de rotinas abstratas que são usadas para mover para um lugar, segurar e guardar uma caixa, e outras.

O Componente Baseado em Plano (PBC)

O PBC do modelo InteRRaP contém as facilidades de planejamento local de um agente.

Há dois modos padrão de PBC: o primeiro é para criar um plano para um objetivo requisitado por um BBC e para controlar a correta execução do plano. O segundo é para interpretar a parte de um agente em um plano em conjunto designado pelo Componente de Cooperação (CC).

 

4.3 Coordenação e Resolução de Conflitos Cooperativa

Algumas situações excedem a capacidade de resolução de problemas do PBC. Nestes casos, o controle é transferido para o Componente de Cooperação (CC). A principal funcionalidade do CC é que ele cria um "plano misto " para uma certa situação, dada uma descrição de um contexto da situação e do contexto mental. As partes básicas do CC são: O CONTROLE DO CC, O GERADOR DO PLANO MISTO, O AVALIADOR DO PLANO MISTO, O TRADUTOR DO PLANO MISTO

O Controle do CC

Primeiro, este módulo serve como uma interface entre o CC e o PBC. Segundo, coordena o trabalho dos outros submódulos do componente. Terceiro, contém um classificador disponível para mapear a descrição de uma meta.

O Gerador do Plano Misto

A tarefa deste módulo é retornar um conjunto de "planos mistos" para uma dada especificação de situação. A seleção de planos é feita puramente por combinação.

O Avaliador do Plano Misto

Como planos mistos são subjetivos, o agente deve saber avaliar um plano misto que está sendo proposto por outro agente. Logo, para gerar planos mistos sensatos, o agente deve ter uma medida para saber o que é um plano sensato, que é dado pela utilidade do plano.

O Tradutor do Plano Misto

Executa a tarefa de transformar um plano misto em um plano simples de um agente, projetando as partes de um agente e adicionando ações sincronizadas, garantindo que o plano misto original seja satisfeito durante a execução do plano.

4.4 Controle

Os módulos do modelo InteRRaP trocam informações e transferem o controle por meio da comunicação.

Este processo pode ser descrito em duas dimensões, uma dimensão bottom-up e uma dimensão top-down.

Como as tarefas se tornam mais complexas, o controle para esta tarefa é transferido da camada mais baixa para a mais alta até um controle apropriado ser encontrado.

Ao mesmo tempo, camadas mais altas ficam ativas e podem arcar com novos eventos. Então, para execução da tarefa, controles de fluxos retornam de camadas mais altas para mais baixas, resultando na execução de ações primitivas na interface do mundo.

Exemplos: Execução de uma tarefa, Coordenação na Resolução de Conflitos

5 COOPERAÇÃO E EXPERIMENTAÇÃO CONTROLADA

A segunda aplicação construída usando o AGenDA testbed foi o sistema MARS, uma simulação de companhias de transporte cooperativo. Dentre as perspectivas do testbed, o principal desafio no caso do MARS foi:

• oferecer diferentes métodos de cooperação baseado na negociação, que habilita-se o projetista de sistema construir um conjunto de diferentes estratégias de programação distribuída;
• prover experimentação de maneira a poder avaliar o desempenho dessas estratégias e comparar a qualidade das soluções encontradas pelo MARS com as tradicionais abordagens para esse problema.

5.1 O Sistema MARS

Esta seção oferece uma pequena introdução sobre a estrutura do sistema MARS.

O cenário MARS (Modelagem Autônoma de Companhias de Transporte Cooperativo) implementa um grupo de companhias de transporte cujo objetivo é entregar um conjunto de pedidos determinados dinamicamente, satisfazendo um conjunto em um dado tempo e/ou limite de custo. A complexidade envolvida nos pedidos pode exceder a capacidade de uma simples companhia. Portanto, a cooperação entre as companhias é requerida de maneira a alcançar os objetivos de maneira satisfatória. Este conjunto geral pode ser visto na Figura 15.8.

Informações incompletas relativas a pedidos e a capacidade de compartilhar recursos permite e requer cooperação entre as diferentes companhias. Embora cada companhia de transporte tenha um local, primariamente com a visão de interesse próprio, a cooperação entre elas é necessária para que se alcance razoavelmente os planos globais. Separadamente dos agentes de sistemas internos (internal system agent), que executam as tarefas tais como representação e visualização do mundo de simulação, a sociedade de agentes MARS consiste de dois tipos de agentes de domínio (domain agent), que correspondem às entidades lógicas no domínio: companhias de transporte (shipping companies) e caminhões(trucks). Em contraste a outras abordagens decidiu-se olhar os caminhões como um agente. Esta visão permite delegar a eles a resolução de problemas com habilidade (tais como planejamento de rota e plano de otimização local). Além disso, obtém-se uma distribuição lógica do sistema mesmo se considerado somente uma simples companhia. Os padrões de cooperação que podem ser observados em negócios de transporte real são: (i) a troca e recuperação da informação entre os agentes; (ii) distribuição de tarefas entre companhias e caminhões (contracting) usando um Contract Net Protocol; (iii) equilibrar a carga dos caminhões de companhias diferentes oferecendo ou pedindo espaço de carga; (iv) negociar as condições para pedidos entre as companhias (v) ter organizado o frete de retorno de um caminhão por uma companhia sócia na região de destino (vi) estabelecer a conexão entre tráfico local e a longo prazo por cooperação.  

5.2 Cooperation Settings

Agentes no AGenDA testbed podem ser equipados com diferentes capacidades de cooperação: os diferentes tipos de comportamento cooperativo que emerge das diferentes configurações são chamados "Cooperation Settings".

Dois cooperation settings são relevantes no domínio de transportes, sendo eles: Vertical Cooperation e Horizontal Cooperation. O primeiro pode ser usado como um protocolo padrão entre uma companhia de transporte e seus caminhões. O segundo considera o fato que companhias são autônomas, entidades de interesse próprio e que elas irão somente cooperar se isso aumentar sua utilidade local, o testbed suporta Cooperação Horizontal por oferecer um protocolo de negociação geral.

Cooperação Vertical: A Extended Contract Net Protocol – O Contract Net Protocol (CNP) é uma famosa técnica de resolução de problemas de DAÍ que pode ser usado para distribuir tarefas entre um conjunto de agentes. Porém o puro Contract Net Protocol terá problemas se as tarefas excederem a capacidade de um simples caminhão. Neste caso, o gerente da tarefa, i.é, a companhia de transporte agente tem que resolver um problema knapsack que por ele próprio é em geral um NP difícil. Para superar esse problema, foi descentralizada a decomposição de tarefas através do desenvolvimento e implementação de uma extensão de CNP chamada ECNP que é um protocolo padrão disponível no AGenDA. Em uma ECNP as duas ações de discurso grants ou reject (concede ou rejeita) são substituídas por quatro novas ações de discurso: temporal grant, temporal reject, definitive grant e definitive reject (concessão temporal, rejeição temporal, concessão definitiva e rejeição definitiva). A ECNP é uma solução direta e natural de uma tarefa de decomposição de problema.

Uma representação flowchart é usada para representar o protocolo de negociação oferecido pelo AGenDA testbed. Um protocolo descreve as regras disputadas pelos agentes individuais no protocolo. Ver Fig 15.9.

A comunicação no ECNP procede da seguinte forma: O gerente (companhia de transporte) anuncia um pedido a seus caminhões. Ele então recebe propostas para o pedido e seleciona a melhor usando uma função de ordenação. O caminhão que ofereceu a melhor proposta é dado como temporal grants. Todos os outros caminhões são dados como temporal reject. Se a melhor oferta não cobre a toda a quantidade do pedido, a companhia de transporte reanuncia a parte restante do pedido. Este procedimento é repetido até a companhia de transporte receber uma proposta que cubra toda a quantidade do pedido que foi finalmente reanunciado. Neste estágio a companhia de transporte tem reunido um conjunto de propostas que cobre o pedido original total. Este conjunto é usado para calcular uma oferta para toda a tarefa, que é retornado ao agente corretor. As concessões posteriores o melhor de todas as ofertas recebidas pelas companhias diferentes. Baseado nesta resposta, a companhia de transporte passa um definitive grant (ou definitive reject respectivamente) para todos os caminhões que tinham temporal grants anteriormente. "Alguém pode mostrar que todas menos a última proposta selecionada são localmente ótimas escolhas para a companhia de transporte" (Fischer et al., 1994). Isso oferece uma valiosa sugestão para próximas melhorias no ECNP.

Por um outro lado, os caminhões devem poder enfrentar mais adiante o temporal e definitive grant ou reject messages. Quando um caminhão recebe um grant temporal pela primeira vez, ele tem que armazenar uma cópia de sua situação local, i.é, o plano válido atualmente, porque ele deve ser capaz de restituir esta situação uma vez que adquire um definitive reject. Todos os temporal grants e temporal rejects subsequentes são dados como concedidos ou rejeitados no Contract Net Protocol. Se a um caminhão é enviado um definitive grant para um pedido, ele remove a cópia criada acima. Se um caminhão adquire um definitive reject, ele tem que remover todas a informação local reunida enquanto estiver recebendo temporal grants e reestabelecer a situação antes do primeiro temporal grant.

 

Cooperação Horizontal por Negociação – Aperfeiçoar o uso das capacidades de transporte é um objetivo crucial para uma companhia de transporte por várias razões econômicas e ecológicas. Devido à distribuição espacial e temporal das entradas dos pedidos, a cooperação com outras companhias pode ser uma operação proveitosa para uma companhia de transporte. Por exemplo, companhias podem trocar pedidos e informações sobre capacidades de cargas livres, e podem solicitar pedidos oferecidos por outros companhias. Porém, em contraste a coordenação entre uma companhia e seus caminhões, a cooperação entre companhias é um processo peer-to-peer onde uma solução pode ser somente encontrada se todos os participantes concordam, e onde as condições de solução devem ser negociadas entre as companhias. E esta negociação peer-to-peer pode ser chamada cooperação horizontal.

Protocolo de Negociação – AGenDA suporta a modelagem de cooperação horizontal por oferecer um protocolo de negociação parametrizado que pode ser instanciado com as condições específicas de negociação. A Figura 15.10 (ver artigo original) ilustra o protocolo por meio de um flowchart. Ela mostra os tipos de mensagens trocadas entre as companhias (representado por seus nós de decisões locais e pela conexão para o protocolo de cooperação vertical com seus caminhões) e raciocínio cooperativo no curso da negociação. Uma companhia (c1, por exemplo) pode decidir anunciar a capacidade de transporte livre a outra companhia (c2, por exemplo). Esta decisão pode ser tomada baseado em informação sobre as capacidades livres de c2 recebidas por seus caminhões. Com base no estado local, c2 decide se que utilizar a notificação, e se sim, envia um pedido para c1. Neste protocolo de negociação onde c1 tem o papel do agente de oferecimento, c2 toma a posição de ordenador. C1 começará enviando uma oferta a c2; c2 decidirá se irá aceitar, rejeitar, ou modificar a oferta C2 fazendo um counteroffer. O processo de negociação continua até ambas as partes terem concordado em uma solução comum ou até que fique claro que nenhum acordo pode ser feito.

Tomada de Decisão – A Tomada de Decisão das companhias durante a negociação é baseada na informação que eles obtêm de seus caminhões, e.g., informações sobre capacidades livres e custos. Isto permite a uma companhia determinar como a cooperação distante conduzirá a um aumento de sua utilidade local. Outra questão importante para tomada de decisão é a modelagem do companheiro; por exemplo, se todos os agentes tem conhecimento completo sobre o critério de decisões de todos os outros agentes, cada agente pode localmente calcular se há uma solução onde todos os seus companheiros concordem. No caso onde todos os agentes tem o mesmo critério de decisão, dois agentes poderiam concordar diretamente no valor da primeira oferta, desde que a negociação seja convergente com este valor. Porém, na realidade, os agentes não tem o completo conhecimento sobre um outro; isto torna o processo de negociação interessante. No sistema atual, a modelagem do agente (partner modeling) é restringida a agentes que fazem suposições simples nos parâmetros de outros agentes. Há vários parâmetros configuráveis que podem ser usados para variar o comportamento de tomada de decisão de um agente (lucro desejado, em porcentagem, para um pedido; lucro mínimo, em porcentagem, aceito por um agente; entre outros).

Oferecer um conjunto de configurações e estratégias diferentes para agentes é uma das importantes funcionalidades de um testbed; contudo, ele tem que ser complementado por ferramentas de execução, monitoração e avaliação dos experimentos de maneira a derivar propriedades gerais de características que são produzidas por um testbed.

 Experimentação Controlada - A habilidade de suportar uma experimentação de um modo controlado é uma característica crucial de qualquer testbed. O AgenDA suporta a derivação de resultados empíricos em um MARS.

A figura 15.11 (ver artigo original) apresenta um snapshot de uma ambiente de simulação para o Sistema MARS descrito na seção 5. O testbed permite variar as características dos agentes, e.g., os métodos de cooperação podem ser usados por companhias e os algoritmos de planejamento locais usados pelos planos. Baseados nestas variações diferentes tipos de experimentos podem ser executados, e dados estatísticos relativo ao custo dos planos, o número de mensagens, e a taxa de sucesso do processo de cooperação que podem ser reunidos. Dois tipos de experimentos foram carregados através do Sistema MARS: Experimentos de avaliação interna e Experimentos de Avaliação Externa.

Os Experimentos de Avaliação Interna foram usados para o estudo de custo e a utilidade de diferentes negociações e estratégias de cooperação desenvolvidas para o Sistema MARS. Eles mostraram a utilidade da cooperação horizontal entre diferentes companhias de transporte, mas também que o atual benefício destes métodos depende dos custos de cooperação nas aplicações.

Os Experimentos de Avaliação Externa foram executados para avaliar o desempenho do sistema em comparação com outras abordagens heurísticas de AI e com abordagens padrões de OR. Deste modo, foi possível mostrar que o desempenho da programação de um MARS foi comparável ao desempenho de um algoritmo OR. Além disso foi capaz de resolver problemas dinâmicos que estavam fora do escopo de outros algoritmos usados nos teste de benchmark.

 

6 AVALIAÇÃO

Nesse artigo foi descrito o AGenDA testbed, um framework geral para o projeto de aplicações DAI. Os dois subsistemas do AGenDA, a arquitetura agente InteRRaP e o ambiente de desenvolvimento MAGSY. O uso prático do testbed foi mostrado no desenvolvimento de dois sistemas para dois domínios: o domínio de transporte e o domínio de carga em docas com interação entre os robôs.

Sumarizando:

• Eventos exógenos (Exogenous Events) – no AGenDA, eventos exógenos ocorrem devido a ação com outros agentes; adicionalmente ele pode ser causado pelo usuário, geralmente, quando o tráfego começa a ficar muito intenso no Sistema MARS.
• Complexidade do Mundo (complexity of the world) – baseado na representação geral do conhecimento gerado pelo nível MAGSY, o AGenDA permite uma representação muito geral dos objetos do mundo e o relacionamento ocasionado entre eles. O outro lado da moeda é que por não impor grandes restrições à estrutura do mundo o AGenDA, atualmente, não provê muito suporte e orientação para modelar um determinado ambiente.
• Custo e qualidade de percepção / efeito / planejamento (cost and quality of sensing/effecting/planning) o testbed é um modelo de utilidade simples para ações e planos. Ele correntemente não suporta meta-raciocínio no senso de planejar a qualquer hora.
• Múltiplos agentes (Multiple Agents) – coordenação e cooperação entre agentes é suportada pela facilidades de comunicação de baixo-nível, protocolos de negociação pré-definidos e facilidades de planejamento cooperativo.
• Interface do Mundo (World Interface) – a interface entre o agente InteRRaP e o componente de simulação do MAGSY é claramente definido; ela é uma semântica clara de ações e percepções.
• Modelo de Tempo (Time Model) – AGenDA tem um modelo de tempo point-based simples que é usado como base para os algoritmos de programação nos sistemas MARS.
• Suporte a experimentação (Experimentation Support) – o testbed fornece um rico ambiente de experimentação permitindo variações dirigidas ao objetivos do agente e parâmetros ambientais, e provê ferramentas para avaliação estatística.

Concluindo, o desenvolvimento de um testbed útil para aplicações DAI como as apresentadas neste artigo é uma tarefa muito difícil, obviamente, ele é um intermediário entre a generalidade oferecida por uma ferramenta e sua utilidade para uma classe específica de aplicações. Trabalhos futuros devem apontar para uma melhoria nos relacionamentos entre a generalidade e o projeto de suporte, iniciando em um alto degrau de generalidade e um baixo degrau de suporte.