Uma Abordagem de Simulação e Controle de Tráfego Utilizando Sistemas Multiagente

Transcrição

1 Uma Abordagem de Simulação e Controle de Tráfego Utilizando Sistemas Multiagente Trabalho curricular apresentado à Universidade Federal de Santa Catarina como requisito para a disciplina: DAS 6607: Inteligência Artificial Aplicada a Sistemas de Controle e Automação Maiara Heil Cancian Ricardo Bedin França Florianópolis, setembro de 2007

2 Resumo Neste trabalho, foi proposto um sistema para simulação e controle de um tráfego urbano, baseado em sistemas multiagente cujos agentes utilizam sistemas especialistas para realizar tarefas inteligentes. O conhecimento necessário para o funcionamento do sistema foi representado numa ontologia, construída com o software Protegé. A plataforma AGLETS foi utilizada a fim de prover o suporte necessário aos sistemas multiagente, assim, pôde-se organizar uma estrutura hierárquica de agentes, onde um agente principal comanda os veículos, também representados por agentes. Uma rede de contrato foi estabelecida para resolver o problema de designação de uma ambulância para atender a um chamado de emergência. As regras utilizadas para reger o movimento dos veículos foram implementadas com o uso de sistemas especialistas, estes criados com o uso do script shell JESS. Palavras Chave: Agentes, sistemas Multiagente, AGLETS, JESS, contole de tráfego. ii

3 Sumário Lista de Figuras v 1 Introdução 1 2 Fundamentação teórica Ontologias Sistemas Especialistas Motor de inferência Modo de raciocínio Estratégia de busca Resolução de conflito Representação de incerteza Sistemas Multiagente Agentes Inteligentes Redes de Contrato Ferramentas utilizadas Protégé AGLETS JESS Descrição do Sistema de Simulação e Controle de Tráfego Funcionalidades do Sistema Representação do Conhecimento Implementação do Sistema 14 iii

4 4.1 O Sistema Multiagente A Rede de Contrato As mensagens trocadas O sistema especialista Execução da aplicação Conclusão 19 Referências 20 iv

5 Lista de Figuras 2.1 Arquitetura de um Sistema Especialista Fluxograma de uma rede de contrato Arquitetura do Protégé A plataforma Tahiti Ontologia para simulação e controle de tráfego Diagrama de classes do sistema Fluxograma da rede de contrato utilizada Screenshot do sistema em funcionamento v

6 Capítulo 1: Introdução A aplicação de tecnologias modernas de computadores para a resolução de problemas com tráfego, tem resultado uma maior mobilidade, segurança e qualidade nas cidades, além do próprio aumento da produtividade. Sobre a aplicação destas tecnologias, denominadas Intelligent Transportation Systems (ITS), é possível dar um salto de qualidade no controle e gerência de trânsito e dos transportes. [10]. No escopo da disciplina DAS Inteligência Artificial Aplicada a Sistemas de Controle e Automação, desejava-se implementar um sistema que fizesse uso dos conceitos vistos durante o curso, tais como a representação do conhecimento por meio de ontologias, a criação de sistemas dotados de inteligência computacional com o uso de sistemas especialistas, e a resolução de problemas por meio de sistemas multiagente. Neste contexto, foi escolhido o tema de simulação e controle de tráfego por ser um domínio onde a aplicação de técnicas de inteligência artificial tem sido bastante estudada Este documento está organizado da seguinte forma: o capítulo 2 apresenta de forma sucinta os conceitos utilizados neste trabalho, bem como as ferramentas utilizadas. O capítulo 3 descreve o sistema que desejava-se implementar, enquanto o capítulo 4 aborda a implementação realizada. As conclusões deste trabalho são apresentadas no capítulo 5. 1

7 Capítulo 2: Fundamentação teórica 2.1: Ontologias Em Inteligência Artificial pode-se assumir uma interpretação para ontologia como sendo um conjunto de entidades com suas relações, restrições, axiomas e vocabulário. Um ontologia define um domínio, ou, mais formalmente, especifica uma conceitualização acerca dele [6]. Segundo Clark [3], uma ontologia é organizada em hierarquias de conceitos (ou taxonomias), pelo fato de não refletirem idealmente nenhum formalismo específico, pode-se considerar um ontologia como a materialização do nível do conhecimento. A utilização de ontologias em substituição á uma abordagem declarativa apresenta muitos benefícios, os mais relevantes podem ser verificados como segue: Reuso de ontologias; Ontologias de Prateleira; Tradução entre linguagens e formalismos de representação do conhecimento; Acesso on-line a servidores de ontologias. 2.2: Sistemas Especialistas Quando é construído um sistema voltado para uma área muito específica, requerendo a experiência de um especialista humano, ele é denominado Sistema Especialista (SE). Este deve ser capaz de emitir uma decisão, apoiado em conhecimento justificado, a partir de uma base de informações, tal qual um especialista de determinada área do conhecimento humano [9]. Para emitir uma decisão sobre um determinado assunto, um especialista o faz a partir de fatos que encontra e de hipóteses que formula, buscando em sua memória um conhecimento prévio armazenado. Com esse processo de raciocínio pode-se não chegar a uma decisão se os fatos de que dispõe forem insuficientes, ou chegar a uma conclusão errada, sendo este erro justificado em função dos fatos que encontrou e do seu conhecimento acumulado previamente em sua memória de trabalho. 2

8 Um SE deve, além de inferir decisões, ter capacidade de adquirir novos conhecimentos e, desse modo, melhorar o seu desempenho de raciocínio. A arquitetura dos SEs apresentada na figura 2.1, deriva dos chamados Sistemas de Produção, que é um nome genérico para todos os sistemas baseados em regras de produção. Figura 2.1: Arquitetura de um Sistema Especialista Estas regras de produção são pares de expressões consistindo em uma condição e uma ação [1]. A idéia inicial dos sistemas de produção foi introduzida por Post, em 1936, quando ele propôs os hoje chamados sistemas de Post [8]. Um sistema de Post consiste em um conjunto de regras para a especificação sintática de transformações sobre cadeias de caracteres, e representa um método geral para o processamento de dados. Os sistemas de produção foram redescobertos durante os anos setenta como uma ferramenta para a modelagem da psicologia humana. O formato condição-ação se adapta à modelagem de todos os comportamentos baseados em pares estímuloresposta. Pode-se portanto distinguir três componentes essenciais: uma base de regras, uma memória de trabalho e um motor de inferência. A base de regras em conjunto com a memória de trabalho formam a chamada base de conhecimento do SE. O motor de inferência é o mecanismo responsável por buscar na base de regras os padrões encontrados na memória de trabalho e executar a ação apropriada. Para solucionar problemas, os SEs precisam acessar uma grande base de conhecimento do domínio da aplicação, portanto o sucesso de um SE depende enormemente da forma como o conhecimento é representado e dos mecanismos para a exploração deste conhecimento. 3

9 2.2.1: Motor de inferência Classifica-se um motor de inferência pelas funcionalidades que este deve possuir: modo de raciocínio, estratégia de busca, resolução de conflito e representação de incerteza : Modo de raciocínio Basicamente, existem dois modos de raciocínio aplicáveis a regras de produção: encadeamento progressivo (forward chaining), e encadeamento regressivo (backward chaining). No encadeamento progressivo, também chamado encadeamento dirigido por dados, a parte esquerda da regra é comparada com a descrição da situação atual, contida na memória de trabalho. As regras que satisfazem a esta descrição têm sua parte direita executada, o que, em geral, significa a introdução de novos fatos na memória de trabalho. A diferença, no encadeamento regressivo, conhecido também como encadeamento dirigido por objetivos, o comportamento do sistema é controlado por uma lista de objetivos. Um objetivo pode ser satisfeito diretamente por um elemento da memória de trabalho, ou pela existência de regras que permitem a inferência de tal objetivo, contendo uma descrição deste em suas partes direitas. As regras que satisfazem esta condição têm as instâncias correspondentes às suas partes esquerdas adicionadas à lista de objetivos correntes. Caso uma dessas regras tenha todas as suas condições satisfeitas diretamente pela memória de trabalho, o objetivo em sua parte direita é também adicionado à memória de trabalho. Um objetivo que não possa ser satisfeito diretamente pela memória de trabalho, nem inferido através de uma regra, é abandonado. Quando o objetivo inicial é satisfeito, ou não há mais objetivos, é cessado o processamento : Estratégia de busca Uma vez definido o tipo de encadamento, o motor de inferência necessita ainda de uma estratégia de busca para guiar a pesquisa na memória de trabalho e na base de regras. Este problema é conhecido como busca em espaço de estados. Este tópico é estudado em inteligência artificial, no contexto de solução de problemas. Descrições detalhadas dos algoritmos de busca podem ser encontradas em [2]. 4

10 : Resolução de conflito Após o processo de busca, o motor de inferência dispõe de um conjunto de regras que satisfazem à situação atual do problema, o chamado conjunto de conflito. Se esse conjunto for vazio, a execução é terminada; caso contrário, é necessário escolher as regras que serão executadas, e a ordem. Os métodos de resolução de conflito mais utilizados ordenam as regras de acordo com critérios como prioridades estáticas, complexidade, tempo decorrido desde a obtenção da regra, confiabilidade, grau de importância, e até seleção randômica. A utilização de um critério pode se tornar insuficiente para resolver os conflitos. Portanto, um SE pode combinar mais de um método, e em geral, é desejável que o usuário possa especificar quais métodos deverão ser usados : Representação de incerteza O tratamento de incerteza é uma ativa área de pesquisa em SEs, pois os domínios adequados à implementação de SEs se caracterizam exatamente por não serem modelados por nenhuma teoria geral, o que implica descrições incompletas, inexatas ou incertas. Diversos métodos foram propostos para tratar este problema: método bayesiano, fatores de certeza (conforme o modelo adotado no MYCIN), teoria de Dempster-Shafer, teoria dos conjuntos nebulosos, teoria de probabilidades subjetivas e teoria de possibilidades. Para quantificar de alguma forma a confiança do especialista, estes métodos atribuem aos fatos e regras uma medida numérica. Os métodos utilizados não mantém entre si nenhuma coerência, e cada um adapta-se melhor a determinados tipos de problemas. Também aqui é desejável que o usuário possa ter a escolha do método mais adequado para seu problema, e de limites mínimos para a medida de incerteza, para truncar fatos ou regras que se encontram abaixo do limiar. 2.3: Sistemas Multiagente Um sistema multiagente consiste num certo número de agentes que agem entre si [12]. Aqui, agentes são definidos como entidades que possuem capacidade de ação autônoma, realizando ações sem a necessidade de constante intervenção do usuário, assim, presume-se que a independência dada a cada agente pode tornar-se um com- 5

11 plicador ao cumprimento harmonioso de tarefas de um sistema como um todo, já que um agente não está necessariamente com uma visão de tarefas globais. Portanto, um sistema multiagente deve possuir meios de fazer com que agentes comuniquemse, negociem e cooperem, num comportamento semelhante ao desejado numa sociedade. A construção de sistemas multiagente pode ser vista em diferentes perspectivas: no nível de agentes individuais, deseja-se criar agentes que sejam independentes e capazes de se comunicarem com outros, enquanto no nível do sistema global a meta é projetar as interações destes agentes de modo que, através da comunicação, soluções satisfatórias para as tarefas designadas possam ser atingidas. Este trabalho está focado, a nível de agentes individuais, na classificação destes, e em um nível mais global, no uso do protocolo de redes de contrato para uma interação desejável entre eles : Agentes Inteligentes Embora seja amplamente aceito que agentes são entidades autônomas e que comunicam-se com outras entidades, tal autonomia pode ser variável, e o comportamento dos agentes também. Uma importante classificação para os agentes diz respeito ao nível de inteligência que estes possuem: Agentes reativos possuem baixo nível de independência, funcionando basicamente por meio de reações aos estímulos do sistema, resultando também numa baixa complexidade. Agentes cognitivos caracterizam-se por serem pró-ativos, dispensando a necessidade de aguardar por estímulos do seu ambiente, assim tendo uma independência maior no processo de tomar decisões. Eles também têm a capacidade de aprender durante seu ciclo de vida, resultando em um aumento de performance ao longo do tempo. Agentes também podem ser classificados quanto à sua mobilidade: agentes móveis têm a capacidade de migrar entre sistemas multiagente, enquanto agentes estacionários permanecem no mesmo sistema durante todo o seu ciclo de vida. Outras classificações, adequadas principalmente a agentes cognitivos, podem ser aplicadas, de acordo com seu comportamento: agentes podem variar em sua benevolência (isto é, o quanto cooperam para melhorar o desempenho global) e veracidade 6

12 - agentes maliciosos podem mandar mensagens falsas deliberadamente de acordo com seus propósitos : Redes de Contrato O protocolo de Redes de Contrato [11] foi desenvolvido para especificar comunicação e controles de alto nível responsáveis pela resolução distribuída de problemas, realizando a distribuição de tarefas após discussões e negociações entre as diversas partes. Basicamente, este protocolo consiste em quatro partes (figura 2.2): Reconhecimento Inicialmente, um agente (dito contratante) se dá conta que precisa de outros agentes para realizar uma tarefa, seja porque não tem a capacidade de cumpri-la isoladamente, seja porque por questões de desempenho ou restrições temporais julga que a tarefa será melhor realizada com ajuda de outros agentes. Anúncio da Tarefa Nesta fase, o agente contratante envia uma mensagem a outros agentes (possíveis contratados) descrevendo a tarefa, comunicando eventuais restrições e outras informações necessárias. Esta comunicação pode ser pontoa-ponto, multicast ou broadcast. Análise Os agentes que desejam candidatar-se ao cumprimento desta tarefa enviam respostas ao contratante, e este analisa quais agentes melhor podem atender às especificações. Emissão do Contrato Por fim, o agente contratante decide quais agentes serão efetivamente contratados e emite-lhes o contrato. De acordo com as necessidades do sistema, agentes podem ser tanto contratantes quanto contratados, e sub-redes de contrato podem ser criadas para a realização de sub-tarefas. 2.4: Ferramentas utilizadas 2.4.1: Protégé O Protégé é uma ferramenta que permite construir ontologias de domínio, personalizar formulários de entrada de dados, inserir e editar dados, possibilitando a criação de bases de conhecimento guiadas por uma ontologia. Sua interface gráfica 7

13 Figura 2.2: Fluxograma de uma rede de contrato provê acesso às barras de menus e ferramentas, além de apresentar áreas de visualização (views) que funcionam como módulos de navegação e edição de classes, atributos, formulários, instâncias e pesquisas na base de conhecimento, propiciando a entrada de dados e a recuperação das informações [7]. Desenvolvido pelo departamento de informática médica da Universidade de Stanford, o projeto original do Protégé era uma ferramenta de aquisição de conhecimento limitada a um sistema especialista para oncologia. Foi modernizado gradativamente para acompanhar a evolução da tecnologia de Sistemas Baseados em Conhecimento, ou seja, servir para aquisição de conhecimento diretamente de especialistas de domínios com menos dependência de engenheiros de conhecimento, permitir diversos formalismos e estratégias de inferência, integrar tarefas (aquisição de ontologias e instâncias, ambiente de teste com inferência) num mesmo ambiente, criar automaticamente formulários para entrada de conhecimento, combinar ontologias e acessá-las via OKBC (Open Knowledge Base Connectivity). O Protégé foi desenvolvido utilizando a linguagem de programação Java e, posteriormente, arquitetura integrável a diversas aplicações, via componentes que podem ser conectados ao sistema. Como conseqüência desta decisão e de sua difusão, elaborados por grupos de pesquisa de usuários, puderam ser adicionados ao sistema, sem necessitar o re-desenvolvimento. A arquitetura do Protégé, vista na figura 2.3 possui uma interface e é definida pelos plug-ins e slots que fazem a interface com a base de conhecimento definidas pelo Protégé, representada pelo núcleo do Protégé que faz o intermédio com a base 8

14 de armazenamento persistente podem ser em formato de banco de dados ou arquivos. A modularização do Protégé está dividida em: Interface com o usuário; Núcleo do Protégé; Armazenamento persistente. Essa arquitetura ajuda no crescimento da ferramenta, pois novos módulos são desenvolvidos preocupando-se somente com o módulo que se deseja, seja uma nova base de dados de armazenamento persistente ou um novo plug-in de interface com os usuários. Figura 2.3: Arquitetura do Protégé 2.4.2: AGLETS A ferramenta AGLETS [4] consiste numa biblioteca Java e uma plataforma, também feita em Java, para agentes móveis, facilitando o desenvolvimento de aplicações baseadas em agentes. Um aglet é um agente Java capaz de mover-se espontaneamente entre servidores. A tecnologia AGLETS foi inicialmente desenvolvida na IBM e atualmente é um projeto open-source, distribuído sob a licença pública da IBM. Na biblioteca de classes oferecida pelo AGLETS, destacam-se as seguintes: 9

15 Aglet A classe que origina todos os aglets, já que estes devem estender a classe Aglet. Possui alguns métodos que usualmente são sobrecarregados pelas classes que a estendem, tais como OnCreation(), que é executado quando o aglet é criado, run(), que é chamado quando ele é executado, handlemessage() que é chamado ao receber uma mensagem, e ondisposing() que é chamado quando ele é excluído. AgletContext Esta classe é responsável por guardar as informações sobre o contexto onde os aglets estão inseridos. Quaisquer informações que um aglet deseje disponibilizar são gravadas neste contexto e então acessadas por outros. Message Classe responsável por encapsular os dados de uma mensagem. Um objeto Message possui um tipo particular, descrito com uma String, e pode conter um tipo primitivo ou objeto como argumento a ser enviado. O AGLETS disponibiliza métodos de envio de mensagens ponto-a-ponto, com suporte opcional a respostas, que também podem conter argumentos. AgletProxy Esta classe controla e limita o acesso direto aos aglets. Comumente é utilizada como referência a um aglet no momento de envio de uma mensagem. O AGLETS possui uma plataforma, chamada Tahiti, que possibilita a invocação de aglets, móveis ou não, e a realização de funções de gerenciamento como mobilidade e destruição de aglets. A interface desta plataforma pode ser vista na figura 2.4. Figura 2.4: A plataforma Tahiti 2.4.3: JESS O JESS [5], lançado em 1995, foi desenvolvido por Ernest Friedman-Hill nos Sandia National Labs como parte de um projeto interno de pesquisa. É um script 10

16 shell para construcção de sistemas especialistas baseado em regras inteiramente desenvolvido em Java e possui um ambiente similar ao CLIPS (C Language Integrated Production System), desenvolvido pela NASA. O JESS utiliza o algoritmo RETE na sua máquina de inferência. Este algoritmo é caracterizado por organizar as regras numa árvore, de modo que sejam divididas em padrões, assim, regras semelhantes percorrerão o mesmo ramo da árvore enquanto possuírem cláusulas iguais. Tal organização é mais onerosa em termos de memória, mas proporciona grandes melhorias na velocidade de verificação das regras. O motor de inferência JESS permite tanto o encadeamento regressivo quanto progressivo. A linguagem Jess é uma linguagem de programação de propósito geral e pode acessar diretamente todas as classes e bibliotecas Java. Por esta razão, Jess é muito usado como ambiente de desenvolvimento rápido de aplicações e scripts. Enquanto o código Java tem que ser compilado antes de rodar, uma linha de código do Jess é executada imediatamente após ser digitada. Isto permite que os usuários experimentem as APIs Java interativamente e desenvolvam programas incrementalmente. 11

17 Capítulo 3: Descrição do Sistema de Simulação e Controle de Tráfego 3.1: Funcionalidades do Sistema Sistemas de controle de tráfego possuem complexidade bastante variável, assim, o domínio do problema de implementar tais sistemas pode ser tão vasto quanto necessário. No escopo deste trabalho, desejou-se implementar a simulação do trânsito numa pequena malha rodoviária, com cruzamentos e bifurcações. Os veículos que circulam nesta malha podem ser ambulâncias ou carros de passeio, ambos devendo respeitar as regras tradicionais de circulação numa estrada, e, portanto, necessitando de um comportamento inteligente. Para tornar o comportamento dos veículos mais complexo, também foi implementada uma funcionalidade de chamada de emergência, que é difundida a todas as ambulâncias, e um processo de decisão é utilizado para que a mais próxima vá ao local da emergência. O comportamento desejado para os veículos pode ser visto com as seguintes regras: Não avançar sob sinal vermelho; Não andar na contra-mão; Não andar em círculos nos cruzamentos; Não avançar ao próximo segmento da estrada se este estiver ocupado. Para que o movimento de todos os veículos seja sincronizado, um controle central sobre as ações é necessário. 3.2: Representação do Conhecimento O conhecimento necessário para a elaboração do sistema foi descrito por meio de uma ontologia, vista na figura 3.1. Nela são vistas as entidades que compõem o sistema: 12

18 Veículos São as entidades que circulam pela malha rodoviária. Seus slots denotam o nome que cada veículo tem, assim como o segmento em que se encontram em um dado momento e o tipo de veículo descrito. Segmentos São as partes atômicas da malha rodoviária. Devem possuir ligações com os segmentos vizinhos, assim como uma posição particular na malha e os veículos que os ocupam, se existirem. Os segmentos regidos por semáforos também devem possuir um slot que represente este semáforo. Semáforos Controlam a passagem de carros nos segmentos que os contêm. Gerente Entidade principal, é o ponto central de comunicação entre as outras entidades. Emergência Uma entidade que representa um chamado para que uma ambulância vá a algum local da malha rodoviária o mais rapidamente possível. Figura 3.1: Ontologia para simulação e controle de tráfego 13

19 Capítulo 4: Implementação do Sistema 4.1: O Sistema Multiagente O sistema é composto por uma arquitetura hierárquica de agentes, sendo que cada veículo é um agente e um agente gerente coordena as ações de todos os agentes veículos. Assim, as classes gerente, PasseioAglet e AmbuAglet foram implementadas como extensões da classe Aglet. Além das classes destes três agentes, outras classes auxiliares também foram implementadas. O diagrama de classes completo pode ser visto na figura 4.1. Figura 4.1: Diagrama de classes do sistema A classe gerente é o ponto central do sistema. Ela contém a malha rodoviária e gerencia a alocação de veículos no sistema, além de receber os estímulos do usuário para avançar a simulação do trânsito e mostrar o andamento da simulação ao usuário através de uma interface gráfica. A cada turno, o gerente atualiza as informações a respeito da posição de cada veículo, para que estes recebam a informação correta de quais segmentos vizinhos estão livres. Esta classe também gerencia as chamadas de emergência e os semáforos, que serão vistos posteriormente. Do ponto de vista de agentes, trata-se de um agente reativo, pois as decisões que toma são de acordo com um plano de ações pré-definido. Também pode-se dizer que é um agente estacionário, 14

20 pois não houve a necessidade de implementação de agentes móveis. A classe PasseioAglet representa o agente de um veículo de passeio. Um veículo de passeio é utilizado apenas para simulação do sistema e assim sua inteligência é restrita ao cumprimento das regras necessárias do trânsito, com o uso de um sistema especialista que será descrito a posteriori. Assim, objetos desta classe são agentes reativos que interagem com o gerente somente o necessário para que possam mover-se corretamente ao longo das estradas. A classe AmbuAglet representa o agente de uma ambulância. Seu comportamento é semelhante ao de um carro de passeio, porém, no surgimento de uma chamada de emergência, é necessária uma comunicação adicional com o gerente a fim de decidir qual ambulância deve atender à emergência. Outras classes auxiliares são utilizadas, porém sem ter as características que denotam agentes: Objetos da classe segmento representam estradas no sistema. Quando o gerente é iniciado, ele instancia diversos objetos desta classe para formar a malha rodoviária. A classe semaforo descreve uma estrutura de dados para representar um semáforo, aqui implementado como um elemento passivo e controlado pelo gerente. Quando um sinal verde passa a vermelho, são necessários quatro turnos de espera para que um sinal se torne verde, para que não ocorram colisões A classe emergencia encapsula os dados necessários para descrever um chamado de emergência a ser atendido por uma ambulância. A classe procura é utilizada para pesquisar o caminho mais curto entre dois pontos, através de um algoritmo de busca em grafos : A Rede de Contrato Neste sistema, pode ser vista uma rede de contrato no processo de escolha de uma ambulância para atender a uma emergência. A figura 4.2 descreve esta rede nos moldes do que foi visto no capítulo 2 assim que o usuário aciona o botão de emergência, um chamado é criado em um lugar aleatório do mapa. Então o gerente envia uma mensagem de emergência a todas as ambulâncias, com a posição da emergência, e 15

21 Figura 4.2: Fluxograma da rede de contrato utilizada cada ambulância calcula o trajeto mais curto até o local da emergência, retornando ao gerente a distância percorrida neste caminho. A ambulância que estiver mais próxima do local da emergência é então escolhida e desloca-se para este local, enviando uma mensagem assim que lá chegar, confirmando o atendimento da chamada : As mensagens trocadas Dada a relativa simplicidade da comunicação entre os agentes, não foi necessária a adoção de um protocolo elaborado para a troca de mensagens. Assim, com os mecanismos já disponíveis na plataforma AGLETS para envio e resposta de mensagens, foram criados os seguintes tipos de mensagens: cadastro Diretiva enviada por um veículo solicitando sua inclusão na malha rodoviária. Recebe como resposta uma assertiva que confirma ou nega a inclusão. anda Diretiva enviada pelo gerente a todos os veículos, para que movam-se ou comuniquem que não puderam se mover. andei Assertiva enviada por um veículo ao gerente, comunicando que movimentou-se e enviando sua nova posição. nada Assertiva enviada por um veículo ao gerente quando não pôde andar. emergencia Diretiva enviada pelo gerente a todas as ambulâncias, juntamente com o local da emergência. Recebe como resposta a distância de cada ambulância em relação ao local. escolhido Diretiva enviada pelo gerente à ambulância escolhida para atender uma emergência, solicitando que esta se desloque ao local determinado. 16

22 atendi Assertiva enviada por uma ambulância ao gerente, comunicando o atendimento de uma emergência : O sistema especialista Sempre que solicitados, os veículos devem decidir para onde moverem-se. Esta decisão é tomada por um sistema especialista implementado com o JESS, recebendo como entradas os segmentos vizinhos livres, o antepenúltimo segmento atingido, e, caso existam, o estado do semáforo do segmento em que o veículo se encontra e o caminho que este deve seguir para atender uma emergência. Basicamente, o sistema verifica as seguintes regras: Primeiramente, verificar se está num sinal vermelho, neste caso, remover da memória de trabalho todos os movimentos possíveis. Em seguida, verificar se alguma das opções conduz a um caminho em círculo dentro de um cruzamento, isto é, verificar se é possível retornar ao antepenúltimo segmento visitado. Em caso afirmativo, esta opção deve ser removida. Após a aplicação das duas regras anteriores, um caminho livre é aprovado caso ele seja obrigatório, e na ausência de caminhos obrigatórios, todos os caminhos livres são aprovados e um é escolhido aleatoriamente : Execução da aplicação A aplicação é executada instanciando-se, a partir do ambiente Tahiti, o agente gerente. Então as estradas podem ser povoadas com agentes de veículos, e, assim que uma ambulância for incluída, pode-se fazer chamadas de emergência. A interface gráfica da aplicação pode ser vista na figura

23 Figura 4.3: Screenshot do sistema em funcionamento 18