Universidad Rey Juan Carlos Escuela Superior de Ingeniería Informática

PROYECTO FIN DE CARRERA

Simulador de tráco rodado en una ciudad virutal:LiveCitySim

Autor: Francisco Buitrago Pavón Tutor: Rubén Ortiz Martín

Junio, 2011

Agradecimientos

En primer lugar a mis padres, Julio y Agustina; porque sin ellos no sería lo que soy ahora, me han dado una buena educación, me han apoyado y siempre han estado allí cuando los he necesitado, han sabido cuando presionarme y en los momentos más difíciles darme ánimos. A mi hermano Julio, sin su compresión y su ayuda esto no habría posible, siempre cuidándome, siempre dándome aliento y sin sus consejos no habría llegado a ser la persona que soy ahora. A mi familia, por estar siempre pendiente de mi, por preocuparse, por quererme por día a día hacerme ser mejor persona. A mi compañero de proyecto Juan Bayona, por su paciencia, su ilusión, sus ganas y empeño en el trabajo, me ha enseñado a que nada es imposible y que todo problema tiene solución, sinceramente muchas gracias amigo. A mis amigos, los más especiales, los que siempre han estado en las sombras, ocultos, apoyándome en cada momento, levantándome en cada caída, animándome en cada fracaso, sois todos muy especiales para mi. A mi tutor del proyecto Rubén Ortiz sin su comprensión y su ayuda esto no habría sido posible, ha sabido ayudarme cuando lo he necesitado y siempre ha estado disponible para cualquier duda, gracias. A los profesores que he tenido a lo largo de mi vida, porque de cada uno de vosotros he aprendido una cosa nueva, gracias por vuestro esfuerzo, dedicación, por vuestra labor educativa y por sacar a los jóvenes de cada generación adelante. A los que no están, que no signica que se hayan ido, gracias por todos los momentos que pase con vosotros, gracias por hacerme ver la vida de otra manera, nunca os olvidaré. A todos, muchísimas gracias por haber ido de la mano conmigo este largo camino que ha sido mi etapa universitaria, todo esto no habría sido posible sin vosotros.

Resumen

El proyecto trata sobre una simulación de tráco rodado en una ciudad virtual. El tráco esta compuesto de vehículos y señales. Los vehículos interactúan con las señales generando situaciones de tráco real. Estas situaciones se pueden ver en un visualizador que ha sido desarrollado por otro miembro del equipo LiveCitySim, para así mejorar la representación de los datos obtenidos. Este proyecto, es el encargado de simular el tráco, para ello genera distintos tipos de rutas y en el que también se pueden elegir varios tipos de conductores. El simulador permite la existencia de varios tipos de cruces y de señales de tráco. Las entradas que recibe son dos: la conguración de la ciudad (que está compuesta por todas las calles, los cruces, las señales) y los elementos activos (del que forman parte los vehículos y los semáforos). La salida que se obtiene de la simulación, es la situación de cada uno de estos elementos activos por unidad de tiempo de simulación. Esta salida es compatible con un visualizador, lo que permite una visualización de estos datos y facilita la representación de los resultados obtenidos.

Índice general 1. Introducción

1

2. Objetivos

5

3. Descripción Informática

7

3.1. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

3.2. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.2.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.2.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.1. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.2. Diagramas de estado . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.4.1. Arquitectura general . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.4.2. Ontología del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4.3. Diseño del simulador . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.5. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.5.1. Tecnologías utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.5.2. Jerarquía de directorios . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.5.3. Detalles de implementación . . . . . . . . . . . . . . . . . . . . . . 37 3.6. Evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.6.1. Ejemplos grácos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.6.2. Ejemplo analítico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 I

ÍNDICE GENERAL

4. Conclusiones

51

4.1. Objetivos cumplidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.2. Evaluación personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.3. Lineas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5. Bibliografía

55

II

Índice de guras 3.1. Ejemplo proceso unicado . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

3.2. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Diagrama de estado global . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Diagrama de estado cargar conguración . . . . . . . . . . . . . . . . . . . 15 3.5. Diagrama de estado calculo de rutas . . . . . . . . . . . . . . . . . . . . . 15 3.6. Diagrama de estado control de colisiones . . . . . . . . . . . . . . . . . . . 16 3.7. Diagrama de estado actualizar estados . . . . . . . . . . . . . . . . . . . . 17 3.8. Diagrama de estado actualizar posición . . . . . . . . . . . . . . . . . . . . 18 3.9. Diagrama de estado salida de datos . . . . . . . . . . . . . . . . . . . . . . 19 3.10. Diagrama clases global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.11. Diagrama clases ciudad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.12. Diagrama clases simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.13. Diagrama de secuencia cargar conguración . . . . . . . . . . . . . . . . . 27 3.14. Diagrama de secuencia cálculo de rutas . . . . . . . . . . . . . . . . . . . . 29 3.15. Diagrama de secuencia cálculo de colisiones . . . . . . . . . . . . . . . . . . 30 3.16. Diagrama de secuencia cálculo de estados . . . . . . . . . . . . . . . . . . . 31 3.17. Diagrama de secuencia cálculo de posiciones . . . . . . . . . . . . . . . . . 32 3.18. Diagrama de secuencia salida de elementos dinámicos . . . . . . . . . . . . 33 3.19. Jerarquía de directorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.20. Ejemplo cruces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.21. Fichero Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.22. Fichero Extendido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.23. Ejemplo conductores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 III

ÍNDICE DE FIGURAS 3.24. Vehículos saliendo de Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.25. Ejemplo coches circulando cruce . . . . . . . . . . . . . . . . . . . . . . . . 45 3.26. Ejemplo semáforo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.27. Detección de vehículo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.28. detección de cruce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

IV

Capítulo 1 Introducción El proyecto que se presenta en este documento forma parte de un proyecto mayor: LiveCitySim. Dicho proyecto está compuesto básicamente de dos partes: un simulador y un visualizador. Estos comparten una serie de clases comunes, e interactúan entre ellos. La parte que trataremos en este documento será el simulador, este realiza las tareas de simulación de tráco real en una ciudad, esta ciudad la recibe mediante un archivo de conguración junto a un chero con los elementos dinámicos. El visualizador se encarga de la mostrar el tráco y la ciudad mediante un motor gráco. Este visualizador se encarga de mostrar todos los elementos de la ciudad como edicios, calles, cruces, señales y los vehículos. También permite ocultar edicios, parar la simulación y observar el tráco desde distintas cámaras. Para ello requieren de dos archivos: la ciudad y los datos de la simulación. El simulador se encarga de la generación de rutas, el control de colisiones, el cambio de estado de los semáforos etc. Para ello transforma la ciudad en un grafo dirigido que sirve como mapa a los vehículos que circulan por la misma. Para entender un poco mejor de que trata el proyecto, hay que conocer una serie de conceptos antes de continuar avanzando en los detalles de la memoria: Agente: es una entidad, que es capaz de percibir un entorno, procesar tales percepciones y responder de manera racional. Estado: en el contexto en el que nos vamos a mover nos referimos a estado, como la situación en la que se encuentra un agente. 1

CAPÍTULO 1. INTRODUCCIÓN Nodo: es una pequeña parte de un cruce, la unión de todos los nodos de un cruce forman el cruce en si, es una ayuda a la representación de la ciudad para la construcción de un grafo, los nodos se unen entre si por medio de aristas, en este caso las aristas representan un carril. Cruce: punto donde se cortan dos o mas calles. Arista o Arco: es la linea que une dos nodos, en este caso las aristas serán los carriles de las calles. Posición: lugar donde se encuentra un vehículo respecto al inicio del carril.

Otros conceptos A parte de estos detalles técnicos hay que destacar el funcionamiento de un semáforo, esta es una señal luminosa que controla el tráco de vehículos. El semáforo regula los cruces mediante la iluminación de tres luces, la verde signica que los coches pueden pasar, la luz roja los coches se detienen y la luz ámbar que los coches pasan pero reduciendo su velocidad. En el caso de los cruces hay que tener en cuenta que por defecto los vehículos que vayan a entrar en el cruce debe ceder el paso a los que se aproximen por la derecha. En el proyecto podemos ver diferentes tipos de conductores cada uno tienen una serie de características y se diferencian en parámetros como: Distancia de seguridad: denimos la distancia de seguridad como el espacio que hay entre vehículos y que asegura que no colisionen entre ellos. Aceleración máxima: es la aceleración máxima que podrá alcanzar el vehículo, contra mayor sea esta más rápido alcanzará velocidad. Velocidad máxima: es la velocidad que alcanzará como máximo, los conductores agresivos tienen la mayor velocidad máxima. Deceleración: será el valor con el que el coche frenará, al frenar el coche adquiere aceleración negativa (ya que va perdiendo velocidad) los conductores agresivos tienen este valor muy alto ya que estos frenaran justo antes de producirse la colisión, el resto de conductores tienen valores mas normalizados que hacen que la operación de frenado sea mas suave. 2

CAPÍTULO 1. INTRODUCCIÓN En la lista se pueden observar los valores más importantes, la modicación de estos valores hace que los conductores se comporten de una forma o de otra, por eso en el proyecto se han elegido tres tipo de perles de conductores: 1. Conductor agresivo: es el típico conductor que deja poca distancia de seguridad con el vehículo de delante, circula a gran velocidad, acelera muy rápido y da frenazos bruscos. 2. Conductor normal: tiene unos valores estándares de velocidad, aceleración y de distancia de seguridad, como su propio nombre indica es un conductor normal. 3. Conductor cauteloso: es un conductor demasiado prudente, sus valores de aceleración y deceleración son muy bajos y su distancia de seguridad la mas grande respecto a los anteriores. Con esta variedad de conductores podemos simular el tráco ya que se pueden generar todas las situaciones posibles como las de un atasco; que se produciría si hay varios conductores cautelosos y detrás viajan conductores agresivos. Con estos conceptos claros podemos pasar a analizar el siguiente punto.

XML

Las siglas provienen de eXtensible Markup Language que traducido al castellano es lenguaje de marcado extensible. Proviene de un lenguaje inventado por IBM en los años setenta llamado GML, este lenguaje permitía una clasicación de documentos, facilitaba su procesamiento. Surgió porque la empresa americana tenía demasiados archivos y buscó una alternativa para gestionarlos de una forma ecaz. Posteriormente tras su estandarización por el ISO pasó a llamarse SGML. Este lenguaje permitió que se generaran otros lenguajes a partir de él como HTML, este último se destinó a la programación en paginas web, las carencias de este lenguaje tanto para la estructuración como las dicultades para la exportación, nació XML. XML solventaba las carencias de HTML, además su principal característica es que todos los archivos parten de un nodo raíz lo que permite claricarlos mejor y la búsqueda dentro del archivo es mucho mas sencilla. No se debe pensar que XML fue concebido para 3

CAPÍTULO 1. INTRODUCCIÓN la generación de paginas web aunque lo permite, es un lenguaje que cambia el paradigma de la programación basada en funciones y objetos. XML se puede usar para cambiar la publicación de las webs, ya que se puede transformar de manera muy sencilla, por eso se usa en estas porque te permite estructurar la información. Generalmente la información se almacena en bases de datos, se pasa a XML y luego se transforma para servírselo al cliente. XML se usa de forma fácil ya que es un chero de texto en el cual solo hay que etiquetar cada atributo con etiquetas de inicio () y n () con una estructura de nodo raíz e hijos. Los archivos XML deben estar bien formados porque sino no sirven de nada, ya que los lectores de XML no lo reconocen. Es un lenguaje mucho más estricto que HTML. Hay muchos entornos de programación en paginas web en los que se puede programar en XML como: Cocoon, Axkit; estos son son gratuitos y luego alternativas de pago como Bea Weblogic. Existen muchas aplicaciones hechas en XML que podemos ver en internet como los blogs barrapunto y Slashdot. Con esto podemos ver que el XML no sólo se usa como soporte para almacenar información sino que también es aplicable en otros entornos como la programación web.

4

Capítulo 2 Objetivos La nalidad del proyecto es lograr la simulación de traco real, para llegar a este punto es necesario dividir el proyecto en diferentes puntos de control o lista de objetivos. 1. Modelado de datos de una ciudad: el primer objetivo es conseguir generar el diagrama de clases de una ciudad y conseguir cargar esta de un chero XML. 2. Representación de una ciudad mediante un grafo: conseguir una representación de la ciudad mediante un grafo dirigido de tal forma que así obtengamos un mapa de la ciudad. Este se utilizará para el cálculo de rutas. 3. Carga de datos desde cheros XML: preparar la aplicación para que pueda cargar los cheros XML de ciudad y de los agentes que intervienen en la simulación. 4. Generación de rutas: generar rutas para los vehículos; es necesario crear varios tipos de rutas. 5. Simulación de tráco: simulación de comportamiento de los vehículos como si de una ciudad real se tratase, conseguir un movimiento uido, sin colisiones e interactuando con las señales estáticas y dinámicas. 6. Sincronización de traco: realizar una simulación en las que los vehículos inicien su trayecto en instantes de tiempo diferentes al instante inicial. 7. Salida de datos de simulación: obtener los resultados de la simulación y volcarlos en un chero XML. 5

CAPÍTULO 2. OBJETIVOS 8. Compatibilidad de datos con el visualizador: es necesario que los datos de salida sean compatibles con el visualizador. Otro objetivo a destacar es el trabajo en equipo con Juan Bayona, encargado del proyecto visualizador, ya que la combinación de los dos proyectos tiene como resultado uno más grande y completo. En este caso los dos compartimos el trabajo en la generación de la ciudad y los proyectos deberán ser compatibles uno con otro.

6

Capítulo 3 Descripción Informática En esta sección analizaremos toda la descripción informática del proyecto, desmenuzaremos el proceso de análisis, del diseño de la arquitectura, los detalles de la implementación y la evaluación del proyecto.

3.1.

Metodología

La metodología usada a la hora del desarrollo del simulador es la del proceso unicado. Para denir esta metodología comenzamos por denir que es un proceso. Un proceso dene quien esta haciendo una determinada tarea, cuando la hace y como hacer que se alcance el objetivo buscado. El proceso unicado está guiado por casos de uso, centrado en la arquitectura, tiene un ciclo de vida iterativo e irracional y está orientado a objetos. Esta metodología se adapta a cualquier tipo proyecto independientemente del tamaño y de la complejidad. Para realizar el modelo de datos usaremos diagramas UML, este lenguaje nos permite modularizar con facilidad y simplica la labor a la hora de repartir el trabajo. El proceso unicado está basado en casos de uso, estos sirven para representar una funcionalidad en el sistema, lo que nos permite realizar una captura de requisitos, se analizan, se diseñan, se implementa y se prueban. Se dice que el proceso unicado está manejado por estos casos porque el desarrollador creará los modelos de implementación en base a ellos y serán implementados en la fase de análisis. Podemos decir que es centrado en la arquitectura del sistema ya que los casos de 7

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

Figura 3.1: Ejemplo proceso unicado uso dependen de la arquitectura y esta nos limita a la hora de seleccionar un caso de uso u otro; normalmente el desarrollo de la arquitectura y de los casos de uso maduran continuamente según va avanzando el desarrollo del software. Al estar en desarrollo continuo llegamos a la conclusión que el proceso unicado es iterativo e incremental, se divide en ciclos, cada ciclo consiste en cuatro fases: concepción, elaboración, construcción y transformación; cada una de estas fases esta dividida en iteraciones. Al nal de cada fase se produce una revisión, después de cada iteración se realizan actividades de captura de requisitos, análisis, diseño, implementación y prueba para ver así la evolución del desarrollo. Esta metodología nos ofrece una gran exibilidad a la hora de trabajar ya que nos permite realizar varias estrategias de ciclos de vida. En la imagen podemos observar un ejemplo práctico del proceso unicado y de sus fases, como se administra el tiempo por iteraciones, como se distribuye el volumen de carga en cada una de ellas y como se distribuye temporalmente cada tarea de cada área.

8

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA 3.2.

Requisitos

Antes de empezar un proyecto de software es necesario saber la funcionalidad de la aplicación desarrollada, cual es su alcance y las limitaciones con las que cuenta. Por ello, a la hora de iniciar un proyecto, una de las primeras tareas es reunirse con el cliente con el n de conocer sus necesidades y realizar una toma de requisitos. En este caso, como el proyecto no es para ningún cliente concreto, se han de elaborar igualmente, pero solicitando estos al tutor del proyecto. Para ello se dividen los requisitos en tres tipos, requisitos funcionales, requisitos no funcionales y requisitos de interfaz.

3.2.1. Requisitos funcionales En este apartado se estudian los requisitos funcionales que están relacionados con el proyecto. Para detallar cada uno de ellos se usará la siguiente nomenclatura RFXX donde RF son las siglas abreviadas de Requisito Funcional y XX el número de requisito. Por tanto, los requisitos funcionales son los siguientes:

RF01 El sistema debe cargar una ciudad de un chero XML. RF02 El sistema debe cargar un chero de agentes en formato XML. RF03 El sistema debe generar rutas, dando un punto origen y un punto nal. RF04 El sistema debe tener diferentes tipos de rutas. RF05 El sistema debe permitir una simulación uida RF06 No debe haber ninguna colisión en la transición de coches RF07 El sistema debe permitir que por los cruces circulen varios coches sin chocarse. RF08 El sistema debe proporcionar una simulación lo más real posible, respetando las señales de tráco.

RF09 El sistema debe tener elementos dinámicos como los semáforos. RF10 Se debe implementar un comportamiento para dichos semáforos. 9

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

RF11 El sistema debe tener varios tipos de agentes. RF12 El comportamiento de los conductores (agentes) debe regirse por estados. RF13 En cada uno de esos estados los agentes se comportaran de manera diferente. RF14 El sistema deberá actualizar el estado de los agentes en cada iteración. RF15 El sistema deberá calcular en cada iteración la posición de los agentes. RF16 El sistema al nal la simulación deberá proporcional un chero en formato XML con los resultados de la simulación.

RF17 El sistema deberá proporcionar un chero de salida compatible con el visualizador. RF18 La ciudad deberá estar compuesta por una lista de cruces, calles y edicios. RF19 Cada calle debe tener un identicador único. RF20 Cada calle debe estar formada por carriles, estos pueden ser a favor o en contra dirección.

RF21 Las calles pueden contener señales. RF22 Las calles deben tener un cruce de inicio y un cruce de n. RF23 Los carriles deben tener un identicador. RF24 Los cruces deben tener un identicador. RF25 Los cruces deben estar conectados al menos con una calle. RF27 Los cruces pueden estar conectados como máximo a cuatro calles. RF28 Las señales deben tener un identicador único. Además en este apartado, cabe destacar los siguientes requisitos de interfaz:

RF29 El sistema deberá proporcionar al usuario una interfaz de fácil manejo. RF30 Dicha interfaz deberá ser capaz seleccionar los archivos de entrada y salida de forma sencilla. 10

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

3.2.2. Requisitos no funcionales En este apartado se agrupan los requisitos de recursos, rendimiento, mantenimiento y potabilidad entre otros. Para detallar cada uno de ellos se utiliza la siguiente nomenclatura: RNFXX donde RNF son las siglas abreviadas de requisito no funcional y XX el número de requisito. Previo al detalle de cada requisito se explica el tipo del que forma parte en función de las agrupaciones citadas anteriormente. Por tanto, los requisitos no funcionales son los siguientes: 1: Los requisitos de recursos especican las características de los equipos y dispositivos participantes en la infraestructura del sistema:

RNF01 Se precisa un ordenador, como mínimo 1 GB de disco duro, un procesador de 1Gh, 1GB de RAM.

RNF02 Dicho ordenador es necesario que tenga instalado la maquina virtual de java. 2: Los requisitos de rendimiento especican cálculos temporales como, entre otros el tiempo de ejecución.

RNF03 El tiempo de arranque de la aplicación debe ser eciente. RNF04 El tiempo de simulación debe ser eciente.

11

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA 3.3.

Análisis

La aplicación esta dividida en tres bloques principales: uno es el entorno de la ciudad donde están almacenados los elementos estáticos de la ciudad como las calles, los cruces y los edicios; otro es el bloque del simulador que se encarga de simular el comportamiento de los elementos dinámicos formado por los vehículos y los semáforos y por el último el visualizador que se encarga de cargar los datos de una simulación y mostrarlos. En esta sección veremos los diagramas de caso de uso y los diagramas de secuencia explicando cada uno de ellos detenidamente.

3.3.1. Diagrama de casos de uso En el proyecto, el simulador se ha dividido en seis casos de uso, que pueden observarse en la gura 3.2

Cargar conguración: se encarga de cargar la conguración del simulador, recibe como entrada los cheros de la ciudad y un chero con los elementos dinámicos, en esta fase también elegiremos el archivo de la salida de datos del simulador.

Calculo de rutas: dependiendo del tipo de elemento dinámico, dependiendo si es un vehículo o un semáforo se encarga de realizar el cálculo de las rutas para los vehículos y posteriormente asignarla a cada uno de ellos, también se encarga de realizar las llamadas a la simulación de cada uno de ellos.

Control de colisiones: es el encargado de la gestión de incidencias de los vehículos hay diversos factores que le condicionan, uno la distancia entre vehículos, cruces y el tipo de conductor de los vehículos.

Actualización de estados: en esta fase el simulador actualiza los estados de todos los agentes.

Actualización de posiciones: después de la actualización de estados este bloque actualiza las posiciones en función del estado en el que se encuentre actualiza la posición y modica los valores de aceleración, velocidad entre otros. 12

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

Escribir en la salida elementos dinámicos: en cada iteración los resultados se almacenan en una lista. Al nalizar la simulación se vuelca todo en el chero de salida.

Figura 3.2: Diagrama de casos de uso

3.3.2. Diagramas de estado Diagrama de estado global 3.3 Este diagrama nos muestra como funciona el simulador. Primero se realiza la carga de los cheros de conguración, posteriormente se calculan y se asignan las rutas a los vehículos para después calcular los estados mediante la detección de colisiones; con los estados calculados estos se asignan para así realizar la actualización de posiciones y nalmente cuando el tiempo de simulación expira se vuelca en el chero de salida. 13

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

Figura 3.3: Diagrama de estado global

Diagrama de estado para cargar conguración 3.4 Aquí se puede ver el funcionamiento del bloque de carga de datos. Primero realizaremos la carga de los elementos estáticos de la ciudad, es decir, la ciudad en si introduciendo la ruta del chero donde se encuentra en la interfaz de usuario. Con esta acción cargaremos las calles, cruces, edicios, aceras y las señales estáticas, una vez nalizado el proceso de carga procederemos a cargar el chero de elementos dinámicos; estos elementos son los agentes y al igual que con la ciudad introduciremos la ruta en la interfaz de usuario y se cargaran los agentes en una lista. En nuestro caso estos agentes se pueden dividir en dos grupos los vehículos y los semáforos. A continuación se introducirá la ruta del chero de salida, el cual recibirá el visualizador. Antes de iniciar la simulación se validan los cheros de entrada y de salida y si todo esta correcto se procede a iniciar la simulación.

Diagrama de estados para calculo de rutas 3.5 Con los datos cargados se procede a generar el grafo; esta tarea es una de las más cruciales en la ejecución de la simulación ya que el grafo nos generará el mapa de la ciudad con el cual realizaremos el calculo de las rutas, en este paso seleccionaremos a los agentes que sean vehículos ya que los semáforos no tienen ninguna ruta que calcular. Los 14

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

Figura 3.4: Diagrama de estado cargar conguración tipos de ruta son cuatro: 1. Corta: es el trayecto mas corto entre el punto de salida y llegada. 2. Media: en esta ruta se ejecuta un recorrido que da una vuelta a una edicio y llega su punto de destino. 3. Larga: la ruta mandará al vehículo a dar una vuelta por la ciudad generando la ruta más larga. 4. Aleatoria: esta ruta es totalmente aleatoria en cada ejecución variará entre corta, media y larga. Tras realizar el calculo de la ruta, esta se le asigna al vehículo y ya esta listo para comenzar la simulación.

Figura 3.5: Diagrama de estado calculo de rutas

Diagrama de estados para control de colisiones 3.6 Con las rutas generadas, ya se sabe por donde los vehículos van a viajar y sus posiciones iniciales, tras todo esto comprobaremos que no se produzca ninguna colisión centrándonos en dos grupos: 15

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA Cruces: en los cruces el control de colisiones se basa principalmente en observar si el cruce esta ocupado o reservado por algún vehículo, si no está reservado lo reservamos y pasamos por el nodo correspondiente, al nal del cruce controlamos la salida de él. Si no hay ningún vehículo en la salida del cruce, permitimos que salga para así evitar colisiones en las salidas. Carril: en los carriles vericamos si en la posición de delante hay algún vehículo, si hubiese un vehículo o estuviésemos al nal del carril donde se encuentran los cruces ,pondríamos el estado correspondiente (FRENAR o ACERCANDOCRUCE).

Figura 3.6: Diagrama de estado control de colisiones

Diagrama de estados para actualizar estados 3.7 Después de que estuviesen calculados los estados en el paso anterior se recorre la lista de agentes y se actualizan los estados. Para los agentes vehículos son: Acelerando: este estado indica que el vehículo acelerará y como consecuencia el vehículo incrementará su velocidad. Freando: el vehículo desacelerará ya que ha encontrado un vehículo delante y por tanto reducirá su velocidad. AcercandoCruce: un vehículo se encuentra en este estado, cuando se aproxima a un cruce, el vehículo comienza a reducir la velocidad hasta llegar a la velocidad de cruce. SaliendoCruce: cuando un vehículo se para antes de circular por un cruce ya sea porque hay un semáforo,una señal o el cruce está ocupado, este estado se activa 16

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA cuando el vehículo vuelve a emprender la marcha asignándole un valor de aceleración de inicio para permitir que se mueva. Detenido: el vehículo se encuentra detenido en un cruce. DetenidoCoche: el vehículo se encuentra detenido porque hay otro vehículo delante que no le permite avanzar es necesario distinguir este estado del anterior ya que las acciones que se realizan después son distintas. Esperando: el vehículo esta esperando a que el cruce se quede libre para poder pasar. Cruce: el vehículo se encuentra cruzando por el cruce. Constante: el vehículo se mueve a velocidad constante. Para los semáforos: Rojo: el semáforo está en rojo los vehículos no pueden pasar. Ámbar: el semáforo está en ámbar. Dicho estado indica a los vehículos que se va a poner en rojo el semáforo que crucen con precaución. Verde: El semáforo está en verde y los vehículos pueden atravesar el cruce sin problemas. En cada uno de estos estados los agentes realizan operaciones diferentes.

Figura 3.7: Diagrama de estado actualizar estados

Diagrama de estado para actualización de posiciones 3.8 Una vez se han actualizado los estados, dependiendo del estado hacen una función propia de cada estado; estas funciones actualizan los valores de aceleración, velocidad y 17

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA nalmente actualizarán la posición con la ecuación: S = S0 + v ∗ t + 1/2t2 ∗ a

(3.1)

Donde: S=posición nal. S0=posición inicial. t=tiempo v=velocidad; a=aceleración. Con esta fórmula los coches actualizaran la posición tras cada iteración, jugando con los valores de aceleración y velocidad el coche se desplazará mas o menos según estos. Esto sólo es válido para los vehículos.

Figura 3.8: Diagrama de estado actualizar posición

18

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

Diagrama de estado para escribir salida de elementos dinámicos 3.9 Una vez nalizado todo el proceso de simulación en cada iteración, se añade una entrada a una lista de agentes donde se ponen sus posiciones y los estados en los que se encuentran los agentes en cada una de estas iteraciones. Cuando las iteraciones se acaban, los datos de la lista se vuelcan en un chero en formato XML.

Figura 3.9: Diagrama de estado salida de datos

19

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA 3.4.

Diseño

En esta parte analizaremos tanto la arquitectura del proyecto,la ontología del mismo y el diseño del simulador, este diseño se realiza tras la fase de análisis que hemos visto anteriormente de donde hemos recabado suciente información para dividirlo en estas tres partes.

3.4.1. Arquitectura general El proyecto simulador forma parte de un gran proyecto que esta compuesto por un visualizador y un simulador, estos comparten una parte que son los elementos estáticos de la ciudad, esta parte está compuesta por el diseño de la ciudad: están denidos los carriles, los cruces, el ancho de acera, los edicios; es la que almacena todos los datos. El simulador tan solo depende de esa parte estática, sin embargo, el visualizador depende de la parte de la ciudad y de los datos que recibe del simulador. En este diagrama 3.10 podemos ver las dependencias de los proyectos entre si. Recordando que en este proyecto tan solo tratamos de los datos de la simulación tan solo es en necesario la ciudad y la salida de datos es un chero que posteriormente el visualizador mostrará.

Figura 3.10: Diagrama clases global

20

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

3.4.2. Ontología del sistema Esta sección trata sobre la ontología del sistema es decir de los elementos que componen el sistema para ello utilizaremos el diagrama de clases de ciudad que se puede observar en la siguiente gura 3.4.2 y del que vamos a comentar los elementos más importantes de la ciudad; describiendo las clases que mayor peso tienen y sus principales funcionalidades. El proyecto ciudad esta compuesto por una clase Ciudad, esta clase es la que contiene todos los datos de una ciudad, está compuesta: por una lista de edicios, una lista de cruces y una lista de calles.

Figura 3.11: Diagrama clases ciudad

21

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA Edicio: dentro de las clases de la ciudad es la que menos relevancia tiene, ya que solo nos aporta información del tamaño, posición y tipo de edicio. Esta clase no interviene para nada para la simulación tan solo para el visualizador. Es un elemento decorativo. Calle: la calle contiene a su vez a otras subclases, contiene una lista de carriles y dos señales una para los carriles a favor y otra para los carriles en contra. • Carril: la clase mas importante para el simulador, ya que por esta clase viajan

los vehículos, contiene el inicio del carril y el n de cada carril, con los cuales podremos calcular su longitud. • Cruce: el cruce es otro de los elementos importantes de la calle ya que tiene un

cruce de inicio y un cruce al nal de calle. • Señal: la clase señal es una clase un poco especial ya que depende de si es

un agente o no, es decir las señales tienen dos tipos, unas son estáticas que son stop, cedas al paso y otras son dinámicas, es decir cambian a lo largo del tiempo no son jas, en este caso formarían parte de nuestros agentes, sería del tipo AgenteSemafóro. Las señales tienen un identicador y un tipo y afectan a los carriles de una dirección, es decir una señal no afecta a un único carril sino a todos de los de la misma dirección. Cruce: la clase ciudad tiene una lista de cruces. El cruce tiene a su vez las cuatro calles con las que puede estar conectado y a su vez tiene un indicador si es un cruce de salida/llegada de vehículos. La distribución de los paquetes de la ciudad es la siguiente en onto, se encuentra las clases que forman parte de la ontología del proyecto y fuera de esta se encuentra la clase XML que es la que se encarga de cargar la ciudad de un chero XML.

22

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

3.4.3. Diseño del simulador El simulador tiene relación directa con ciudad en todas las ramas que se pueden ver en el diagrama, la principal funcionalidad que usa de ciudad es la misma ciudad en si,que se utiliza para general el grafo,con el cual se generan las rutas y se tienen todos los agentes localizados, también usa la clase Xml está la utiliza para leer la ciudad de un chero en formato XML. Como podemos ver en el siguiente diagrama 3.4.3, las clases más importantes del simulador y su funcionalidad son:

Figura 3.12: Diagrama clases simulador

23

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

EscribirItinerario: contiene una lista de agentes, asigna las rutas a cada agente y hace una llamada al método actualizar de la clase Controlador donde actualiza los estados y posiciones de los agentes.

Grafos: es la encargada de crear el grafo de la ciudad. Recibe como parámetro una ciudad. Con la ciudad y sus calles generamos los nodos y los enlaces entre nodos para terminar de completar el grafo.

Controlador: encargada de gestionar el recorrido de los vehículos así como la encargada de controlar las colisiones y los cruces. También asigna los valores a los estados de cada agente y los pone en marcha dependiendo el tiempo de salida de cada agente.

Agente: aquí está denido el agente de manera genérica. Las clases AgenteCoche y Agentesemáforo heredan de esta. Contiene el estado y el identicador del agente.

AgenteCoche: clase que hereda de Agente; su principal característica es que representa a los vehículos y contiene todos los datos de estos como: velocidad, aceleración, ruta, tipo de agente, tipo de ruta entre otras. Su método más importante es actualizar. Este método recibe el tiempo como parámetro y dependiendo del estado en el que se encuentre el agente actualiza su posición realizando diferentes tipos de cálculos.

AgenteSemaforo: en ella está denida la estructura de un semáforo es muy parecida a Agente pero tiene tres constantes que indican la duración de cada estado. Su principal método es actualizar que recibe como parámetro el tiempo actual. Este método efectúa los cambios de estado de los semáforos.

ConductorCauteloso, ConductorAgresivo, ConductorNormal: son los tipos de agente que hay. Cada uno tiene unas constantes especicas de distancias de seguridad, velocidad máxima, aceleración máxima, velocidad de cruce entre otras.

ListaAgentes: es la clase que contiene la lista de agentes, gracias a esta clase permite leer los agentes de un archivo en formato XML. 24

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

ListaAgente3D, Agente3D: ListaAgentes3D es una lista de Agentes3D, esta última es muy parecida a Agente, pero modicada con los datos que le hacen falta al visualizador. Se eliminan campos que al visualizador no le hacen falta para hacer mas legible el XML de salida.

Ventana: situada en el paquete gui es la interfaz de usuario. Desde esta clase almacenaremos las rutas de los cheros de entrada y de salida. Donde cargaremos los datos de la ciudad. Realiza una llamada al método actualizar de la clase EscribirAgentes.

Inicio: situada como Ventanaen el paquete gui. Forma parte de la interfaz. De hecho esta clase hace una llamada a Ventana.

25

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

Diagramas de secuencia En esta sección se analizaran en profundidad los diagramas de secuencia explicando cada caso de uso de una forma mas detallada, veremos que métodos son llamados y por qué clases son llamados para así completar el análisis del diseño del simulador.

Diagrama de secuencia para cargar conguración El programa se inicia con la clase inicio que hace una llamada a la clase ventana desde la cual se hace una llamada a la interfaz de usuario donde este introduce la ruta de la ciudad, de los agentes y del chero de salida. Una vez validado la ruta se carga el chero y se hace una llamada al método leerciudad de la clase xml este transforma el contenido del chero en un objeto de tipo Ciudad con el cual podremos trabajar para la simulación. Esta misma operación se realiza también con el chero de agentes pero esta vez la llamada la recibirá la clase ListaAgentes y esta clase devuelve un objeto de tipo ListaAgentes en el que ya se

encuentran todos los agentes tanto vehículos como semáforos. Tras este paso se recibe la ruta del chero de salida para volcar los datos de la simulación. Con estos pasos, los datos de la simulación ya están cargados y listos para usarse.

26

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

Figura 3.13: Diagrama de secuencia cargar conguración

27

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

Diagrama de secuencia para calculo de rutas A la hora de calcular rutas la clase ventana utiliza la clase Grafo para obtener el grafo pasándole como parámetro la ciudad, la clase grafo lee los cruces de la ciudad y genera una lista de nodos con estos cruces devolviendo un grafo a la clase Ventana. Tras esta tarea efectúa la llamada al método actualizar de la clase EscribirItinerario el cual recorre toda la lista de agentes y

genera las rutas con los puntos de origen y destino junto al tipo de ruta. Según el tipo de ruta que le llegue como parámetro esta asignará una de las tres rutas disponibles corta, larga o media. En caso de recibir el parámetro ruta aleatoria asignará aleatoriamente una de las tres anteriores en cada ejecución.

28

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

Figura 3.14: Diagrama de secuencia cálculo de rutas

29

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

Diagrama de secuencia para control de colisiones Tras haber sido cargadas las rutas por la clase EscribirItinerario esta efectúa una llamada a la clase controlador a través del método actualizar. Esta clase a su vez llama a su método actualizar, este primero comprueba el tiempo de salida de los agentes que son vehículos. Si el tiempo actual es mayor que el tiempo de salida los pone a circular. Una vez que están circulando se llama al método movercoche. En este método cuando el vehículo se encuentra fuera de un cruce se llama al método controlardistanica que es el encargado de controlar las colisiones entre los vehículos a través de un algoritmo que verica las distancia entre los vehículos y los cruces; controlardistancia pone el estado al agente según va avanzando la ejecución hasta que termina la simulación.

Figura 3.15: Diagrama de secuencia cálculo de colisiones

30

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

Diagrama de secuencia para actualización de estados Una vez asignado el estado en el método mover de controlador, si se encuentra en un cruce o bien si ha sido calculado mediante controlardistancia; este realiza una llamada a toda la lista de agentes con el método actualizar. Este asigna el estado a todos agentes y dependiendo en el estado que se encuentren se le asignan unos valores de velocidad o aceleración diferentes para que estén listos para el penúltimo paso de la ejecución del programa que es el de actualizar posición.

Figura 3.16: Diagrama de secuencia cálculo de estados

31

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

Diagrama de secuencia para actualización de posiciones Agente llama al método actualizar, si es un AgenteCoche, esta llamada provocará que se meta en el método

actualizar y se actualice la posición en función de los valores que tenga de velocidad, posición anterior y aceleración. Esto lo realiza mediante la ecuación vista en el apartado de diseño 3.1 y se obtiene la nuevo posición del agente.

Figura 3.17: Diagrama de secuencia cálculo de posiciones

32

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

Diagrama de secuencia para escribir salida elementos dinámicos Cada iteración que realiza el método actualizar de la clase escribiritinerario se añade una entrada a una lista de Agentes3d con los datos de los agentes en ese instante de tiempo. Una vez nalizado el tiempo de simulación esta lista de listas de Agentes3D se vuelca en un chero XML gracias a la librería XStream.

Figura 3.18: Diagrama de secuencia salida de elementos dinámicos

33

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA 3.5.

Implementación

En esta sección veremos los detalles de implementación, las tecnologías utilizadas, las librerías utilizadas y la jerarquía de directorios del simulador.

3.5.1. Tecnologías utilizadas Para la realización del proyecto las tecnologías utilizadas han sido java y XML. El compilador que he elegido a sido eclipse(en su versión 3.5.2) por su cómoda interfaz gráca, elegí el lenguaje de java porque te permite modularizar, es un lenguaje actual y para el objetivo del proyecto nos permitía usar muchas librerías y disponíamos de mucha documentación. Respecto a las librerías utilizadas el proyecto trabaja con tres:

Jgrapht(version 0.8.2): librería utilizada para la generación del grafo y el cálculo de las rutas mediante el algoritmo de Dijkstra. Es una librería muy potente porque te permite el uso de múltiples algoritmos para calculo de rutas y la generación de todo tipo de grafos ya sean conexos, dirigidos, no dirigidos. En el caso del simulador usamos un grafo dirigido con peso.

XStream(versión 1.3.1): Esta librería ofrece de manera sencilla la importación y exportación de archivos en XML, está muy bien documentada y hay mucha información de ella en internet. Se usa para cargar la ciudad, carga el chero de agentes y también es utilizada en la exportación del chero utilizado por el visualizador.

Swing(versión 1.1.1): Librería utilizada para la creación de la interfaz de usuario que permite la creación de ventanas, botones, examinar rutas entre otras muchas aplicaciones. Sofware utilizado en el proyecto: MagicDraw UML(version 16.8): herramienta que se ha utilizado para la generación de los diagramas del proyecto. Textmaker(version 3.0.2): editor de latex con el cual se ha realizado la memoria. 34

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

3.5.2. Jerarquía de directorios En esta sección veremos la división del proyecto en distintos paquetes y el por qué de su división. Los principales motivos de la división es para formar grupos de archivos que tienen relación, esto sirve para hacer el proyecto mas legible y facilita la modularidad del diseño.

Figura 3.19: Jerarquía de directorios

35

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA El proyecto está dividido en siete paquetes, cada paquete tiene una misión en el proyecto y por eso están situadas las clases según su funcionalidad en el simulador, los paquetes están divididos de la siguiente forma: 1. livecitysim.simulador: es el paquete raíz del proyecto aquí se encuentran todos los subpaquetes que vamos a analizar. 2. livecitysim.simulador.agentes: aquí se encuentran los cheros AgenteCoche.java, AgenteSemaforo.java, ConductorAgresivo.java, ConductorCauteloso.java, Con-

ductorNormal.java. Estos cheros son los que denen los agentes y su comportamiento. Por un lado tenemos los que hacen referencia a los vehículos y por otro a los que hacen referencia a los semáforos; dentro de los vehículos tenemos los tres perles de conductores. 3. livecitysim.simulador.control: este paquete está dedicado al control de los vehículos, la gestión de incidencias y contiene un único chero Controlador.java. 4. livecitysim.simulador.gui: es el paquete donde se aloja la interfaz del sistema, en ella están las clases Inicio.java, Ventana.java, VentanaAyuda.java que son las que se encargan de gestionar la interfaz. 5. livecitysim.simulador.rutas: en este paquete se encuentran las clases: EscribirItinerario.java, Grafos.java, Nodo.java que son las encargadas de

generar el grafo de la ciudad,las rutas e inician la simulación. 6. livecitysim.simulador.xml: en este paquete se encuentran las clases que exportan e importan los agentes. Los cheros que contiene este paquete son: Agente3D.java, LectorAgentes.java, ListaAgente3D.java, ListaAgentes.java.

7. livecitysim.simulador: el paquete mas importante porque es donde se encuentra la clase que inicia el simulador y una clase que permite generar agentes. Contiene el siguiente chero: Ejecutable.java, EscribrirAgentes.java.

36

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

3.5.3. Detalles de implementación A continuación se explicaran los detalles de implementación más importantes para así terminar de comprender el funcionamiento y la complejidad del simulador. Estos detalles son la detección de incidencias, calculo de rutas y el chero de conguración.

Detección de incidencias Hay diferentes tipos de incidencias que se producen a lo largo de la simulación a continuación veremos todas ellas y como se han solventado estos problemas.

Cruces Cuando un vehículo se aproxima a un cruce este se detiene o pasa según el estado del cruce pero la implementación de este comportamiento es una de las mas costosas ya que para conseguir que se realice esta tarea hay que dividir los cruces en nodos y conectarlos entre sí. Esta labor fue muy complicada ya que había que hacer búsquedas dentro de los cruces para unir los nodos correctamente con el riesgo de que si los unías incorrectamente la conexión entre los nodos las rutas que se generarían serian erróneas y los vehículos podrían viajar en un sentido que no les corresponden. Para evitar colisiones la forma más sencilla de hacerlo era evitar que los dos vehículos estuvieran viajando al mismo tiempo por el cruce. Tras conseguir esto que fue relativamente fácil, los vehículos no se chocaban pero esta solución solo permitía atravesar un vehículo el cruce por lo tanto le quitaba realismo a la simulación. Para dar más realismo se decidió que los cruces se dividieran en los nodos anteriormente mencionados dejando el comportamiento de los vehículos de esta forma: antes de entrar a un cruce comprueba si los nodos por los que tiene que pasar están reservados u ocupados, si no lo están los reservamos y ocupamos el primer nodo, según vamos avanzando vamos liberando los nodos para que el siguiente pueda pasar. Con esto conseguimos no ocupar totalmente los cruces y producir una situación de tráco más uido. En esta gura 3.5.3 podemos observar la división de los nodos de tal forma que se puede viajar de un extremo a otro sin que colisionen los vehículos.

Control de distancias Tras solventar el problema de las colisiones entre vehículos en los cruces también hay que evitar que colisionen mientras circulan para ello se generaron 37

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

Figura 3.20: Ejemplo cruces dos funciones:

controlsalida: su función hace es comprobar si la salida del cruce hay algún vehículo para permitir salir al vehículo o no, sin esta función lo vehículos salían del cruce sin comprobar si al otro lado había otro vehículo y se podrían chocar.

controlardistancia: la misión de esta es controlar que no colisionen durante la circulación. Primero se separan los agentes de los que son vehículos a los que son semáforos después se comprueba por que calle circulan y posteriormente se compara su posición con la del vehículo que hace la llamada a la función cuando esta diferencia de posiciones es menor a la distancia de seguridad, el vehículo comienza a desacelerar hasta el punto de pararse si es necesario. Estas dos funciones son las que llevan el peso de la simulación ya que sin ellas no sería posible un tráco sin colisiones.

Estados de los vehículos Los vehículos pueden pasar por diferentes estados a lo largo de la ejecución de la simulación ya que según van avanzando o van encontrando incidencias estos cambian para que el coche cambie su comportamiento y pueda evitar una colisión, pararse en un semáforo y acelerar en el carril. Para ello vamos a denir estos estados y lo que se realiza en cada uno de ellos en profundidad: 38

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA 1. ACELERANDO: en este estado los vehículos aceleran, este salta cuando no hay ningún coche cerca y no se está cerca de un cruce. En este estado incrementa la velocidad del coche. 2. FRENANDO: este estado se activa cuando se encuentra cerca de un coche, la aceleración se convierte en desaceleración, con esta desaceleración se hace el cálculo de la velocidad que es menor a la que llevaba antes de comenzar el frenado. 3. ACERCANDOCRUCE: se activa cuando el vehículo se encuentra a una distancia del nal menor que la distancia de seguridad del coche mas dos unidades, este estado lo que provoca es la reducción de la velocidad del vehículo hasta que llega a la velocidad de cruce. 4. SALIENDOCRUCE: se activa cuando un vehículo esta esperando en el cruce y va a reanudar la marcha. Con este estado conseguimos que reanude la marcha hasta llegar a la velocidad de cruce. 5. DETENIDO: se activa cuando un vehículo se para en un cruce ya sea porque está ocupado por otro vehículo, por una señal o por un semáforo. Pone la velocidad y aceleración del coche a cero. 6. DETENIDOCOCHE: se activa cuando tiene un coche delante y puede chocar con el (en el caso de una caravana por ejemplo) y con frenar no es suciente. Es necesario distinguirlo del estado detener ya que el coche después de detenerse toma el valor ACELERANDO o SALIENDOCRUCE. 7. ESPERANDO: se activa cuando un vehículo está esperando en un cruce a que este se quede libre para poder pasar. 8. CRUCE: En este estado el vehículo se encuentra en velocidad de cruce y se activa mientras que el coche pasa por un cruce. 9. CONSTANTE: en este estado se mantiene en velocidad constante, no se altera la velocidad. Se activa cuando el vehículo llega a su velocidad máxima. 39

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

Cálculo de rutas En este apartado se verá todo lo necesario para la generación de las rutas, desde la complejidad de la generación del grafo hasta el propio algoritmo que calcula las rutas.

Generación del grafo Para que los vehículos puedan circular por la ciudad, es necesario un mapa, este mapa se representa mediante un grafo dirigido, la tarea de la generación del grafo a simple vista parece sencilla ya que cada cruce es un nodo y cada calle un arista; deberíamos tener una arista por cada sentido de la calle, por lo tanto una arista por cada carril en vez de por cada calle, pero en este punto se nos genera un pequeño problema comentado anteriormente en los cruces que hay que ocupar todo el cruce entero. Tras la solución mencionada en el apartado anterior la tarea de construir este mapa ahora se complica un poco ya que ahora hay que elegir que para la unión de los nodos entre cruces es algo laboriosa. Primero hay que seleccionar el nodo y luego hay que ir a la lista de nodos para encontrar con el otro nodo que va unido, comprobando que esa unión no se produce entre los nodos de dentro del cruce después coger el carril de la calle y asignarlo a ese enlace. A parte de esto hay que escoger el "peso"del carril con el método calcular distancia y asignarlo a la arista (o arco).

Tipos de rutas Los agentes tiene cuatro tipos de rutas disponibles para elegir. Para todas ellas se usa la librería Jgrapht, esta librería permite el cálculo del algoritmo de Dijkstra en grafos conexos como el que hemos generado. Estas rutas son: Corta: este tipo de ruta es el camino más corto y se calcula por el algoritmo de Dijkstra. Media: en esta ruta se coge el origen del vehículo y se le fuerza a pasar por una serie de puntos usando rutas cortas entre estos puntos intermedios, la suma de estos generan la ruta media. Larga: se calcula igual que la media lo único que esta recorre casi toda la ciudad, estos puntos de control por los que debe pasar el vehículo son mas numerosos que en los de la media y generan una ruta mas larga. 40

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA Aleatoria: es un tipo de ruta aleatoria entre las tres que se mencionaron anteriormente, en cada ejecución sale una ruta diferente, ya que esta recibe el reto de la división entera de un numero del uno al cien y lo divide entre tres, dependiendo el resultado de esa división se le asigna una ruta. Por último mencionar que los vehículos aparecen cuando el tiempo de salida es mayor que el tiempo actual y desaparecen cuando llegan a los nodos destino que se encuentran en los cruces Stargate este tipo de cruce lleva un identicador especial para que el visualizador lo reconozca.

Fichero de conguración Para poner el simulador en marcha hay que proporcionarle un chero de conguración con los agentes. Hay que recordar que tenemos dos tipos de agentes: los AgentesCoche y los AgentesSemaforo y que dentro de los AgenteCoche hay tres tipos los conductores normales, conductores cautelosos y los conductores agresivos. Aquí podemos observar un ejemplo de chero de conguración que no está desplegado: Este chero está compuesto

Figura 3.21: Fichero Agentes por cuatro agentes uno agresivo, uno normal, uno cauteloso y un semáforo. A continuación vamos a ver los parámetros que recibe cada tipo de conductor se puede comprobar que son los mismos para todos lo único que cambia son los puntos de origen, n, tiempo de salida como se puede ver en la siguiente imagen, donde está el chero desplegado:

41

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

(a)

(b)

(c)

Figura 3.22: Fichero Extendido

42

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA 3.6.

Evaluación

En esta sección veremos la evaluación del proyecto, es decir, comprobaremos si su funcionamiento es correcto. Lo haremos a través de ejemplos grácos y ejemplos analíticos que nos ayudarán a comprender y vericar que el simulador funciona correctamente. Las capturas han sido realizadas del proyecto visualizador de Juan Bayona.

3.6.1. Ejemplos grácos En la gura 3.6.1 podemos observar el funcionamiento del simulador en la primera de las imágenes vemos como se mueven los vehículos, transitan con normalidad, sin colisionarse. En esta captura de pantalla podemos ver el comportamiento de los vehículos en el cruce, podemos observar que como todos los vehículos van en el mismo sentido y ninguno se queda bloqueado.

En las guras 3.23(a), 3.23(b), 3.23(c) podemos observar los tipos de conductores que hay: en todas las imágenes hay al menos un conductor agresivo (en la imagen identicado por conductor uno) que como se puede observar en 3.23(b) y 3.23(c) son los mas rápidos ya que son los que tienen mayor aceleración y menor distancia de seguridad respecto a los cruces y a otros vehículos. Hay que tener en cuenta que todos salen al mismo tiempo como se puede ver en la imagen 3.23(c) y la longitud del carril por el que circulan es la misma. Conductor uno recorre más distancia en el mismo tiempo que el conductor normal (conductor dos). En la siguiente imagen 3.23(c) se puede observar la misma comparación pero esta vez entre un conductor agresivo y un conductor cauteloso (conductor tres), la distancia que saca respecto al conductor normal es mucho mayor ya que el conductor cauteloso tiene unos valores de aceleración muy bajos por lo tanto adquiere velocidad muy poco a poco 43

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA y como consecuencia recorre mucha menos distancia que un un conductor normal y que un conductor agresivo.

(a)

(b)

(c)

(d)

Figura 3.23: Ejemplo conductores En esta captura podemos observar que los agentes al estar formados por diferentes tipos de conductores al encontrarse primero conductor cauteloso provoca un atasco en la calle. También podemos observar que hay un Stop en el cruce, lo que provoca que el coche se pare y posteriormente prosiga su ruta. Hay que comentar que las señales afectan a los carriles de un mismo sentido. Como podemos ver en la gura 3.6.1 los coches van atravesando uno a uno el Stop sin chocarse y respetando el orden en el que han llegado; no se adelantan en ningún momento y circulan todos en la.

Figura 3.24: Vehículos saliendo de Stop 44

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA En la gura 3.6.1 podemos ver un claro ejemplo del funcionamiento de los cruces, se aprecia que los vehículos no colisionan en ningún momento, se puede ver también que los vehículos solo se bloquean si se pueden chocar, es decir que no ocupan todo el cruce solo los nodos por los que pasan permitiendo a los conductores del otro sentido circular por el.

(a)

(b)

(c)

Figura 3.25: Ejemplo coches circulando cruce En esta gura observemos el comportamiento de los vehículos al interactuar con un semáforo, vamos a ver los tres casos posibles: Semáforo en verde: el vehículo continua su trayecto sin detenerse en el semáforo.

(a)

(b)

Figura 3.26: Ejemplo semáforo

45

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA Semáforo en rojo: el vehículo se detiene antes de entrar al cruce.

Semaforo en ámbar: en este caso el coche lo toma como si fuese un semáforo en verde y pasa por el cruce. El único apartado que queda por evaluar son los distintos tipos de rutas, no pongo las capturas porque sería demasiado largo para poner un ejemplo práctico, como mejor se aprecia es en la visualización.

46

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

3.6.2. Ejemplo analítico En esta parte comentaremos el comportamiento de los vehículos pero de manera analítica para darnos cuenta de como evolucionan los vehículos en su transición en que estados. tiempo idAgente posicion

estado

0

0

0

DETENIDO

1

0

0.33

ACELERANDO

5

0

8.37

ACELERANDO

10

0

27.44

ACELERANDO

12

0

35.47

ACERCANDOCRUCE

14

0

0.21

ACELERANDO

21

0

35.46

ACERCANDOCRUCE

23

0

0.2

CRUCE

24

0

1.08

ACELERANDO

39

0

35.66

ACERCANDOCRUCE

41

0

0.2

CRUCE

56

0

35.03

ACELERANDO

57

0

37.29

ACERCANDOCRUCE

58

0

38.89

DETENIDO

59

0

0.2

SALIENDOCRUCE

64

0

5.33

ACELERANDO

79

0

38.76

ACERCANDOCRUCE

80

0

0.2

CRUCE

81

0

0.3

FRENANDO

82

0

5.33

DETENIDO

100

0

5.33

DETENIDO

Podemos observar como es la evolución del agente en un recorrido normal, podemos ver que el agente en el primer instante se encuentra DETENIDO hasta que empieza a moverse y se pone estado ACELERANDO, se puede apreciar como cambia el estado cuando se aproxima al cruce y como en el instante 58 se ha detenido en el Stop del recorrido, 47

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA nalmente en el instante 82 llega a su destino y se queda en estado DETENIDO. Con esto podemos comprobar con datos numéricos como se comporta el agente según avanza y observar las distancias de seguridad respecto al nal del cruce.

Detección de vehículo En esta imagen podemos observar como se efectúa la detección de un vehículo más lento, podemos ver en la tabla los valores de distancia, velocidad y estado en los que se encuentra antes de encontrarse con el coche.

Figura 3.27: Detección de vehículo tiempo agente posición

estado

velocidad carril

5

0

5.005

ACELERANDO

1.2

c1

5

1

0.03

ACELERANDO

3.2

c1

48

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA Podemos ver que en el instante cinco de tiempo aún no ha saltado el patrón de detección porque aun tiene distancia por lo tanto los dos coches acelerarán. tiempo agente posición

estado

velocidad carril

6

0

6.205

ACELERANDO

2.2

c1

6

1

3.23

FRENANDO

1.2

c1

Cuando se detecta el vehículo del agente cero se aprecia que agente uno se pone en estado frenando hasta que la distancia de seguridad siga siendo mayor a la que tiene estipulada. tiempo agente posición

estado

velocidad carril

7

0

8.305

CONSTANTE

2.2

c1

7

1

4.23

ACELERANDO

2.2

c1

Al no haber peligro ya que el agente cero esta por encima de su distancia de seguridad el agente uno vuelve acelerar, por el contrario el agente cero como ha alcanzado su velocidad máxima se mantiene a velocidad constante en su correspondiente estado.

49

CAPÍTULO 3. DESCRIPCIÓN INFORMÁTICA

Detección de cruces En la imagen podemos observar como el agente se encuentra en estado acelerando hasta que alcanza su velocidad máxima y se le asigna el estado CONSTANTE esperando encontrarse al cruce.

Figura 3.28: detección de cruce tiempo agente posición

estado

velocidad carril

5

0

30.005

ACELERANDO

1.96

c1

8

0

35.005

CONSTANTE

2.2

c1

Una vez ha llegado a la distancia de seguridad con el cruce, el estado del agente cambia a ACERCANDOCRUCE, este provoca que la velocidad del vehículo se reduzca hasta llegar a la velocidad de cruce. Cuando alcanza esta se queda en estado de CRUCE. tiempo agente posición

estado

velocidad carril

9

0

37.95

ACERCANDOCRUCE

1.59

c1

10

0

39.56

CRUCE

1.2

c1

En la ultima tabla podemos apreciar como el vehículo ha salido del cruce y se le asigna el estado ACELERANDO nuevamente para ir adquiriendo velocidad hasta alcanzar la velocidad máxima. tiempo agente posición

estado

velocidad carril

11

0

1.0

CRUCE

1.26

c1

14

0

2

ACELERANDO

1.86

c1

50

Capítulo 4 Conclusiones En este apartado irán las conclusiones del proyecto, se dará una explicación de cómo se han alcanzado los objetivos, una pequeña evaluación personal sobre el proyecto donde se intenta plasmar la experiencia de realizar un proyecto de estas características y por último el apartado de líneas futuras donde se habla de las posibles mejores para el simulador.

4.1.

Ob jetivos cumplidos

Llegado a este punto, es hora de evaluar si se han cumplido los objetivos que se mencionan al principio de la memoria. Respecto al modelado de datos de la ciudad en la parte de análisis podemos observar el diagrama de clases; como se ha conseguido un modelado de clases coherente y que aporta toda la funcionalidad necesaria para llevar acabo el proyecto. En el punto dos en la clase grafo se denen los métodos para la construcción del grafo, en la parte de detalles de implementación podemos observar los problemas de la generación del grafo y la solución de estos mediante la división de los cruces en nodos. Gracias a la librería XStream y a la implementación de la clase Xml en ciduad se consigue leer una ciudad de un chero XML previamente creado cumpliendo otro de los objetivos del proyecto. Los agentes realizan la lectura en la clase LectorAgentes del proyecto simulador. En el cuarto punto se pide la generación de rutas, en la clase EscribirItinerario observar un método generador de rutas dependiendo del tipo de

ruta que reciba como parámetro podemos generar cuatro tipos de rutas: larga, media, corta y aleatoria. Quinto: simulación de tráco. Podemos realizar la simulación sin problema de 51

CAPÍTULO 4. CONCLUSIONES colisiones consiguiendo un tráco uido; podemos ver alguno de los problemas a la hora de generar ese tráco en detalles de implementación el apartado de gestión de colisiones. En el punto seis en la clase ControlAgente se puede observar como el tráco esta perfectamente sincronizado los vehículos no salen todos a las vez sino por instantes de tiempo y los semáforos tienen una cadencia de cambio constante, no aleatoria. Por último mediante una lista de listas de agentes podemos almacenar toda la simulación y sacar la información en un chero XML para que el visualizador lo procese. Por último también se ha cumplido el objetivo de trabajar en equipo y formar parte de un gran proyecto ya que ha sido costosa pero a la vez muy productiva y enriquecedora la experiencia de compartir una parte del proyecto con Juan Bayona Beriso autor del proyecto visualizador y del trabajo común con la ciudad.

52

CAPÍTULO 4. CONCLUSIONES 4.2.

Evaluación personal

El proyecto de n de carrera supone acabar un camino iniciado hace ya tres años, supone poner en práctica todos los conocimientos y herramientas que nos han enseñado durante este tiempo. Es el gran proyecto que te termina de denir como ingeniero. Elegí LiveCitySim porque me proporcionaba todo lo que buscaba para poner punto y nal a la carrera ya que es un proyecto muy interesante para el cual he tenido que aprender muchísimas cosas y me ha ayudado a terminarme de formarme, lo mas bonito del simulador es que permite simular hasta tres tipos de conductas diferentes y se pueden generar innidad de tipos de coches y la sincronización con los semáforos es perfecta. Los grandes retos suelen venir acompañados de grandes dicultades en este caso para mi, las dos tareas más difíciles han sido sin duda la generación de grafo. Esta parte sobre todo me ha costado muchas horas de implementación del algoritmo y de pruebas ya que ha sido una labor muy difícil el de unir todos los cruces con los nodos, saber la orientación de estos y dejar el grafo conexo totalmente. Otra de las partes del proyecto en las que más me he esforzado ha sido la tarea de gestionar las colisiones y la actualización de posiciones, ya que he tenido algunos problemas con las aceleraciones negativas que he tenido que subsanar poco a poco y por no decir el tema de los cruces conseguir que varios vehículos circulen por un cruce sin que se choquen es muy satisfactorio para mi. Por último hacer mención a una última eventualidad que se dio cuando ya estaba el software totalmente acabado, surgió una modicación de ultima hora, había un problema que los coches debían viajar por los cruces, lo que suponía un pequeño cambio que al principio parecía fácil pero que luego se convirtió en varios días de trabajo. Todos estos problemas fueron resueltos poco a poco y también gracias a ellos puedo valorar positivamente este ultimo gran proyecto ya que todo el esfuerzo ha merecido la pena.

53

CAPÍTULO 4. CONCLUSIONES 4.3.

Lineas futuras

El proyecto simulador se puede aplicar en un futuro para simular el traco de cualquier ciudad siempre que esta este implementada en un archivo XML, las posibles mejoras que se podrían realizar al simulador y que no han sido implementadas por falta tiempo y porque ampliaría bastante la dicultad del proyecto son: Crear una lista que simule una cache para coches por carril: se podría crear una lista auxiliar por cada carril para mejorar el tiempo de búsqueda para que así los vehículos tarden menos tiempo en encontrar a otros vehículos en su carril. Esto disminuiría el tiempo de ejecución. Hacer que los semáforos afecten a un sólo carril: se puede modicar la implementación para poner semáforos que sólo afecten a un carril o que impida hacer un giro hacia alguna dirección para darle más realismo a la simulación. Introducir rotondas: el simulador solo admite cruces y por el momento no acepta rotondas es una posible mejora se podrían añadir estas al diseño. Permitir adelantamientos: sería una gran mejora que se puede realizar es esta permitir el adelantamiento entre vehículos siempre que tengan un carril a la izquierda para hacerlo. Añadir otra GUI: se podría añadir otra interfaz de usuario que permita generar los agentes de forma sencilla, haciendo clics en ventanas de tal forma que generará el código XML de los agentes. Respecto al comportamiento se podrían realizar alguna mejora como renar los parámetros de aceleración y velocidad máxima. Introducción de pasos de cebra con peatones e implementar un comportamiento que permita que los vehículos se paren en el paso de cebra cuando haya peatones pasando por ellos. El proyecto tiene muchas aplicaciones desde simular el tráco rodado de una ciudad como ver el comportamiento de ciertos conductores en los atascos, simulación de trayectos con tráco, sin tráco, puede servir para calcular los limites de velocidad y poder realizar posibles cambios en la señalización de las ciudades. 54

Capítulo 5 Bibliografía XML http://www.totalxml.net/history-xml.php http://www.itwriting.com/xmlintro.php

"XML al descubierto"Michael Morrison Ed. Prentice Hall, 2000. http://barrapunto.com/

"Java y XML"; Brett McLaughlin Ed. Anaya Multimedia, 2001. Latex http://www2.dis.ulpgc.es/~lalvarez/teaching/pi/latex/TutorialLatex.pdf http://jci.codemonkey.cl/charlas/tutorial_latex.pdf

Xstream http://www.wikio.es/article/74734928 http://xstream.codehaus.org/

Swing http://www.wikihow.com/Create-a-Swing-GUI-in-Java

55

CAPÍTULO 5. BIBLIOGRAFÍA http://www.ehow.com/how_2386772_create-swing-gui-java.html

Jgraph http://www.jgraph.com/ http://dev.cs.uni-magdeburg.de/java/jgraph/tutorial/t1.html

Diagramas http://es.wikipedia.org/wiki/Diagrama_de_clases

Capturas Motor gráco para simulaciones de traco sobre una ciudad virtual: LiveCitySim, Juan Bayona Beriso.

56