Campus Ciudad de México Escuela de Graduados en …

117
, TECNOLOGICO DE MONTERREY® Campus Ciudad de México Blblfoteca C.;&Qildad._..., Escuela de Graduados en Ingeniera y Arquitectura Maestría en Ciencias de la Computación "Simulador de tráfico en tiempo real" Autor: Felipe Morales Torres Director de la tesis: Dr. Benjamín Hernández Arreguín Abril 2012

Transcript of Campus Ciudad de México Escuela de Graduados en …

,

TECNOLOGICO DE MONTERREY®

Campus Ciudad de México

Blblfoteca C.;&Qildad._...,

Escuela de Graduados en Ingeniera y Arquitectura

Maestría en Ciencias de la Computación

"Simulador de tráfico en tiempo real"

Autor: Felipe Morales Torres

Director de la tesis: Dr. Benjamín Hernández Arreguín

Abril 2012

CONTENIDO

Lista de Figuras

Lista de Tablas

1. Introducción 1.1. Antecedentes ..... . 1.2. Definición del problema 1.3. Objetivos . 1 .4. Justificación . 1.5. Hipótesis .. 1.6. Metodología .

2. Marco Teórico 2.1. Multitudes . . . . . . . . . . . . . . . .

2.1.1. Introducción a las multitudes . . 2.1.2. Características de una multitud . 2.1.3. Modelado por tipo de multitud

2.2. Simulación de tráfico . . . . . . . . . . 2.2.1. Movimiento de vehículos . . . . 2.2.2. Automatización y Simulación de tráfico

2.3. Cómputo en paralelo 2.3.1. GPU . 2.3.2. CUDA

3. Desarrollo y Simulación 3.1. Especificaciones generales 3.2. Variables de entrada ...

3.2.1. Agentes . . . . . 3.2.2. Caminos o rutas 3.2.3. Edificios .... 3.2.4. Otras variables .

3.3. Procesamiento de Variables de entrada 3.4. Vinculación de nodos para generar rutas 3.5. Generación de movimiento ...... .

4. Resultados y Conclusiones 4.0.1. Conclusiones . 4.0.2. Trabajo a futuro .

¡¡

iv

1 3 4

7

7

8 8

10 10 10 11 12 18 21 30 57 58 63

71 71 73 74 76 80 80 81 84 88

97 105 106

LISTA DE FIGURAS

1.1. Estadísticas de crecimiento mundial 1950-201 O 2 1.2. Tipos de multitudes . . . . . . . . . . . . . . . 3 1.3. Factores de influencia en una multitud . . . . . 4 l .4. Flujo de multitud en pasillo con una sola puerta 4

2.1. Multitudes por tamaño: pequeñas, medianas y grandes 11 2.2. Multitud enorme estudiada como un fluido, fotografía real 13 2.3. Multitud enorme estudiada como un fluido, simulación en forma de fluido 13 2.4. Multitud simulada dentro de VRLab . . . . . . . . . . . . . . . 14 2.5. Esquema gráfico de animacion en el desarrollo de VRLab . . . . 15 2.6. Ejemplo de una animación de multitudes con partículas en maya 17 2.7. Intersección simulada de la ciudad de XiaDongMen 20 2.8. Visualización de una red micro y macroscópica . . . . . . . . . . . . . . . 21 2.9. Resultados del enfoque basado en el movimiento de gas para el tráfico . . . 25 2.1 O. Ejemplo de un modelo LWR, mediendo la densidad mediante las variables

de tiempo y velocidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.11. Gráfica de comparación entre lo medido en tiempo real y lo simulado por

medio de ecuaciones estocásticas . . . . . . . . . . . . . . . . . . . . . . . 28 2.12. Planeación de ruta de movimientos para controlar la forma en la que un

vehículo se estaciona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.13. Resultado final de las pruebas de movimiento hacia atras con 5 remolques en

un trailer . . . . . . . . . . . . . . . . . 30 2.14. Ejemplo de un dispositivo car-like robot . . . . . . . . . . . 31 2.15. Curva de Bezier . . . . . . . . . . . . . . . . . . . . . . . 34 2.16. Diferentes ramificaciones con longitudes y angulas variados 35 2.17. Sistema de seguimiento de llegadas de autobuses, utilizando smartphones 37 2.18. Estadísticas de resultados del estudio del salto transversal, en la comunica-

ción entre vehículos, utilizando VANETs . 41 2.19. Modelo Ackerman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.20. Resultados del algoritmo CUT . . . . . . . . . . . . . . . . . . . . . . . . 43 2.21. Resultados del simulador híbrido en enfoques macroscópicos y microscópicos 46 2.22. Ejemplos de topologias de redes Myrinet . . . . . . . . . . . . . . . . . . . 49 2.23. Cluster de computadoras en red Myrinet . . . . . . . . . . . . . . . . . . . 49 2.24. Correlación entre el estado y la densidad local, de acuerdo a un tiempo es-

pecífico . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.25. Esquema de un simulador basado en capas . . . . . . . . . . . . . . . . . . 52 2.26. Entorno físico y conceptual de la simulación de tráfico . . . . . . . . . . . 54 2.27. Beneficios por utilizar el algoritmo "Vehicle Traffic Light" en la ciudad de

Porto, Portugal . . . . . . . . . . . . . . . . . . . . . 57 2.28. Diferenciación en el ancho de banda entre CPU y GPU . . . . . . . . . . . 59

2.29. Diferencia de velocidad en Gflops entre CPU y GPU 59 2.30. Arquitécturas CPU y GPU . . . . . . . . . . . . . 60 2.31. Dependencias de ingreso para enlaces verticales . . 62 2.32. Procesamiento en el CPU y GPU a través de CUDA 65 2.33. Proceso de pipeline gráfico . . . . . . . . . . . . . . 67 2.34. Ejemplo de arreglo de administración de nodos . . . 69 2.35. Comparación de aceleración entre los diversos paradigmas utilizados 70

3.1. Esquema del simulador de tráfico . . . . . . . . . . . . . . . . 72 3.2. Esquema de archivo XML . . . . . . . . . . . . . . . . . . . 74 3.3. Muestra de creación de un camino, por medio del archivo csv 78 3.4. Tipos de direcciones en los nodos 79 3.5. Pipeline de ejecución en Open GL 81 3.6. Buffer de vértices en Instancing 83 3.7. Vínculos entre nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 3.8. Vínculos entre nodos, considerando los sentidos 86 3.9. Textura y sus componentes . . . . . . . . . . . . . . . . . . . . . . 89 3.10. Ejemplo del llenado de la textura . . . . . . . . . . . . . . . . . . . 90 3.11. Diagrama de ejecución en CUDA y sus diferentes tipos de memoria 94

4.1. Especificación del movimiento de un solo carril de izquierda a derecha en posiciones (x,y) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.2. Caso de estudio cuando un nodo se encuentra con un nodo de sentido con-trario sin ninguna opción de movimiento . . . . . . . . . . . . . . . . . . . 100

4.3. Resultado de la primera simulación. . . . . . . . . . . . . . . . . . . . . . 101 4.4. Especificación de nodos en posiciones (x,y) en dos carriles con sentidos con-

trarios ............................... . 4.5. Resultado de la segunda simulación . . . . . . . . . . . . . . . . 4.6. Dibujado del camino para el caso del crucero y coordenadas (x,y)

4.7. Imagen I para la ejecución del simulador para el crucero 4.8. Imagen 2 para la ejecución del simulador para el crucero 4.9. Imagen 3 para la ejecución del simulador para el crucero 4.1 O. Imagen 4 para la ejecución del simulador para el crucero

102 103 104 106 107 108 109

LISTA DE TABLAS

2.1. Rendimiento en redes vehiculares de caminos en Estados Unidos

3.1. Formato de archivo csv ....... . 3.2. Formato de archivo csv para el camino 3.3. Archivos XML a cargar

4.1. Nodos tipo crucero y sus enlaces

64

75 77 80

105

, l. INTRODUCCION

La población mundial ha tenido un crecimiento exorbitante comparado con siglos ante­

riores, la explosión demográfica muestra cifras que nos dejan ver el incremento de personas

en todo el mundo, tan solo en la última década se ha tenido un crecimiento según el reloj

universal I la cifra de población asciende a 6,897 millones de personas en todo el mundo, un

crecimiento de casi 1,000 millones en la última década.

En la figura 1.1 se puede ver e! aumento de la población por década tornado de la agencia

de Censos de Estados Unidos. Gran parte de esta población se encuentra concentrada en las

grandes urbes, a medida que un país se mueve de una economía agrícola a una economía

industrializada se produce una migración en gran escala de los residentes rurales hacia las

ciudades. En este proceso, el índice de crecimiento de las áreas urbanas duplica el índice de

crecimiento global de la población. En 1950, el 29 % de la población mundial vivía en áreas

urbanas, en 1990 esta cifra era del 43 % y para el año 2000 se aumentó a más del 50 %.

1 World Clock 20 I O la organización que lleva las estadísticas de conteo de personas, mortalidad, enferme­dades, etc

2

World Population: 1950-2050 10 9

8

J L.--- 9 Billio n

vi 7 e ~ 6 e 5 e o 4 ~ "3 3 a.

2 o CL

----~ BBillion_

-------7 Billion _.,,,--

6 Billion _.,.r 5 Billior> ___,.,

4 Biilion ~ 3 Billion 1

f 1

o o o o 2 @ § o o o o o l.f) <O r-- o N "' "" l.f)

~ ~ ~ ~ ~ o o o o N N N N N N

Year Sou1ce; U.S. C•nsus Bureou. lnte111.11iom1I Data Boso. December 2010Updcllo.

Figura 1.1: Estadísticas de crecimiento mundial 1950-201 O

Esa migración a las ciudades conlleva una importante disminución del número de perso­

nas que vive en el campo, y en consecuencia índices de crecimiento negativos en las áreas

rurales. En los países menos desarrollados, el rápido crecimiento de la población mundial ha

diferido este fenómeno aplazándolo hasta las primeras décadas del siglo XXI. La previsión

para América Latina es que en el año 2020 más de 300 millones de niños vivan en las ciuda­

des. En este sentido los espacios cada vez son menos y las necesidades son mayores, existe

sobre explotación del suelo en el que la población vive y cada vez hay menos espacios libres,

lo que provoca es tener un gran número de personas en espacios pequeños.

Es importante contar con mecanismos que permitan el movimiento y traslado de es­

tas grandes cantidades de personas, que por definición 2 se denomina multitudes, como un

número grande de personas o cosas, olra de las definiciones indica que efectivamente son un

número grande de personas o cosas que se mantienen o consideran juntas, al respecto [ 1] es­

tablece una multitud desde un conjunto de personas agrupadas colectivamente, estableciendo

un rango mínimo de decenas, indicando para esto, diferentes tamaños de multitud, desde un

tamaño pequeño (decenas), tamaño medio (cientos) hasta el tamaño grande (miles o cientos

de miles).

2Real academia de la lengua española

1.1 Antecedentes 3

1.1. ANTECEDENTES

Desde a inicios de la década de los 80 se pudo observar el rápido crecimiento de la pobla­

ción en espacios pequeños, lo que provocó que los investigadores de la época comenzaron a

realizar trabajos sobre el control y movimiento de multitudes. Forsyth [2] establece que las

multitudes son un grupo grande de elementos que ocupan una ubicación única y que com­

parten una meta en especial. Se muestra la clasificación en !a figura 1.2, la cual contempla

los diferentes tipos de multitudes dependiendo el objetivo o razón por la cual los elementos

que pertenecen a la misma se encuentran dentr, así como el comportamiento de las mismas.

Público Cmial

Multitudes

Reuniones

Auditorio o Colas de Audiencia~ espera

Turbas de !incharniento

Turbas <lgre,siv,us

forbas o Grupos

Disturbios Escape o

fuga

Figura 1.2: Tipos de multitudes

P<lnicos

Codicioso

En 1999, Gwyenne f3], establece las diversas variables que influyen sobre la población y

su movimiento, tal y como se muestra en la figura 1.3.

A través de los años se ha investigado en diversas formas a las multitudes, desde su

composición, factores de creación, e inclusive ideologias politicas, sociales y psicológicas

asociadas a la misma, sin embargo, el punto más atacado dentro de una multitud, es su

movimiento, ya sea al interior de la multitud, visto desde el punto de vista microscópico o el

comportamiento de la multitud como un bloque, visto desde el punto de vista macroscópico.

Se describió en 1999 [4] una serie de experimentos al interior de un corredor el cual

contenia una sola puerta de salida, y en el mismo se mostraron diversos comportamientos de

1.2 Definición del problema 4

-

Figura 1.3: Factores de influencia en una multitud

personal que se movía a través del mismo con diversas trayectorias, lo cual no indicaba un

patron claro de movimiento.

Dirección del flujo Puerta

Figura 1.4: Flujo de multitud en pasillo con una sola puerta

1.2. DEFINICIÓN DEL PROBLEMA

Una de las metas de las ingenierías en la actualidad, es la fluidez en el movimiento de

las multitudes, en donde multitud se define como un número grande de personas o cosas

(movimiento del latín moveré- hacer que un cuerpo deje el lugar o espacio que ocupa y pase

a ocupar otro). En este sentido el movimiento de una multitud, se puede definir como hacer

que un gran número de personas o cosas deje el lugar o espacio que ocupa y pase a ocupar

otro.

J .2 Definición del problema 5

Las multitudes como podemos ver pueden estar conformadas por diversos elementos, no

necesariamente personas, vehículos, etc, lo que conlleva a diseñar algoritmos de movimiento

automatizados, que como la definición lo indica, nos permitan realizar el traslado del cuerpo

u objeto de un espacio a otro.

En la actualidad las grandes urbes denotan un crecimiento de integrantes saturado, es

decir, los caminos disponibles, las rutas, las formas de transpo11arse no crecen al ritmo de las

necesidades de movimiento de las personas; es común en la vida diaria observar saturación

en todos los medios de transporte, como parte de la solución diversas ramas se han creado a

partir de otras como el caso de la ingeniería del transporte que maneja :

1. Problema del tránsito y su solución.

2. Transporte e ingeniería de tránsito.

3. Usuario de servicios de transpo11e.

4. Vehículos.

5. Sistema vial.

6. Dispositivos para el control del transito.

7. Volumen del tránsito.

8. Variables de velocidad.

9. Análisis del flujo vehicular.

1 O. Análisis de la congestión vehicular.

11. Capacidad Vial

12. Semaforización.

13. Estacionamientos.

1.2 Definición del problema 6

14. Accidentalidad.

15. Transporte público.

Cada uno de estos temas tienen el propósito de mejorar la forma en la que las sociedades

se mueven, con elementos propios del tránsito de las ciudades o las vialidades, se pretende

atacar el movimiento de las sociedades con instrumentos, caminos, educación, etc. Sin em­

bargo se realiza conforme al libre tránsito de cada persona, es decir, se pretende controlar el

flujo de personas con dichos instrumentos sin interferir en sus decisiones o alternativas de

rutas a tomar, solamente se sugiere y en algunos casos como el uso de semáforos se "impone"

A pesar de lo anterior, el factor humano influye directamente en el éxito o fracaso de las

metodologías utilizadas, ya que si los métodos de manejo, las rutas y las decisiones tomadas

por cada una de las personas conlleva a un tránsito denso, ninguna herramienta persuasiva

por parte de los mecanismos de control llegará a buen fin.

Ya que aunque las metodologías a utilizar pueden ayudar, no solucionan completamen­

te la problemática derivado a que siempre contamos con el factor húmano en la toma de

decisiones lo cual impacta directamente en el éxito o fracaso de las políticas utilizadas.

Áreas como la robótica pretenden encontrar algoritmos de control de movimiento de mul­

titudes de robots. Por definición un robot se declara como una Máquina o ingenio electrónico

programable, capaz de manipular objetos y realizar operaciones antes reservadas solo a las

personas. En este sentido se espera que el movimiento de los robots sea lo más cercano al

de los movimientos en la inteligencia de esquivar obstáculos, trazar trayectorias y manejo de

colisiones.

Dentro de la misma definición se puede observar que se maneja un amplio espectro de

posibles objetos que pueden ser tomados como un robot, de acuerdo al manejo de multitudes

que se pretende en la presente investigación, ya que los algoritmos del manejo de multitudes

puden adaptarse a cualquier máquina que pretenda realizar el traslado de un punto A a un

punto B, calculando sus trayectorias y definiendo el mejor camino posible.

1.3 Objetivos 7

El trabajo de tesis busca realizar una investigación sobre las técnicas, modelos, algorit­

mos de manejo de multitudes, etc. con la finalidad de aportar nuevos escenarios o incorporar

modificaciones a los ya existentes con el propósito de ayudar en el manejo de multitudes

dentro de un entorno vial, es decir en tráfico. De la misma forma el trabajo se ocupará de

la animación de los modelos utilizados o propuestos dentro de la investigación con la fina­

lidad de realizar el entorno gráfico que nos permita dimensionar los resultados obtenidos

teóricamente.

1.3. OBJETIVOS

Nuestros objetivos dentro del desarrollo de la tesis son los siguientes:

1. Crear un entorno gráfico que se pueda utilizar para el movimiento de multitudes de

vehículos, explorando las capacidades de la taijeta gráfica.

2. Estudiar los diferentes algoritmos/procedimientos de movimiento de vehículos en tráfi­

co

3. Estudiar sobre el manejo de colisiones para un conjunto de automoviles dentro de la

animación.

4. Generar la simulación de lo establecido teóricamente.

5. Estudiar los resultados aplicando diferentes casos de tráfico.

1.4. JUSTIFICACIÓN

Es importante contar con herramientas que nos permitan modelar el movimiento de las

multitudes, ya sea que estas multitudes se desplacen de forma personal, es decir, como per­

sonas que se mueven por alguna razón, ya sea de seguimiento o por convicción propia, hasta

multitudes de tráfico que se puedan mover fluidamente por los entornos viales.

1 .5 Hipótesis 8

Usualmente el manejo de multitudes provoca lograr las mejores condiciones de movi­

miento que puedan tener las mismas o poder conseguir que se puedan trasladar de un punto

A con determinadas coordenadas (:r,y) hacia un punto B establecido, con las mejores condi­

ciones de fluidez, tratando de establecer ciertas acciones de acuerdo a decisiones concretas

que se encuentran a cargo de personal de vialidades o tráfico en las ciudades.

Estas decisiones antes de ser aplicadas, deben ser estudiadas y aplicadas con detenimien­

to ya que de las mismas depende el impacto a miles de personas o inclusive en entornos

urbanos con tráfico muy denso a millones de personas. Lamentablemente la construcción de

caminos o la incorporación de carriles, cruceros, vialidades implica poder contar con herra­

mientas que nos permitan medir las variables asociadas al tráfico antes de aplicarlas, de no

ser así se podrían tener consecuencias negativas en la sociedad a la que se aplican deterio­

rando el nivel de vida de las personas o inclusive tener perdidas económicas al interior de las

ciudades.

1.5. HIPÓTESIS

Al estudiar las diferentes investigaciones, enfocadas a un entorno de movimiento vial, se

espera en este trabajo poder establecer un simulador grfico en el cual se puedan dibujar miles

de vehculos generando su movimiento por la tarjeta grfica, los cuales se puedan ejecutar de

forma eficiente con el propsito de que puedan visualizarse los resultados en tiempo real.

1.6. METODOLOGÍA

El documento constará de diferentes capitulas que nos permitirán adentrarnos al desarro­

llo del simulador de una forma secuencial, estableciendo en primera instancia el capitulo de

Introducción que nos da un breve panorama de las multitudes así como su interacción con los

entornos viales también de multitudes y explicando la motivación necesaria que nos permita

visualizar la utilidad de contar un simulador de tráfico.

1 .6 Metodología 9

En el siguiente capitulo del Estado del Arte, realizamos un enfoque más profundo a las

investigaciones realizadas en la simulación de multitudes realizando énfasis en los trabajos

relacionados a los simuladores de tráfico, incluyendo diversos trabajos de áreas enfocadas al

estudio del tránsito vehicular.

Una vez que ya hemos obtenido el panorama de lo que se ha desarrollado con respecto

al terna de la tesis, presentarnos nuestra propuesta de un simulador de tráfico explicando

para esto, los diferentes componentes, así como paso a paso ir observando las variables de

entrada, su proceso y la visualización de un simulador gráfico áe tráfico.

Finalmente en el capítulo de Resultados y Conclusiones exploramos tres casos básicos

de movimiento dentro de un simulador de tráfico, tales como el camino en un solo sentido,

doble sentido y finalizando los casos de uso con la simulación de un crucero. En este mismo

capitulo se encuentran los resultados e imagenes de estos tres casos, así como los datos de

simulación y desarrollando las conclusiones del simulador construido así como el trabajo

que se puede desarrollar posteriormente que no se encuentra incluido en la tesis, y como

punto final, la referencia bibliogrífica utilizada.

,I'

2. MARCO TEORICO

2.1. MULTITUDES

2.1.1. INTRODUCCIÓN A LAS MULTITUDES

El desarrollo de multitudes se ha estudiado en diversos campos en gran medida durante

las últimas decadas, áreas diferentes se han interesado por el comportamiento de una mul­

titud desde su concepción hasta su movimiento en conjunto, pasando por la agrupación de

sus elementos o miembros tomando en cuenta diversos factores, algunos campos de estudio

interesados en el modelado y estudio de las multitudes han sido la ingeniería ele seguridad,

el diseño arquitectónico y el entretenimiento digital entre otros.

La multitud como tal puede contar un comportamiento diferente al estudiarla desde cada

uno de sus elementos o bien enfocando la misma en un punto de vista general.

La investigación [ I] nos indica que los elementos de una multitud dentro de su comporta­

miento usual o normal puede ser afectado por otros en la multitud, lo cual puede depender de

varios factores que pueden ser fisiológicos, psicológicos y sociales. Una observación común

10

2. J Multitudes 11

en un comportamiento humano es que un individuo puede comportarse de manera muy dife­

rente en una multitud comparado con su actuar individual.

Dentro de los campos en donde es posible aplicar la investigación de multitudes, el di­

seño arquitectónico, puede contemplar desde cuestiones básicas tales como agregar algún

elemento al esquema del inmueble, hasta desarrollar un complejo sistema de evacuación de

un edificio en donde se sahe que pueda reunirse una multitud.

2.1.2. CARACTERÍSTICAS DE UNA MULTITUD

Es importante dentro del modelado y simulación de la multitud puntualizar el tamaño de

la multitud a considerar, tal y como lo indica [ I], el tamaño de una multitud tiene diferentes

clasificaciones y puede consistir de miles o aun cientos de miles(multitud enorme), cientos

(tamaño medio), o decenas(tamaño pequeño) de individuos, clasificación que se observa en

la figura 2.1, obtenida de 1

Del tamaño de la multitud a estudiar corresponderá en gran medida del tipo de enfoque

que se le pueda dar al estudio de la multitud, ya que al ser una multitud enorme o de gran

tamaño se puede estudiar a la multitud como una sola entidad con sus propias características

y reacciones frente a ciertas circunstancias o al considerar una multitud pequeña, se puede

estudiar en particular la interacción entre sus elementos .

• Figura 2.1: Multitudes por tamaño: pequeñas, medianas y grandes

Otra característica de una multitud será la escala de tiempo a utilizar para el periodo

1 hllp://www.photaki.es

2. 1 Multitudes 12

de la medición de la multitud, ya que pueden considerarse reacciones de corto plazo como

en situaciones de emergencia, hasta comportamientos de largo plazo como propagación de

ideologias entre una multitud.

De estas dos características esenciales al modelar y simular una multitud se puede espe­

cificar el tipo de enfoque a utilizar. Para el caso de una multitud de largo plazo, usualmente

se utiliza el enfoque de investigadores sociales, ya que normalmente se enfocan en tratar de

visualizar el desarrollo de ideologías, las cuales son diseminadas a través de los individuos

de una población, comunmente este tipo de investigación involucra lapsos de tiempo desde

semanas hasta años.

2.1.3. MODELADO POR TIPO DE MULTITUD

El modelo utilizado para multitudes de largo plazo se establece como una red de inter­

acciones entre agentes y cada agente puede ser simplemente caracterizado por su tipo de

opinión y el grado de incertidumbre que un agente puede tener dentro del periodo de tiempo

a estudiar tal y como lo muestra[5], para cambiarla en determinadas circunstancias. de acuer­

do a estas características el modelo las contempla como una serie de ecuaciones matemáticas

las cuales dentro de la simulación son muy restringidas a cierto tipo de entornos, es decir,

los modelados de este tipo de multitudes son de tipo específico y no general.

Para el caso de multitudes de corto plazo consideradas de un tamaño grande, el modelo

más usual, ya que es el que se adapta mejor a este tipo de multitudes es el enfoque basado

en flujo, ya que permite tomar a la multitud como una entidad homogenea, la cual responde

a los estímulos del entorno de forma global, es importante mencionar que aunque se toma la

idea de un fluido para especificar el comportamiento de la multitud.

No necesariamente el fluido tiene un comportamiento errático o desordenado, al contra­

rio, ya que se conforma por elementos pensantes, el concepto de fluidos pensantes ha sido

ubicado como el tema central a investigar para las multitudes de gran tamaño y con una es­

cala de tiempo a corto plazo, las cuales para modelar este tipo de comportamiento describen

2.1 ML1ltitL1des 13

el movimiento por medio de ecuaciones diferenciales, para lo cual elementos estadísticos y

algunas hipótesis de comportamiento son incluidas.

Figura 2.2: Multitud enorme estudiada como un fluido, fotografía real

Figura 2.3: Multitud enorme estudiada como un fluido, simulación en forma de fluido

En la figura 2.2 obtenida de [6] se puede visualizar una multitud de gran tamaño en

un centro religioso, en ella se puede observar una fotografía real de dicha congregación, y

posteriormente en la figura 2.3 el modelado mediante fluidos realizado por un enfoque de

dinámica de partículas.

Al contar con una multitud de gran tamaño los individuos involucrados no son contem­

plados como entes separados, al contrario al estudiarlos como un fluido, derivado de su

2.1 Multitudes 14

comportamiento denso, es más factible estudiarlos como una sola masa.

Para el estudio de dichas multitudes se creo por la universidad de Florida el software

EVACNET [7], de acuerdo a las especificaciones del software permite determinar los planes

de evacuación optimos de algún edificio en especifico. La simulación del mismo produce un

resultado óptimo ya que minimiza el tiempo para evacuar el edificio, y el objetivo principal es

evacuar al personal que ocupa el edificio lo más pronto posible, sin embargo dicho software

tiene la reestricción comentada para este tipo de multitudes ya que enfoca su compo11amiento

en el entorno global con velocidades constantes de movimiento de la multitud y no toma en

cuenta comportamientos específicos del mismo.

Existen otros desarrollos como es el caso del trabajo realizado por el VRLab del Instituto

Federal Suizo de tecnología, la cual contempla la animación y trata a la multitud individual­

mente para especificar las rutas de movimiento y dividiendo de acuerdo a la cercanía con la

animación por regiones de nivel de detalle para el dibujado de los elementos.

Figura 2.4: Multitud simulada dentro de VRLab

Los resultados de las animaciones realizadas por VRLab contemplan animaciones de

más de 10,000 agentes, los cuales son simulados tal y como lo muestra la figura 2.5 . En esta

figura se puede observar diferentes etapas que dentro del desarrollo del modelo se establecie­

ron con el proposito de realizar un modelo de simulación de tráfico lo más eficiente posible,

2. 1 Multitudes 15

utilizando las últimas técnicas de modelado y que contemplan los elementos de dicha figura,

tales como "instancing" que nos permitirá dibujar el mismo modelo miles de veces sin sobre­

cargar el proceso de dibujado, "culling" que hace el procesamiento del dibujado únicamente

de los elementos que se encuentran dentro de la vista de la cámara.

D

D Simulation

Update

Figura 2.5: Esquema gráfico de animacion en el desarrollo de VRLab

Las multitudes que tienen un plazo o término de corta duración que involucran multitu­

des de tamaño pequeño a mediano son del tipo de multitudes que mas se estudian, ya que

contemplan el elemento del movimiento en masa de una multitud en su totalidad, así como

el estudio en especifico de los individuos.

Existen basicamente dos tipos de enfoques dentro de esta simulación, y que van a de­

pender de las reglas de movimiento así como la forma de visualizar a los elementos que

conforman a la multitud.

Los dos tipos fundamentales son el enfoque basado en agentes y el enfoque basado en

entidades, sin embargo, estos dos enfoques no tienen una diferenciacion muy clara, ya que

su comportamiento dentro de la simulacion es muy similar, la principal diferencia se refiere

a la complejidad de los mecanismos de accion de cada uno, mientras una entidad usualmente

tiene un comportamiento homogeneo y genérico, un agente contempla una estructura de

toma de decisiones más compleja, que en ocasiones trata de asemejar en gran medida al

2. 1 Multitudes 16

comportamiento humano, dicha complejidad como se podrá observar mas adelante puede

ayudar en la visualización mas cercana a la realidad de una multitud, sin embargo puede

demeritar en el graficado y procesamiento de información ya que involucra un procesamiento

y poder de cómputo mayor.

El enfoque basado en entidades ha sido estudiado desde el punto de vista de una partícula,

dichas entidades contemplan leyes físicas que permiten estudiar a los elementos dentro de

una multitud como particulas en movimiento. Dentro del comportamiento de estas partículas

pueden aplicarse fuerzas de movimiento o atracción derivadas de factores físicos, sociales y

psicológicos.

Dichas partículas involucran determinados aspectos físicos, tales como masa, velocidad,

fuerza de atracción o repulsión, como se muestran en la ecuación 2.1

. rlv; vf ( t) e\l ( t) - V¡ ( t) . . . rnt- = rn,~-~--- + ¿ .f1J + ¿.f1.'LL'

rft; T j(ii) 11•

(2.1)

Estos aspectos físicos se obtienen de los elementos que establecen el comportamiento del

movimiento de una entidad durante cierto tiempo t con velocidades v; y estableciendo cierta

dirección e, y finalmente sumando las fuerzas de atracción y repulsión que puedan obtenerse

del acercamiento de las partículas.

En las fuerzas que forman parte de la segunda parte de la ecuación se pueden integrar

elementos de comportamiento motivados por factores físicos, sociales y psicológicos. Sin

embargo existen algunos criterios que no pueden ser contemplados por la naturaleza de las

ecuaciones tales como lazos familiares o personalidad de un individuo.

Inclusive dentro de dichos parámetros se pueden establecer criterios como de dependen­

cia, ya que el modelar una entidad que dependa de otra para su movimiento es sencillo,

simplemente incorporando una menor velocidad a la entidad, este mismo comportamiento

puede ser aplicado para los patrones de conducción que se pueden ingresar al modelo de

tráfico, ya que no todos los conductores en la vida real lo hacen de la misma forma.

2.1 Multitudes 17

Figura 2.6: Ejemplo de una animación de multitudes con paiticulas en maya

En la figura 2.6 se puede observar una animación de entidades de una multitud conside­

radas como partículas.

El siguiente enfoque es el de los agentes, y particularmente el más utilizado de todos los

paradigmas de modelado y simulación de multitudes, principalmente porque se asemejan en

gran medida al comportamiento de un ser humano y contemplan diversas características que

permiten una simulación más cercana a la realidad.

El aspecto más complicado dentro de este tipo de simulacion, y el mas estudiado se

refiere al movimiento de los mismos al interior del entorno, es importante mencionar que

los aspectos a considerar pueden resultar muy complejos, mientras mas complejas sean las

interacciones o las rutas tomadas por los agentes.

Cada uno de los agentes como multitud no necesariamente tiene un objetivo en común,tienen

un punto de origen y una meta ya sea parcial o final, es decir, en el trazado de la ruta puede

que tenga ciertos puntos a donde debe llegar temporalmente y realizar su movimiento casi

inmediatamente. Cada una de estas rutas puede ser preestablecida o en tiempo real, ya que

cada uno de sus agentes al incorporar detalles de inteligencia puede escoger diversas rutas de

acuerdo a una serie de reglas de decisión, las cuales pueden ser muy variadas y complejas.

Reynolds en 1987 [8] estableció tres reglas basicas en el comportamiento de multitudes,

2.2 Simulación de tráfico 18

las cuales al ser los ejes del movimiento de la multitud, con algunas variaciones siguen

siendo consideradas y son la cohesión, separación y alineación, casi todos los trabajos sobre

multitudes incluyen en su totalidad o parte de estas características, ya que el movimiento de

una multitud aunque puede resultar complicado de estudiar es necesario que genere patrones

que mantengan un orden de acuerdo a la separació n entre los agentes, la cohesión de la

multitud en su totalidad y la alineación del movimiento en general de todos los agentes.

Complementando la simulación de los agentes, es importante incluir un periodo de ani­

mación gráfica de la misma, ya que es la que permite de una forma visual observar los

resultados y corregir errores inherentes a la simulacion.

En algunas ocasiones no es importante la apariencia del agente, sino el comportamiento

estudiado mediante ciertos criterios y obteniendo los resultados de dicho comportamiento,

diversas aplicaciones como la desarrollada por Crowd Dynamics Pte Ltd establecen algorit­

mos de planeación de rutas con el mínimo esfuerzo para minimizar el costo del movimiento

del agente.

Algunos otros trabajos han incorporado un framework llamado ViCrowd [9] el cual tiene

una estructura jerárquica en donde los niveles más altos se denominan grupos que se en­

cuentran formados por individuos, dichos individuos de acuerdo a cierto conocimiento de su

entorno pueden planear rutas y evitar colisiones con elementos estáticos y con otros agentes,

dicha herramienta permite tener avatars en 3d para animar la simulación.

2.2. SIMULACIÓN DE TRÁFICO

Para la simulación de multitudes de tráfico es importante considerar los aspectos de simu­

lación de multitudes de personas ya que en gran médida el desarrollo y paradigma a utilizar,

ya sea un enfoque macroscópico o microscópico involucra invariablemente el uso de agentes

y como se ha explicado extensamente en las secciones anteriores, la incorporación de reglas

de operación, así como Inteligencia Artificial es imprescindible.

2.2 Simulación de tráfico 19

El uso de técnicas en las que los agentes podrán desenvolverse son críticas e indispensa­

bles ya que en la medida en la que los automóviles cuenten con un movimiento fluido dentro

de la simulación, la misma podrá acercarse en gran medida a la realidad.

Como se mencionaba anteriormente la simulación de automóviles puede ser enfocado

desde el punto de vista local, es decir, un automovil involucrando su movimiento y desarrollo

en una región, el cual se podría tomar como una multitud de automóviles pequeña en un

enfoque microscópico.

Al respecto [ l O] estudia el tráfico con un enfoque microscópico, midiendo la cantidad

de emisiones vehiculares que se dan en una determinada intersección, que se establecen por

medio de estándares publicados por la Unión Europea y los Estados Unidos, y que resultan

de la formas de aceleración, paro, y desaceleración de los vehículos en el momento en el que

se encuentran en una intersección.

Contempla cuatro modelos importantes en la simulación de tráfico:

• Modelo de generación de veículos

• Modelo de representación de la red vehicular

• Modelo de control de señales

• Modelo de comportamiento vehicular

Con estos cuatro modelos se realizó una simulacion en una determinada ciudad de China,

tomando como datos lo ocurrido en una hora. Durante este periodo de tiempo una cantidad

de 7,000 vehículos en una hora pico transitaron por la intersección que se muestra en la figura

2.7

Se estableció un mayor énfasis en las características de los autobuses que circulan por el

camino, ya que los automóviles contienen pocas reglas de movimiento, que no simulan en

gran medida el comportamiento de un vehículo real, ya que el movimiento de un vehículo no

es lineal siempre, depende de diversos factores que no entran dentro del alcance del artículo.

2.2 Simulación de tráfico

Jipi Qi.10

BmStop 1

Bm Stop

C'hangjiang RiverBnnk

BmStop

Bus Stop 1 l11t

Raih~ay Station

No.15 Middle School

Bus Stop

Figura 2.7: Intersección simulada de la ciudad de XiaDongMen

20

Así mismo el conjunto de las variables contemplan la emisiones de contaminantes que

estos factores implican, haciendo hincapié en señalar que mientras menos se encuentren pla­

neados los movimientos de frenar, acelerar, permanecer detenido, así como la sincronización

de las señales, la contaminación asociada a una intersección aumenta.

Entre los enfoques a utilizar, existe una subdivisión que procura el uso de forma or­

denada de los diferentes puntos de vista de simulación establecidos como macroscópicos y

microscópicos, el denominado Modelado de multi resolución (MRM) por sus siglas en inglés

nos permite evitar las limitaciones de estos dos paradigmas y utilizarlos en conjunto.

En este sentido [ 11] explora el uso de esta nueva tecnología y combina las técnicas ma­

croscópicas y microscópicas, dentro de un framework llamado UNIFY, ya que permite utili­

zar dos diferentes tipos de modelado: el primero que establece un vehículo como una entidad

que solamente depende del automovil que va por delante así como de características propias

de la entidad para realizar su recorrido, y el otro que involucra otras entidades adyacentes a

la que se estudia con el proposito de considerar un sistema más global.

De esta forma propone dos caminos para llevar a cabo la simulación siendo el primero de-

2.2 Simulación de tráfico 21

cicir la velocidad de un vehículo para la relación densidad-velocidad en un vinculo específico

y guardar la información de origen-destino para cada vehículo pero no tornando atención de

dos vehículos adyacentes. El otro es considerar un vinculo corno un sistema de cola-servidor,

es de esta forma que conjuntando estos dos caminos se establece este frarnework.

Es importante considerar que el uso de múltiples variables en un sistema híbrido pue­

de implicar un gran poder de cómputo. por lo que es necesario establecer cuales variables

pueden ser consideradas para un mejor desarrollo de la simulación y establecer reglas de con­

sistencia de requerimientos a nivel de dinámicas de tráfico, representación de la red vehicular

y la consistencia del ciclo de simulación.

El diagrama de la interacción de las redes micro y macroscópica se puede observar en la

figura 2.8

Macro/Meso Nctwork

Figura 2.8: Visualización de una red micro y macroscópica

2.2.1. MOVIMIENTO DE VEHÍCULOS

Existen diversos trabajos que han explorado la forma en la que los vehículos se mueven

dentro de su entorno al ser conducidos con diferentes tipos de comportamiento, se ha identi­

ficado en gran rnédida los factores que inlluyen en el movimiento sincronizado o en algunas

ocasiones caótico de los automóviles.

2.2 Simulación de tráfico 22

Los vehículos mantienen particularidades que los alejan del movimiento de una multitud

de génte, inclusive algunos autores han explorado el modo en el que se pudiera automatizar

el movimiento que hace un conductor al estacionar su automovil, ya que se encuentran una

serie de pasos recurrentes en la forma en la que se realiza este movimiento.

En este campo Dirk Helbing ha explorado diversas variables matemáticas que nos ha­

blan, sobre como el movimiento de un vehículo se puede dar por determinados patrones de

movimiento que se dan a lo largo de la simulación de tráfico, para lo cual ha publicado di­

versas investigaciones que explican con ecuaciones numéricas o en forma de simulación, la

interacción de los vehículos.

Tal es el caso de [ 12], en donde nos da un enfoque numerico de las simulaciones ma­

croscópicas dentro del tráfico, estableciendo el uso de ecuaciones diferenciales parciales o

"PDE" por sus siglas en inglés, las cuales sin embargo son inestables numericamente, de­

rivado del tipo de discretización que se utiliza en tiempo y espacio, inclusive con variables

pequeñas que nos permitirían un menor margen de errores para este tipo de ecuaciones.

De acuerdo a lo publicado por [ 13 ], las ecuaciones diferenciales parciales son las que

contienen una diferencial parcial para una función determinada con diversas derivadas par­

ciales de acuerdo a la ecuación 2.2

F(:r:, y ... , u, u,r, uy, H:r:r, uyy, ... ) = O (2.2)

Estas ecuaciones parciales de la función F se tendrá un número finito de derivadas, en

donde una función de acuerdo a 2.3

u(:r, y, ... ) (2.3)

Es la solución de la primera ecuación, si en alguna región del espacio de sus variables

independientes, la función y sus derivadas satisfacen la ecuación identicamente en x,y.

Y tal y como ocurre en la teoría de las ecuaciones diferenciales ordinarias una ecuaciín

2.2 Simulación de tráfico 23

diferencial parcial es de orden n, si las derivadas de mayor orden que ocurren en F son de

orden n. Las ecuaciones diferenciales parciales se clasifican también según el tipo de función

F considerada.

En particular se tienen la ecuación diferencial parcial lineal si F es lineal en la función

incógnita y sus derivadas, la ecuación diferencial parcial casi-lineal que es más general, si F

es lineal en al menos una de las derivadas de más alto orden. Como lo comenta este trabajo,

las ecuaciones diferenciales parciales se encuentran en diversas cuestiones de la vida real, y

una de ellas es la simulación macroscópica del tráfico.

Para el caso de las soluciones numéricas asociadas al tráfico, con el punto de vista de

PDEs se requieren de métodos que corren bajo ciertas condiciones, las cuales se basan en la

ecuación 2.4

ríp rí(pV) + ---:- + -. - = + - v - (:r, t) M, 61;

(2.4)

En donde la primera p se refiere a la densidad vehicular que se tiene por carril en la

posición :r, en el tiempo t, incorporando mediante la variable V otro elemento muy impor­

tante dentro de la simulación de tráfico refiriendose a la velocidad promedio del Vehículo.

De acuerdo a esta ecuación el cambio temporal de la velocidad es dada por el cambio en el

espacio, establecido por el tráfico, y que el movimiento del vehículo será denotado en la me­

dida del movimiento del vehículo, considerando el aspecto de que se pueden tener elementos

que aumenten o disminuyan la velocidad (por ello la incorporación de los signos +-) tales

como rampas, de ascenso/descenso, o inclusive caminos de gran velocidad.

Para describir el tiempo y el espacio dentro del tráfico por incorporaciones o el tráfico

que es derivado del paro-avance, se necesita una ecuación dinámica de velocidad, para la

mayoria de los modelos continuos puede darse de acuerdo a la ecuación 2.5

óp <5V r5P l - + V-. = -1- + -(Ve - V) ól ó:r c)J; T

(2.5)

2.2 Simulación de tráfico 24

De acuerdo a esta ecuación el cambio de la velocidad promedio del vehículo se encuentra

dado por tres terminos:

• a) Termino de transporte. Se encuentra dado por la propagación de la velocidad a través

de los vehículos.

• b) Termino de presión. Refleja si una anticipación de los cambios en el espacio dados

por la situación de tráfico o los efectos de dispersión provocados a la variación de la

velocidad de los vehículos.

• c) Termino de relajación. Describe la adaptación de los conductores al flujo vehicular

de acuerdo a una velocidad de equilibrio.

También nos muestra datos estadísticos del tráfico que de acuerdo a estas ecuaciones

pueden ser estudiados, por ejemplo la cuota de salida promedio es alrededor de 200 vehículos

por kilómetro por carril, sin embargo depende de muchas variables y no siempre se tiene el

mismo resultado.

El enfoque dado para este trabajo se encuentra en la relación que tiene el movimiento

basado en la cinética de los gases, aplicado a la simulación del tráfico, para lo cual se ha

establecido una simulación que estudia la interacción vehicular en terminos del modelo de

cinética de los gases, con grandes similitudes. Tomando como cambios en el movimiento

de los gases, algunas comparaciones idénticas en el caso de la amplitud que se tiene para el

cambio de la densidad vehicular y en términos de la propagación.

Otra particularidad establecida en este trabajo es la forma en la que se compara la dis­

tancia mínima entre lo vehículos, de acuerdo a la propagación que se da en las partículas de

gas.

Finalmente se muestran los resultados de utilizar diferentes métodos de discretización

utilizando como enfoque, la cinética de los gases de acuerdo al movimiento del tráfico, tal y

como se muestra en la figura 2.9.

2.2 Simulación de tráfico

p rveh1c\es,'km)

60

40

20

o 2

10

p (vehic\es,km)

60

40

20

o

p (vehic\es,'llmj

10

Figura 2.9: Resultados del enfoque basado en el movimiento de gas para el tráfico

25

Dentro de la misma línea de investigación encontramos [ 14], el cual enfoca su estudio

en la validación de la simulación de tráfico por medio de un modelo estocástico del flujo

de tráfico, por definición [ 15] [ 16] un proceso estocástico se se define como un espacio de

estados S es una colección de variables aleatorias de acuerdo a la ecuación 2.6

X 1,t ET (2.6)

Los cuales se encuentran definidos en en el mismo espacio de probabilidades establecido

en la relación 2. 7

ft,F,P (2.7)

La variable T es definido como el conjunto de parametros, si este conjunto se encuentra

2.2 Simulación de tráfico 26

dentro de los números naturales, el proceso se convierte en un proceso de parámetros discre­

to. Pero si T no es contable el proceso se encuentra dentro un parámetro continuo. El indice

t representa el tiempo, y un objeto del conjunto X es un estado o posición del proceso en

un tiempo t. En general siempre que se intenta realizar prediciones sobre el comportamiento

futuro de un módelo teórico, utilizamos un proceso estocástico, ya que se utilizan variables

aleatorias de un conjunto para predecir dicho compo,tamiento.

En primera instancia [ 14] menciona que es imprescindible contar con herramientas de

este tipo, es decir, estocásticas para utilizarlas dentro de un simulador de tráfico. Dicha inves­

tigación hace hincapie en la reducción de productividad en la que impacta el tráfico, siendo

una fuente permanente de reducción de recursos. El 32 % del tránsito en Estados Unidos se

realiza bajo un entorno congestionado que causa pérdidas por 87.2 billones de dólares, más

del 50 % que la decada anterior.

Para lo anterior se han utilizado Sistemas Inteligentes de Transportación (ITS por sus

siglas en inglés), para los cuales se toman datos de tráfico en tiempo real para apoyo y

predicción de tráfico. Cada vez se han obtenido más formas de ingresar datos de tráfico,

que se encuentran disponibles a través de diversos dispositivos, que han permitido generar

bases de datos que se han podido utilizar por la comunidad científica para la investigación

del tráfico.

ESte trabajo [ 14] propone una ecuación diferencial parcial de tipo estocástico, que cap­

tura la variación en el tráfico del tiempo y el espacio. El cual inclusive se puede utilizar para

la construcción de bloques de edificios o elementos de la urbe que permitieran un mejor

flujo de tráfico. Las funciones matemáticas asociadas al trabajo, se enfocan en el modelo

LightHill-Whitham-Richards (LWR), el cual consiste en dos ecuaciones, la primera de ellas

es derivada de la ley de conservación que establece que la diferencia entre el flujo entrante y

el flujo saliente de una celda es igual al incremento de los vehículos en una celda y la segunda

que se llama la relación fundamental entre la densidad ( el numero de vehículos por unidad

de distancia) y el volumen (por ejemplo el número de vehículos pasando por una unidad de

2.2 Simulación de tráfico 27

tiempo en un lugar (:i:,y) en un tiempo t. En la figura 2.1 O se puede observar una gráfica del

modelo LWR, estableciendo la densidad.

lTrl

Figura 2.10: Ejemplo de un modelo LWR, mediendo la densidad mediante las variables de tiempo y velocidad

Así mismo se establecen funciones de velocidad-densidad que permite establecer un pro­

medio de estos dos elementos de acuerdo a diferentes tipos de camino, en este mismo sentido

el modelo estocástico se acopla a la información de Google Map. Los datos de tráfico, tales

como el conteo de vehículos y la velocidad, se mide cada minuto desde diferentes puntos.

Despues de diversos criterios, se obtuvo la gráfica mostrada en la figura 2. I O, la cual nos deja

visualizar un 8.96 % de error, entre lo medido en la realidad y lo estipulado en las ecuaciones

estocásticas.

Otro de los trabajos, hablando sobre movimiento de vehículos 117 J se refiere a la forma

en la que los automóviles pueden ser controlados al estacionarse en entornos estrechos, este

algoritmo especificado establece una serie de sensores o escaner que nos permitan identificar

el entorno en el cual el vehículo será estacionado, de esta forma se generan trayectorias

y señales al automóvil con el proposito de que se pueda estacionar sin interacción con el

conductor y de forma segura.

La investigación propone tres aspectos importantes y prioritarios dentro de su algoritmo

2.2 Simulación de tráfico

e .g

200

180

160

UD

120

~ 100

~ 90

50

40

20

Den~ity

Avcr:::ige pcrcf::nt:;191;,: crror8 9611 %,

o/ o 20 ~ m oo 100 120 1m 1m 100 200

Obs@Nalion

Figura 2.11: Gráfica de comparación entre lo medido en tiempo real y lo simulado por medio de ecuaciones estocásticas

para controlar la forma en la que los vehículos se estacionan:

28

• Generalidad. El planeador es capaz de control la forma en la que se estaciona un

vehículo en diversos entornos.

• Simpleza. El costo del computo en el automóvil es bajo, para lo cual el camino resul­

tante debe ser suave y simple.

• Optimización. El planeador no debe solamente proporcionar una solución sino un con­

junto de soluciones posibles al estacionar el vehículo.

Es importante el análisis matemático que proporciona esta investigación ya que nos per­

mite visualizar un paradigma concreto en el que las dimensiones físicas del vehículo juegan

un papel principal, las cuales serán estudiadas en todo el trabajo y que permiten establecer

de que forma el vehículo se mueve y la forma en la que evita colisionar con elementos fijos

de su entorno considerando en todo momento el área a ocupar durante las maniobras.

Hasta este momento hemos abordado el tema del movimiento de vehículos particulares,

o que por sus dimensiones, se consideran pequeños o de tamaño cstandar, para los cuales se

2.2 Simulación de tráfico

a b

Figura 2.12: Planeación de ruta de movimientos para controlar la forma en la que un vehículo se estaciona

29

encuentran establecidas la mayoría de las investigaciones realizadas por tráfico, sin embargo

existen varias aspectos aun por considerar, tal es el caso de las vialidades, es decir los cami­

nos por donde van a transitar lo vehículos, así como el movimiento para vehículos de mayor

tamaño, tal es el caso de camionetas de gran tamaño, autobuses, o inclusive trailers de carga.

En este sentido [ 18] estudia la forma en la que los trailers realizan sus movimientos,

centrandose en el movimiento hacia atras, y que en muchas ocasiones se necesita realizar,

ya que la mayoria de las veces las descargas de estos vehículos se realizan de atrás hacia

adelante.

Dicho trabajo, establece un algoritmo que permite el movimiento hacia atrás de forma

2.2 Simulación de tráfico 30

estable y seguro de un trailer con 5 remolques, en una planeación de la ruta o el camino que

evita obstáculos y que de acuerdo a sus resultados, tiene un buen desempeño en la vida real.

En la figura 2.13 el simulador, entregó los resultados que se pueden observar, con el control

del movimiento hacia atrás del algoritmo propuesto.

C)Obst acle Sta r t

Goal

Figura 2.13: Resultado final de las pruebas de movimiento hacia a tras con 5 remolques en un trailer

2.2.2. AUTOMATIZACIÓN Y SIMULACIÓN DE TRÁFICO

La investigación del movimiento de un vehículo puede estar contemplada en dos cuestio­

nes básicas: la primera se refiere a la visualización del movimiento propio del automóvil, en

la que pueden estar presentes características tales como el tipo de manejo, la acumulación del

tráfico, patrones de estancamiento, entre otros. Esto es que se refiere a estudiar como el ser

humano realiza el manejo de los automóviles y su interacción con los diferentes elementos

del tráfico, tales como otros conductores, señales de tránsito, agentes de tránsito, semáforos.

Sin embargo existe otra área de investigación, explorada en gran medida por la robótica,

y se refiere a la forma en la que un robot de tipo automóvil o vehículo, 'car-like robot" por

2.2 Simulación de tráfico 31

su término en inglés, se mueve, desde los aspectos mecánicos, sensores, hasta su interacción

con el entorno, tipos de movimiento, etcetera.

Figura 2.14: Ejemplo de un dispositivo car-like robot

Estos dispositivos electro-mecánicos son un conjunto de instrumentos físicos de hard­

ware que permiten al robot interactuar con su entorno y que establecerán las variables de

entrada, tales como definición de obstáculos, caminos o rutas preestablecidos en el entorno,

cercanía con otros agentes o robots. Este hardware se encuentra diseñado con el propósito de

dotar al robot de las herramientas que le permitan obtener información a través de la ejecu­

ción de sus tareas.Así mismo es importante para la forma en la que genere salidas tales como

encender las luces, mover los dispositivos mecánicos, activar sensores, etcétera.

Sin embargo entre la entrada y la salida se encuentra el procesamiento de todos los datos,

ya que del ingreso de las variables del entorno, de acuerdo a ciertas condiciones, máquinas

de estado finito, algoritmos genéticos, entre otros algoritmos, se realiza la toma de decisiones

de acuerdo a la forma en la que esta programado el dispositivo.

En este sentido, investigaciones como [ 19] establecen mecanismos mediante los cuales

estos robots manejados como automóviles son configurados para moverse en su entorno de

acuerdo a los cambios de trayectoria que estan estrechamente involucrados con los compo­

nentes mecánicos, para lo cual el robot modelado contempla su postura como una ecuación

de cuatro elementos, tal y como se muestra en la ecuación 2.8

2.2 Simulación de tráfico 32

[r,y,0. K] (2.8)

Los primeros dos elementos se refieren a la posición del robot, que como se puede ob­

servar es denotada por dos dimensiones, la variable f/ se rctiere a la orientación del robot y

finalmente 1; contempla la curvatura en determinada posición, de acuerdo a estos elementos

se genera un polinomio con curvatura cubica el cual establecido en estos datos, se puede

observar como un polimonio curvo de orden cuarto.

Existen algoritmos para espacios de dos dimensiones, los cuales funcionan sin incorporar

el manejo de los sistemas físicos que se dan dentro de una simulación de tráfico. En el mo­

mento en el que se empiezan a considerar otros factores y ocupamos más de dos dimensiones,

el cómputo asociado a la ejecución y rendimiento se vuelve complicado.

Sin embargo esta investigación establece un mecánismo, mediante el uso de conside­

raciones físicas y estableciendo ecuaciones de estado las cuales son como lo muestran las

relaciones2. 9, 2.10 , 2.11 y 2.12

:1: = V(t)cos(O(t)) (2.9)

y= V(t)súi(0(t)) (2.10)

0 = K(t)V(t) (2.11)

K = a(t)/L (2.12)

Siendo los valores no mencionados anteriormente el referente a V para la velocidad li­

neal, o la velocidad angular, t para el tiempo y L para la base de la llanta.

2.2 Simulación de tráfico 33

Estableciendo estos y algunos otros parametros se realizó la ejecución en robots propie­

tarios de la empresa Toyota, procesando diferentes tipos de ruta y obstáculos en el camino

del robot, lo que mostró como resultado un tiempo rápido, usualmente menor a los 40ms que

permite un huen acoplamiento con un control en tiempo real.

Otro de los trabajos realizados en este mismo sentido [20] incorpora la verificación del

resultado de los movimientos que realizan los robots dentro de la búsqueda del camino libre

de obstáculos o de manera más eficiente.

Dicho trabajo establece los movimientos del robot de forma suave, ya que se pretende

que cada uno de los robots que realiza su labor dentro de un entorno común y corriente

deberá asegurar que sus movimientos sean lo menos bruscos posibles, esto con el propósito

de no generar un impacto negativo en la vida de las personas, ya que de no ser así puede

implicar un riesgo potencial para su medio ambiente.

Así mismo la mayoría de los trabajos de investigación contemplan el movimiento de los

robots como automóviles, siendo agentes que buscan llegar a su meta, sin importar el costo

generado a través de cada uno de los pasos que el robot realiza en cada ciclo, sin embargo en

[20] se estudian los costos asociados a una meta.

Mediante el algoritmo A* implementado en la citada publicación se busca obtener el me­

nor costo de las soluciones posibles, sin embargo, para el caso de dicho algoritmo usualmente

el movimiento suave, explicado como uno de los ejes de esta investigación no es encontrado

en un algoritmo A* que no contemple algún tipo de modificación, por lo que al interior del

artículo se exploran posibilidades de lograr un movimiento suave y continuo utilizando A*.

Lo importante para lograr el resultado esperado, de acuerdo al trabajo establecido por

Yumiko en 2006, es incorporar movimientos pequeños, en cada paso de la simulación, que

nos da la ventaja de contar con un movimiento más suave, sin embargo esto no es pósible

con el algoritmo clásico A*, para lo cual se utiliza el algoritmo A* dinámico que establece

sus vectores de forma más suave, ya que son combinaciones de líneas rectas.

Para buscar dentro de la rejilla bidimensional de celdas, es necesario establecer un arbol

2.2 Simulación de tráfico 34

de búsqueda estático con un inicio y una meta, a través del cual se obtendrán los datos que

nos permitirán escoger una rama a ser explorada detalladamente.

Como puntos básicos de movimiento o conjunto de direcciones de manejo, de acuerdo al

nombre que le da la publicación, se toman los movimientos de comportamiento como "linea

recta o continuar derecho", "dar vuelta a la derecha", "dar vuelta a la izquierda". Con estos

tres elementos se construye un arbol de busqueda.

Posteriormente se construyen curvas utilizando curvas spline, que se refiere a las curvas

que tienen interpolación o que se pueden ver como una curva continua, pero que en realidad

cuenta con porciones polinómic3s unidas entre si, un ejemplo común de estas curvas son

las curvas de Bezier que se puede visualizar en la figura 2.15 obtenida de 2, las cuales

mediante un punto origen y destino se conectan estas dos coordenadas y de acuerdo a puntos

de control, se diagrama la curva de bezier .

midpoint 3 l midpoint 4

ending point

/ context point

Figura 2.15: Curva de Bezier

Se tienen diferentes rejas de celdas que establecen los valores a utilizar durante la eje­

cución, las cuales se manejan en dos dimensiones, una de las rejillas guarda los costos para

cada una de las celdas y la se utiliza como bandera de verificación con el propósito de ubi­

car para finalizar la búsqueda de ramas a través de la misma celda o de una anterior rama y

así ubicar la ruta completa.

Se realiza una búsqueda por medio de las celdas, para obtener la ruta desde el inicio

2http://www.html5canvastutorials.com/tutorials/html5-canvas-bezier-curvcs/

2.2 Simulación de tráfico 35

hasta el final, ya que dentro de las celdas se va marcando la que la precede, su celda padre u

origen, así mismo se realiza distancia euclidiana para el cálculo heurístico de la meta, y de

acuerdo a una lista se van obteniendo los candidatos a escoger para continuar con el conjunto

de direcciones y el planeador escoge el costo mínimo, así como el siguiente nodo de la lista.

Como parte de los resultados el artículo publica que se realizaron cambios en la longi­

tud de la línea recta hacia donde se mueve el robot al realizar las mediciones, las primeras

mediciones se daban con la unidad y posteriormente finalizaban con una magnitud de 11,

obteniendo que el tiempo se incremente al tener mayores magnitudes de líneas que indican

movimiento hacia adelante.

También se pudo obtener que el cambio en los angulas no cambia en gran medida el

tiempo obtenido de respuesta. Al final se pudo observar que se encontró en más ocasiones

el camino más corto con lineas más cortas de movimientos y con angulas más pequeños de

conjunto de direcciones, en la siguiente figura se puede observar la imagen de la combinación

de diferentes ramos con sus angulas, así como longitudes de líneas de movimiento recto.

1 /,

\~\!if,11";'---,., 11 I 1 1 ]

,- : !i 1 1 .. - J._,_ -

Figura 2.16: Diferentes ramificaciones con longitudes y angulas variados

En cuanto a la automatización, se ha buscado cada vez más y más que las herramientas

tecnológicas con las que cuenta la población sean utilizadas en apoyo al movimiento de las

personas y a la interacción que tienen en todo sentido con la necesidad de trasladarse, ya sea

en vehículos particulares o vehículos de transporte público.

2.2 Simulación de tráfico

Los dispositivos como los Sistemas de posicionamiento global "GPS" por sus siglas en

inglés, permiten realizar el seguimiento o "tracking" de los vehículos a través de las redes de

tránsito, inclusive crear herramientas de visualización de tráfico en tiempo real.

Otros de los dispositivos que se pueden tomar como dispositivos de entrada de datos,

pueden ser sensores, los cuales nos permiten conocer el nivel de congestionamiento de las

vialidades, y mandarlo a centrales de control de tráfico, que a su vez publica los resultados

para que el público en general conozca el estado del tráfico y conocer los puntos de conflicto.

El conocer los datos que arrojan las mismas vialidades en tiempo real es de suma impor­

tancia, ya que permite inclusive modificar patrones de control de tráfico, inclusive como se

menciono en el marco teórico el manejo de semáforos dinámicamente por medio de ingreso

de datos que permitan diversificar los tiempos de la luz roja y verde en las intersecciones,

ayuda en gran medida a que la densidad de automóviles pueda fluir de mejor forma dentro

del entorno de la cuidad.

Inclusive algunas investigaciones como [21 J exploran la capacidad de ingresar datos por

medio de smartphones, ya que mencionan que es complicado para todas las agencias de

transito dentro de las urbes poder contar con dispositivos como sensores a ciertas distancias

o inclusive dispositivos de seguimiento en cada uno de los vehículos de transporte público.

Indican que el seguimiento de los autobuses de transporte o de trenes subterráneos ha

sido ampliamiente aceptado por los usuarios de estos servicios, ya que les permite conocer

en tiempo real, con una gran certeza el periodo que tendrán que esperar al siguiente autobús,

o el tiempo promedio del ciclo completo de cada uno de los elementos que intervienen dentro

del proceso.

Sin embargo, como se menciona no todas las agencias han podido incorporar elementos

de seguimiento o monitoreo, derivado a falta de recursos ya que implica un gasto que no

todas las agencias pueden absorber, a pesar de esto, la investigación de [2 l J, establece un

nuevo paradigma, en el que los usuarios que ingresan a una aplicación por medio de su

smartphone, e ingresan a un autobús, cooperan con el sistema completo a modo de sensores.

2.2 Simulación de tráfico 37

Los smartphone particulares envían los datos al sistema con el propósito de ser proce­

sados, ya que uno de los puntos imprescindibles de los agentes móviles es su bajo nivel de

procesamiento comparado con una computadora personal, un servidor y en conjunto con una

base de datos, por lo que los datos son enviados al servidor central, el cual analiza todos los

datos ingresados y entrega los resultados de predicción de llegadas.

El procedimiento busca en gran medida o en su totalidad ser completamente automático,

por lo que se enfrentarán a diversos retos, como el hecho de buscar la forma de conocer

cuando un usuario realmente subió a un autobús, un taxi o simplemente se encuentra cami­

nando, con el apoyo del GPS y de diversos algoritmos se puede conocer los datos necesarios

para el sistema y poder contribuir al seguimiento del transpo1te sin necesidad de contar con

una gran cantidad de recursos.

En la figura 2.17 podemos ver el diagrama del sistema de seguimiento de llegadas,

utilizando los smartphone como ingreso de datos.

local transit tracking software on smartphone ,- - - - - - - - - - - - - - - - - - - - - - - - - - l

spalio-temporal rnatching

transit schedules

underground transit

tracking

\ 1

1+---------''. GPS \ 1

enable

vehicle iclentity anci locatio11

activity classifier

privacy lilter

proxy vehicle GPS trace

-------------------------J

central server ,---------------1

official transit schedules

arrival predictions

Figura 2.17: Sistema de seguimiento de llegadas de autobuses, utilizando smartphones

La comunicación intervehicular también puede darse por medio de redes inhalámbricas

que permitan a los automóviles intercambiar datos que puedan ser útiles en el movimiento

2.2 Simulación de tráfico 38

de los mismos, así como de los conductores.

Como lo muestra [22], la comunicación entre automóviles puede permitir un mayor ma­

nejo del tráfico, esta comunicación se centra en comunicación inhalámbrica que permite tres

aspectos en concreto para los vehículos dentro del tráfico:

• a) Seguimiento dentro del tráfico

• b) Información por anticipado para el trayecto

• c) Sistemas de asistencia de manejo o conducción

Contrastando con los algoritmos de verificación con alguna central, estas redes de vehícu­

los denominadas VANETs "Vehicular ad hoc Networks" no necesitan de un procesamiento

o nodo central de comunicación ya que se centran en el intercambio de información entre

automóviles, mediante protócolos ya establecidos y utilizando dispositivos específicos insta­

lados en los vehículos, sin necesidad de una infraestrúctura pública.

Sin embargo existen algunas reestricciones que deben ser consideradas por la mayoría

de algoritmos que pretendan utilizar una VANET, tal como el porcentaje de los vehículos

que cuentan con dispositivos que permitan esta comunicación que es en promedio debajo del

1 O% en países desarrollados, así como el pequeño rango de comunicación o espacio para

intercambio de información. Estas redes VANET se encuentran ampliamente investigadas en

la actualidad ya que se piensa que pueden ayudar en gran medida el desarrollo de cuestiones

de tráfico.

De acuerdo al algoritmo publicado el trabajo antes mencionado no es necesario contar

con un gran número de dispositivos para lograr una buena comunicación, ya que se cuentan

con dos estrategias básicas de intercambio de información vehicular:

• a) Salto Longitudinal.

• b) Salto Transversal.

2.2 Simulación de tráfico 39

En el primer tipo de estrategia el salto longitudinal se refiere al intercambio de infor­

mación que se da en el mismo carril, poniendo un ejemplo, encontramos a un automóvil en

un cruce y cuenta con un dispositivo de comunicación que le permita intercambio de datos

mediante una VANET, este automóvil envía información relevante a los automóviles que se

encuentran dentro del misma vía o camino! y en la misma dirección, el mensaje deberaá ser

envíado a algunos cruces anteriores con el propósito de ser útil y anticipar circunstancias.

Lo que sucede es que el vehículo envía la información al siguiente vehículo que se en­

cuentra en el rango de vista del mismo y así suscesivamente hasta que llega a su destino al­

gunas intersecciones antes, sin embargo, este tipo de comunicación se encuentra superditado

a siempre encontrar un vehículo que pueda retransmitir el mensaje a uno anterior y así hasta

llegar al destino, y dentro de este proceso se puede obtener perdida, ya que la dinámica en

el tráfico es muy variable y como se comento anteriormente es muy bajo el porcentaje de

vehículos que cuentan con los dispositivos de comunicación apropiados.

La segunda estrategia que es en donde se enfoca más la investigación habla sobre el salto

transversal, que ocupa el otro sentido, es decir los vehículos que vienen en dirección contraria

al vehículo que prelende enviar el mensaje, para lo cual el vehículo en el otro sentido guarda

la información y la replica hasta que encuentra un destinatario en el sentido del vehículo que

envío el mensaje con el fin de que sea útil.

Cada una de estas estrategias cuentan con ventajas e inconvenientes. Una de las prin­

cipales desventajas para el salto longitudinal se encuentra en que el mensaje puede fallatar

cuando la distancia entre equipos es mayor o llegar y resultar obsoleta cuando el destinatario

final la pueda leer, sin embargo esta problemática se resuelve con el salto transversal, ya que

es cuestión de tal vez un tiempo más corto por que se utiliza la propia dinámica del vehículo

que lleva el mensaje, sin embargo cuenta con dos reestricciones principales, la primera cues­

tión se refiere a un punto técnico, ya que como se explico anteriormente el rango de amplitud

de la comunicación de las VANET es limitado, por lo que derivado de la velocidad de los

automóviles no se puede concretar el mensaje. La segunda restricción se refiere al posible

2.2 Simulación de tráfico 40

cambio de ruta o trayectoria que puede tener el vehículo mediante el salto transversal.

Enfocandose en el salto transversal, ya que son menores sus saltos de información y la

probabilidad de finalizar la transmisión es mayor, se consideran tres etapas principales:

1. Una vez que el mensaje es generado por un vehículo equipado, el mensaje es reenviado

continuamente por este vehículo por un cierto tiempo, hasta que se encuentra con otro

vehículo equipado en el carril opuesto en un intervalo de tiempo.

2. El mensaje es enviado desde el vehículo origen por un salto transversal al vehículo del

carril contrario en un tiempo 2.

3. Finalmente el mensaje es guardado por el vehículo del carril opuesto y envíado a un

vehículo equipado del mismo carril que el primer remitente, y replicado por los au­

tomóviles del mismo carril hasta que se considere obsoleto.

De acuerdo a lo anterior se obtienen tres tiempos que pueden ser consideradas como

variables estocásticas derivado de las dinámicas de los vehículos. Finalmente el módelo

analítico del trabajo se centra en una autopista o camino bidireccional con cuatro carriles

por sentido y manteniendo ciertas velocidades y densidades de comunicación. En la figura

2.18 se encuentran los resultados de los análisis matemáticos resultantes de los brincos que

se dan en la intercomunicación.

Dentro de la automatización del movimiento de automóviles existen estudios que investi­

gan la forma en la que un automóvil sigue a otro, durante una ruta que mantiene el líder y se

asume que existe otro vehículo detrás que mantiene la misma ruta con algunas restricciones.

Tal es el caso de [23], el cual explora la posibilidad de un automóvil que sigue a otro

en su trayectoria, lo cual permite conocer en mayor medida la dinámica del movimiento de

los automóviles bajo ciertas circunstancias y no solamente en línea recta, sino también en

movimientos de vueltas laterales.

2.2 Simulación de tráfico 41

Figura 2.18: Estadísticas de resultados del estudio del salto transversal, en la comunicación entre vehículos, utilizando VANETs

Se obtienen datos a través del vehículo considerando su trayectoria, así como la posición

en la que se encuentran y con una velocidad determinada, dentro de la investigación se estu­

dian los movimientos en línea recta del vehículo líder, así como las curvas que pueden ser las

más complicadas en un seguimiento de vehículo ya que no es tan fácil mantener la seguridad

del vehículo trasero en una ruta con vueltas.

Un ejemplo es el hecho de tratar de seguir el movimiento, tal cual lo establece el vehículo

de adelante, sin considerar el momento en el que lo hace, ya que puede provocar en una

colisión con algún obstáculo, por lo que más alla de esto, se pretende realizar seguimientos

de ruta, y no tanto de movimientos, con el fin de evitar las colisiones con elementos fijos y

con movimiento del entorno.

En la investigación mencionada es imprescindible que los sensores sean exactos en gran

medida y con un controlador que procese las variables de entrada de forma veloz, ya que de

no contar con un sensor lo suficientemente confiable, los datos de entrada generados para su

proceso provocaran un error en la salida de los datos y al final en la simulación, así como el

controlador debe realizar los cálculos de forma rapida, sino la respuesta del vehículo trasero

sera tardía y no sera útil.

Los sensores son dos cámaras que se instalaron en el frente del vehículo trasero y con

2.2 Simulación de tráfico 42

reconocimiento de patrones, pueden ubicar al vehículo delantero. Es importante también

considerar distancias de seguridad y no establecer el movimiento de los vehículos uno tras

otro, ya que sería más complicado el seguimiento del vehículo, como inseguro, para lo cual

se publica el algoritmo CUT (Control Using Trajectory) propio de la investigación.

Con las variables de entrada x,z que se obtienen del automóvil líder que se utilizarán para

el control lateral, y denotando ciertas reglas de control y angulo se procesan los datos.

Finalmente para los resultados de la simulación se ocuparon vialidades europeas, que

tienen las características de contener el peor escenario y los grados más complicados de

giros, cada uno de los automóviles mantienen una velocidad constante de I O m/s y una

distancia de 25 metros constante durante la simulación, para los girlos se ocupa el Modelo

Ackennan[24 ], el cual como la figura 2.19 muestra, se manejan los giros de las llantas

dependiento del control y la relación que tienen las llantas delanteras con las traseras .

.. ' ' ..

' ' ' •

, ,. , , , ,

Figura 2.19: Modelo Ackerman

En la figura 2.20 se observan los resultados obtenidos del seguimiento de un vehículo a

otro por medio de este algoritmo.

De acuerdo a lo comentado en el marco teórico de multitudes, es imprescindible definir el

alcance del simulador a explorar, derivado a los recursos necesarios para cada tipo de ejecu­

ción y la forma en la que se abordará la definición del problema, sus alcances, las diferentes

variables que se incorporaran al mismo y finalmente los resultados que podrá entregar.

2.2 Simulación de tráfico

0.5

-05

100 150 für,olr-lrill'f'IQSj80m3j

2!:,0

Figura 2.20: Resultados del algoritmo CUT

43

Ya que si es necesario estudiar solamente una intersección o crucero, será necesario so­

lamente enfocarnos en el punto de vista microscópico, y poder visualizar la interacción que

tendrán los vehículos, con los otros vehículos que componen dicho crucero o simplemente

con el semaforo que este controlando la intersección, por lo que será indispensable solamente

enfocarse en sus interrelaciones de estos elémentos y no de toda la ciudad o urbe.

Existe la posibilidad de que se pretenda estudiar el movimiento del tráfico como un

fenómeno social que puede ser visto desde la forma más general posible y visualizar los

resultados del módelo de forma global y con resultados matemáticos

Jason en 2011 [25], propone, un simulador que pueda ser un simulador híbrido entre

estos dos tipos de enfoques, el cual estudia los dos tipos de simulación y su interrelación,

inclusive permitiendo que existan puntos de encuentro entre los dos enfoques y establecer

un sistema más fluido de interface entre los mismos.

En este trabajo se toman en cuenta datos de tráfico real, así como datos probabilísticos

de movimiento que puedan darse. Menciona en el mismo que los simuladores han ido evolu­

cionando de forma drástica, empezando por diversos enfoques incorporados en 1992, hasta

lo visto con el videojuego Grand Thef Auto.

Sin embargo una constante siempre se ha mantenido en todos estos trabajos y se trata

de la demanda de computo o procesamiento a gran escala que exigen estos simuladores,

2.2 Simulación de tráfico 44

por la gran cantidad de variables que inciden en los mismos, ya sea desde el punto de vista

macroscópico o microscópico en ocasiones los recursos de simulación deben ser muy bien

administrados, ya que enfocándonos en el punto de vista macroscópico, utilizamos ecuacio­

nes diferenciales parciales, y del otro lado, con un enfoque microscópico, las simulaciones

son basadas en agentes los cuales generan un movimiento de acuerdo a ciertas reglas.

Dicho trabajo propone un esquema de simulación el cual en rendimiento y fidelidad, se

mantiene en buenos parametros, el simulador toma en cuenta grandes bloques de ciudades

y su estudio se puede centrar de forma macroscópica, sin embargo, es posible realizar un

acercamiento y poder visualizar la ejecución de forma focal izada y en un plano en específico.

Dentro del simulador se obtienen los parámetros de diversos criterios, ya que busca acer­

carse lo más posible al mundo real, por lo que la definición tanto de las redes de caminos

como de agentes permiten establecer una amplia gama de posibilidades para incluir dentro de

la ejecución, ya que dependiendo de estos ingresos de datos, la simulación tendrá resultados

diferentes, un ejemplo de esto son los caminos que pueden definirse entre otros criterios co­

mo caminos rurales y urbanos, ya que parámetros como la velocidad del vehículo, así como

la incidencia de accidentes es variada.

La simulación pretende en gran medida ser eficiente ya que utiliza los recursos de compu­

to de forma ordenada y realizando un simulador que permita entregar los resultados y no

simplemente ejecutarse y permanecer mucho tiempo hasta poder encontrar un resultado, de

la misma forma no se pei:judica a la flexibilidad del modelo, tal y corno se comentó en el

párrafo anterior involucra diversas cuestiones a través del mismo.

El componente clave dentro de la simulación es tratar de acoplar dos diferentes tipos de

enfoques, como se comento, el enfoque micro y macroscópico, ya que se realiza de forma

continua, en donde uno se centra en la velocidad y posición explicita de cada vehículo y el

otro en una densidad que se tiene por tramo, es decir por un bloque más grande, para lo cual

se necesitan de interfaces en donde se puedan acoplar los dos tipos de simulación.

Para lo anterior es importante que los límites o fronteras se encuentren muy bien definido,

2.2 Simulación de tráfico 45

así como las condiciones iniciales de los vehículos, y se controlarán de forma muy concreta

el acoplamiento de los vehículos en las dos simulaciones.

Con el proposito de lograr una simulación continua cada carril se divide en celdas que

representan el tráfico y se toma en cuenta el módelo Aw-Rascle-Zhang, que explicado por

[26] es un sistema de ecuaciones que contiene modelos con doble fase de transición y que

mantiene la forma hiperbólica enunciada en las ecuaciones 2.13 y 2. 14

Pt + (y - p'+ 1)x = O (2.13)

Yt + (y2/p- yp')x = O (2.14)

En estas ecuaciones 2.13 y 2.14 se establece el modelo como una función que mide la

densidad de los automóviles en tiempo mayor o igual a cero y de acuerdo a su posición

x, se obtiene que la velocidad promedio de los automóviles enn donde --:1 mayor a 1 dicha

velocidad será una constante.

Para el caso de la simulación basada en agentes, se utiliza un método discreto basado en

el modelo car-following, en donde cada velocidad y aceleración de un vehículo se encuentra

delimitada por el movimiento del coche de enfrente, así mismo se determina el cambio de

carril en un vehículo de acuerdo a diferentes variables de seguridad y criterios de manejo,

entre diversos tipos de conducción de las personas.

Finalmente se obtiene un buen acercamiento al rendimiento que se tiene en el mundo

real, y el simulador establece los dos tipos de simulación de acuerdo a su objetivo principal,

y de acuerdo a lo mostrado en la figura 2.21 se obtienen velocidades 9-17 veces más rapidas

incorporando un enfoque macroscópico a un enfoque basado en agentes, estos resultados se

encuentran obtenidos en el CPU, mediante un dispositivo lntel Core i7 980x, que corre a

3.33Ghz

Otro simulador [27] , habla sobre la parelelización en el tiempo de ejecución del mo-

2.2 Simulación de tráfico 46

Figura 2.21: Resultados del simulador híbrido en enfoques macroscópicos y microscópicos

delado de tráfico, para lo cual realiza un análisis de los datos de! mundo real, utilizando el

modelo de Nagel/Shcreckenberg, el cual en un principio solamente contemplaba un carril del

camino, sin embargo en investigaciones posteriores se extendio el uso para más de un solo

carril. Además en tiempos de computo el enfoque a realizar es más rapido que explorar las

capacidades del mundo físico, ya que se realiza de forma discreta en el tiempo y el espacio.

Se utilizan grafos de datos para representar la red a través de los procesos, sin embargo

esto conlleva que un gran overhead o acoplamiento entre cada uno de los procesadores sea

necesario. Para lo cual se ha tratado de paralelizar los procesadores teniendo un menor costo

de sincronización entre ellos, sin embargo se ha tenido que partir el tiempo de simulación

entre los procesadores y despues un costo de sincronización entre los mismos, probando

como una alternativa de solución máquinas de estado finito que nos permitan controlar cada

uno de los pasos.

De acuerdo al modelo de Nagel/Scherenberg, se obtiene un automata celular que depende

de un conjunto de celdas que cambian su estado conforme a la simulación, para lo cual cada

una de las celdas, de acuerdo a estudios realizados deberán ser de un tamaño promedio de

7.5 metros, con el propósito de que los automóviles puedan ocupar este espacio, haciendo la

analogía con el tama ño promedio real de un automóvil.

2.2 Simulación de tráfico 47

Para lo anterior cada uno de los vehículos toma 4 reglas simples de movimiento dentro

del simulador:

• Aceleración. Va acoplada a la velocidad, ya que si un vehículo no ha alcanzado su

velocidad máxima, se incrementará la aceleración de acuerdo a un valor especificado.

• Frenado o descenso de la velocidad. Se refiere al punto en el que un vehículo pretende

dejar de moverse, por lo que realiza una desaceleración.

• Aleatorización. Se ingresa una variable que permite realizar un aumento/disminución

de la velocidad de forma aleatoria, ya que en muchas ocasiones el comportamiento de

los vehículos no es fijo, por lo que al ingresar una variable aleatoria nos permite tener

una variación del movimiento vehicular más real.

• Movimiento del vehículo. El movimiento que se deberá generar a través de las celdas,

ya que siempre deberá el vehículo estar contenido dentro de alguna celda en cada

momento de la ejecución.

A pesar de sus reglas básicas el modelo de Nagel/Schreckenberg exhibe de forma ca­

si idéntica, lo que se da en el mundo real, ya que se forman congestionamientos con alta

densidad de vehículos y el movimiento entre celdas no ocupadas, se realiza en multiples

vehículos. Para el caso de este simulador cada uno de los nodos procesa el estado por cada

paso de ejecución y así mismo se procesa cada uno de los nodos separadamente, sin embargo

al procesarlos por diferentes procesadores se tiene un problema de acoplamiento.

Este problema de acoplamiento se encuentra dado por la división de tiempo que se ha

mencionado, y no siempre se acopla el tiempo de la simulación global, con el tiempo que

tiene cada uno de los nodos procesados. Otra desventaja es que al tener datos por separado

es necesario guardar una gran cantidad de datos de cada uno de los estados, por cada uno de

los procesos, durante toda la simulación.

2.2 Simulación de tráfico 48

Para lo cual cada procesador realiza una ejecución en un tiempo predeterminado y de

acuerdo a su acoplamiento ocupa tiempo de ejecución del proximo proceso, el cual a su

vez, entra en una fase extendida del anterior, mediante el cual el nuevo proceso genera las

condiciones iniciales en un proceso parecido a la preparación de la ejecución más ardua.

Cada proceso se encarga de calcular el resultante por cada intervalo de tiempo, para lo

cual será necesario realizar una armonización de los tiempos, ya que no todos los procesos

se ejecutan al mismo tiempo, aún más acentuado para procesos que conlleven más tiempo

de lo normal, derivado de su complejidad, para lo cual se tendrá un error, el cual deberá ser

cuidado para no invalidar la prueba, cuando el error sea mayor a los datos estableciendo

limites máximos de error.

Para la ejecución paralela de la simulación basados en el módelo Nagel/Schreckenberg

es necesaria la comunicación entre cada uno de los pasos de la simulación obteniendo un

gran overhead, provocando un retraso, el cual se puede acentuar con los problemas entre la

red de comunicaciones de los procesadores.

Sin embargo de acuerdo a lo mencionado por la investigación dicho simulador puede

mejorarse con el uso de medios más rápidos de comunicación, por ejemplo, incluyendo pro­

cesadores de 64 bits, así como redes de tipo Myrinet. Dichas redes, ser refieren a sistemas

de red local desarrollados por la empresa Myricom que utilizan redes locales de alta velo­

cidad , con el fin de interconectar diversas máquinas y poder lograr un cluster de n número

de máquinas.Las figuras 2.22 y 2.23 hacen referencia en primera instancia a clásicas co­

nexiones o topologías de conexion de este tipo y un cluster, tomado como fuente de AMD

l28].

Sin embargo la simulación se desarrolla en procesadores de 32 bits.

Realmente el único estado que se conoce bien, sería el estado O, ya que los demás se

irán moviendo de acuerdo a la ejecución simúltanea de sus elementos, y realizando los aco­

plamientos necesarios y al realizarse de forma paralela, se deberan verificar inclusive si se

tienen dos estados de simulación idénticos, ya que el enfoque original de este tipo de ejecu-

2.2 Simulación de tráfico

Mod hnst

Nerwork

~edport

~ Network as 1napped

Figura 2.22: Ejemplos de topologías de redes Myrinet

WorkslMion

1 1 1

1 1 1 1 1 1 1 1

Comµuh:1 Compute Compulfl Nui.JM Nmltt Nodff

MS·MPI lntorconnflc1

Figura 2.23: Cluster de computadoras en red Myrinet

ción requiere de un acoplamiento exacto de los estados asociados.

49

Como conclusión se obtienen varias gráficas que nos permiten medir el nivel de desvia­

ción o cambio, tal y como lo muestra la figura 2.24.

Como un elemento que se estudia en este artículo se menciona el uso de redes y así uti­

lizar lo más que se pueda de recursos informáticos al alcance de un simulador de tráfico. Tal

es el caso del simulador desarrollado por la universidad de Shangai en China [29], el cual

explora el uso de la red y la interconexión entre servidores para poder simular el tráfico y

entregar una plataforma que genere datos de salida de forma dinámica.

2.2 Simulación de tráfico

(/)

0.8 e o cii ·5 a, 0.6 "O

o e o 0.4 -~ ~ o 0.2 ü

o o

.. ·······-···········=·· -------~~~~=

500 1000 Simulation time

1500 2000

Figura 2.24: Correlación entre el estado y la densidad local, de acuerdo a un tiempo específico

50

Este simulador explora las capacidades del cómputo y realiza una organización exhaus­

tiva de los elementos que puedan coordinarse de mejor forma de tal suerte que proporcionen

una plataforma robusta de simulación de tráfico.

Para esto contempla una serie de procesos o requisitos indispensables a los que este

simulador de tráfico conceptualiza y se enfrenta:

1. Demanda de muchos datos. Casi la mayoría de las simulaciones siempre se realiza de

forma local, ya que el poder de computo, así como de información requiere el uso de

un gran número de datos.

2. Requiere de estilos de simulación flexibles. Derivado a que las entidades de tráfico

usualmente contemplan elementos complejos de simular, el módelo debera contemplar

aspectos flexibles de la simulación.

3. Coordinación. Se requiere de la coordinación entre sub-sistemas que ya se tienen y

que se puedan comunicar entre si, con el fin de no generar un gasto innecesario de

algo que ya se tiene, tal vez no en la forma en la que se busca, pero debera encontrarse

la manera de acoplar los diferentes subsistemas

2.2 Simulación de tráfico 51

4. Estandarización. El estandarizar es necesario ya que al interior de la plataforma se

tendrá una gran cantidad de sub-sistemas ejecutandose al mismo tiempo, el intercam­

bio de información deberá darse en lenguajes que los diferentes actores puedan enten­

der.

5. Dinámica tolerante a fallas. Motivado a que el transito de los vehículos no puede espe­

rar, es necesario que una falla en el sistema no provoque congestiones o acumulaciones

de vehículos innecesarias, sino que se minimice en la medida de lo posible el impacto

de una falla en la plataforma.

La tecnología de Grid, trata de resolver el uso de los datos y la coordinación dinámica

de los mismos a través de internet. Otro concepto utilizado es el de High Leve) Architecture

(HLA) o arquitectura de alto nivel que se refiere a una simulación como su nombre lo indica

de alto estandar que se basa en la estandarización y reuso de componentes que ya existen en

el entorno en el cual se desarrollará la simulación.

Para lo cual se cuenta con elementos que funcionan por separado que mediante el uso

de HLA y Grid se obtiene un esqueleto o infraestructura de información a ser explotada, sin

embargo el procedimiento de intercambio de información, como se realizará el recorrido del

flujo de datos, no existe.

En este sentido el trabajo enunciado establece el uso de HLA y la tecnología existente de

agentes para construir la plataforma de simulación y de acuerdo al Grid se pueda obtener el

soporte basado en entidades.

El trabajo contempla diferentes arquitecturas y procedimientos de desarrollo. El primer

tipo de división es la arquitectura de simulación por medio de tres capas principales:

l. Capa superior. Es la capa que tendrá contacto con el usuario y que todos los sub­

sistemas que corren al interior del simulador deberán ser invisibles para esta capa,

solamente serán necesarios para la entrega o ingreso de información con el usuario.

2.2 Simulación de tráfico 52

2. Capa intermedia. Es la capa que consiste en una red de programas y aplicaciones in­

termedias a modo de comunicación.

3. Capa inferior. Se trata de la capa de los recursos que proporcionara los elementos

que permitan el procesamiento, cómputo, así como el guardado de información, la

plataforma propia de inteligencia de los agentes, y algunos elementos más propios del

tráfico como es el caso de predicciones a futuro sobre el tráfico.

En la figura 2.25 se esquematiza el uso de capas para la construcción del grid.

Traffíc simulation grid application

Disastcr Crowd Disp~'t"sing Simulation

Urgcnt Trnffic Cr,mmanding Simulation

Traffic Flow Optima! Distrihution Simulation

Traffic Signa! Time Optimal Dislrihution Simulation

HLA Scrvicc(RTI scrvicc) Simulation

Application Grid

Mi<ldlcwarc

Fecleration Dcclaration Ohject \Ianagcmcnt I\fonagcmcnt I\fanagcmcnt

\Vork Flow Scrvicc

Owncrship Time Data Dislrihution Managemcnt \fanagctn,~nt Man.lgcment

. . . . . . . . .. . .

•••

•••

lnfonnation Resource Securitv ·'

Transaction

Grid

Middlewarc

Simulation Grid

Resource

Scrvicc

Job Managcment

Computmg Rcsource

Agcnt Platform

lvlanagemcnt Mmagement Management

Data Coordina te Managcment lvfanagcmcnt •••

,ltor~gc

'Rcsourcc Trnl 1c l ln1ty

Moclcl Data base Fe i:rnlc Am 1assa or

Modd DaLJbasc

Tra 1c Fnity Gcncmtor

•••

Figura 2.25: Esquema de un simulador basado en capas

El procedimiento desarrollado por este simulador consta de los siguientes pasos:

1. Definir el objetivo. Al ser un grid que contendra diferentes subsistemas que serán desa-

2.2 Simulación de tráfico 53

rrollados por diferentes programadores, es necesario enfocar un objetivo en común

para toda la federación de elementos.

2. Conceptualizar. Es necesario establecer un modelo conceptual de la federación con el

fin de que todos conozcan el diagrama gene:ral y las interacciones entre los subsiste­

mas.

3. Definir búsquedas. Es importante que los desarrolladores produzcan búsquedas acoor­

de al diagrama general del simulador

4. Desarrollo de la federación. La cual debera ser de forma coordinada en la red y acoorde

a la especificación de la base de datos del modelo.

5. Integración y pruebas.Se integra la totalidad de los componentes y se desarrolla un

plan de pruebas, y se ejecuta de acuerdo a valores de entrega y resultados.

6. Ejecución y resultados. Se obtiene la federación ya en ejecución y los resultados de la

puesta en marcha.

Se obtienen procesos de sincronización de tiempos y se implementan elementos como

diversos servidores IBM, así como protocolos de intercambio de información, incluyendo

FTP, para lo cual se muestra en la figura 2.25 el resultado final de la implementación del

simulador y como dato final solamente explican que la arquitectura ha sido desarrollada

completamente y los resultados de simulación cumplen o son suficientes a las demandas de

simulación de tráfico.

Otro elemento que ha sido estudiado en gran medida, dentro de toda la ingeniería vial

y que afecta a la mayoría de las grandes cuidades es el como los semáforos se incorporan

dentro de las intersecciones, con el fin de lograr un buen equilibrio entre fluidez, seguridad

y control vehicular.

De esta forma [30] simula el uso de señales de transito o en concreto semaforos mediante

los vehículos que funcionan como estas señales.

2.2 Simulación de tráfico

( 1

Grid Environment

scnd

/-Í~;ffi:;---,\ ~ \,~m.it-; A!!env' :1

---·--·~·---·---~--....

I• Agent · · ·• Ü¡,1Jera lor . .

Qucry computmg ~~irci;: informotion

ltanium Smcr ...___

-------Qn~ry computing ·-----.1 ·o ~

rcs.ou:_~1~~~!9-rJ...----~ 1. • \\,>\ID.,

~1-----ft- - ' ra IC /-· l ;,

fu . y , ,. ~ Qui;:rv and nclton . tan1um M ~r : íCl!ISl~I

/'v ,-~ ~~ ,--v Y-1

compL~ing foOlHC

ltílniumSel'\fr

Figura 2.26: Entorno físico y conceptual de la simulación de tráfico

54

De acuerdo a lo explicado anteriormente este simulador hace uso de las VANETs y los

vehículos se utilizan para controlar el tráfico sin necesidad de infraestructura física en las in­

tersecciones, para lo cual los vehículos funcionan a modo de controladores, como se explica

a continuación.

El costo estimado para un incorrecto manejo del tráfico, ya representa para la unión

europea el 1 % del costo total de los servicios, para lo cual usualmente las soluciones se

pueden dar mediante tres estrategias:

1. Reducir el número total de vehículos que circulan por los caminos.

2. Aumentar la infraestructura actual de caminos.

2.2 Simulación de tráfico 55

3. Aumentar el flujo de vehículos con la infraestructura ya existente.

Las dos primeras alternativas representan un costo mayor, ya que en la primera implica un

cambio de cultura organizacional, así como el acercm más las fuentes de trabajo, transporte

público, entre otras. Para el caso de la segunda alternativa implica una inversión de gasto

capital que no siempre es posible realizar, en algunos casos se justifica completamente el

realizar nuevas obras, sin embargo, en algunos otros casos es un gasto que debe evitarse en

gran medida.

Por lo que la tercera opción resulta imprescindible desarrollarla por razones económicas,

y en este caso en concreto el uso de VANETs resulta importante y relevente. Ya que el mis­

mo hecho de implementar la infraestructura correspondiente para un semáforo, puede ir en

costo de los 50 mil dolares hasta 200 mil, para el caso de algunos dispositivos más sofisti­

cados, por lo que el hecho de controlar semáforos con todas las intersecciones generaría un

costo exorbitante de dinero, para dotar tan solo en Estados Unidos de semáforos en todas las

intersacciones costaría 33 billones de dolares.

Dentro de toda urbe se encuentran interseciones que son cruciales para el flujo de vehícu­

los de la ciudad, por lo que la investigación se centra en ellas, en la mayoría de los cruceros

más conflicitovs se encuentran inclusive semáforos que se controlan de forma dinámica, y

son el campo de acción para este trabajo de investigación, con el proposito de que sean los

vehículos que funcionen como semáforos que puedan controlar el desarrollo de una intersec­

ción por medio del display de los vehículos involucrados, los cuales funcionarán por medio

de protócolos ya defnidos VANET.

Ha sido probado en múltiples ocasiones que los semáforos pueden ayudar a la fluidez de

una ciudad, o pueden inclusive retrasar el flujo, ya que la mayoría de los semáforos(alrededor

del 70-90 % ) internacionalmente son fijos, es posible que los vehículos a menudo tengan que

esperar tiempo innecesario en cruceros que mantienen la luz roja, más alla del tiempo viable

de la intersección, en algunas ciudades inclusive de paises desarrollados se ha optado por

2.2 Simulación de tráfico 56

utilizar semáforos que tienen un rango de tiempo que se parametriza de acuerdo al flujo de

vehículos.

La optimización de los semáforos en la intersección ha provocado el desarrollo del con­

trol urbano de tráfico UTC, el cual ha sido foco de investigación de los últimos 40 años y

algunos de los principales criterios de control han sido los siguientes:

1. Duración del ciclo en su totalidad, es decir, el total del tiempo que pasa la luz en verde

para todas las direcciones en ese crucero en específico

2. Lapzo de luz verde. El tiempo por cada dirección en concreto que se tiene para la luz

verde

3. Orden de secuencia. La secuencia mediante la cual se controlarán las posibles rutas en

la intersección.

4. El último parámetro de control que no es en todas las intersecciones se denomina offset

para semáforos que se encuentran interconectados entre cruceros de la misma región

Se tienen algunos rabajos ya realizados como el SCATS 3 y el SCOOT 4, los cuales

controlan el tráfico en su mayoría por detectores, ubicados en cada intersección y así conocer

el tamaño de cola y poder establecer los tiempos maximos y minimos de duración de sus

semáforos.

Otra forma de controlar las intersecciones se puede realizar mediante nodos que se co­

muniquen con los vehículos que pasen por el cruce y tomar los automóviles como sensores

moviles.

Sin embargo este enfoque establece una serie de reglas que permitirían ejecutarse con

exito el algoritmo, una de las cuales se refiere a los sistemas de comunicación que deberán

tener los automóviles, ya que se asume que cada uno de los vehículos tendrán instalados sis­

temas de posicionamiento, así como dispositivos de sensores y comunicación con los demás

3Sydncy Coordinated Adaptivc Traffic systcm 4Split Cyclc and Offset Optimization Techniquc

2.3 Cómputo en paralelo 57

automóviles. Es importante la anterior regla ya que los semáforos serán establecidos por la

comunicación que exista entre los vehículos.

En las intersecciones se elegirá un líder que de acuerdo a las condiciones actuales de

tráfico en la intersección establecerá un tiempo de espera y realizará la función de semáforo

en rojo, por lo que comunicará a los demás vehículos en los displays hacia el conductor que

es necesario detenerse, así mismo durante toda la fase se controlara el envío de mensajes a

los demás automóviles, hasta que se decida obtener una luz verde y poder continuar con el

camino, hasta que ei siguiente vehículo más cercano al centro del crucero, de acuerdo a las

condiciones establezca el rol de líder y emprenda las acciones ya explicadas.

Finalmente dentro de los resultados se implementaron en el simulador DIVERT, especial­

mente en la ciudad de Porto en Portugal, obteniendo los resultados que se pueden observar

en la figura 2.27

Expeolét.l benetil when compared lo l6°""o TL in Porlo ,oo~--~----~-~

80

40

20 .. ,/ ....

120 251 ~ •Medlum-1ow1 'lilediurn-tugh1 11-iigll.>

Vehiole clcnsity '.ve~ttrA

Figura 2.27: Beneficios por utilizar el algoritmo "Vehicle Traffic Light" en la ciudad de Porto, Portugal

2.3. CÓMPUTO EN PARALELO

Existen acercamientos que proponen el uso del poder de cómputo en paralelo con el

proposito de poder procesar un gran número de agentes y sus interacciones con los agentes

2.3 Cómputo en paralelo 58

restantes, así como evitar colisiones y procesamiento de datos, variables de entorno, entre

otras.

El principal objetivo de este tipo de cómputo es realizar una implementación lo más

eficiente posible en el acceso a los datos y la forma de procesarlos de forma paralela, en la

que una misma acción se pueda ejecutar a! mismo tiempo por diferentes hilos o nucleos, los

cuales tendrán que contar con una forma de administrarse y poder correr simultaneamente

sin contratiempos o errores.

Se puede implementar un cómputo en paralelo para simulación de tráfico de diferentes

formas, una de las más comunes es realizarlo con computadoras conectadas por medio de una

red o inclusive con super computadoras las cuales nos permiten un poder de procesamiento

que permite incluir diversas variables y modelar comportamientos en los movimientos so­

ciales incluyendo los de multitudes de personas o como es el caso de nuestra investigación

sobre tráfico.

2.3.1. GPU

Otro enfoque de cómputo en paralelo utiliza las taijetas gráficas como método de pro­

cesamiento, en un principio solamente se ocupaban en un principio solamente se ocupaba

de tareas relacionadas a las operaciones de visualización, sin embargo la Unidad de Proce­

samiento Gráfica (GPU) ha permitido el involucramiento de las tm:jetas en operaciones que

anteriormente podian ser ejecutadas solamente por el CPU.

Actualmente el poder de procesamiento en comparación entre el CPU y el GPU se puede

visualizar en las figuras 2.28 y 2.29, existe una diferencia de casí l O veces mayor rapidez y

mayor ancho de banda en el comparativo realizado con estos dos dispositivos [3 l].

Esta diferencia en el poder de procesamiento tiene diferentes razones, de las más impor­

tantes se encuentra el hecho de que los CPU's son dispositivos de uso general, es decir, que

al interior de una PC estos se encargan de realizar tareas de procesamiento de casi cualquier

tarea, por lo que no se especializa en cierto tipo de ejecuciones, lo que el GPU si maneja un

2.3 Cómputo en paralelo

·rhe-oretkaJ úB/,-

2.00

180

160

140

120

100

80

60

-CPU

GPU

Figura 2.28: Diferenciación en el ancho de banda entre CPU y GPU

enfoque a tareas de operaciones de punto flotante, muy comunes en el área de gráficos.

Theoretical GFLOP/s 1500

1000

TSO

500

250

o

~lnt,rl CPU Smcle- PrOC.ISlOO lnt-e-t CPU Ooubte PrKl'SIOn

S,e,p-01 Pcnh~~l Jun...C.. Od-05

=·~·*.#·~, H arJN'""OWn

M.ar-07 Jul-08 Dec-09

Figura 2.29: Diferencia de velocidad en Gflops entre CPU y GPU

59

Otro de los puntos que explican el poder mayor de procesamiento que tienen los GPU's

comparados con los CPU's se debe a la arquitectura física y lógica con la que se encuentran

diseñados y ensamblados, tal y como podemos ver en la figura 2.30 se pueden observar

dichas diferencias, siendo la más notable la organización con respecto al espacio destinado a

la Unidad Lógico Aritmética.

Este poder de procesamiento se puede ocupar para realizar operaciones paralelizables,

las cuales nos permitan un mejor desempeño en el rendimiento que se utilizará para el movi-

2.3 Cómputo en paralelo 60

LJ

CPU GPU

Figura 2.30: Arquitécturas CPU y GPU

miento de multitudes grandes o enormes, tal y como se menciona en las secciones anteriores,

el modelado de multitudes de gran tamaño conlleva una demanda de recursos importante, y

ya que nuestro objetivo es simular gráficamente un módelo de tráfico de vehículos.

Se han generado pocos trabajos que exploren la capacidad del GPU en la simulación del

tráfico, tal es el caso de f32], en este trabajo se explota el alto procesamiento y rendimiento

que manejan las tarjetas gráficas con el proposito de establecer un simulador que puede

manejar grandes multitudes de tráfico.

Utiliza el GPU para simular millones de nodos y enlaces que simulan el comportamiento

de millones de vehículos a través de movimiento de vehículos, los cuales siguen caminos

predefinidos y especificas que deben ser respetados, es decir, no se contempla el movimiento

sin restricciones, sino que todo el proceso de movimiento de vehículos re realiza a través de

estructuras de cola para los enlaces de automóviles.

Utilizan la metología de la formulación o enfoque del problema a través de paradigmas

basados en campos, tales como los relacionados con algunos otros dominios científicos, co­

mo los campos electro-magnéticos, sin embargo la metodología publicada por este trabajo

de investigación agrega aspectos de detalles de comportamiento no lineal.

Se utilizan como en los campos magnéticos vectores que contienen la dirección y la

2.3 Cómputo en paralelo 61

magnitud o intensidad del movimiento para cada nodo. Los valores de las entidades dentro

de la simulación son codificados para un menor uso del acceso de memoria, y para este

trabajo en específico se lograron resultados para más de 2 millones de nodos de la red y 20

millones de vehículos representados procesados con el GPU y dando una velocidad mayor

de la manejada hasta ese momento en otros simuladores.

El modelo de mobilidad contiene tres componentes.

• Rutina global de elección de giros o saltos a través del recorrido

• Modelo de mobilidad para representar los vehículos

• Modelo de estructura de tila o cola que nos permite manejar los estancamientos o

congestiones vehiculares

La forma en la que se realiza la división de los componentes en el área de la simulación es

realizado por medio de rejillas que contienen a su vez celdas, cada una de las cuales pueden

ser de tipo horizontal o vertical, y que permiten un arreglo de rejilla de dos dimensiones y

como su nombre lo especifica las rejillas horizontales solamente permiten el movimiento de

dirección solo de forma horizontal, y lo mismo pasa con las verticales.

Se establece un vector de probabilidades el cual se define de la siguiente forma:

(2.15)

Dicho vector guarda la probabilidad de vuelta a la izquierda, derecha, continuar hacia

adelante y realizar una vuelta en U.

Para el movimiento de los vehículos se representan dos fases: la fase de división y de

unión. En la primera fase se tienen dos contadores para el caso del movimiento horizon­

tal(derecha, izquierda) y para el vertical(arriba, abajo), los cuales nos permiten definir me­

diante números flotantes el número de vehículos que ocupan cada celda y mediante esta

2.3 Cómputo en paralelo 62

fase de división se genera en cada la celda la fracción del vehículo actual que se movera

posiblemente a cada uno de los 4 destinos probables.

En la siguiente fase de unión se cuentan los coches entrantes a la celda y se suman a

los actuales. Para el caso del procesamiento de la cola o tila, se modela en terminas de

la acumulación de coches por celda y en cuanto se detecta una saturación o congestión se

comienzan a mover los vehículos a los vecinos.

La figura 2.31 nos muestra de forma gráfica el acomodo de los enlaces considerando los

ingresos y tipos de movimiento que puede tener cada una de las celdas, ya sea horizontal

y vertical y la conexión entre los enlaces y los nodos, ya que dependienta el movimiento

realizado(izquierda, derecha, continuar de frente, vuelta en U) se puede acceder a otro tipo

de celda.

Por ejemplo en la primera celda que se encuentra en la esquina superior izquierda la

acción tomada por el vehículo es continuar hacia adelante o movimiento recto(straight), lo

que provoca que se encuentre en otra celda vertical, ya que su movimiento próximo podrá ser

hacia arriba o hacia abajo.

(-2. 0 ) (-2.~1)

1 --- :e: t-- s 1~.1

Figura 2.31: Dependencias de ingreso para enlaces verticales

Para el alojamiento de los datos requeridos para la simulación utilizan texturas, en la

cual cada una de sus elementos se denominan texels. Para el procesamiento de los caminos

2.3 Cómputo en paralelo 63

se utilizan anchos predefinidos del camino y se calcula el maximo número de automóviles

que pueden dejar una celda, de acuerdo a las siguientes igualdades:

J\,1 ax1s = 1\1 axúrwsulúlaporsemaf oral = velocidcullúnde*rnerlúlaopasocletiem.po/ largodelvehiculo

(2.16)

!ii ru: = AJ ci:r1 s * conteodevehú:uloactiwl * largoclelvehiculo * largodcl.<;egm,ento (2.17)

Estas dos igualdades nos permiten determinar e inclusive modificar o variar la velocidad

de evacuación dependiendo o acorde al tamaño del modelo, permitiendo mayor flexibilidad

y fidelidad al modelo.

Dentro de la red vehicular cada uno de los nodos representan las intersecciones y los bor­

des o uniones de esos nodos, se refieren a los segmentos de camino que se tienen entre estas

intersecciones, para lo cual se contempla dentro del modelo los datos en latitud y longitud

que son convertidos a valores positivos en x,y de la red de simulación.

Como resultados del trabajo se tiene la simulación se visualizan las variables de salida

como colores en los puntos de congestionamiento y de tráfico vehicular, en la tabla 2.1

se puede observar los resultados del rendimiento y procesamiento con distintas ciudades de

Estados Unidos que contienen números variables de nodos, enlaces y los tiempos en los

que se realiza la ejecución, así como el tiempo de evacuación y los recursos utilizados en

términos de las texturas ocupadas.

2.3.2. CUDA

Hasta hace algunos años programar el GPU para realizar tareas de procesamiento se tor­

naba un poco complicado, ya que era necesario utilizar rigurosamente lenguaje ensamblador,

2.3 Cómputo en paralelo 64

Cuadro 2.1: Rendimiento en redes vehiculares de caminos en Estados Unidos Estado Nodos Enlaces Textura Tiempo de evac(Hr.) Tiempo de ejecución (Segs)

DC 9,559 14,884 1048576 35.20 54.90 LA 413,574 988,458 4194304 65.07 409.591 TN 583,484 1,335,586 3211264 157.91 353.89 FL 1,048,506 2,629,268 4194304 179.20 611.83 Tx 2,073,870 5,116,492 3211264 217.60 777.65

lo que dificultaba en gran medida el aprendizaje y manejo de rutinas complicadas o que ne­

cesitaran algoritmos complicados de procesamiento.

Posteriormente tres nuevos lenguajes se desarrollaron en especifico para poder acceder

al GPU, los dos primeros proveniente del estandar OpenGL : el OpenGL Shading Language

(GLSL) , así como el creado por NVIDIA "C for graphics" Cg y el vinculado a DirectX de

Microsoft llamado "High Leve) Shading Language" desarrollado en conjunto con NVIDIA.

Finalmente para las tarjetas gráficas de NVIDIA se publicó el Compute Unified Device

Architecture (Arquitectura de Dispositivos de Cómputo Unificado) por sus siglas usualmente

llamado CUDA, el cual utiliza una variación del lenguaje C y que nos permite especificar el

acceso a memoria de hilos(threads), así como bloques de los mismos y poder utilizarlos para

ejecutar nucleos denominados kernels en CUDA de forma paralela.

En la figura 2.32 se observa el procesamiento de la ejecución paralela por medio del

cómputo con CUDA.

De acuerdo a [33), cada vez es mayormente usado el GPU para desarrollo de cómputo

en general, ya que la forma en la que se paraleliza la ejcución de los datos, es el cómputo del

futuro, mientras más grandes sean los recursos necesitados para el computo, de mejor forma

se justifica el uso de GPU para su ejecución.

Sin embargo existen ciertas reestricciones ya que el cómputo en paralelo, en su inicio

fue concebido para el uso dentro de ambientes gráficos y a pesar de que el desarrollo de la

programación en el GPU se ha venido actualizando con el paso del tiempo, la concepción

enfocada al pintado de objetos, en algunos casos se conserva, el cómputo en paralelo se

2.3 Cómputo en paralelo 65

Figura 2.32: Procesamiento en el CPU y GPU a través de CUDA

ejecuta con éxito en las siguientes tipos de aplicaciones:

• Los requerimientos de cómputo son grandes, ya que el rendering requiere millones de

pixeles por segundo y cada uno de ellos cientos de operaciones, con el proposito de

atender la demanda de recursos de aplicaciones en tiempo real.

• Aplicaciones en las que el paralelismo es indispensable, ya que para el pipeline de

grálicos, el paralelismo se acopla de buena forma

• Aplicaciones en las que el rendimiento es más importante que la latencia. Ya que el

GPU tiene prioridad en el rendimiento más que en la velocidad, ya que el GPU fun­

ciona en nanosegundos y los sistemas visuales de los humanos operan en los milise­

gundos, por lo que la diferencia es imperceptible, ya que el avance en el rendimiento

compensa este tipo de retraso o latencia.

De acuerdo a lo anterior el cómputo en el GPU para apliaciones de propósito general

ha tenido un gran crecimiento, ya que una vez exploradas las capacidades de procesamiento

y rendimiento que puede obtenerse de una tarjeta grática, ha provocado que se hayan reali­

zado una extensa cantidad de algoritmos y procesos que antes se realizaban en cómputo en

paralelo, tal vez en diferentes máquinas, en servidores o inclusive en el CPU.

2.3 Cómputo en paralelo 66

Esto ha tenido varias razones, sin embargo entre las más importantes podemos encontrar

que aunque el GPU siempre ha tenido el poder de cómputo que se puede observar en este

momento, la programación en la tarjeta gráfica nunca se había aperturado en la forma en la

que se tiene ahora.

De acuerdo al pipeline gráfico se tienen diferentes procesos dentro del desarrollo gráfico

ordenados de operaciones menores a mayores de acuerdo a los siguiente:

• Operaciones en los vértices. Que se refiere al hecho de que cada vértice debe ser trans­

formado en la pantalla y típicamente transformado por las luces que interactúan sobre

él.

• Montaje de primitivas. Cada uno de los vértices se montan en triangulos, los cuales

son esenciales para el hardware, ya que es la forma en la que trabaja la tarjeta gráfica.

• Rasterización. Proceso, mediante el cual se determina que espacio en la pantalla de­

berá ser ocupado por determinados triangulos de los gráficos

• Operaciones en Fragmentos. Se usa información sobre el color asociado a los vértices,

incluyendo algunos datos adicionales provenientes ppara formar las texturas y cada

fragmento se sombrea para determinar su color final.

• Composición. Todos los fragmentos son montados en una imagen final con un color

por pixel, usualmente manteniendo el fragmento más cercano a la cámara para cada

ubicación del pixel.

El proceso anterior se puede visualizar diagramado por NVIDIA para mayor referencia

en la figura 2.33

La diferencia fundamente! entre este proceso de ejecución y el utilizado por el CPU es

principalmente en que el CPU divide las actividades de la cola de actividades de una en una y

utiliza la mayoría de sus recursos para ejecutar esa actividad y completarla, mientras tante el

GPU realiza las actividades indicadas en paralelo, tratando de tener un mayor rendimiento.

2.3 Cómputo en paralelo

System Memory !

CPU

Video M.emory

Geometry J----ii----+-

Cornmands - '' - l • )'fi;s;U..h ;_ W)l

1

On- Chip Cache. Memory

1 Rasterization

Fragment Shading

' and Raster Operations

Figura 2.33: Proceso de pipeline gráfico

67

Así mismo el CPU ocupa aproximadamente 20 ciclos desde que un proceso o tarea entra

en la cola del pipeline y la deja, finalizando su ejecución, al contrario del GPU que ocupa

miles de ciclos para finalizar la actividad, y lo que provoca que la latencia de la actividad sea

grande.

El modelo de programación del GPU mantiene una dinámica denominada SPMD que

por sus siglas en ingles significa Single Program Mulltiple Data, lo que provoca que el GPU

procese varios elementos(vértices o fragmentos de vértices) en paralelo utilizando el mismo

programa.

Algo importante es que se pueden ocupar datos de la memoria compartida con una ope­

ración de lectura llamada "gather" e inclusive en algunos GPUs escribir en locaciones arbi­

trarias de la misma memoria global compaitida por medio de la instrucción "scatter".

La lógica de la programación en el GPU debe estar estructurado de tal forma que utilice

el paradigma orientado a datos, ya que aunque es posible estructurar el código, usualmente

el programar en GPU con ramificiaciones incoherentes puede provocar procesos de acceso

incorrectos.

Existen tres corrientes dentro de la programación en el GPU, de acuerdo a la evolución

que se ha dado en este campo:

2.3 Cómputo en paralelo 68

• Programar en el GPU para gráficos

• Programar en el GPU para propósito general de la primera forma.

• Programar en el GPU para propósito general de la forma más reciente.

De las tres categorías, en la que se centra esta investigación ocupa cuestiones inherentes

a todas las categorías, ya que la simulación se establece dentro de un entorno gráfico (pri­

mera categoría), utilizando shaders para programar, mediante Frame Buffer Objects y Vertex

Buffer Objects (Segunda categoría) y finalmente estableciendo parámetros de ejecución me­

diante CUDA, realizando una programación estructurada en los datos (tercera categoría).

Hablando de esta última categoría podemos comentar que los kernels en CUDA son

flexibles, en mejor manera que los primeros intentos de programar en el GPU tales como

el Open GL Shading Language (GLSL), y permitiendo mayor variedad de tipos de datos,

inclusive programando en forma casi idéntica a C.

Los cuatro vocablos principales dentro de la programación en CUDA son "scatter-gatter","map",

"reduce" y "sean". Las operaciones de scatter-gatter son utilizadas para leer, escribir de una

localidad de memoria específica, map nos sirve para aplicar una operación global para todos

los elementos de una lista o una colección como se haria en un ciclo dentro del CPU, pero

con acceso más rapido ya que se tiene bien establecida la cantidad de datos y sus localidadas

y así aplicar más rápidamente la instrucción.

El tipo de operación reduce, contempla operaciones para conjuntos de elemento, como

por ejemplo sumar 8 elementos de una textura y dejar el resultado en otra textura que tenga

el resultado de tamaño cuatro u ocho veces menor. El comando Sean que nos permite tomar

un arreglo de elementos y homogeneizarlo o reducirlo en otro arreglo, con una reducción

que sea necesario aplicarle.

En este sentido l34J proporciona un nuevo enfoque de procesamiento de tráfico, ponien­

do como eje principal la ejecución de forma paralela mediante CUDA, estableciendo dos

métodos principales completamente paralelizables mediante la inclusión de un enlace único

2.3 Cómputo en paralelo 69

explorando una función de acceso atómica propia de CUDA. En la figura 2.34 se observa

una de las formas en la que se guardan los datos de administración de nodos.

Array of admin shucts

Admin Data Strnct

Start Pos End

• • • Index o 1 n

s p E s p E m • • • • • • • • •

Veh Veh Veh Veh Empty Empty

Array of all vehicle data

Figura 2.34: Ejemplo de arreglo de administración de nodos

Estos dos metodos principales moveNode y moveLink se ejecutan de forma paralela

para cada uno de los agentes, utilizando buffers que se compottan como nodos, los cuales se

administran en forma de bloque por el programa principal, una vez que se realizó la ejecución

sin optimización se buscaron nuevas formas de administrar los nodos.

El aitículo explora diferentes paradigmas, algunos de los cuales son sugeridos por el

equipo de desarrollo de CUDA, tales como Ring Buffers los cuales son arreglos o listas

circulares con bloques definidos y que no contienen inicio ni fin, sino que el último elemento

se comunica con el primer elemento de la lista por lo que no se tendrán elementos nulos

dentro del arreglo, este cambio permitió un crecimiento del 300 % en la aceleración de la

simulación, tal y como se visualiza en la figura 2.35

2.3 Cómputo en paralelo

§­R l t-"""7".;,,.,---------- ---------; ,,..

i 1 O+----~--~------~--~~

o 20 40 60 iO iOO

Pcpulitkm p<rctnt,1(1:

AOSNODES --S'.>ANODES

-+- R!NGNODES

- .RINGNOOF-"i.2

J_¡\',I

J Figura 2.35: Comparación de aceleración entre los diversos paradigmas utilizados

70

3. DESARROLLO Y SIMULACIÓN

3.1. ESPECIFICACIONES GENERALES

El enfoque para la simulación es visto desde un punto de vista microscópico, ya que se

centra en la forma en la que los agentes se moverán dentro del entorno víal, no incoporando

ecuaciones macroscópicas a nivel general, sino simplemente visualizando el movimiento a

nivel particular y para cierto tipo de entornos, tales como algunas calles o cruceros. Ya que lo

que se busca es poder encontrar una forma en la que los vehículos se puedan mover utilizando

el poder del cómputo en el GPU.

El desarrollo propuesto busca utilizar el poder de procesamiento paralelizable en gran

medida del GPU, conforme a esto la construcción del simulador estará enfocado a la parte

del procesamiento que se desarrolle en el GPU y utilizando el CPU para la carga de datos,

parámetros, etc.

Se busca que mediante el desarrollo el simulador pueda ejecutar cientos o inclusive miles

de agentes simultáneamente que se procesen por medio de la tarjeta gráfica, permitiendo la

71

3. J Especificaciones generales 72

visualización del comportamiento de los automóviles de una forma que permita obtener un

rendimiento de procesamiento que se realice por arriba de los 30 cuadros por segundo.

El desarrollo del simulador se basa en lo especificado en los trabajos [11], [32] y [10],

incorporando el ingreso de datos pararelizable en forma de archivos, incluyendo los agentes,

edificios, entre otros, así mismo incluyendo los datos manejados por OpenGL y la generación

de movimiento a través de CUDA y el pre-procesamiento de datos, tratando en gran medida

no sobre cargar la ejecución del simulador y realizarla lo más ágil posible.

Se realiza el desarrollo de acuerdo a diversas etapas que se pueden visualizar en la figura

3.1

+ • t

Figura 3.1: Esquema del simulador de tráfico

En el simulador se especifican diversas etapas que se complementan para construir la

simulación de tráfico, en primera instancia ingresamos los datos en diferentes tipos de archi­

vo, posteriormente se realiza el procesamiento de los datos y se realiza el dibujado de los

mismos, generando el movimiento con el procesador gráfico.

Se ha trabajado en un engine gráfico que se desarrollo durante el transcurso del posgrado

en la cual se han incorporado diversas herramientas gráficas que se explicarán a lo largo de

3.2 Variables de entrada 73

este capítulo.

3.2. VARIABLES DE ENTRADA

La simulación necesita de variables propias del modelo a utilizar, ya que su uso no es

particular de una situación sino que la simulación permite ser parametrizada de acuerdo a lo

que el usuario desee ingresar.

Estas variables son las que usualmente vemos en la vida real y en el tráfico común y

que nos permitirán tener una interacción más concreta con el usuario poder desarrollar una

simulación que corresponda a diversas necesidades propias de cada situación, por lo que

este simulador no se realizará de forma lineal con los mismos criterios de entrada, sino que

será alimentado tal y como se muestra en la sección anterior por archivos.

Estos archivos permiten una gran flexibilidad en la definición de parámetros y datos a

utilizar dentro de un sistema.

Dentro de nuestro primer tipo de archivo se encuentra Extensible Markup Language

(XML), el cual es leído usualmente por un parser, y se obtienen los datos que contiene el

archivo XML y que se realiza por medio de etiquetas, el esquema de forma general se mues­

tra en la figura 3.2, cada una de las etiquetas guardan parametros al interior de ellas, siendo

que por si mismas las etiquetas nos especifican el tipo de valor que se espera al interior de

las etiquetas, estos mismos datos podrán ser de forma recursiva, como se muestra en la figu­

ra enunciada se pueden agrupar datos, hasta el nivel que se requiera dentro del sistema que

utilizará.

Este tipo de archivos nos permitirán definir los datos y variables globales que se utilizarán

durante toda la simulación, tales como agentes, los edificios de las ciudades, entre otros

valores que se requeriran al interior de la ejecución del modelo.

Otro tipo de archivos a utilizar serán los archivos separados por comas (CSV), los cuales

se han elegido de tal forma que nos permita definir de forma más ágil valores de coordenadas,

3.2 Variables de entrada 74

/\ Parameter Para meter

Figura 3.2: Esquema de archivo XML

para lo cual los valores de datos se pueden ingresar ya sea numéricos o de cadenas, solamente

separados por comas entre dato y dato, siendo un archivo muy común en diversos sistemas

tanto como valores de ingreso o valores de salida.

De esta forma utilizando estos tipos de archivos y algunos propios que se especificarán

en el código nos permitirá tener una interacción con el mismo simulador.

3.2.1. AGENTES

Los primeros datos a ingresar son los relacionados a los automóviles, dentro del archivo

AgentsTraffic.xml se establecen diversos aspectos de los vehículos, tales como el tipo de

modelo que se pretende utilizar, número de agentes que utilizará el modelo, entre otros.

Uno de los aspectos más importantes y que definirá en gran medida el desarrollo de la

simulación y que es en sí misma la razón principal de ser de un simulador de tráfico son las

actividades que realizará cada uno de los agentes durante el día, es decir, las coordenadas

que el vehículo tomará como puntos de inicio y fin de sus movimientos y durante los cuales

el vehículo permanecerá en modo detenido, en la tabla 3.1 se puede observar la organización

del archivo tipo csv que es necesario incluir en la simulación.

Básicamente este archivo establece como parámetros: el agente, las posiciones x,y,z del

3.2 Variables de entrada 75

Cuadro 3.1: Formato de archivo csv Agente Pos x Pos y Pos z Actividad

l 50 o 25 Home 350 o 467 School 1850 o -525 Job 50 o 25 Home

2 1523 o 1600 Home 2 -52 o -15 Job 2 1523 o 1600 Home

vehículo y el identificador o nombre de la actividad, el simulador valida que la cantidad de

vehículos establecidos en el archivo .xml coincida con los mismos que se ingresan dentro del

archivo .csv.

Para definir si dentro del simulador se deberán tomar los valores del archivo CSV o no, se

encuentra definido dentro del archivo AgentsTraffic.xml, una variable "position" que puede

contar con dos valores posibles: "CSV" o "RANDOM". Si se especifica "CSV" el simulador

leera el archivo .csv establecido en la etiqueta del archivo xm. Existirán valores a utilizar

tales como el número de clones que se refiere al número de agentes a utilizar durante la

simulaciín, como paramctros propios de los agentes, realizando las siguientes validaciones,

con el proposito de cuidar la integridad de los datos dentro de la simulación:

• Verificación de la existencia del archivo csv

• El número de agentes leidos deberá ser igual al número de clones + 1, es decir, si

dentro del archivo se especifican que el agente, cuenta con 11 clones, el archivo csv,

deberá contar con las posiciones de al menos 12 agentes, de acuerdo a la especificación

descrita anteriormente.

• Cada agente deberá contar con al menos una actividad, aparte de su punto de inicio,

es decir, el punto de inicio se cuenta también como una actividad, al final cada agente

contará con la referencia mínimo a dos puntos, uno de inicio y uno de final dentro de

la simulación y poder obtener el movimiento del agente.

3.2 Variables de entrada 76

• Los valores especificados en las posiciones de actividades deberán ser valores numéri­

cos.

El fallo en alguna de las reglas descritas provocará el mostrar el error que fue encontrado,

así como se realizará la finalización de ia ejecución del simulador.

Si dentro del archivo xrnl se especifica "RANDOM" el simulador estahlecera posiciones

aleatorias para los vehículos en su inicio, y le asignará una actividad aleatoria, con el pro­

pasito de que todos los agentes creados cuenten con posiciones minimas de un origen y un

destino, tal y como en el caso de la elección del archivo csv.

El simulador ingresa los datos a una clase tipo AgentTraffic que hereda de la clase prin­

cipal Agent que es específica para movimiento de personas, los datos ingresados en el .csv

se toman para realizar una cola de actividades a realizar por los agentes, validando que la

primera así como la última actividad se denominen "home", independientemente de que no

coincida la posición x,y,z el simulador toma estas etiquetas como inicio y fin de actividades

de un determinado agente.

3.2.2. CAMINOS O RUTAS

Una vez que ya contamos con la definición de los automóviles, especificando sus activi­

dades, así corno el tipo de agente que contendrá al vehículo, en toda simulación de tráfico es

imprescindible establecer las reglas mediante las cuales los automóviles se podrán mover en

su entorno, para lo cual necesitamos conocer las rutas o caminos a tomar.

En este sentido se establece, de primera forma la lectura que se tendrá para el ingreso de

los datos, provenientes de alguna fuente, para lo cual se estableció la clase RoadParser, que

realiza la lectura del archivo Roads.xml, en donde se establece el ID del camino, así como el

archivo csv que contendrá los nodos a leer.

El archivo csv estará organizado como lo específica la tabla 3.2.

En el archivo csv de rutas en primera instancia se encuentra el id del nodo, el cual de-

3.2 Variables de entrada 77

Cuadro 3.2: Formato de archivo csv para el camino

Id nodo Pos x Pos y Pos z Sentido

o o 10 R 2 5 o 10 R 3 10 o 10 R ,

15 o JO R '+

5 20 o 10 R 6 25 o 10 R 7 30 o 10 R 8 o o 15 R 9 5 o 15 R 10 10 o 15 R 11 15 o 15 R 12 20 o 15 R 13 25 o 15 R 14 30 o 15 R

berá ir de forma numérica, de no ser así la carga del archivo provocará un error que se

muestra al usuario y finalizará el simulador, posteriormente los nodos se especifican por sus

posiciones x,y,z.

La tabla de rutas generaría un camino tal y como lo muestra la figura 3.3. Se puede

observar que las posiciones en coordenadas de los nodos, permiten la creación del camino,

gracias a la definición de los nodos, es importante que los nodos mantengan una congruencia

secuencial, ya que de no ser así los caminos por donde podrán moverse los automóviles

serán limitados e incorrectos, es decir, al definir el archivo csv que lee el parser de caminos,

se está creando las posibles rutas por las que los automóviles podrán trasladarse.

En el ejemplo del archivo se pueden observar dos carriles por donde los automóviles

podrán moverse, aun no se define el sentido de los automóviles, sin embargo, este primer

ejemplo nos permite visualizar el como crear una ruta o camino.

El último campo del archivo csv, permitirá saber en que sentido puede moverse el nodo,

es decir, en el camino se podrá mover de la siguiente forma:

• R. Nodo que pertenece al movimiento de izquierda hacia la derecha

3.2 Variables de entrada

40

35

30

25

20

151--------,-----

10

5 ,__ __ _

5 1 0 i5 20 25 30 35 40 45

Figura 3.3: Muestra de creación de un camino, por medio del archivo csv

• L. Nodo que pertenece al movimiento de derecha hacia izquierda

• U. Nodo que pertenece al movimiento de abajo hacia arriba

• D. Nodo que pertenece al movimiento de arriba hacia abajo

• W. Nodo que pertenece a un crucero y puede tener múltiples sentidos

• X. Nodo que pertenece a un crucero y puede tener múltiples sentidos

• Y. Nodo que pertenece a un crucero y puede tener múltiples sentidos

• Z. Nodo que pertenece a un crucero y puede tener múltiples sentidos

• T. Nodo que permite el ingreso de automóviles a la simulación

• S. Nodo que permite la salida de automóviles de la simulación

78

• RTR. Nodo que interconecta de un movimiento que se mueve hacia la derecha y da

vuelta a la derecha

• RTL. Nodo que interconecta de un movimiento que se mueve hacia la derecha y da

vuelta a la izquierda

3.2 Variables de entrada 79

• LTR. Nodo que interconecta de un movimiento que va hacia la izquierda y da vuelta a

la derecha

• LTL. Nodo que interconecta de un movimiento que va hacia la izquierda y da vuelta a

la izquierda

• UTR. Nodo que interconecta de un movimiento que va hacia arriba y da vuelta a la

derecha

• UTL. Nodo que interconecta de un movimiento que va hacia arriba y da vuelta a la

izquierda

• DTL. Nodo que interconecta de un movimiento que va hacia abajo y da vuelta a la

izquierda

• DTR. Nodo que interconecta de un movimiento que va hacia abajo y da vuelta a la

derecha

Para mayor referencia se puede observar de forma gráfica en la figura 3.4.

R

UTR

U D

J RTL RTR UTL

LTR LTL

Figura 3.4: Tipos de direcciones en los nodos

3.2 Variables de entrada 80

3.2.3. EDIFICIOS

Las rutas predefinidas podrán tener a sus lados edificios que podrán rodear a los caminos

definidos, estos edificios se definirán mediante un archivo xml, el cual tendrá dentro de sus

definiciones el número de bloques o manzanas.

Con estos datos el simulador realizara una instancia de edificios divididos de acuerdo al

tamaño de la manzana y la orientación de la manzana, establecida por las posiciones iniciales

y finales dentro del plano cartesiano a utilizar.

Es importante que se definan los bloques de edificios en diferentes espacios que los no­

dos, ya que de no ser así, se tendrán espacios en común y al ejecutar el modelo, se podrán

ver elementos que se translapan entre los vehículos y los edificios.

3.2.4. OTRAS VARIABLES

Se cuentan con varios cargadores de archivos XML para los diferentes elementos que se

utilizan dentro de la animación, independientes al cargador de tipos de agentes de tráfico, ya

explicado. Se encuentran divididos de acuerdo a la tabla 4.1

Archivo

agents.xml agentstraffic.xml audio.xml cameras.xml constans.xml lbos.xml glslshaders.xml menu.xml objects.xml skybox.xml vbos.xml ligths.xml

Cuadro 3.3: Archivos XML a cargar

Descripción

Definición para el AgentsParser original Para el cargador de agentes de tráfico Características de audio de la simulación Definición de camaras a utilizar Variables globales Definición de variables de carga de los Frame Buffer Object Características a utilizar por los shaders Interacción con el usuario Objetos diferentes de agentes que se dibujarán dentro de la simulación Variables para el pintado del skybox Definiciones para el uso de Vertex buffer Objects Definición de variables de carga de los puntos de iluminación

3.3 Procesamiento de Variables de entrada 81

3.3. PROCESAMIENTO DE VARIABLES DE ENTRADA

De acuerdo a lo cargado en las primeras fases de la simulación, ya sea mediante los

archivos .xml o .csv, ya explicados, se inicializan diversos elementos de la simulación, tales

como el audio, menu y algunos otros como los Vertex Buffer Object(VBO) y los Fragment

Buffer Object (FBO) que se explican a continuación.

Dentro de la ejecución de gráficos en el dispositivo se sigue una secuencia que va de lo

particular a lo general, es decir, se especifican los valores y las operaciones que tendrá la

ejecución gráfica, tal y como lo muestra la figura 3.5, en ella se puede observar las opera­

ciones que se realizan, siendo de las primeras instancias las operaciones relacionadas a los

vértices, tales como ensamblaje e incorporación en primitivas, pasando por diferentes opera­

ciones, hasta llegar a las operaciones en fragmentos, tales como texturas y coloración de los

fragmentos.

Vertices

Pixel Updates

Vertex Connectivity

· · Vertex T ransformatíon

Raster Operations

Transformed Vertices Primitive

===> Assembly and Rasterization

Colored Fragments

Fragments

Fragment · Texturing and

Co!oring .

Figura 3.5: Pipeline de ejecución en Open GL

Posteriormente se inicializan los caminos, por medio de un metodo initroads, a partir de

lo leído por el parser. Como primera fase se guardan todos los nodos con sus datos en una

3.3 Procesamiento de Variables de entrada 82

clase llamada Nade, la cual tiene como elementos: ID, posteriormente la posición del nodo

a cuatro posiciones, es decir, como vector de cuatro valores, estos cuatro valores se refieren

a las posiciones (:r,y,z) del nodo, leídos a través del archivo csv.

La última posición "w" se refiere a si el nodo se encuentra asignado u ocupado por algún

agente en ese momento, esto nos va a servir en el momento de asignar los agentes a los nodos

y posteriormente las validaciones que se realizarán durante la ejecución del simulador. Una

vez que se han leído los nodos, se guardan en una clase llamada Road que guardará los

objetos especificados como nodcs.

Dentro de las siguientes etapas se encuentra la inicialización de agentes, la cual toma co­

mo lectura el ingreso de los agentes leídos mediante la carga del xml, esto lo realiza mediante

una variable global definida en el programa principal denominada agents parserTraffic, esta

variable cuenta con toda la información leida y que servira para crear los agentes, cada uno

de los agentes guarda datos tales como el modelo MD2 especificado, el número de frames

de la animación, etcétera.

Cada uno de estos agentes que hereda de la clase principal agents, se llama agentsTraftic,

especializada para el procesamiento de agentes de tráfico y en ella se guarda en una variable

global que determina el modelo a utilizar en toda la animación, es importante mencionar que

no son modelos diferentes para cada uno de los agentes, ya que de acuerdo a una variable

"clones" leída mediante el archivo xml, se determina el número de agentes a utilizar duran­

te la simulación. Sin embargo estos agentes no tendrán modelos separados, sino por medio

de un VBO creado por cada uno de los frames de animación, mediante instancing se pinta­

ran dentro de la simulación, proceso de pintado que se explica más adelante en el presente

documento.

NVIDIA establece el Instancing de vértices como el uso de la tecnología de graficado

que emplean las tarjetas de video, con el proposito de dibujar una gran cantidad de objetos

que cuentan con las mismas características y que se repiten en todo el rendering.

De acuerdo con la lectura de las posiciones de los agentes, conforme a cada una de sus

3.3 Procesamiento de Variables de entrada

Verte• Stream Layout

lnrunce o: Verte, n

lnstance k: Verte• l

lnstance k: Vertex 2

Instante k: Vertex n

Verte11 Fo,mat

Positíon

Normal

Te.<tul'f Coordinates -----·-Jnst¡nce lndex

Figura 3.6: Buffer de vértices en Instancing

83

actividades, deberá ser validado con lo que contiene Road, ya que aunque un automóvil

tal vez inicie su ruta en un lugar específico dentro del mapa, es esencial poder ubicar el

automóvil dentro de algún camino, por lo que se realiza el siguiente algoritmo:

1. Ejecución de initAgents

2. Llamar a metodo de clase Road para asignación de nodo, enviando posiciones iniciales

de agentes

3. Dentro del metodo de asignación de nodo

a) Extraer todos los nodes del camino que sean de tipo T o nodo de ingreso a la

simulación

b) Verificar los nodos, con la posicion del agente

e) Encontrar el que tenga la menor distancia entre posAgent y posNode

d) Asignar el nodo al Agente y marcar el nodo en su posición w con 1.0 para denotar

ocupación

3.4 Vinculación de nodos para generar rutas 84

e) Regresar el valor de la posición al agente

4. Guardar la posición regresada en el agente.

5. Continuar ejecución.

De esta forma aseguramos que los automóviles siempre esten contenidos en un camino

de inicio, y que no comiencen en posiciones alejadas del camino, sino que se procurá asignar

un nodo lo más cercano posible a su primera actividad, que es básicamente lo que funciona

en la vida real, en donde los conductores buscan la vialidad más cercana para poder dirigirse

a cada una de sus actividades.

Aunque es posible que los automóviles, puedan en su momento circular fuera del ca­

mino si las condiciones físicas así se presentan, se asume dentro del presente trabajo de

investigación que es necesario que los automóviles se muevan de acuerdo a los caminos

predeterminados.

De esta misma forma, se hace una verificación de sus actividades de cada uno de los

agentes, y así como se ingresan los puntos de inicio en un nodo dentro del camino, de la

misma forma las actividades se acoplan al nodo más cercano, de acuerdo a la distancia de

sus cordenadas x,y, por lo que sabemos que iniciarán en un nodo preestablecido y finalizaran

de la misma forma dentro del camino.

3.4. VINCULACIÓN DE NODOS PARA GENERAR RUTAS

Una vez que se han definido los nodos, nos hace falta un elemento más que permita una

interconexión entre los nodos, cada uno de estos nodos necesitarán un vínculo entre ellos,

los cuales se procesarán una vez que se defina la regla de relación o vínculo entre nodos.

Necesitamos establecer una distancia mínima entre ellos, la cual nos permitirá saber si un

nodo tendra relación con algún otro. Tal y como ocurre en la vida real, un automóvil en

cierto tiempo puede moverse de un punto a otro, no necesariamente realiza un salto de un

3.4 Vinculación de nodos para generar rutas 85

punto a otro, sino que dentro del mundo real el vehículo viendolo desde el punto de vista de

un nodo, se mueve conforme la figura 3.7, en ella se puede ver los vínculos que tiene cada

uno de los nodos, para el caso del nodo con ID I se puede conectar mediante vínculo con los

nodos 8 y 2, y su vez el nodo con ID 2 tiene la capacidad de moverse al nodo 9 y 3.

Figura 3.7: Vinculas entre nodos

Sin embargo estos nodos, deberán contar con un elemento extra además de la distancia

entre ellos como criterio para poder establecer una relación entre los mismos, ya que no

en todos los caminos la distancia minima entre carriles y nodos se asume como un camino

continuo, que pasaría si el nodo número 8 tuviera un diferente sentido que el nodo número

1, no podría el automóvil moverse del nodo 1 al 8, lo que provocaría una colisión, aunque

sabemos que en la vida real las colisiones son susceptibles de ocurrir, y este es uno de los

casos, cuando un vehículo se incorpora a un carril en sentido contrario, sin embargo, la

presencia de choques en la simulación se tratará posteriormente.

Este inconveniente se puede ver graficamente en la figura 3.8.

Para resolver este problema, se han incorporado en la carga de los nodos, tal y como se

explica en la sección del ingreso de caminos o rutas , los nodos tienen un valor al final del

renglón que permite conocer el sentido estricto del automóvil, y se cuenta con diferentes

tipos, por ejemplo el movimiento hacia la derecha(R), izquierda(!), etc.

3.4 Vinculación de nodos para generar rntas 86

Figura 3.8: Vinculos entre nodos, considerando los sentidos

Existe un tipo adicional a los cuatro sentidos usuales de un automóvil y se refiere al nodo

de tipo crucero, ya que como sabemos en la vida real , los puntos que se encuentran en un

crucero permiten el movimjento en diferentes sentidos, controlados por algún tipo de señal ,

para lo cual estos nodos, de acuerdo a un tiempo predeterrrunado dentro de la simulación

pueden tener el sentido hacia la derecha, arriba, abajo, etcétera, todo dependerá de la forma

de su configuración y el tiempo destinado a acada uno de los mismos.

Se realiza un análisis como primer paso, con el propósito de definir cuales son los nodos

que pueden ser relacionados, cada uno de los nodos verifica de acuerdo a distanci a y al

parámetro del sentido, si algún otro nodo tiene relación con el mi smo, esta información se

guarda en un vector de de cuatro componentes, se asume que cada uno de los nodos puede

optar tres camjnos como máximo para continuar con su ruta.

Este vector de cuatro componentes, guarda en sus tres primeras posiciones, los datos de

los ID de los nodos que se relacionan con él, y al final como valor de control, que se usará en

el kernel y se explicará posteriormente, se tiene un valor último que guarda el número de

nodos con los que tiene relación el nodo actual.

Regresando al ejemplo de la figura 3.7, el nodo con ID 1 tiene dos opciones de mo­

vimiento, inclusive un nodo del caJTil central pudiera contar con tres nodos hacia donde

3.4 Vinculación de nodos para generar rutas 87

moverse. Este mismo caso sucede cuando el nodo se encuentra pegado a su lado derecho

circulando de izquierda a derecha y pretende dar vuelta a la derecha, las únicas tres opciones

son dar la vuelta e incorporarse a la circulación de arriba hacia abajo, la siguiente opción es

continuar por el carril por donde viene, y la última sería cambiar de carril, si es que existe

otro carril al cual incorporarse a su lado izquierdo.

Para el caso de las vueltas, de acuerdo a la definición de las mismas, una conexión entre

dos nodos podrá darse si la primera letra del tipo de nodo, corresponde con la primer letra

del tipo de nodo relacionado a la vuelta, es decir, para un nodo que vaya circulando de

arriba(UP), hacia abajo (DOWN), su tipo de nodo estará denotado por la letra D, y si dentro

de su rango existe un nodo que contenga la letra D al principio, como es el caso de DTL

(Down Turn Left), se trata de un nodo que viene de la circulación de arriba hacia abajo y que

pretende dar la vuelta a la derecha, por lo que es posible tener el vínculo o la conexión entre

estos dos nodos.

Esta forma de vincular los nodos, relacionandose de forma sencilla permite que el propio

simulador realice un análisis y creación de posibles rutas, la cual no se deberá calcular en

tiempo de ejecución, ya que los posibles caminos por los que un automóvil pueda moverse

ya se encuentran pre-procesados, y dentro del kernel de CUDA que se ejecuta dentro del

GPU, solamente será necesario realizar una búsqueda de máximo tres nodos, es decir no se

deberá consultar todo el camino en búsqueda de nodos libres para su uso.

Acorde a esto necesitaremos un mecanismo de control que nos indique en que nodo se

encuentra actualmente el agente, ya que como se ha explicado en el procesamiento de varia­

bles de entrada, los agentes al iniciar, así como cada una de sus actividades están regidas por

la definición de un nodo, ya que un automóvil para propósitos del simulador deberá iniciar

siempre en un punto preciso del camino y moverse de acuerdo al camino definido y finalizar

dentro de un nodo.

Dentro de dicha variable guardamos todos los agentes y el ID del nodo que los contiene,

dicha variable será utilizada al generar el movimiento en las siguientes etapas del simulador.

3.5 Generación de movimiento 88

3.5. GENERACIÓN DE MOVIMIENTO

A partir de los datos que se guardan en los agentes y rutas, posterior a la lectura de los

datos todos ellos obtenidos y procesados en el CPU, es necesario definir una forma en la que

puedan leerse y escribirse los datos en la memoria del GPU, para lo cual de acuerdo a la

figura 3.5, podemos observar que uno de los elementos que se generan como datos dentro

del pipeline del dispositivo gráfico son las texturas, las cuales nos servirán como camino

de comunicación entre la memoria del GPU y la memoria del CPU, definiendose texturas

de datos de vertices que seran utilizadas, tanto para las posiciones, las rotaciones de los

agentes, datos de posiciones de los nodos, ocupación e inclusive para guardar los datos de

las velocidades.

Una textura para OpenGL usualmente se compone en cada uno de sus pixeles, en con­

creto para las texturas se llaman texels que se refieren a los componentes de color que serán

aplicados como textura de los objetos en el rendering.

Los texels que componen las texturas guardan los cuatro elementos de color de la unidad,

y se forma de RGBA, que hacen referencia a los colores rojo, verde, azul y el componente

de transparencia asociado a un color, en nuestro simulador se utiliza esta posibilidad que

se tiene gráficamente de guardar las posiciones en las texturas y adicionalmente se guardan

algunos otros elementos, como es el caso de los destinos.

En la figura 3.9 se puede observar como se llenan los datos correspondientes a las posi­

ciones de los agentes, realizando la multiplicación del ancho por el alto de la textura esta se

debera generar con un valor mayor al número de agentes, siempre respetando la estructura

cuadrada de la textura, es decir, contar con el mismo ancho y el mismo alto, con el propósito

de homogeneizar lo leído por el simulador.

Al trabajar con texturas es necesario que los datos que se escriban tengan una estructura

cuadrática, es decir, como lo indicamos en el parrafo anterior los valores se guarden de

acuerdo a un mismo ancho y alto para lo cual se busca en primera instancia la raiz cuadrada

3.5 Generación de movimiento

EJ Pos.tuoncs.de ,1gentc'.)

Figura 3.9: Textura y sus componentes

89

entera que cubra en su totalidad el número de agentes, o en su defecto que sea mayor. Por

ejemplo si dentro del archivo xml se declaran 28 agentes, la raiz cuadrada entera sería 5, sin

embargo, 25 no cubre en su totalidad el número de agentes, por lo que se toma el siguiente

número 6, por lo que la textura se genera con un ancho de 6 elementos y 6 puntos por alto, y

se guardan las posiciones de los agentes en los 28 primeros texels, resultando los 8 restantes

con valores que se completan con 0.00, como se puede observar en la imagen 3.1 O.

A partir de la transposición de las texturas, es necesario un elemento que dentro del si­

mulador permita las operaciones a nivel vertice y controlar la forma en la que se pintarán

los agentes en el simulador a nivel de Fragment Buffer Object y los Vertex Buffer Object.

En este sentido se tienen códigos establecidos en forma de shader, para una correcta inter­

pretación un shader es un código escrito en lenguaje de Open GL Shading Language, que

nos permite explorar las capacidades y utilizar las posibilidades de ejecución de código en

el dispositivo gráfico y que se utilizarán en primera instancia antes de la llegada de CUDA.

Para el simulador se utilizan con el propósito de contar un mecanismo de posicionamiento

de agentes, así como rotaci 'n y opciones propias del graficado, como coloración y textura.

Gracias a esta implementación es posible contar con una relación entre lo manejado en el

shader y CUDA realizando una actualización de los datos guardados en la textura asociada

3.5 Generación de movimiento

Agcntes 0 28

Cclda5Totalcs 0 36

Cr.ldasdesocupadas0 · 8

Ancho e 6

Alta e G

Figura 3.10: Ejemplo del llenado de la textura

90

al shader y tener ese cambio también en la textura que se lee directamente por CUDA, lo que

nos permite una mayor rapidez y eficiencia en la ejecución de la simulación.

Ya que mantenemos el traslado de las texturas, es necesario inicializar los elementos pro­

pios del tráfico, para lo cual se especifican los valores y se inicializa un manejador de VBOs

explicado anteriormente, el cual generará los elementos necesarios de memoria que se com­

partirán entre el simulador ejecutandose en el CPU y los datos necesarios para el movimiento

dentro del GPU, todo esto a través de vertices, es por esta razón que fue necesario utilizar un

manejador de Vertex Buffer Objects.

Posteriormente se ejecuta el nucleo o kernel de CUDA por primera vez, con el propósito

de que se actualicen los datos de las posiciones por primera vez, y realizar el pintado en

primera instancia, de acuerdo a lo establecido en el kernel de CUDA, al correr este metodo

se realizan una serie de pasos, como se muestra a continuación.

l. Se establecen diversas variables de tipo Vértice.

2. Se inicializa una variable de recurso de Cuda que nos permitirá obtener valores de

3.5 Generación de movimiento 91

CUDA al CPU de tipo CudaGraphicsResource, la cual constará de diversos elementos

de un arreglo de acuerdo a las variables inicializadas anteriormente, esta variable es

la base de recursos que utiliza la APi de cuda para ejecutar diversos comandos en el

CPU, para obtener los valores de CUDA [35]

3. Con la instrucción CudaGraphicsMapResource, se mapean los valores de las textu­

ras establecidas en la inicialización de la variable mediante CudaGraphicsResource,

dentro de la propia variable res

4. Se inicializan las variables necesarias que guardarán el tamaño de los datos a obtener,

ya que como se ha mencionado anteriormente el espacio a ocupar por los valores que

se utilizan durante la ejecución es indispensable para CUDA, derivado al manejo de la

memoria y los datos que realiza.

5. Mediante el llamado al método cudaGraphicsResourceGetMappedPointer, se obtienen

los valores de posiciones, puntos de control y actividades, entre otros guardadas ante­

riormente en las texturas, dentro de las variables de tipo Vertex .

6. Se llanza el kernel o función principal de CUDA, el cual se explicara en mayor pro­

fundidad posteriormente.

7. Se realiza la ejecucion del metodo cudaGraphicsUnmapResources, que nos permite

limpiar la variable res, y liberar la memoria y los datos asignados a la misma, ya que

de no ser así los valores obtenidos mediante este recurso de CUDA se continuarán

guardando pudiendo llegar a un desbordamiento de memoria o errores de acceso por

la presencia de datos que ya no se están utilizando.

Dentro de cuda es necesario incoporar el código de forma que su ejecución se pueda

realizar de forma paralela, para lo cual se ha tratado de acoplar lo más posible los datos

dentro del Kernel de CUDA ya que el mismo mantiene un gran rendimiento para la ejecución

3.5 Generación de movimiento 92

que se pueda realizar muchas veces al mismo tiempo con un gran nivel de procesamiento,

por lo que se decidio continuar con el mismo esquema de generar los datos de vectores de las

variables por medio de las instrucciones antes mencionadas y poder definir el movimiento

del vehículo de acuerdo al offset predeterminado por CUDA.

Posteriormente necesitamos tener un elemento en común que nos permita dentro del

kernel de CUDA ejecutar en múltiples ocasiones por los diferentes threads o hilos. Para el

caso del movimiento utilizamos la ejecución de una rutina global, la cual tendra el número

de hilos dependiendo del número de agentes que se obtenido, y que se obtiene del producto

del ancho y alto de la textura para lo cual nuestro bloque de hilos estará en proporción al

tamaño de la textura a utilizar.

Se necesita así mismo un mecanismo que nos permita leer los datos de los nodos los

cuales deberán ser transversales a toda la ejecución, el hecho de ser transversales nos permi­

tirá que la ejecución de cada hilo, a pesar de que se realiza de forma paralelizada, tenga un

modo en común que nos permita leer las posiciones de los nodos y su disposición.

Se ha buscado ingresar una única vez, la posición de los nodos a la memoria del GPU,

ya que dicha posición no cambia durante la ejecución, lo que sufrirá modificación se refiere

a la posición de los agentes, su estado, y la ocupación de los nodos.

Uno de los primeros intentos se establecio ejecutando un solo kernel que guarde los da­

tos en la memoria compartida(SHARED GPU MEMORY) con el proposito de que sea leído

por otro kernel dentro de su ejecución, sin embargo la memoria compartida se establece

como una forma de compartir datos entre los diferentes hilos de ejecución a través del pro­

cesamiento del kernel, sin embargo, al tener dos diferentes tipos de kernel (inicialización y

ejecución), no es posible de acuerdo a la propia especificación de CUDA enviar datos entre

diferentes kernel.

Por lo anterior se ha optado utilizar la misma memoria global obtenida de las propias

texturas, pero en el mismo nodo de ejecución, es decir, cada que se ejecuta el kernel, se

envían una serie de datos:

3.5 Generación de movimiento 93

1. Datos de posiciones iniciales. Contienen las posiciones de los agentes en el inicio de

la simulación, así como datos de pertenencia a los nodos, variables de control de los

agentes, entre otros.

2. Ancho de la textura de posiciones. Contiene el tamaño de la textura, para el asigna­

miento de memoria de CUDA.

3. Alto de la textura de posiciones. Contiene el tamaño de la textura, para el asignamiento

de memoria de CUDA.

4. Tiempo. Nos permite saber en que momento de la ejecución nos encontramos y con­

trolar aspectos de las curvas de bezier, los movimientos en los cruceros, entre otros.

5. Velocidades. Velocidades obtenidas aleatoriamente en la inicialización de CUDA y

que se enviarán como datos de velocidades maximas para cada uno de los agentes,

para lo cual el tamaño del parámetro concide con el de las posiciones enumerado en la

primera posición.

6. Metas . Este elemento guarda los datos de posición de la primera actividad diferente a

la posición de inicio definida en las primeras etapas.

7. Datos de nodos. Guarda las posiciones de los nodos, así como la bandera de ocupado/­

libre para cada uno de los nodos.

Es importante mencionar que como se ha mencionado anteriormente la asignación de me­

moria durante la ejecución de los kernel es muy importante no se realiza de forma dinámica,

es decir, al momento de enviar los datos a la memoria del GPU deberán ya tener un ancho

predeterminado, para lo cual desde un inicio se configuran los agentes, posiciones iniciales

y las características de los nodos, así como el pre-procesamiento de las posibles rutas

Así mismo la mayoría de estos datos se envían en forma de vértices al kernel de CUDA,

a excepción de los parámetros de ancho, alto y el tiempo, los cuales son valores numéricos.

3.5 Generación de movimiento 94

Una vez que los datos e encuentran dentro del kernel de CUDA, la ejecución paralelizada

se realizará para cada uno de los agentes dentro de un hilo asignado a cada uno de ellos,

para lo cuai se tendrá la asignación de la memoria compartida para guardar los datos en

común de los nodos que utilizarán todos los hilos. Esta asignación se ha realizado tomando en

cuenta dos aspectos: el primero se refiere a que la memoria compartida puede ser consultada

por todos los hilos en la ejecución, los nodos al ser un elemento transversal para todos los

agentes, será necesario que se consulten al mismo tiempo por cada uno de los hilos.

En el momento en el que un nodo sea ocupado, deberá ser actualizado su último cam­

po y no podrá ser utilizado por ningún otro agente, sin embargo este proceso se explica a

continuación. Continuando con las razones de utilizar la memoria compartida, la segunda se

refiere al hecho de que la diferencia entre la rapidez de consulta entre las memorias global

y compartida se puede observar en la figura 3.11, el acceso a memoria para un bloque de­

terminado se realiza más rapido para la memoria compaitida, ya que se encuentra asignada

dentro del mismo bloque de hilos de ejecución.

Figura 3.11: Diagrama de ejecución en CUDA y sus diferentes tipos de memoria

Una vez que hemos asignado la memoria compartida para los nodos, se hace una ejecu­

ción paralelizada de cada uno de los agentes, por cada uno de los hilos, con el propósito de

contar con datos siempre actualizados entre la ejecución del simulador es necesario incluir

3.5 Generación de movimiento 95

dentro del kernel, el comando synctheads() que nos permite tener una sincronización de los

datos actualizados por cada uno de los hilos en los demás durante la ejecución.

Se realiza la ejecución del siguiente algoritmo en el kernel de cuda, para cada uno de los

agentes, este algoritmo es el que nos permitirá de forma central controlar el movimiento de

los vehículos y que se ejecutará en cada paso de la ejecución el cual enviará las posiciones

al shader para el movimiento gráfico de los automóviles en la simulación.

1. Se obtiene el agente a procesar por el hilo, mediante un índice

2. Con ese índice, se busca dentro de la variable que guarda las posiciones de los agentes

y los nodos, cual es el ID del nodo que contiene ese agente en ese momento.

3. Se busca dentro de la variable que contiene las relaciones de los nodos con otros no­

dos, es importante mencionar que dicha búsqueda no será de más de tres elementos,

de acuerdo a lo explicado anteriormente, ya que cada uno de los nodos, tiene como

máximo tres vínculos con algún otro nodo.

4. Si se tiene algún nodo libre se asigna en su último elemento un l.O con el propósito

de marcarlo como ocupado, y al mismo tiempo se desocupa el nodo en el que se

encuentra, y en este mismo paso se actualiza la posición del agente con la posición

del nodo escogido.

5. De no contar con algún nodo libre el agente mantiene su posición actual hasta que

encuentra en alguno de los siguientes ciclos, algún nodo que pueda ocuparse.

6. Se envía el ángulo de rotación del agente conforme a una relación trigonométrica, de

acuerdo al movimiento generado, entre la posición actual y la posición futura, es decir

el automóvil se alineará de acuerdo al movimiento generado. Este dato se envía al

shader que pintará el modelo, de acuerdo al ángulo de rotación dado en grados.

Para la asignación de un nodo si se encuentra ocupado o inclusive libre, se ejecutaron

tres tipos de sentencias, de acuerdo a lo estipulado por el manual de programación en CUDA

3.5 Generación de movimiento 96

que nos permiten que los datos se den de forma sincronizada y que los threads esperen a

contar con un nodo realmente desocupado, estas tres instrucciones se les envían los datos de

acuerdo a lo siguiente:

1. AtomicAdd. Se envían como parámetros la dirección de memoria del dato a actualizar

y el valor a sumar.

2. AtomicSub. Se envían como parámetros la dirección de memoria del dato a actualizar

y el valor a restar.

3. AtomicCas. Se envían como parámetros la dirección de memoria del dato a actualizar

y el valor a comparar.

4. AtomicExch. Se envían como parámetros la dirección de memoria del dato a actualizar

y el valor a establecer.

En los primeros dos casos se aplica una operación aritmética ya sea de suma o resta

dependiendo de lo utilizado y en el tercer caso se compara si el valor del nodo se encuentra

ocupado, también en una operación atómica, para el último caso se guarda en la dirección de

memoria envíada el dato que se envía como segundo parametro.

4. RESULTADOS Y CONCLUSIONES

Se ha trabajado el simulador de tráfico con una tarjeta NVIDIA GeForce GT 540M de

2Gb, con un procesador Intel Core i3-23 IOM con una velocidad de 2.1 O Ghz, los lenguajes

de programación utilizados son OpenGL, c++, CUDA y GLSL.

Se ha utilizado para el desarrollo las versiones de Visual Studio 2008, Open GL 3.1 y

para el caso de CUDA la versión 4.0.

En un principio se desarrollaron diferentes comportamientos de tráfico involucrando so­

lamente el uso de OpenGL para la simulación y dibujando cada uno de los modelos por

medio del cargador de objetos GLM.

Los resultados se han verificado de forma visual y a nivel de código, inspeccionando las

variables asociadas al movimiento de los vehículos, tanto en cuda como dentro de de Visual

Studio.

Para el caso de los resultados se inspeccionan tres casos principales, los cuales represen­

tarían en un 70 % lo que sucede en el tráfico real, los cuales son los siguientes:

1. Camino con un único carril y un sólo sentido

97

3.5 Generación de movimiento 98

2. Camino con dos carriles, cada uno con sentidos contrarios

3. Crucero

Estos tres casos, replicandolos "n" número de veces podríamos ver el comportamiento

en gran medida de lo que usualmente se puede observar en el tráfico común.

Por ejemplo si quisieramos definir un camino que tenga tres carriles, en los cuales cada

uno de los carriles vayan todos al mismo sentido, se podría replicar el archivo csv de ru­

tas utilizando el primer ejemplo del camino de un solo carril y un solo sentido, solamente

cambiando las coordenadas para generar tres carriles diferentes.

De acuerdo a lo establecido en el simulador se puede generar este camino sin ninguna

problemática.

Así mismo si quisieramos el mismo camino que tenga seis carriles, con tres carriles

moviendose hacia un sentido y tres carriles hacia otro sentido, inclusive intercalados como

ocurre en algunos tipos de vueltas, se replicaría lo establecido en el segundo caso de las

pruebas realizadas en este trabajo.

Otro caso que se puede modelar sin problemas, es el relacionado a movimientos en diago­

nal, ya que aunque no se establezcan movimientos en los sentidos explicados anteriormente

(arriba, abajo, derecha, izquierda) simplemente estableciendo el camino con una ideología

de movimiento en diagonal se puede generar este movimiento simplemente respetando los

sentidos mediante los cuales los carriles se moverán.

Finalmente replicando y combinando estos casos y el del crucero, podría establecerse

una ciudad que contenga diversos elementos de movimiento.

Se han incorporado para los tres casos un número de I 00 agentes que se mueven dentro

del camino definido, tal y como se ha explicado anteriormente estos automóviles se incor­

poran en una posición al interior de los nodos que se define como nodo de entrada a la

simulación.

Estos automóviles, siguen una ruta que va dependiendo de los enlaces o links que tendrá con

3.5 Generación de movimiento 99

los nodos conforme se va moviendo. La metodología de movimiento es buscar el nodo que

se encuentre libre más cercano, sin impo1tar que se necesite un cambio de carril o que se

realice una incorporación a otro de los sentidos.

Para el primer caso de estudio, el camino establecido solamente contiene nodos que van

en un solo sentido de derecha a izquierda con una separación entre nodos que permita que el

movimiento de los vehículos se realice sin que se realice una colisión entre ellos, de acuerdo

al módelo predefinido.

De la misma forma estos nodos son subsecuentes, ya que permiten que el vehículo se

mueva de un ponto inicial a un punto final, solamente involucrando las coordenadas en x,

ya que las coordenadas predefinidas en y, serán fijas durante todo el camino y solamente

permitirán que el automóvil se pueda mover de izquierda a derecha.

rn:

'1501

125!

100' l

75,

sl 25lR Rl R R R R R. R R R R R R R R R R R R

O'

O 25 50 75 100 125 150 175 100 225 150 27í lOO ll5 150 175 4C-O 41í

Figura 4.1: Especificación del movimiento de un solo carril de izquierda a derecha en posiciones (x,y)

En la figura 4. l se visualiza la definición del camino en términos del camino a generar,

cada uno de los nodos, tiene una separación que permita que los vehículos se puedan mover

y como se estableció en la definición de los caminos, los nodos están definidos de tipo R,

3.5 Generación de movimiento 100

es decir que se podrá mover con dirección a la derecha (Right), y los nodos permitirán un

movimiento continuo del vehículo a través de ellos.

Es importante comentar que si un vehículo se encuentra con un nodo de sentido contra­

rio, no podrá continuar su flujo y buscará el nodo más cercano que le permita continuar su

movimiento, en este caso si el vehículo se encuentra con un nodo de sentido contrario, en ese

momento se detendrá ya que no cuenta con otros carriles o sentidos que le permitán moverse.

Tal y como lo muestra la figura 4.2, se explora la posibilidad de establecer un nodo

de sentido contrario, para este caso el automóvil se encuentra moviendo con sentido a la

izquierda y al querer incorporarse al crucero se encuentra con un nodo de sentido contrario,

por lo que el automóvil se detiene en este nodo y deja de moverse, provocando que los

automóviles que vienen detrás de él también se detengan.

Figura 4.2: Caso de estudio cuando un nodo se encuentra con un nodo de sentido contrario sin ninguna opción de movimiento

Así mismo se han establecido dos manzanas o blocks de edificios que rodean este carril

los cuales se han predefinido en un archivo xml con sus coordenadas x,y de inicio y de final,

cuidando que no obstruyen el camino a seguir por los automóviles.

3.5 Generación de movimiento 101

Se ha probado el simulador con 100 agentes que se moverán de derecha a izquierda,

dando como resultado un promedio de frames por segundo de 45. Los vehículos se han

movido conforme el nodo más cercano permita su incorporación y teniendo un movimiento

con velocidades aleatorias.

Para mayor referencia se podrá visualizar el resultado de este primer acercamiento en la

figura 4.3

Figura 4.3: Resultado de la primera simulación

El segundo caso, se refiere a la réplica del primero, pero teniendo un doble sentido, ya

que nos permitirá observar como se comporta el pre procesamiento de nodos que tienen un

sentido contrario cercano.

Para esto se han establecido los nodos de derecha a izquierda con una distancia mínima,

es decir la distancia del coche, con el propósito de observar si los vehículos no se incorporan

a un sentido incorrecto o generan los caminos sin importar el sentido.

Para este caso se establecieron dos carriles sin ninguna separación más que la del sentido,

3.5 Generación de movimiento 102

tal y como se da en muchos de los caminos que se dan en la vida real, indicando movimientos

hacia la derecha y hacia la izquierda con separación de los nodos en las coordenadas x

continuas, y solo dos cambios en las coordenadas y, tal y como lo muestra la figura 4.4. En

ella se puede observar la definición de los nodos de tipo L(left) y R(right) que conformaran

nuestro camino y por donde los automóviles podrán desplazarse.

~-!

200! i

mi !

150!

m! 100!

75l

50llll l l L l

25RRRRR R R R R R R R R

o 25 so 1s 100 m !)() m 200 m 250 m 100 m J5o m 400 425

Figura 4.4: Especificación de nodos en posiciones (x,y) en dos carriles con sentidos contrarios

De la misma forma que el primer caso se probó el movimiento de 100 vehículos con rutas

de derecha a izquierda y en sentido contrario. Se observo un buen desempeño del simulador,

ya que en ningún momento los vehículos ocuparon el sentido contrario y así mismo mostra­

ron una buena continuidad de movimiento sin colisiones y corriendo de la misma forma con

un promedio de 45 fps.

El resultado de esta simulación se observa en la figura 4.5 .

Finalmente el último caso, el caso del crucero es más complejo de definir, ya que las

variables a utilizar fueron más numerosas, en este caso se estableció un nuevo tipo de nodos

que nos permitien realizar la simulación correctamente, fue necesario la incorporación de

3.5 Generación de movimiento 103

Figura 4.5: Resultado de la segunda simulación

nodos de tipo crucero, los cuales solamente involucran dos tipos de movimiento.

Es importante mencionar que los nodos y la construcción de los caminos fueron pensados

en la ideología americana de los sentidos, es decir los automóviles circulan pegados a su lado

derecho y a partir de esto todas las derivaciones posibles.

En la figura 4.6, se visualizan los tipos de nodos necesarios para definir un crucero con

una estructura usual dentro de lo visto en la vida real. Los nodos necesarios para el centro

del crucero son los siguientes:

1. W. Permite un movimiento en crucero y que podrá tener dos sentidos: el sentido de

dirección hacia la derecha y el sentido de dirección hacia abajo, es decir estos tipos de

nodos podrán tener interconexión o vínculos con los nodos de tipo R y los nodos de

tipo D

2. X. Permite un movimiento en crucero y que podrá tener dos sentidos : el sentido de di-

3.5 Generación de movimiento 104

rección hacia la derecha y el sentido de dirección hacia arriba, teniendo interconexión

con los nodos tipo R y tipo U.

3. Y. Permite un movimiento en crucero y que podrá tener dos sentidos : el sentido de di­

rección hacia la izquierda y el sentido de dirección hacia abajo, teniendo interconexión

con los nodos tipo L y tipo D.

4. Y. Permite un movimiento en crucero y que podrá tener dos sentidos : el sentido de di­

rección hacia la izquierda y el sentido de dirección hacia arriba, teniendo interconexión

con los nodos tipo L y tipo U.

o 25 50 75 O -200 90 125 T ·100 O ·75 T

.i5 1 ·175 90 125 R -100 O -50 O

-50 f 2 -150 90 125 R -100 O -15 O

-15 D l -125 90 125 R -100 o 00

D 4-100 90 125 W -100 o 2i o 25 D 5 -75 90 125 W -100 O 150 D

50 l l l y y z 6 ·50 90 125 X -100 O 1750

i5 l l l l ,· L y 2 z 7 -25 90 125 X -100 O 200 S

100 R R R w w X X 8 o 90 115 R -100 O -7i T

12i R R 9 25 90 125 R -7i O -50 O

150 10 50 90 125 R -7i O -2i D

17i 11 75 90 115 5 -7i o O D

200 12 -200 90 100 T ·/) o 25 O

125 1l -175 90 100 R .75 O 150 O

250 14 -150 90 100 R ·/) o 17í o 275 15 .125 90 100 R -75 O 200 S

300 16 -100 90 100 W .50 O -75 T

315 17 .75 90 íOOW -so O ·SO O

350 18 -50 90 100 X .50 O -2í D

375 19 -25 90 100 X .50 o O D

20 o 90 100 R .50 o 25 D

21 2i 90 100 R .50 O 150 D

22 50 90 100 R .50 O 17í D

Figura 4.6: Dibujado del camino para el caso del crucero y coordenadas (:¡;,y)

Cada uno de estos tipos de nodos también tendrá interconexión con ellos mismos, de

acuerdo a las siguientes reglas:

Finalmente en las figuras 4.7, 4.8, 4.9 y 4. 10 se puede observar la simulación en

ejecución para el caso 3 del crucero.

3.5 Generación de movimiento

Cuadro 4.1: Nodos tipo crucero y sus enlaces

Nodo origen Conexion I Conexion 2

W X RD X y

z

4.0.1. CONCLUSIONES

z w y

UD LD LU

105

Para el desarrollo de esta tesis se exploraron diferentes comportamientos del tráfico, fi­

nalizando con la ejecución de tres casos principales.

Esta ejecución se realizo explorando las capacidades tanto de graficación e imagen de

la tarjeta gráfica, así como el poder de cómputo asociado al GPU, dando como resultado un

simulador que es altamente parametrizable mediante los archivos xml y que permite tener

una ejecución de forma dinámica de las diversas variables de simulación de tráfico.

Se puede obtener datos en tiempo real de la simulación de tráfico ya sean visuales o en

forma de datos que nos permiten conocer de que forma puede desarrollarse el tráfico en cierta

área que cuente con determinadas características.

Así mismo el simulador se ejecuto por arriba de 30 cuadros por segundo desde algunos

cuantos de agentes, decenas, cientos e inclusive miles, llegando hasta 10 mil agentes eje­

cutandose ya en un promedio de 15 frames o cuadros por segundo, para lo cual dentro de

un cuadrante pequeño I O mil agentes en una vialidad puede denotar en gran medida lo que

sucede en el tráfico real de una urbe.

Es importante comentar que se tuvieron diversos retos en el transcurso del desarrollo de

la simulación, dentro de los principales se podrían enumerar los siguientes y las soluciones

desarrolladas:

1. Archivos CSV. Se incorporaron al parser de archivos xml, tinyxml, como metodos

dentro del parser, un lector de archivos csv, para diversas rutas.

2. Movimiento en CUDA. Lo mas importante para CUDA es la forma en la que se ma-

3.5 Generación de movimiento 106

Figura 4.7: Imagen I para la ejecución del simulador para el crucero

nejara la memoria, mediante el paradigma orientado a datos, ya que es necesario tener

bien establecido las variables y el espacio a ocupar, asi como su homogeneizacion de

datos, ya que de no ser asi. la ejecucion de los mismos es erronea.

3. Interconexion VBO-CUDA. Ya que los datos leídos en el VBO manager se actualizan

en CUDA, fue necesario llevar un control puntual de los datos ingresados en los dos.

4.0.2. TRABAJO A FUTURO

Dentro del simulador aun quedan diversas cuestiones que no se han logrado obtener y

que forman parte del trabajo que se puede desarrollar en un trabajo a futuro dentro del pro­

pio simulador, estos casos que no se han explorado permitirían obtener un simulador más

robusto que contemplará en gran medida la gama de posibilidades que se pueden ver en el

3.5 Generación de movimiento 107

Figura 4.8: Imagen 2 para la ejecución del simulador para el crucero

tráfico real y ayudar en la investigación y aplicacion de nuevas rutas, caminos, vialidades,

inclusive desde su concepción y ahorrando presupuesto que puede ser utilizado de otra for­

ma o aplicándolo en rutas de vialidades que realmente se encuentre probado mediante el

simulador que funcionen.

Algunos de los casos sería el poder realizar la incorporación de un mayor tipo de movi­

mientos o casos de estudio tales como cruceros con semáforos parametrizables y que puedan

ser controlados por tiempos predefinidos de los mismos, los cuales permitiría un estudio más

profundo de la incidencia de señales de tránsito en el control vehicular, estudiando tiempos

de incidiencia, manejo de secuencias, tipos de semáforos, etcétera.

Otro aspecto importante sería incorporar todos aquellos datos que se pueden observar

en la ejecución del simulador, tales como posiciones de los agentes en determinado tiempo,

3.5 Generación de movimiento 108

Figura 4.9: Imagen 3 para la ejecución del simulador para el crucero

comportamientos, tiempo de desplazamiento, es trascendental poder observarlos a manera

de estadística en un archivo de texto o inclusive CSV como los archivos de ingreso de datos,

que inclusive puedan servir como entrada a otros sistemas o como parámetros de medición

de comportamiento.

Otro aspecto puntual que se da mucho en el tráfico cotidiano es el de tipo de conducción

o tipos de manejo entre la población, para lo cual el mismo simulador nos podría permitir

observar de que forma impacta el tipo de conducción de los habitantes de una ciudad y cual es

la incidencia de determinados tipos de manejo en la fluidez, accidentes, congestionamientos

y generación de conflictos.

Otra cuestión que puede desarrollarse a futuro es la variedad en los modelos a ocupar,

es decir, al hablar de un simulador gráfico es importante que lo que se pueda observar sea

3.5 Generación de movimiento 109

Figura 4. 1 O: Imagen 4 para la ejecución del simulador para el crucero

llamativo para los usuarios, ya que de esta forma es posible contar con una herramienta con

variedad de edificios, vehículos, inclusive camellones, banquetas, entre otros, por lo cual

sería importante la incorporación de más modelos en la simulación.

BIBLIOGRAFÍA

[l] SUIPING ZHOU, DAN CHEN, W. C. L. L. M. Y. H. L., ANO TIAN, F. Crowd mode­

ling and simulation technologies. ACM Trans. G1: 21, 3 (20010), 1-35.

[2] FORSYTH, D. Group dynamics. 355-361.

[3] GWYNNE, S., E. G. M.O. P. L., ANO FILIPPIDIS, L. A review of the methodologies

used in the computer simulation ff evacuation from the built environment. building and

environment.

[4] K., M. Die evakuierung von personen aus gebauden nach wie vor ein nationales und

intemationales problem. 741-749.

[5] G., D. Comparing extremism propagation pattems in continuous opinion models. 1-9.

[6] SAAD ALI, M. S. A langrangian particle dynamics approach for crowd flow segmen­

tation and stability analysis. 1-6.

[7] PARKE, F. l. Computer generated animation of faces. In ACM annual conference

( 1999), vol. 21, pp. 451-457.

[8] REYNOLDS, C. Flocks, herds and schools: A distributed behavioral model.

[9] REYNOLDS, C. Hierarchical model for real time simulation of virtual human crowds.

[ 10] ZHANG BEN, SHANG LEI, C. D. A sludy on the lraffic intersection vehicle emission

base on urban microscopic traffic simulation model. 789-7949.

[ 11] HUANG WEINAN, SUN HAN, L. K. A multiple representation entity-based approach

to hybrid traffic simulation model. 7-12.

[ 12] DIRK HELBING, M. T. Numerical simulation of macroscopic traffic equations. 89-99.

110

BIBLIOGRAFÍA 111

[13] H., D. S. Ecuaciones Diferenciales Parciales. http://www.branchingnature.org, 2012.

f 141 KANG-CHING CHU, LI YANG, R. S. C. S. Yalidation of stochastic traffic flow model

with microscopic traffic simulation. 672-677.

[15] NUALART, D. Stochastic Processes. mat.ub.es, 2007.

[ 16] RODRIGUEZ, T. Procesos estocasticos. http://centros.edu.aytolacoruna.es/maristas/Apuntes

Estadistica P3.pdf, 2012.

[ 17] D. KIM, W. CHUNG, S. P. Practica) motion planning for car-parking control in narrow

environment. 129-139.

[ 18] KAZUO TANAKA, T. K. Intelligent control of a car with n trailers trajectory stabili­

zation and ga-based path planing. 250-254.

[ 19] SIMON THOMPSON, S. K. Continuos curvature trajectory generation with obstacle

avoidance for car-like robots. 1-8.

[20] KATO YUMIKO, H. M. Vehicle control device and vehicle control method. 1-9.

[21] ARVIND THIAGARAJAN, JAMES BIAGIONI, T. G. J. E. Cooperative transit trac­

king using smart-phones. 85-99.

[22] ARNE KESTING, MARTIN TREIBER, D. H. Connectivity statistics of store-and­

forward intervehicle communication. 172-181.

[23] STEFAN K. GEHRIG, F. J. S. A trajectory-based approach for the lateral control of

car following systems. 3596-3601.

[24] TRUCK, R. Principie of ackerman steering. http://www.rc-truckncar-

tuning.com/ackerman.html, 2007. [Online; accessed 15-mar-2012].

BIBLIOGRAFÍA 112

[25] JASON SEWALL, DAVID WILKIE, M.C. L. Interactive hybrid simulation of large­

scale traffic. 135:1-11.

[26] GARAVELLO, M. Onfiuido-dynamic modelsfor urban traffic. Dipartimento di Scien­

ze e Tecnologie Avanzate Universita del Piemonte Orientale A Avogadro, 2007.

[27] TOBIAS KIESLING, J. L. Towards time-parallel road traffic simulation. 1-9.

[28] AMD. Power Processing with the Microsoft Windows Compute Cluster Server.

http:/ /developer.amd.com/Membership/Print. aspx? Article1D=53, 2003.

[29] JIANKUN WU, LINPENG HUANG, J. C. M. L. X. W. Research on grid-based traffic

simulatino platform. 1-8.

[30] MICHEL FERREIRA, RICARDO FERNANDES, H. C. W. V. O. K. T. Self-

organizated traffic control. 85-89.

[31 J NVIDIA. NVIDIA CUDA programmg zone.

http://www.nvidia.com/object/cudahomenew.html, 2012.

[32J KALYAN S. PERUMALLA, BRAMDON G. AABY, S. B. Y. S. K. S. Gpu-based real­

time execution of vehicular mobility models in lartge-scale road network scenariosl.

95-103.

[33] JOHN D. OWENS, MIKE HOUSTON, D. L. S. G. J. E. S. J. C. P. Gpu computing.

879-899.

l34J DAVID STRIPPGEN, K. N. Multi-agent traffic simulation with cuda. 741-749.

[35] NVIDIA. CUDA API REFERENCE MANUAL. Doxygen, 2012.