Departamento de Ciencias de la Computacion
e Inteligencia Artificial
Simulador de Inundaciones.
Sistema Multiagente
Tutores: Proyecto Fin de Carrera presentado
D. Joaqun Borrego Daz por Alejandro Blanco Escudero
D. Gonzalo A. Aranda Corral y Manuel Gomar Acosta
Sevilla, 2 de Julio de 2010

"Nunca permit que la escuela interriera en mi
educacion."
Mark Twain

Indice general
1. Introduccion 1
1. Inicios del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Solucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Software Libre . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Estructura de la Memoria . . . . . . . . . . . . . . . . . . . . 4
2. Huracan Katrina 7
1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Efectos en Nueva Orleans . . . . . . . . . . . . . . . . . . . . 9
3. Estudios e Informacion sobre el Desastre . . . . . . . . . . . . 10
3. Simulacion Basada en Agentes 13
1. Agentes Inteligentes . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1. Que no es un Agente . . . . . . . . . . . . . . . . . . . 15
1.2. Tipos de Agentes . . . . . . . . . . . . . . . . . . . . . 16
V

2. Sistemas MultiAgente (SMA) . . . . . . . . . . . . . . . . . . 17
2.1. Cuando utilizar un SMA . . . . . . . . . . . . . . . . . 18
2.2. Estrategia de Trabajo . . . . . . . . . . . . . . . . . . 19
2.3. Protocolos de Comunicacion . . . . . . . . . . . . . . . 19
4. Simulacion de Inundaciones 21
1. Planteamiento del Problema . . . . . . . . . . . . . . . . . . . 21
2. Movimiento del Agua . . . . . . . . . . . . . . . . . . . . . . . 22
2.1. Direccion del Agua . . . . . . . . . . . . . . . . . . . . 22
2.2. Velocidad de Propagacion del Agua . . . . . . . . . . . 22
2.3. Otros Problemas con el Agua . . . . . . . . . . . . . . 23
3. Inundaciones en un Entorno Urbano . . . . . . . . . . . . . . . 23
3.1. Ros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2. Forma de los Edicios . . . . . . . . . . . . . . . . . . 24
3.3. Calles y Carreteras . . . . . . . . . . . . . . . . . . . . 24
3.4. Alcantarillado . . . . . . . . . . . . . . . . . . . . . . . 24
3.5. Prioridades de las Personas . . . . . . . . . . . . . . . 25
3.6. Supervivencia en un Entorno Inundado . . . . . . . . . 25
3.7. Evacuacion de Personas . . . . . . . . . . . . . . . . . 26
4. Obtener Informacion Real del Terreno . . . . . . . . . . . . . 26
4.1. Posibles Rutas de Evacuacion . . . . . . . . . . . . . . 26
5. Geolocalizacion . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1. Discretizacion de los Datos . . . . . . . . . . . . . . . . 27
6. Visualizacion de los Resultados . . . . . . . . . . . . . . . . . 27
VI

6.1. Estadsticas . . . . . . . . . . . . . . . . . . . . . . . . 28
5. Solucion Propuesta 29
1. Denicion del Escenario de Simulacion . . . . . . . . . . . . . 29
2. Agentes en la Simulacion . . . . . . . . . . . . . . . . . . . . . 29
2.1. Agente Creador . . . . . . . . . . . . . . . . . . . . . . 30
2.2. Agente Reloj . . . . . . . . . . . . . . . . . . . . . . . 31
2.3. Agentes Entorno . . . . . . . . . . . . . . . . . . . . . 31
2.4. Agentes Entrada de Agua . . . . . . . . . . . . . . . . 32
2.5. Agentes Peaton . . . . . . . . . . . . . . . . . . . . . . 33
2.6. Agentes Actualizacion . . . . . . . . . . . . . . . . . . 33
3. Elevacion del Terreno . . . . . . . . . . . . . . . . . . . . . . . 33
4. Geolocalizacion . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5. Open Street Maps . . . . . . . . . . . . . . . . . . . . . . . . . 34
6. Generador de KML . . . . . . . . . . . . . . . . . . . . . . . . 34
7. Visor Bidimensional . . . . . . . . . . . . . . . . . . . . . . . . 35
8. Estadsticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6. Tecnologa Elegida 37
1. Licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2. JADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.1. Arquitectura FIPA . . . . . . . . . . . . . . . . . . . . 39
2.2. Implementacion de FIPA en JADE . . . . . . . . . . . 44
3. Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4. JAK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
VII

5. Jcoord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6. Otras libreras . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.1. Java CSV . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2. OpenWFE . . . . . . . . . . . . . . . . . . . . . . . . . 47
7. Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.1. Open Street Maps . . . . . . . . . . . . . . . . . . . . 48
7.2. Servicio de elevaciones de la USGS . . . . . . . . . . . 49
7. Implementacion (I): Metodologa y Tecnologas de Soporte 51
1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2. Metodologas Agiles . . . . . . . . . . . . . . . . . . . . . . . . 52
2.1. Reuniones de Desarrollo . . . . . . . . . . . . . . . . . 52
2.2. Reuniones con los Tutores . . . . . . . . . . . . . . . . 53
2.3. Sistema Incremental . . . . . . . . . . . . . . . . . . . 53
2.4. Reparto de Tareas Dinamico . . . . . . . . . . . . . . . 54
3. Forja IRIS-Libre . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.1. Subversion . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2. Planicador de Tareas . . . . . . . . . . . . . . . . . . 55
4. Blog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5. Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
8. Implementacion (II): Ingeniera de Escenarios 59
1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2. Ejemplo de Escenario . . . . . . . . . . . . . . . . . . . . . . . 61
3. Generacion de Escenarios . . . . . . . . . . . . . . . . . . . . . 63
VIII

9. Implementacion (III): Sistema Multiagente 65
1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2. Agente Creador . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3. Agente Reloj . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4. Agentes Entorno . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.1. Casillas Adyacentes y Multiples Entornos . . . . . . . . 72
4.2. Movimiento del Agua . . . . . . . . . . . . . . . . . . . 73
5. Agentes Entrada de Agua . . . . . . . . . . . . . . . . . . . . 74
6. Agentes Peaton . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7. Agentes Actualizacion . . . . . . . . . . . . . . . . . . . . . . 79
8. Maya Hexagonal . . . . . . . . . . . . . . . . . . . . . . . . . 80
8.1. Matriz de Alturas . . . . . . . . . . . . . . . . . . . . . 81
8.2. Matriz de Agua . . . . . . . . . . . . . . . . . . . . . . 81
8.3. Matriz de Calles . . . . . . . . . . . . . . . . . . . . . 81
8.4. Coronas . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.5. Coordenada a Casilla, y Viceversa . . . . . . . . . . . . 83
9. Especializacion: Multiples Desastres . . . . . . . . . . . . . . . 84
10. Elevacion del Terreno . . . . . . . . . . . . . . . . . . . . . . . 85
10.1. Cache de Alturas . . . . . . . . . . . . . . . . . . . . . 85
11. Open Street Maps . . . . . . . . . . . . . . . . . . . . . . . . . 86
11.1. Parsear XML . . . . . . . . . . . . . . . . . . . . . . . 86
11.2. Dibujar Calles . . . . . . . . . . . . . . . . . . . . . . . 87
11.3. Rellenar Figuras . . . . . . . . . . . . . . . . . . . . . 88
11.4. Intersecciones de Caminos . . . . . . . . . . . . . . . . 89
IX

1.2. Personales . . . . . . . . . . . . . . . . . . . . . . . . . 128
2. Ampliaciones y Mejoras . . . . . . . . . . . . . . . . . . . . . 129
2.1. Rendimiento . . . . . . . . . . . . . . . . . . . . . . . . 129
2.2. Otras catastrofes . . . . . . . . . . . . . . . . . . . . . 129
2.3. Interfaz Graca . . . . . . . . . . . . . . . . . . . . . . 130
A. Licencia del Simulador 131
B. Concurso Universitario de Software Libre 147
1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
1.1. >Que es...? . . . . . . . . . . . . . . . . . . . . . . . . . 147
1.2. >Que Objetivos Persigue? . . . . . . . . . . . . . . . . 148
1.3. Premios Locales . . . . . . . . . . . . . . . . . . . . . . 148
2. Descripcion General . . . . . . . . . . . . . . . . . . . . . . . . 148
3. Participacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Bibliografa 151
XI

Indice de guras
2.1. Huracan Katrina visto desde el espacio . . . . . . . . . . . . . 7
2.2. Da~nos producidos por el huracan al Superdome . . . . . . . . . 8
2.3. La ciudad de Nueva Orleans inundada . . . . . . . . . . . . . 9
2.4. Afectados solicitando ayuda en Nueva Orleans . . . . . . . . . 10
3.1. Tipos de agentes . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Agentes del simulador . . . . . . . . . . . . . . . . . . . . . . 30
5.2. Rejilla hexagonal . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.1. Compatibilidad de otras licencias libres con la GPL v3 . . . . 38
6.2. Logo de JADE . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3. Arquitectura de la plataforma FIPA . . . . . . . . . . . . . . . 40
6.4. Ciclo de vida de un agente FIPA . . . . . . . . . . . . . . . . 41
6.5. Interfaz graca de usuario de JADE . . . . . . . . . . . . . . . 45
6.6. Agente snier de JADE . . . . . . . . . . . . . . . . . . . . . 45
6.7. Logo de JAK . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.8. Logo de Open Street Maps . . . . . . . . . . . . . . . . . . . . 48
6.9. Logo de la USGS . . . . . . . . . . . . . . . . . . . . . . . . . 49
XIII

7.1. Ciclo de vida iterativo del software . . . . . . . . . . . . . . . 53
7.2. Logo de IRIS-Libre . . . . . . . . . . . . . . . . . . . . . . . . 54
7.3. Logo de Subversion . . . . . . . . . . . . . . . . . . . . . . . . 55
7.4. Logo de Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.5. Logo de Gitorious . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.1. Esquema con todos los agentes . . . . . . . . . . . . . . . . . . 66
9.2. Agente Creador . . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.3. Agente Reloj . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
9.4. Comunicaciones del agente Reloj . . . . . . . . . . . . . . . . 70
9.5. Agente Entorno . . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.6. Comunicaciones del agente Entorno . . . . . . . . . . . . . . . 72
9.7. Agente Entrada de Agua . . . . . . . . . . . . . . . . . . . . . 74
9.8. Comunicaciones del agente Entrada de Agua . . . . . . . . . . 75
9.9. Agente Peaton . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9.10. Peaton atascado . . . . . . . . . . . . . . . . . . . . . . . . . . 78
9.11. Comunicaciones del agente Peaton . . . . . . . . . . . . . . . . 79
9.12. Agente Actualizacion . . . . . . . . . . . . . . . . . . . . . . . 80
9.13. Comunicaciones del agente Actualizacion . . . . . . . . . . . . 80
9.14. Ro Mississippi visto por el visor bidimensional . . . . . . . . . 92
10.1. Area de simulacion . . . . . . . . . . . . . . . . . . . . . . . . 96
10.2. Division en 3 zonas del area afectada . . . . . . . . . . . . . . 97
10.3. Zona 1 de simulacion . . . . . . . . . . . . . . . . . . . . . . . 98
10.4. Zona 2 de simulacion . . . . . . . . . . . . . . . . . . . . . . . 99
XIV

Indice de listados
8.1. Escenario de ejemplo . . . . . . . . . . . . . . . . . . . . . . . 61
9.1. Fichero CSV de ejemplo . . . . . . . . . . . . . . . . . . . . . 93
10.1. Escenario post Katrina simulado para la zona 1 . . . . . . . . 106
10.2. Escenario post Katrina simulado para la zona 2 . . . . . . . . 108
10.3. Escenario post Katrina simulado para la zona 3 . . . . . . . . 109
XVII

2 Captulo 1. Introduccion
a otro tipo de catastrofes mas documentadas, como por ejemplo inundaciones.
2. Motivacion
Los desastres naturales provocan enormes perdidas, tanto personales co-
mo materiales. Se hace un gran esfuerzo en preparar medidas y se realizan
grandes inversiones en material, y aun as siguen produciendose tragedias
cada vez que una inundacion, un terremoto, etc, azota a algun pas[6].
Por ello resulta de vital importancia ser capaces de simular estos esce-
narios, para poder comprobar los efectos del desastre y tomar las medidas
adecuadas. El conocimiento previo al desastre es la clave, y la unica forma
de obtenerlo es la simulacion.
Pero por desgracia realizar una simulacion realista mediante metodos tra-
dicionales resulta extremadamente complejo, ademas de caro computacional-
mente. Por ello nosotros proponemos un simulador basado en agentes.
3. Solucion
Los sistemas multiagente son una tecnica de inteligencia articial que nos
permite abordar este problema desde un nuevo punto de vista. Un agente es
una entidad inteligente y autonoma, pero relativamente simple, y por lo tanto
computacionalmente ligera. Es la conducta combinada de estos agentes la
produce un resultado en conjunto inteligente, un comportamiento emergente
que no tiene por que estar planeado desde un principio.
Con esta herramienta es posible dise~nar un simulador cuya carga compu-
tacional no sea inabarcable y que produzca resultados satisfactorios.
3.1. Objetivos
Se pretende con este proyecto desarrollar la base de un Simulador de
Desastres, centrandose en el caso de una inundacion. El simulador ha de
cumplir las siguientes condiciones:

3. Solucion 3
Ha de simular utilizando datos reales del terreno simulado. No tendra
sentido realizar una simulacion si no se puede aprovechar la informacion
obtenida con ella.
Ha de ser escalable y distribuido. Es imprescindible que se pueda simu-
lar sobre areas tan grandes como se quiera, y que simplemente a~nadien-
do mas maquinas a la infraestructura de simulacion esto sea posible.
Ha de ser facilmente extensible a otros desastres naturales. La arquitec-
tura del simulador ha de estar dise~nada para que esta tarea no requiera
grandes modicaciones del codigo existente.
Ha de respetar los estandares utilizados en los sistemas multiagente.
En concreto los estandares de comunicacion entre agentes establecidos
por la FIPA 1.
Ha de poder generar estadsticas sobre el estado de las personas simula-
das, para poder realizar comparaciones entre simulaciones, o con datos
reales.
Como caso gua utilizaremos las inundaciones que siguieron al huracan
Katrina en la ciudad estadounidense de Nueva Orleans, en el a~no 2005.
Hemos escogido este caso concreto por la gran cantidad de documentacion
disponible.
3.2. Resultados
Para la visualizacion de resultados se ha optado por dos metodos. Un visor
bidimensional que muestra la simulacion en \tiempo real", y un generador de
KML2. KML es un estandar para la representacion de informacion geograca,
y se puede abrir con multiples visores, uno de los mas conocidos es Google
Earth.
Generar cheros KML nos permitira mostrar los resultados de la simu-
lacion sobre imagenes satelite del terreno simulado, con gracos en 3D del
terreno y con los edicios modelados tambien en 3D. De esta manera la repre-
sentacion de los resultados estara mucho mas cercana a la realidad y sera mas
accesible y sencilla de interpretar.
1Foundation for Intelligent Physical Agents: http://www.fipa.org/
2Keyhole Markup Language: http://www.opengeospatial.org/standards/kml/

2. Efectos en Nueva Orleans 9
2. Efectos en Nueva Orleans
El 2 de septiembre de 2005 el 85 % de la ciudad de Nueva Orleans estaba
bajo el agua, donde en algunas zonas llego a 7 m de profundidad. Durante
un tiempo, la ciudad estuvo inhabitable. Todos los servicios publicos estaban
suspendidos y no era posible utilizar la infraestructura fsica debido a la gran
cantidad de agua. Ademas estaba en crisis de orden publico debido al violento
saqueo generalizado que se presenta por la falta de alimentos y seguridad. El
Superdome, principal refugio "de ultima hora"tuvo que ser evacuado debido
al deterioro de las condiciones de vida en su interior (da~no a los generadores,
falta de aire acondicionado e interrupcion del servicio de entrega de agua).
Figura 2.3: La ciudad de Nueva Orleans inundada
Durante los das anteriores se generalizo el vandalismo y la escasez de
alimentos, vivienda y agua produjo un desorden civil de grandes proporciones.
La tarde del 1 de septiembre, la ocina del alcalde pidio ayuda urgente para
controlar la situacion que haba alcanzado niveles desmedidos. Durante varios
das estuvo vigente la ley marcial, el uso de la fuerza contra el saqueo y la
recomendacion urgente de abandonar la ciudad a traves de la conexion con

10 Captulo 2. Huracan Katrina
Crescent City, o en su defecto buscar refugio en pisos mas altos. La rotura
de una seccion del dique hizo que el nivel de agua aumentase en vez de
disminuir, y los esfuerzos para reconstruirlo temporalmente arrojando bolsas
de arena desde helicopteros no resultaron efectivos. En la tarde del 30 de
agosto, y en atencion a la imposibilidad de restaurar el aislamiento con el
lago Pontchartrain, y al empeoramiento de las condiciones de vida en los
albergues, la gobernadora de Luisiana, Kathleen Blanco, ordeno la evacuacion
de todos los residentes de Nueva Orleans[10].
Figura 2.4: Afectados solicitando ayuda en Nueva Orleans
3. Estudios e Informacion sobre el Desastre
Como el huracan afecto a Estados Unidos, pas desarrollado y con grandes
recursos, hay mucha informacion disponible. Informacion meteorologica sobre
la evolucion y desarrollo del huracan[4], e informacion sobre las perdidas hu-
manas y materiales[15][12], as como informes sobre la actuacion de las fuer-
zas de seguridad y emergencias del estado[10]. Tambien es posible encontrar
informacion sobre los evacuados[13], estudios demogracos[20], encuestas[1],
etc.
Aparte de todos estos estudios, tambien es muy importante contar con
informacion geograca del terreno afectado. Afortunadamente, y una vez
mas, dado que se trata de Estados Unidos, contamos con varias fuentes de
informacion.

3. Estudios e Informacion sobre el Desastre 11
La U.S. Geological Survey (USGS1) es una institucion gubernamental de-
dicada al estudio biologico, geologico, geograco y geoespacial de Estados
Unidos. Entre otras muchas funciones, mantiene una base de datos de in-
formacion sobre la altura del terreno, la National Elevation Dataset (NED2.
Dicha base de datos contiene informacion de multiples fuentes, incluso pro-
veniente de la Shuttle Radar Topography Mission (SRTM3) desarrollada por
la National Aeronautics and Space Administration (NASA). Estos datos al-
canzan en algunas zonas -como es el caso de Nueva Orleans- la precision de
1=9 de segundo de arco (aproximadamente 3 metros).
Existen tambien servicios de informacion con los datos relativos a la or-
ganizacion de las ciudades: calles, parques, etc. Un servicio que proporciona
informacion de calidad, y de acceso libre, sobre Nueva Orleans es Open Street
Maps (OSM4.
La forma de acceder y procesar estos datos se presenta en captulos pos-
teriores.
1http://www.usgs.gov/
2http://ned.usgs.gov/
3http://www2.jpl.nasa.gov/srtm/
4http://www.openstreetmap.org/

Captulo 3
Simulacion Basada en Agentes
Creo que para nal de siglo el uso de las pa-
labras y la opinion general habran cambiado
tanto, que uno podra hablar sobre maquinas
pensantes sin que le contradigan.
Alan M. Turing
1. Agentes Inteligentes
Una posible denicion muy resumida de agente inteligente sera la siguien-
te: un agente inteligente es una entidad autonoma que observa y actua sobre
un entorno, y dirige su actividad en pos de uno o mas objetivos. Por supues-
to esta denicion no abarca muchos matices, pero nos da una idea general
que nos sirve como punto de partida. La variedad de agentes es muy amplia,
as como su complejidad, que puede ir desde un sencillo agente puramente
reactivo a uno complejo que imite a una persona, por ejemplo.
Las siguientes caractersticas son necesarias para que un proceso sea con-
siderado un agente de algun tipo[19]:
Un agente es indenticable; tiene lmites denidos, por lo que es facil
determinar cuando algo es parte del agente, no lo es, o es un carac-
terstica compartida.
13

1. Agentes Inteligentes 15
Proactividad Para conseguir sus objetivos han de tomar decisiones y rea-
lizar acciones segun una estrategia.
Comunicacion Deben poder comunicarse entre s, compartir informacion,
e incluso, cooperar para la consecucion de sus objetivos.
Aunque existen agentes puramente reactivos, es difcil aplicarles la eti-
queta de inteligentes. Un grado de proactividad es imprescindible, aunque
se hace necesario encontrar un equilibrio entre la reactividad y la busqueda
activa de objetivos.
1.1. Que no es un Agente
A veces resulta mas claro y practico comparar lo que se quiere denir con
elementos relacionados y resaltar las diferencias, que dar una denicion. A
continuacion sigue una comparacion entre un agente inteligente y otros tipos
de software relacionados.
Agentes frente a Programas
Las principales caractersticas que distinguen a un agente de un progra-
ma arbitrario son cuatro: reactividad al entorno, autonoma, proactividad y
persistencia[11].
Agentes frente a Objetos
Las diferencias que intuitivamente se pueden encontrar son las siguientes[23]:
Los agentes son mas autonomos que los objetos.
Los agentes tienen un comportamiento mas
exible, reactivo, proactivo
y social.
Los agentes tienen como mnimo un hilo de control, pero pueden tener
mas.

16 Captulo 3. Simulacion Basada en Agentes
Agentes frente a Sistemas Expertos
Las diferencias son las siguientes[23]:
Los sistemas expertos no estan emparejados a su entorno.
Los sistemas expertos no estan dise~nados para tener un comportamien-
to reactivo ni proactivo.
Los sistemas expertos no tienen capacidades sociales.
1.2. Tipos de Agentes
Existen varios tipos de agentes segun sus caractersticas y capacidades.
Lo que sigue es solo una de las posibles clasicaciones.
Reactivos
Los agentes puramente reactivos actuan unicamente en base a su percep-
cion. La funcionalidad del agente esta basada en la regla de condicion-accion:
si tal condicion entonces tal accion. Este tipo de agentes es particularmente
interesante cuando el entorno es observable en su totalidad.
Tambien es posible que un agente reactivo contenga informacion de su
estado en cada momento, lo que les permite obviar condiciones que ya hayan
activado acciones en momentos anteriores.
Reactivos basados en Modelo
Este tipo de agentes es capaz de desenvolverse en entornos que son solo
parcialmente observables. Almacenan su estado en cada momento mante-
niendo algun tipo de estructura que describa el entorno que no se puede
percibir. Obviamente, esta cualidad requiere informacion sobre como se com-
porta y funciona el entorno. Es esta informacion adicional la que completa
las percepciones del agente.

2. Sistemas MultiAgente (SMA) 17
Un agente reactivo basado en modelo realiza un seguimiento del estado
del entorno en cada momento, usando su modelo interno. Con ambas infor-
maciones (su modelo interno y sus percepciones) toma las decisiones de la
misma manera que un agente puramente reactivo.
Basados en Objetivos
Los agentes basados en objetivos son agentes basados en modelo que
ademas almacenan informacion relativa a situacion que son deseables. Gracias
a esto el agente es capaz de escoger de entre multiples posibilidades aquellas
que cumplen un objetivo.
Basados en Utilidad
Loa agentes basados en objetivos solo diferencian entre estados objetivo
y no objetivo. Es posible denir una medida de cuan deseable es un estado
en particular. Esta medida se obtiene a traves del uso de una funcion de
evaluacion de la utilidad de un estado concreto.
Gracias a esta funcion el agente es capaz de escoger aquellos estados que
ayudan o favorecen la consecucion de los objetivos, en el caso de que ningun
estado posible cumpla un objetivo directamente.
Con capacidad de Aprendizaje
El aprendizaje presenta ventajas tales como que permite a los agentes
operar en entornos inicialmente desconocidos, y convertirse en agentes mas
competentes de lo que su conocimiento inicial por s mismo permitira. Esta
capacidad de aprendizaje requiere que el agente tenga memoria, y permite la
mejora de la ecacia de este a lo largo del tiempo.
2. Sistemas MultiAgente (SMA)
Un sistema multiagente (SMA) es un sistema compuesto de multiples
agentes inteligentes que interactuan entre s. Estos sistemas se utilizan para

2. Sistemas MultiAgente (SMA) 19
2.2. Estrategia de Trabajo
Existen multiples formas de plantear un sistema multiagente, pero una
de la mas habituales es la tecnica de divide y venceras. Basicamente se trata
de subdividir el problema en problemas mas peque~nos resolubles por agentes
particulares, o bien por un subconjunto de agentes que cooperen entre s.
La solucion global surgira de la combinacion del trabajo de cada agente,
esta supersolucion puede surgir de manera automatica como un comporta-
miento emergente, o puede ser necesario que otro agente explcitamente se
encargue de elaborarla.
El principal obstaculo a la hora de aplicar esta tecnica es que los pro-
blemas normalmente no tienen una solucion general. Muchas veces se ha
necesario resolver cada caso por separado, lo que puede conducir a com-
portamientos erroneos o a la aparicion de comportamientos emergentes no
deseados.
2.3. Protocolos de Comunicacion
Es la capacidad de comunicacion entre los agentes que componen un SMA
lo que permite que el sistema funcione y resuelva problemas. Sin comunica-
cion no hay SMA.
Existen varios metodos de comunicacion entre agentes, pero el mas ha-
bitual es el paso de mensajes entre ellos. Para poder llevar esto a cabo es
necesario denir protocolos de comunicacion, y dos de los mas utilizados son
el Knowledge Query Manipulation Language (KQML)1 y el Agent Commu-
nication Language (ACL)2.
Es muy importante que estos protocolos se estandaricen para poder esta-
blecer interacciones entre diferentes plataformas de agentes.
1http://www.cs.umbc.edu/research/kqml/
2http://www.fipa.org/repository/aclspecs.html

Captulo 4
Simulacion de Inundaciones
Solo podemos ver un poco del futuro, pero
lo suciente para darnos cuenta de que hay
mucho por hacer.
Alan M. Turing
1. Planteamiento del Problema
Nuestro simulador consta de tres grandes elementos: el agua, las personas
y la ciudad.
Para poder simular una inundacion primero necesitamos saber como se
comporta el agua. Desde aspectos basicos como que tiende a moverse hacia las
zonas bajas del terreno, hasta cosas no tan basicas como puede ser dinamica
de
uidos.
Por otro lado queremos simular la reaccion que tendran las personas ante
una inundacion, para ello necesitamos saber la velocidad a la que pueden
desplazarse y los posibles cursos de accion que tomaran.
Por ultimo queremos que nuestro sistema sea global, de tal forma que
no este restringido solo a una zona concreta del planeta. Para ello hemos de
utilizar sistemas de informacion global. Aunque siempre estaremos a expensas
de la disponibilidad de los datos.
21

24 Captulo 4. Simulacion de Inundaciones
3.1. Ros
En una ciudad, un ro sera, por lo general, un sector con
ictivo cuan-
do se produzca una inundacion, pues probablemente sea el causante de la
inundacion.
Los calculos necesarios para calcular el caudal introducido y el caudal
evacuado son complejos de por s[16], pero podran ser resueltos por nuestro
sistema multiagente si tuviesemos acceso a los datos necesarios, tales como
la forma del lecho del ro, etc.
3.2. Forma de los Edicios
La forma de los edicios tambien va a in
uir en el desarrollo de la inun-
dacion. Cuando entre el agua dentro del edicio se modicara su velocidad
y trayectoria, y ademas las paredes o fachadas pueden canalizar el agua y
llegar a formar piscinas, o inundar sotanos.
Sin conocer la forma del edicio no podemos hacer una simulacion del
todo el a realidad, pues estos afectan al movimiento del agua y evolucion de
la inundacion. Con una fuente de datos de elevacion sucientemente buena,
que contenga las alturas de los edicios, el simulador sera capaz de simular
adecuadamente el agua. Pero una vez mas, estamos a merced de la calidad
de los datos.
3.3. Calles y Carreteras
Las calles y carreteras tienen la particularidad de ser practicamente pla-
nas, y de inclinacion suave, lo que las hacen idoneas para que el agua pueda
moverse sin mucha dicultad. Actuan como canales conduciendo el agua a
mas velocidad por la ciudad que el agua que atraviesa edicios.
3.4. Alcantarillado
Todas las ciudades tienen una red de alcantarillado, al menos todas las
del primer mundo, que no es mas que un conjunto de canales subterraneos
dedicados al desplazamiento de agua.

3. Inundaciones en un Entorno Urbano 25
En caso de inundacion, las redes del alcantarillado moveran una gran
cantidad de agua que no se vera afectada por obstaculos o irregularidades
del terreno. Es un problema que se puede asemejar al de las ltraciones, pero
con un factor de incidencia mucho mas alto.
Para poder incluirlo en el simulador se hace necesario el disponer de un
mapa del alcantarillado y de sus zonas de desague. Se podra asumir que
practicamente debajo de cada calle habra una conduccion de alcantarilla,
pero se estaran ignorando los caudales de las conducciones y los puntos de
entrada o salida de agua.
3.5. Prioridades de las Personas
Se han realizado estudios[17] en algunas poblaciones sobre que es lo que
haran sus habitantes en caso de crisis. Se han considerado aspectos tales
como su disponibilidad a salvar a familiares en apuros, o a vecinos, o simple-
mente a cualquier desconocido que lo necesite.
En el simulador esto se podra traducir en comportamientos de ayuda
entre agentes, como indicarles el camino a seguir o incluso acompa~narles a
un lugar seguro.
3.6. Supervivencia en un Entorno Inundado
Tambien es importante, ante una catastrofe, recoger informacion acerca
de los supervivientes para posteriores analisis. Por ejemplo, tras las inunda-
ciones producidas por el huracan Katrina en Nueva Orleans se han realizado
encuestas[1] de este tipo.
Informacion sobre los peores momentos de la inundacion, las zonas mas
afectadas, los lugares de mayor concentracion de personas, etc. Este tipo
de datos pueden darnos una idea aproximada de como se podran prevenir
ciertas situaciones de riesgo. Tambien nos puede ser util para realizar un
informe de da~nos y necesidades de la poblacion tras el desastre.
En nuestro caso contar con este tipo de informaciones nos permitira con-
trastar los resultados simulados con casos reales, para realizar comparaciones
y sacar conclusiones.

Captulo 5
Solucion Propuesta
No podemos resolver los problemas utilizan-
do la misma manera de pensar que utiliza-
mos cuando los creamos.
Albert Einstein
1. Denicion del Escenario de Simulacion
Los datos de entrada del simulador son los que llamamos Escenario. En
ellos se dene el area de simulacion, tama~no de los hexagonos, las entradas
de agua, los tiempos, las personas, etc.
Toda esta informacion estara denida en un chero tipo clave=valor, que
sera procesado por el agente Creador al lanzar la simulacion.
2. Agentes en la Simulacion
En el siguiente esquema se muestran los agentes que conforman el simula-
dor. Algunos de ellos tienen un papel mas importante que otros, destacando
los agentes Entorno y los agentes Peaton.
29

2. Agentes en la Simulacion 31
2.2. Agente Reloj
La necesidad de un agente que sincronizase la simulacion no se hizo pa-
tente hasta bien avanzado el desarrollo del simulador. El motivo se explica
en profundidad en el captulo 9.
Este agente tiene el objetivo de sincronizar al resto de agentes, y su fun-
cionamiento es muy sencillo. Dado un periodo de tiempo, denido en el Es-
cenario de simulacion, el agente Reloj ha de enviar regularmente un mensaje
al resto de agentes dando lugar a un ciclo de simulacion.
Los agentes que reciben estos mensajes, y por lo tanto estan sincronizados,
son: agentes Entorno, agentes Entrada de Agua y agentes Peaton.
2.3. Agentes Entorno
Probablemente el agente con mas responsabilidades y trabajo de todo el
simulador. Su mision es manejar la informacion relativa al terreno de un area
de simulacion.
Para asegurar la escalabilidad del sistema ha de ser posible dividir el area
a simular entre varios agentes Entorno, de manera que cada Entorno se
pueda ejecutar en un nucleo diferente, o incluso en una maquina diferente.
Esta division ha de ser totalmente trasparente para los demas agentes.
Estos agentes se encargan de:
Obtener la elevacion del terreno y la informacion relativa a calles, pun-
tos de interes, etc.
Mover el agua de la inundacion por el entorno.
Recibir el agua que entre en la simulacion desde un agente Entrada
de agua.
Informar a los agentes Peaton de que es lo que ven a su alrededor dada
su posicion.
Informar a los agentes Actualizacion de la evolucion de la simulacion.

3. Elevacion del Terreno 33
2.5. Agentes Peaton
El objetivo nal de toda persona que se ve envuelta un desastre es salvarse
a s misma y a sus allegados. Ese mismo objetivo es compartido por estos
agentes, pues representan a una o a un grupo de personas.
El ciclo de vida del agente sera tal que:
1. Solicitar informacion acerca de lo que le rodea al agente Entorno co-
rrespondiente.
2. Analizar dicha informacion y escoger una posicion a la que moverse.
3. Informar al agente Entorno del movimiento y estado de salud.
4. En caso de haber alcanzado algun refugio, vuelta al punto 1.
En todo momento el agente debera tratar, evidentemente, de no perder
la vida ahogado en la inundacion.
2.6. Agentes Actualizacion
Actuan unicamente como receptores de mensajes, su mision consiste en
recibir las actualizaciones de los agentes Entorno y pasarselas a otros ele-
mentos del sistema, que son los que las procesaran. Como por ejemplo, los
generadores de KML, los visores bidimensionales o los generadores
de estadsticas.
En denitiva, estos agentes sirven para obtener informacion de la simu-
lacion que se este llevando a cabo.
3. Elevacion del Terreno
Para obtener los datos de elevacion del terreno hemos de utilizar fuentes
de datos externas. En concreto para los Estados Unidos utilizaremos el ser-
vicio web de la USGS1, donde proveen informacion de hasta 1=9 de segundo
1United States Geological Survey: http://www.usgs.gov/

34 Captulo 5. Solucion Propuesta
de arco de precision (aproximadamente 3 metros), gracias a la base de datos
NED2. Este servicio es gratuito y de libre uso.
El simulador ha de ser totalmente independiente de la fuente de datos
de elevacion, de manera que sea sencillo a~nadir nuevas fuentes de datos para
poder simular en territorios fuera de los Estados Unidos. De esta manera el
terreno sobre el que simular solo estara limitado por los datos de los que
dispongamos.
4. Geolocalizacion
Para poder geolocalizar los elementos y poder utilizarnos en nuestra si-
mulacion, necesitamos crear una equivalencia entre casilla y coordenada.
De esta forma todo lo que simulemos podremos trasladarlo por medio de
las casillas al mundo real y toda la informacion del mundo real que podamos
recoger la podremos representar por medio de las casillas.
5. Open Street Maps
Para la informacion relativa a calles, puntos de interes, etc, recurriremos
a OSM3. OSM es un esfuerzo colaborativo para crear cartografa libre, es
gratuito y de libre uso[22]. La calidad de los mapas en las ciudades mas
grandes e importantes es muy buena, aunque en lugares menos poblados
decae.
Pero al igual que con los datos de elevacion, el simulador ha de ser inde-
pendiente de OSM y ha de poder utilizar otras fuentes de datos.
6. Generador de KML
El generador de KML sera un cliente de un agente Actualizacion. Esto
signica que por cada generador de KML que este atendiendo a la simu-
2National Elevation Dataset: http://ned.usgs.gov/
3Open Street Maps: http://www.openstreetmap.org/

7. Visor Bidimensional 35
lacion habra un agente Actualizacion. Sera el agente el que mantenga la
comunicacion con los agentes Entorno que sean necesarios.
El chero resultante debera ser, como es natural, correcto conforme al
estandar. Para ello contamos con herramientas de validacion4 con las que
comprobar que nuestros cheros se ajustan al estandar mantenido por el
OGC5. Es muy importante que se ajusten al estandar para su correcta vi-
sualizacion en cualquier visor de KML.
7. Visor Bidimensional
Se hace necesario un visor que muestre la evolucion de la simulacion en
pseudo tiempo real, pues estara supeditado a la frecuencia con la que reciba
datos nuevos desde los agentes Entorno. Al igual que el generador de
KML funcionara a traves de un agente Actualizacion.
El visor sera bidimensional para facilitar el dibujado y reducir la carga
computacional. Debera mostrar el estado de la simulacion con cada nue-
va actualizacion, aunque no se podran mostrar todos los pasos dado que de
aquellos estados que ocurran entre actualizacion y actualizacion no tendra in-
formacion.
Gracias a este visor no es necesario esperar a haber completado la simula-
cion para poder visualizar los resultados, aunque es claramente mas limitado
que el chero KML.
8. Estadsticas
Tambien es muy importante que se puedan extraer estadsticas de las
simulaciones. Para ello usaremos, una vez mas, un agente Actualizacion.
Una vez generado el chero se podra trabajar sobre el mediante un pro-
grama cualquiera de hojas de calculo o similar, pudiendo generar gracas,
aplicar formulas, etc.
Los datos que se almacenaran seran los relativos a las personas. Numero
4Por ejemplo http://www.kmlvalidator.com
5Open Geospatial Consortium: http://www.opengeospatial.org/standards/kml

36 Captulo 5. Solucion Propuesta
de muertos, de personas a salvo, etc, y el tiempo transcurrido en la simulacion.
Las estadsticas que se quieran sacar se tendran que calcular a posteriori, por
ejemplo con una hoja de calculo, sobre los datos de estos cheros.

Captulo 6
Tecnologa Elegida
Cualquier tecnologa lo sucientemente
avanzada es indistinguible de la magia.
Arthur C. Clarke
1. Licencias
Para este proyecto vamos a usar la licencia GPL (Licencia Publica General
de GNU) en su version 3 o posterior, escrita y mantenida por la FSF1. El
texto legal se puede encontrar en el Apendice primero.
Al colocar el simulador bajo esta licencia nos tenemos que asegurar que
todas las libreras que utilicemos esten bajo licencias compatibles con la nues-
tra. A continuacion sigue un graco con la relacion de compatibilidad de otras
licencias libres con la GPL v3.
1Free Software Foundation: http://www.fsf.org/
37

2. JADE 39
JADE esta desarrollado y mantenido por Telecom Italia3, y es una pla-
taforma para el desarrollo de sistemas multiagentes.
JADE puede ser considerado como un \middleware" que comporta una
plataforma de agentes y un entorno de desarrollo. Al utilizar JADE el desa-
rrollador solo tiene que concentrarse en los agentes que escriba, el resto de
aspectos del sistema estan ya resueltos, tales como el intercambio de mensa-
jes, la busqueda de agentes, el ciclo de vida de estos, etc. Ademas esta escrita
en Java, lo que aumenta la portabilidad a multiples entornos de ejecucion
frente otros lenguajes de programacion.
Dado que nuestro proyecto hace uso de la licencia GPL v3, es vital que el
software que utilicemos sea tambien libre y este bajo una licencia compatible.
En concreto JADE usa la licencia LGPL4 v2.
Ademas de ser Software Libre, JADE tiene tambien la virtud de cumplir
con la especicacion completa de la FIPA. Cumplir con dichos estandares
es muy importante para que sea posible la interaccion entre sistemas mul-
tiagentes, y que el proyecto no sea un entorno cerrado sin capacidad de
comunicacion.
Por todos estos motivos hemos escogido esta tecnologa de agentes. El
hecho de utilizar JADE nos condiciona a utilizar Java como lenguaje y pla-
taforma de desarrollo para el proyecto. El resto de libreras y paquetes que
utilizamos, y que describimos en los siguientes apartados, estan pues escritos
en este lenguaje.
2.1. Arquitectura FIPA
La arquitectura que sigue JADE ha sido desarrollada por FIPA con el
objetivo de permitir la construccion de sistemas multigente que se integren
entre s en un entorno de computacion particular. Adicionalmente podran in-
teroperar con sistemas construidos con diferente tecnologa pero que tambien
sigan estas especicaciones, todo ello con el mnimo esfuerzo.
3http://jade.tilab.com/
4Licencia Publica General Reducida de GNU:
http://www.gnu.org/licenses/old-licenses/lgpl-2.0.html

44 Captulo 6. Tecnologa Elegida
Performativa O tipo de acto comunicativo. FIPA proporciona varios tipos
como \request", \query", etc.
Emisor y receptor/es Los identicadores (AID) de todos los agentes in-
volucrados en la conversacion.
Contenido El contenido en s del mensaje.
Descripcion del contenido De que manera esta expresado el contenido
del mensaje, por ejemplo, siguiendo un lenguaje formal.
Control de la conversacion Parametros que permiten a los agentes man-
tener varias conversaciones sin mezclar mensajes, por ejemplo: \re-
ply with", \in reply to", etc.
2.2. Implementacion de FIPA en JADE
Como ya hemos comentado anteriormente, JADE implementa por com-
pleto la plataforma FIPA que acabamos de describir[8]. Por ejemplo, para
implementar el ACC hace uso de eventos Java para agentes en una misma
maquina, y HTTP, IIOP o Corba para comunicacion entre maquinas.
En JADE la plataforma de agentes puede distribuirse entre varios con-
tenedores, que pueden encontrarse todos en una o en varias maquinas. En
denitiva, la plataforma puede comprender varios ordenadores, mientras que
un contenedor se ejecuta en un unico ordenador, que a su vez puede ejecutar
mas contenedores en paralelo (de la misma u otra plataforma).
Ademas de los agentes especicados por FIPA, JADE provee una interfaz
graca para el control y monitorizacion del estado de los agentes. Esta interfaz
permite, en otras acciones, crear agentes, pausarlos, matarlos, etc. El agente
que muestra esta interfaz se denomina RMA.

46 Captulo 6. Tecnologa Elegida
3. Java
Java es un lenguaje de programacion orientado a objetos desarrollado por
Sun Microsystems, recientemente adquirida por Oracle, a principios de los
a~nos 90. El leitmotiv de los desarrolladores de Java era write once, run any-
where, que hace referencia a la portabilidad de un programa Java, capaz de
ejecutarse alla donde hubiera una maquina virtual, una de las caractersticas
mas notorias de la plataforma.
La eleccion de utilizar Java viene condicionada a la eleccion de utilizar
JADE, que esta escrito en este lenguaje.
De Java existe una implementacion totalmente libre de nombre OpenJDK5.
OpenJDK soporta el 99 % de la plataforma, y el simulador podra ejecutarse
sobre esta implementacion.
4. JAK
JAK (Java API for KML) son un conjunto de libreras para el manejo de
cheros KML desde Java. JAK ha sido desarrollado por Micromata GmbH6.
Figura 6.7: Logo de JAK
Al igual que en el caso de JADE es necesario que JAK sea compatible
con la licencia de nuestro proyecto, la GPL v3. Los desarrolladores de JAK
optaron por liberar las libreras bajo una licencia BSD7 de 3 clausulas, o
como tambien se la conoce, licencia BSD modicada o nueva licencia BSD.
La licencia de JAK se puede consultar en su sitio web.
Gracias a JAK podremos generar los cheros KML con el resultado de la
simulacion.
5http://openjdk.java.net/
6http://labs.micromata.de/display/jak/Home
7Berkeley Software Distribution:
http://www.opensource.org/licenses/bsd-license.php

3. Forja IRIS-Libre 55
que proporciona, encontramos:
3.1. Subversion
Como sistema de control de versiones la forja proporciona SVN4, este
sistema permite llevar un control sobre los cambios en el codigo, y obtener
siempre una copia actualizada con la ultima version.
Figura 7.3: Logo de Subversion
Este tipo de software es imprescindible cuando se trabaja en grupo, pues
facilita la colaboracion y permite mantener un orden en el desarrollo.
3.2. Planicador de Tareas
La forja tambien dispone de una sencilla aplicacion de control de tareas,
que, entre otras cosas, lo que permite es:
1. Crear una tarea, con una breve descripcion de la misma.
2. Asignarlas a un desarrollador, y as poder repartir la carga de trabajo.
3. Estimacion del tiempo necesario, para poder planicar otras tareas.
4. Progreso de la tarea, para poder hacer un seguimiento del progreso de
la misma.
5. Fecha lmite de nalizacion.
Con estos sencillos parametros la herramienta incluso genera un diagrama
de Gantt para ayudarte con la planicacion.
4http://subversion.tigris.org/

2. Ejemplo de Escenario 61
gados de mostrar los resultados, as se dene la nura de los resultados
obtenidos.
Hay que destacar que los datos denidos en el escenario son los datos
iniciales de la simulacion, y que muchos se traducen a agentes, como por
ejemplos las entradas de agua o las personas. Esto permite que en caliente
se puedan a~nadir, por ejemplo, nuevas fuentes de agua a la simulacion, pues
se puede a~nadir agentes nuevos a una simulacion en marcha.
2. Ejemplo de Escenario
Listado 8.1: Escenario de ejemplo
1 type=u t i l . f l o o d . FloodScenar io
2 name=Ejemplo
3 d e s c r i p t i o n=Escenar io de ejemplo para l a memoria
4 date =01/01/2010
5 hour =12:00:00
6 t i c k =500
7 r ea lT i ck=5
8 NW=[29.95 , 90.07 ]
9 SE=[29.945 , 90.065]
10 t i l e S i z e =15
11 p r e c i s i o n=5
12 numEnvs=1
13 randomTerrain=False
14 DBServer=// l o c a l h o s t
15 DBPort=3306
16 DBUser=ejemplo
17 DBPass=ejemplo
18 DBDriver=mysql
19 DBDb=dis s im
20 waterSource =[29 .947 , 90.067 ,30 ]
21 waterSource =[29 .946 , 90.069 ,30 ]
22 person =[29 .948 , 90 .068 ,10 ,5 ,3 , [ 29 .948 , 90 .0657 ] ]
23 person =[29 .946 , 90 .066 ,10 ,5 ,3 , [ 29 .948 , 90 .0657 ] ]
24 person =[29 .947 , 90 .069 ,10 ,5 ,3 , [ 29 .948 , 90 .0657 ] ]
25 person =[29 .9485 , 90 .068 ,10 ,5 ,3 , [ 29 .948 , 90 .0657 ] ]
26 person =[29 .9451 , 90 .066 ,10 ,5 ,3 , [ 29 .948 , 90 .0657 ] ]
27 updateTimeKml=1000
28 updateTimeVisor=500

3. Generacion de Escenarios 63
DBDriver especica que tipo de servidor se esta utilizando, en este caso se
utiliza MySQL1. DBDb es el nombre de la base de datos donde se encuentra
la tabla Elevations, dicha tabla esta descrita en la seccion donde se trata la
obtencion de datos de alturas.
No todos los elementos DB son imprescindibles. Por ejemplo, si se utiliza
el servidor de base de datos de chero SQLite2 no es necesario denir mas
que DBServer y DBDriver.
Cada lnea con la clave waterSource representa una entrada de agua di-
ferente al sistema, todas las entradas denidas en el chero del escenario se
activan nada mas comenzar la simulacion. Para a~nadir fuentes de agua que
aparecen un tiempo despues del comienzo de la simulacion hay que a~nadir
agentes Entrada de Agua en caliente. El array contiene los siguientes da-
tos: latitud, longitud y cantidad de agua que entra en cada tick medida en
unidades de altura de la simulacion. El orden en que aparecen estos elementos
es jo.
Al igual que con las entradas de agua, puede haber multiples lneas con la
clave person. Representan a agentes Peaton en la simulacion. Los parametros
del array son, en orden, los siguientes: latitud, longitud, distancia de vision en
hexagonos, velocidad en hexagonos, numero de clones y un array de objetivos
-con multiples pares latitud y longitud, aunque en este caso solo hay un
objetivo-. Todos estos parametros seran discutidos en la seccion de los agentes
Peaton.
updateTimeKML y updateTimeVisor se miden ambos en milisegundos,
y hacen referencia al tiempo que transcurre entre que los agentes Entorno
envan actualizaciones a los generadores de KML y a los visores respectiva-
mente.
3. Generacion de Escenarios
Aunque es perfectamente posible escribir un chero escenario con un edi-
tor de textos, resulta mas sencillo utilizar el script de lanzamiento de la
simulacion para generar uno en un modo interactivo. Dicho modo se explica
en detalle en la seccion dedicada al script de lanzamiento.
1http://www.mysql.com/
2http://www.sqlite.org/

66 Captulo 9. Implementacion (III): Sistema Multiagente
Figura 9.1: Esquema con todos los agentes

1. Introduccion 67
En programacion con agentes lo habitual es que los agentes en s no
contengan la logica de su actividad, si no que tan solo contienen el codigo
de inicializacion y de nalizacion. Toda actividad que desarrolle el agente
durante su vida debe estar contenida en sus comportamientos, luego para que
el agente haga cualquier accion ha de a~nadrsele el comportamiento adecuado.
Para la programacion de agentes utilizamos JADE, y JADE funciona me-
diante herencia. Por ejemplo, para programar un agente hemos de extender
la clase jade.core.Agent. Y lo mismo para los comportamientos de los agentes,
se extiende la clase jade.core.behaviours.Behaviour. Una vez extendida la cla-
se correspondiente se implementan los metodos abstractos y se sobreescriben
los que se consideren necesarios.
Por ejemplo, en el caso de un agente, JADE proporciona una manera de
inicializarlo, que es sobreescribir el metodo setup(). JADE nos garantiza que
dicho metodo se ejecutara una unica vez al crear el agente.
De la misma manera se trabaja con los comportamientos. Ademas JADE
proporciona multiples clases de las que extender, estos comportamientos re-
nados -heredan todos de jade.core.behaviours.Behaviour- facilitan la pro-
gramacion. Por ejemplo, para un comportamiento que cree a otro agente
lo habitual es solo se ejecute una vez, para ello se hereda directamente de
jade.core.behaviours.OneShotBehaviour y JADE nos asegura de que solo se
ejecutara una vez.
A continuacion pasamos a explicar los agentes del simulador. Por cada
agente hay un esquema de los comportamientos que utiliza, y en algunos de
ellos -los que inicien un dialogo con otros agentes- tambien hay un esquema
de las comunicaciones que mantienen.
Dichos esquemas de comunicacion siguen el siguiente formato: A cada
lado se situa un agente, a la izquierda el que comienza el dialogo. Entre los
agentes hay
echas que representan mensajes, el sentido de la fecha denota
al emisor y al receptor. Sobre cada
echa va descrito, y en este orden, desde
que comportamiento se enva, que comportamiento lo recibe, y de que trata
el mensaje -tipo o contenido del mismo-. Obviamente el comportamiento que
enva el mensaje es del agente emisor, y el que recibe es del agente receptor.

72 Captulo 9. Implementacion (III): Sistema Multiagente
behaviours.people.RegisterPeopleBehav es el comportamiento con el que
se comunican los Peatones para avisar al entorno de su posicion y salud.
Figura 9.6: Comunicaciones del agente Entorno
4.1. Casillas Adyacentes y Multiples Entornos
El Entorno recibe muchas peticiones, normalmente de los Peatones,
solicitando las casillas adyacentes a una dada. El agente consulta su maya
hexagonal y devuelve las casillas pedidas.
El unico problema es que un Entorno solo conoce lo que ocurre en el
terreno que simula, pero no los datos del resto de Entornos. Para los Pea-
tones esto es un problema, pues para ellos el que se simule con multiples
Entornos debera ser transparente. Esto signica que las fronteras que se-
paran los trozos de terreno de los diferentes agentes Entorno suponen una
barrera a la vision de los Peatones, lo cual no tiene ningun sentido.
Para solucionar dicho problema tuvimos que renar el comportamiento
AdjacentsGridBehav, y hacer que cuando detectase que la casilla de la que se
solicitan los adyacentes esta mas cerca del borde del terreno que la distancia
de vision pedida, entonces solicitase los adyacentes restantes a los agentes
Entorno correspondientes.

4. Agentes Entorno 73
Es decir, que cuando un agente Peaton solicita los hexagonos adyacentes
a uno dado a un Entorno concreto, puede estar involucrando a mas agentes
en el proceso pero sin saberlo. Para los Peatones este proceso es del todo
transparente.
4.2. Movimiento del Agua
Dadas las limitaciones vistas en el captulo 4, y sobre todo dada nuestra
intencion de crear un modelo sencillo y abarcable, hemos implementado un
relativamente sencillo comportamiento para simular el movimiento del agua.
Dicho comportamiento es UpdateFloodGridBehav.
El funcionamiento del algoritmo es el siguiente:
1. Se solicitan a la maya hexagonal las casillas cuyo nivel de agua ha sido
modicado desde la ultima vez que se ejecuto el algoritmo.
2. Se recorren dichas casillas, y se consulta el valor del agua y terreno de
las casillas inmediatamente adyacentes.
3. Si se encuentran casillas adyacentes mas bajas entonces se mueve agua
a dichas casillas -se mueve la mitad de la diferencia en altura, es decir,
se iguala el nivel-. Si se encuentran casillas mas altas se trae agua de
dichas casillas.
4. Todas las casillas cuyo nivel de agua haya sido afectado se marcan como
modicadas, y seran revisadas por la siguiente pasada del algoritmo.
Para el funcionamiento de este algoritmo cuando se simula en multiples
Entornos se hizo necesario incluir un borde exterior extra o corona a las
mayas hexagonales. Esta corona es del ancho de una casilla y mantiene el
valor del terreno y nivel de agua, aunque no se muestra en los visores. La
utilidad de esta corona es saber cuando se debe pasar agua, y cuanta, a otros
Entornos.
Cuando un Entorno decide mover agua de una de sus casillas a una de
la corona comprueba a que Entorno pertenece dicha casilla. Si lo encuentra
le avisa de que ha a~nadido agua a la casilla. Si no lo encuentra es que es
una casilla fuera de la simulacion con lo que el agua se pierde. El simulador
desconoce que le ocurre a todo el agua que se sale de la simulacion, por lo que

74 Captulo 9. Implementacion (III): Sistema Multiagente
los bordes exteriores, no las fronteras entre Entornos, son sumideros por los
que desaparece agua de la simulacion. La cantidad de agua que desaparece
viene determinada por la altura del terreno, otra utilidad de la corona.
Tambien ocurre que cuando un Entorno modica el nivel de agua de
una casilla del borde inmediatamente interior a la corona -es decir, el borde
exterior de su area de simulacion- debe avisar del nuevo nivel al agente que
tenga esa casilla como corona, si es que lo hay.
Para manejar toda esta comunicacion entre Entornos creamos el com-
portamiento InterGridBehav.
Como anecdota cabe comentar que en una primersima version del simu-
lador, cuando estabamos aun dise~nandolo y haciendo pruebas, optamos por
agenticar el agua. De esta forma cada \gota" de agua era un agente que
recorra el terreno y escoga donde quedarse, inundando la casilla. El sistema
funcionaba pero muy poco escalable, dado que la cantidad de agentes agua
era abrumadora. Lo desechamos rapidamente y comenzamos el dise~no del
sistema actual.
5. Agentes Entrada de Agua
Este tipo de agente es de lo mas sencillo. Son agentes para nada inteli-
gentes, cuya unica mision es enviar un mensaje al Entorno correspondiente
en cada paso de la simulacion avisandole de la cantidad de agua que debe
a~nadir.
Figura 9.7: Agente Entrada de Agua

6. Agentes Peaton 75
En su inicializacion el agente busca su Entorno, para ello necesita cono-
cer el escenario de simulacion que solicita al agente Creador. Consultando
las coordenadas geogracas donde esta situado y el escenario descubre en
que trozo del terreno ha cado. A partir de ah se limita a mandar un men-
saje en cada tick del Reloj.
Figura 9.8: Comunicaciones del agente Entrada de Agua
6. Agentes Peaton
Durante la inicializacion estos agentes averiguan cual es el Entorno cuyo
terreno contiene su coordenada inicial, para ello utilizan el escenario que
solicitan al agente Creador. Una vez inicializados comienzan a moverse por
el terreno tratando de salvarse de la inundacion.

76 Captulo 9. Implementacion (III): Sistema Multiagente
Figura 9.9: Agente Peaton
Como hemos visto en el escenario de simulacion, los agentes Peaton
reciben una serie de parametros de entrada. A saber:
Posicion inicial Dado en coordenadas geogracas latitud,longitud.
Distancia de vision Medida en hexagonos, representa cuantos hexagonos
es capaz de ver el peaton en lnea recta. Se utiliza a la hora de solicitar
casillas adyacentes a la posicion en ese momento.
Velocidad La cantidad de hexagonos que la persona es capaz de recorrer en
un unico paso de simulacion.
Objetivos Coordenadas geogracas de los refugios que el Peaton conozca
desde el principio. Pueden ser mas de uno, uno, o directamente ninguno.
El comportamiento base de todos los Peatones funciona de la siguiente
manera:
1. Solicitar casillas adyacentes segun distancia de vision al Entorno.
2. Recibir casillas y escoger a cual moverse.
3. Si se ha escogido casilla, avisar al Entorno de la nueva posicion. Si no,
volver al paso 1 sin moverse de la posicion.

78 Captulo 9. Implementacion (III): Sistema Multiagente
refugio poda coincidir con su posicion actual, dado que el calculo de la
distancia no tiene en cuenta los edicios ni las calles. Al dotar de memoria
al agente, y penalizar severamente el moverse a casillas por las que acaba
de pasar, soluciono el problema. El agente preere dar un rodeo y alejarse
temporalmente del refugio a volver sobre sus pasos o quedarse quieto.
Figura 9.10: Peaton atascado
Como se puede apreciar en la imagen la casilla en la que se encuentra el
peaton -el punto rojo- es la mas cercana al refugio -hexagono de borde rojo-.
Esto provocaba que el agente se quedase quieto u oscilase alrededor de dicha
casilla.
Cabe destacar que no se han tenido en cuenta ni la capacidad de las calles
ni de los refugios, el numero de personas que puede haber en una casilla es
ilimitado.

8. Maya Hexagonal 81
a dos casillas. La implementacion de la maya hexagonal se encuentra en la
clase util.HexagonalGrid.
La manera de almacenar la informacion es a traves de matrices cuadradas,
los metodos de acceso y calculo de adyacentes la hacen parecer una maya
hexagonal a quien los usa. Todas las matrices almacenan datos de tipo short,
pues no es necesario un rango mayor y as se ahorra memoria. Todas las
matrices son de la misma dimension.
8.1. Matriz de Alturas
El rango del tipo basico short en Java va desde -32768 hasta 32767, y
dependiendo de la precision en altura que se este utilizando el rango en
metros sera menor o mayor que este.
8.2. Matriz de Agua
Para el caso de inundacion se a~nade esta matriz, que a diferencia de la
matriz de alturas, solo almacena valores positivos -no tiene sentido un nivel
de agua negativo-. Los valores de esta matriz cambiaran a lo largo de la
simulacion, otra diferencia con respecto a la matriz de alturas.
Sumando los valores de una casilla en las matrices de alturas y agua se
obtiene la altura total del terreno en ese punto.
8.3. Matriz de Calles
Esta matriz no se modica una vez rellena, y almacena valores clave que
denen el tipo de casilla del que se trata. Valores del tipo \calle", \avenida",
\autova", \hotel", \ro", etc.
Gracias a estos valores los agentes tienen una representacion de las cons-
trucciones y calles que los rodean.

82 Captulo 9. Implementacion (III): Sistema Multiagente
Tipos de Calles
Para saber en que tipo de calle nos encontramos nos ayudamos de la
informacion de OSM, que viene categorizada en grupos, tales como \carre-
teras\, "puntos de interes\, \vas de agua\, etc. A cada grupo le asignamos
un rango de valores, teniendo en cuenta el numero de subgrupos que tiene.
Por ejemplo, el grupo "carreteras\ tiene multiples subgrupos, como pueden
ser "calle\, "avenida\, "autova\, etc.
Estos valores los identicamos por medio de constantes globales; y se
comparan mediante funciones estaticas, que nos devuelven el tipo concreto o
los valores padre -para los subgrupos-.
Prioridad de la Informacion
Ocurre que en ocasiones varios elementos caen en la misma casilla, pues
estan muy cercanos geogracamente y les corresponde el mismo hexagono.
Pero en cada casilla solo podemos almacenar un valor, por lo que rellenamos
la matriz de forma que se sobreescribe el valor que hubiera si el nuevo valor es
mayor que el viejo. As nos aseguramos que la informacion que consideramos
mas prioritaria -de mayor valor- permanezca en la matriz.
Intersecciones
A veces es util, sobre todo en el caso de las calles, saber cuando se cruzan
dos o mas elementos. Para ello, a la hora de sobreescribir valores, si nos
encontramos con que haba un valor igual al que nosotros queremos insertar,
incrementamos en una unidad el valor que hubiese -haciendolo impar-.
Obviamente para que este sistema funcione, los valores que insertemos
normalmente en la matriz -cuando no se sobreescribe ningun valor- tienen
que ser todos pares. As si el valor de una casilla es impar sabemos que en
ese punto hay una interseccion de dos elementos.