Download WORD - Trabajos de Grado de la facultad de Ingeniería de Sistemas

DOCUMENTO DE INVESTIGACION SOBRE LAS HERRAMIENTAS PARA IMPLEMENTACION
DE SISTEMAS MULTIAGENTES
PROYECTO:
“CONCURRENCIA EN SISTEMAS MULTIAGENTE: IMPLEMENTACIÓN DE UN SIMULADOR
DE TRÁFICO URBANO”
DIRECTOR:
ENRIQUE GONZALEZ GUERRERO
ESTUDIANTES:
DANIEL FERNANDO RODRIGUEZ NIÑO
GERMAN OCTAVIO ARDILA DIAZ
PROYECTO DE INVESTIGACIÓN II
PONTIFICIA UNIVERSIDAD JAVERIANA
BOGOTA, 2002
TABLA DE CONTENIDO
TABLA DE CONTENIDO ________________________________________________________________ 2
HERRAMIENTAS Y CRITERIOS DE SELECCION __________________________________________ 3
HERRAMIENTAS QUE SE RECHAZARON SEGÚN LOS CRITERIOS DE ACEPTACIÓN
DEFINIDOS ___________________________________________________________________________ 4
AGENT DEVELOPMENT KID ________________________________________________ 4
APRIL AGENT PLATAFORM _________________________________________________ 4
HERRAMIENTAS ACEPTADAS SEGÚN LOS CRITERIOS DEFINIDOS ________________________ 5
JADE: ______________________________________________________________________ 5
Características básicas: ______________________________________________________________ 5
Arquitectura: ______________________________________________________________________ 5
Características tenidas en cuenta para el diseño de JADE con respecto a la teoría de agentes: ________ 6
Detalle del sistema de comunicaciones: __________________________________________________ 6
El modelo de Ejecución: _____________________________________________________________ 6
Concurrencia en Jade: _______________________________________________________________ 6
ZEUS _______________________________________________________________________ 7
Características Básicas: ______________________________________________________________ 7
Arquitectura: ______________________________________________________________________ 7
Características tenidas en cuenta para el diseño de ZEUS con respecto a la teoría de agentes: ________ 8
Comunicaciones: ___________________________________________________________________ 8
Esquema de manejo de la comunicación _________________________________________________ 8
Esquema de Arranque: _______________________________________________________________ 9
Coordinación:_____________________________________________________________________ 10
FIPA-OS ___________________________________________________________________ 10
Arquitectura: _____________________________________________________________________ 10
Diseño de los agentes según la definición de agentes: ______________________________________ 12
Estructura del Agente: ______________________________________________________________ 12
Esquema de manejo de la comunicación ________________________________________________ 13
CONCLUSIONES _____________________________________________________________________ 15
HERRAMIENTAS Y CRITERIOS DE SELECCION
En total se revisarón las características de varias plataformas de agentes, entre las cuales se
encuentran las siguientes:
o
o
o
o
o
JADE
AGENT DEVELOPMENT KID
APRIL AGENT PLATAFORM
FIPA-OS
ZEUS
Los criterios para escoger las que serían evaluadas son los siguientes:
Criterio
Cumple con el estándar FIPA.
Que posea algún mecanismo
de interoperabilidad.
Ha sido desarrollada por una
organización conocida o de
renombre.
Es
de
licencia
preferiblemente.
Es
de
código
preferiblemente.
libre
Justificación
Este es un estándar que están
adoptando
múltiples
plataformas
de
agentes
reconocidas.
Es importante que posean
mecanismos
de
interoperabilidad
entre
plataformas,
bien
sea
determinado por el lenguaje de
programación
o
por
un
mecanismo como CORBA.
La
plataforma
debe
ser
reconocida con casos exitosos
o debe ser desarrollada por una
entidad con cierto prestigio.
Bajar los costos del proyecto.
abierto En caso de que se necesite
realizar
modificaciones
o
adaptaciones de acuerdo al
tema de estudio.
Tiene
documentación
de Al
interactuar
con
una
técnica detallada y posee herramienta desconocida es
manuales de usuario.
necesario
tener
buena
documentación para ver como
se
alinea
con
el
direccionamiento del proyecto.
Lenguaje de desarrollo sea A modo informativo.
preferiblemente
(no
necesariamente) Java.
La filosofía de plataforma debe Por la naturaleza del proyecto
manejar agentes móviles, tanto la herramienta debe manejar
en Internet como en sistemas agentes móviles por lo menos
distribuidos.
en el ámbito de Sistemas
Distribuidos.
Identificador
FIPA
Interoperabilidad.
Proveedor Reconocido.
Licencia Libre.
Código Abierto.
Documentación.
Lenguaje
Agentes Móviles
Criterios
Herrami
enta
AGENT
DEVELO
PMENT
KID
APRIL
AGENT
PLATAF
ORM
JADE
ZEUS
FIPA-OS
FIPA
X
Interope Proveed Licencia Código
rabilidad
or
Libre
Abierto
Reconoc
ido
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Docum Lengua Agent Acepta
entació
je
es
da
n.
Movib
les
Java
X
No
X
X
X
C
X
No
Java
Java
Java
X
X
X
Si
Si
Si
Después de evaluar las características básicas de las herramientas con respecto a los criterios de
evaluación como se ve en la tabla se escogieron las siguientes para estudiaras mas
profundamente:
o
o
o
JADE (Java Agent DEvelopment Framework)
ZEUS
FIPA-OS
HERRAMIENTAS QUE SE RECHAZARON SEGÚN LOS
CRITERIOS DE ACEPTACIÓN DEFINIDOS
A continuación se presentan algunas de las características de las herramientas estudiadas y que
se rechazaron teniendo en cuenta los criterios de aceptación definidos:
AGENT DEVELOPMENT KID
o
o
o
o
o
Desarrollado por una casa de software llamada Tryllan.
Su licencia es comercial.
Cumple con los estándares FIPA.
Esta demasiado orientado a agentes móviles en Internet.
Todo el desarrollo de la plataforma esta basado en JAVA y XML.
APRIL AGENT PLATAFORM
o
o
o
o
o
o
Opera Solo sobre UNIX, Linux y MacOS.
Cumple los estándares FIPA.
Esta desarrollada en lenguaje C.
Esta orientada a agentes móviles.
Desarrollado por Fujitsu.
No se consigue fácilmente la documentación referente a la herramienta.
HERRAMIENTAS ACEPTADAS SEGÚN LOS CRITERIOS
DEFINIDOS
JADE:
Características básicas:
o
o
o
o
o
Esta desarrollada 100% en JAVA.
Es de licencia libre y código abierto.
Cumple con los estándares FIPA.
Maneja agentes móviles.
Puede interactuar con Java Expert System Shell.
Arquitectura:
Como se observa en la gráfica la arquitectura básica de jade se compone de:
o
En un modulo de administración de los agentes, el cual es como un directorio de páginas
blancas, este permite a los agentes ubicar a otros agentes.
o
Un modulo de administración de servicios, el cual es como un directorio de paginas
amarillas y que permite a los agentes, ubicar servicios provistos por otros agentes.
o
Un canal de comunicación entre agentes que se encuentran en un mismo contenedor de
agentes, esta canal se maneja a través de eventos Java.
o
Entre contenedores la comunicación se realiza a través de paso de mensajes, mas
específicamente utilizando RMI.
o
La comunicación entre agentes que se encuentran en diferentes maquinas se realiza a
través del protocolo IIOP.
Características tenidas en cuenta para el diseño de JADE con respecto
a la teoría de agentes:
o
o
o
Los Agentes son Autónomos: Para cumplir esta regla que determina la definición de
agente, en JADE los agentes son objetos activos.
Los agentes son entidades sociales: La concurrencia de agentes internos es requerida.
Los Mensajes son actos de Habla, no son invocaciones: Requiere paso de mensajes no
sincrónicos.
Detalle del sistema de comunicaciones:
o
o
o
o
Todo agente posee una cola de mensajes ACL.
El costo de la comunicación depende de la ubicación del agente al que se le quiere enviar
un mensaje.
Cada contenedor de agentes maneja un despachador de mensajes RMI, una tabla de
descripción global de los agentes y una tabla de referencia a sus propios agentes.
El protocolo para manejo de mensajes interplataforma es IIOP.
El modelo de Ejecución:
o
o
o
El agente es capaz de manejar concurrencia. Soporta múltiples conversaciones a la vez.
El agentes es autónomo en su totalidad y tiene la capacidad de decidir cuando lea su cola
de mensajes recibidos y cuando envía.
Para el modelamiento del comportamiento de los agentes, jade provee sus propias librerías
de comportamientos y mecanismos, para determinarlos, como un administrador de
comportamientos y un administrador de ciclo de vida.
Concurrencia en Jade:
o
El manejo de la concurrencia entre diferentes contenedores de agentes se realiza a través
de la maquina virtual de Java.
o
El manejo de concurrencia entre agentes en el mismo contenedor se realiza a traves de
primitivas multithread, administradas por la maquina virtual de JAVA.
ZEUS
Características Básicas:
o
o
o
Cumple con los estándares FIPA.
Es de licencia publica y de código abierto
Provee acceso a bases de datos.
Arquitectura:
Agent Name Server
Address
Book
request
Co mmon Message Format (Language)
Shared mesage content
representation and ontology
reply
Agent
Facilitator
B
A
D
MESSAGE
Transport Protocol
C
o
o
o
o
Agent
Agent
Agent
Perform
Task A
Perform
Task C
Perform
Task D
Posee un motor para la administración de la coordinación entre agentes.
Permite modelar distintos tipos de sociedades de Agentes.
Posee un mecanismo de inteligencia basado en metas.
Provee Servicios de búsqueda de agentes por nombre a través de la red.
Abilit ies
Database
External
program
o
Provee directorios de paginas amarillas para la ubicación de servicios.
Características tenidas en cuenta para el diseño de ZEUS con respecto
a la teoría de agentes:
o
o
o
El comportamiento de los agentes puede ser modelado a través mecanismos, libres,
orientados a metas, o racionales.
Los agentes son autónomos como objetos activos.
Los agentes son autónomos.
Comunicaciones:



Para la comunicación entre agentes sea o no interplataforma utiliza protocolos como TCP/IP
sockets.
Permite el Manejo de Ontologías.
La comunicación entre agentes e maneja a través de KQML adaptado a los estándares FIPA
ACL
Esquema de manejo de la comunicación
Si encontró
dirección.
Libreta local
de
direcciones.
No encontró
dirección.
Nuevo
socket
Almacena
Mensaje en turno
de buffer Espera
Manejador de mensajes
Mailbox (Basado en Sockets) FIFO
Thread que maneja la Entrada
Buffer de Entrada
Thread que administra la salida
Buffer de Salida
Cada agente tiene una libreta local de direcciones, cuando recibe una petición de comunicación de
otro agente, procede a revisar en su libreta local de direcciones para ver si conoce al agente que
esta tratando de establecer comunicación. En caso de que no lo conozca almacena el mensaje en
un buffer de espera mientras solicita al agente servidor de nombres la dirección del agente que
esta tratando de comunicarse. Cuando el agente servidor de nombres responde con la dirección
del agente, esta es registrada en la libreta local de direcciones, después de esto se saca el
mensaje del buffer de espera y se atiende; como la dirección del agente emisor ya esta registrada
en la libreta local de direcciones el agente receptor procede a establecer un nuevo socket para
comunicarse con el agente emisor.
Esquema de Arranque:
Como se observa el primer agente que se ejecuta al inicializar un sistema multiagente en Zeus es
el agente servidor de nombres, donde posteriormente los demás agentes que se creen registraran
sus nombres incluido el agente Facilitador y el agente que permite el monitoreo de la plataforma.
Posteriormente el agente facilitador solicita las direcciones de los agentes que existan, una vez el
agente servidor de nombres le entrega los datos de las direcciones el agente facilitador solicita a
los agentes existentes en la plataforma que informen sus habilidades, de esta manera el agente
facilitador conoce todas las habilidades de los agentes existentes en una plataforma.
Por ultimo la operación de la plataforma es monitorieada por el agente visualizador debido a que
este solicita a todos los agentes existentes que le envíen copia de los mensajes que manden.
Coordinación:
Soporta tres tipos de coordinación:
o
o
o
La coordinación se realiza a través de un protocolo contract-net.
Coordinación por esquemas tradicionales de IA; en este tipo se puede manejar
coordinación centralizada e individual.
Por esquemas de negociación basados en actos de habla.
FIPA-OS
Características Básicas:
o
o
o
o
o
Desarrollado 100% en JAVA.
Puede realizar interacción con bases de datos.
Es de licencia libre.
Cumple los estándares FIPA.
Puede interactuar con Java Expert System Shell.
Arquitectura:
La siguiente figura muestra el esquema interno de una plataforma:
Como se aprecia la arquitectura básica esta compuesta por tres módulos Básicos:
o
o
o
o
Administrador de Agentes: Es te modulo permite tener un control sobre los agentes
existentes en el sistema, prácticamente es homologo al modulo de paginas blancas
utilizado en JADE.
Directorio Facilitador: Igual que en JADE los servicios que puede prestar cada agente se
buscan en un directorio de paginas amarillas, en FIPA este modulo es conocido como el
directorio facilitador.
Servicio de Transporte de mensajes: El servicio de transporte de mensajes se realiza
internamente a alto nivel a través de mensajes ACL mas a bajo nivel entre agentes en la
misma maquina se realiza mediante el uso de primitivas RMI.
Para comunicación externa entre plataformas, FIPA-OS maneja una diversa pila de
protocolos de RED como los que se pueden apreciar en la gráfica.
En la plataforma FIPA-OS no existe el concepto de contenedor de agentes, cada maquina
ayuda como contenedor de agentes.
Mas a fondo la estructura de un agente como tal se maneja como se presenta en la figura anterior,
las capas más importantes a destacar en este modelo son:
o
o
o
Administrador de Tareas: Esta capa tiene la capacidad de partir la tarea correspondiente a
un agente en unidades más pequeñas, que tienen la capacidad de intercambio de
mensajes y operan como para parte del agente.
Administrador de Conversación: Provee los mecanismos para verificar el estado de las
conversaciones, manejar la comunicación punto a punto y la comunicación de grupos y se
encarga de validar que se cumplan las reglas del protocolo de comunicación utilizado.
Servicio de Transporte de Mensajes se encarga de enviar y recibir mensajes de diferentes
protocolos como HTTP, IIOP, ACL y otros.
Diseño de los agentes según la definición de agentes:
o
o
Los agentes son autónomos mediante el esquema de objetos activos.
Son entes sociales y están en capacidad de manejar sus comunicaciones a su voluntad ( la
comunicación no es sincrónica).
Estructura del Agente:
Capa del Agente
Agente
Capa de Tareas
Capa de Conversación
Mensajería
Capa de Mensajería (MTS)
Perfiles
Conversión
Parses
Fipa-Os divide el Agente en tres grandes capas:
Agente que se compone por la capa Agente o Shell del agente y la capa de tareas. La capa de
Agente provee las instrucciones para ser utilizadas por el programador. La Capa de Tareas divide
toda la funcionalidad del agente en tareas pequeñas que desarrolla el agente. El agente debe estar
desarrollado en forma de tareas pequeñas, algunas de ellas que se puedan realizar en paralelo. En
las tareas se tiene la habilidad de enviar y recibir mensajes. Éstas por ser ejecutadas como tareas
pueden ejecutarse simultáneamente.
Mensajería se compone por la capa Conversión y la capa Mensajería. La capa conversación se
encarga de agrupar los mensajes que hagan parte de una misma conversación entre agentes. La
capa de Mensajería (MTS: Message Transport Service) provee la habilidad de envío y recepción de
mensajes. Actualmente se trabaja sobre RMI y CORBA.
La parte de Conversión esta en desarrollo. Permitirá tener una interfaz para poder compartir
información con otras bases de datos de agentes. La Capa “parses” proveerá un mecanismo de
cambio de mensajes entre distintas plataformas de agentes, donde los mensajes se expresan por
la semántica de la información y no por su implementación, haciendo transparente para el
desarrollador el intercambio de mensajes entre distintas plataformas.
Envío y Recepción de Mensajes:
Existen tres primitivas para enviar y recibir mensajes. Hay que recordar que estas primitivas se
manejan en forma de tareas, es decir en paralelo, ya que pueden ocurrir en cualquier momento y
concurrentemente.



Enviar: Public void send(Message msg)
Recibir: Public void handle Message(Message msg)
Errores: Public voId handleError(Message msg)
Un error que se puede presentar es el fallo en el envío de un mensaje.
Esquema de manejo de la comunicación
En el momento existe intercambio de mensajes con RMI
o CORBA, es decir, utilizan un broker para realizar la comunicación entre agentes. Cada
plataforma posee su broker, medio por el cual una plataforma puede comunicar sus agentes con
agentes de la otra plataforma.
En el momento no existe un mecanismo de Broadcast o Multicast para que una plataforma se
anunciePlataforma
en la red. 1Antes de iniciar Plataforma
la comunicación
es necesario que las plataformas sepan que
2
existen otras. Ya que éstas no se anuncian, es necesario registrar las plataformas que se han
iniciado. A la plataforma 1 se le indica que existe la plataforma 2 en determinada máquina. Luego
se le informa a la plataforma 2 que existe la plataforma 1 en otra máquina. Después de esto ellas
intercambian información acera de los agentes que tienen disponibles.
RMI
/
CORBA
RMI
/
CORBA
Cuando un agente desea enviar un mensaje a otro agente en otra plataforma, lo realiza con la
primitiva send, el agente no sabe y no le interesa si el agente esta un la misma plataforma o en
otra. La plataforma recibe la petición de envio de mensaje, revisa si el agente de destino esta en su
plataforma, si no lo esta revisa en las plataformas que tiene registrada, si lo encuentra envía el
mensaje a la otra plataforma y espera confirmación o error. Si no encuentra la agente devuelve un
mensaje de error al remitente.
CONCLUSIONES
Ventajas de Utilizar una plataforma para desarrollo de Sistemas Multiagentes.





La ventaja de utilizar una herramienta de agentes en el desarrollo del proyecto es que esta ya
tiene implementados y validados los mecanismos de comunicación y coordinación necesarios
para el correcto funcionamiento de un sistema multiagente.
Debido al tipo de problema que se quiere estudiar y de la manera como se piensa aplicar un
enfoque distribuido al mismo, son importante las capacidades para movilidad de agentes entre
maquinas que brindan estas herramientas.
Las herramientas de agentes que utilizan el estándar FIPA, brindan una arquitectura que
puede ser aprovechada en el desarrollo del simulador ya que brindan una servidor de nombres
y un directorio de servicios, lo cual sería útil en el desarrollo del simulador si se tiene en cuenta
que cada agente en el simulador debe conocer la ubicación de otros agentes y de sus
servicios. Supongamos que el simulador se modela de la siguiente forma existe un agente
carro entra a una calle, este necesita saber como se llama el cruce o semáforo que existe en la
calle y como consultar si esta en verde rojo, etc.
Las herramientas estudiadas, utilizan mecanismos conocidos de comunicación distribuida
como RMI o CORBA, que están alineadas con diseño distribuido que se pretende dar al
simulador.
La mayoría de las plataformas estudiadas, no poseen mecanismos de broadcast o de
multicasting, aunque se pueden implementar usando las mismas primitivas brindadas por la
herramientas, e incluso en algunas como Zeus esto se facilitaría bastante debido a que poseen
un directorio local de direcciones.
Desventajas de Utilizar una plataforma para desarrollo de Sistemas Multiagentes.

Después de analizar las arquitecturas estudiadas y los esquemas de comunicación manejados
en cada una de las herramientas podemos determinar que una de las desventajas de
implementar el simulador con una de estas herramientas, es la sobrecarga que tendrían para el
sistema los procesos de administración de mensajería en cada agente, esto podría afectar
alguna de las variables que se tratan de medir en este proyecto.