modelo para micro-simulaciÓn de trÁfico vehicular y
TRANSCRIPT
MODELO PARA MICRO-SIMULACIÓN DE TRÁFICO VEHICULAR Y
PEATONAL UTILIZANDO CUDA
DIEGO HERNANDO RODRÍGUEZ GAITÁN
Grupo de Investigación IMAGINE
Departamento de Ingeniería de Sistemas y Computación
Facultad de Ingeniería
Universidad de los Andes
Bogotá, Colombia
Enero 2012
MODELO PARA MICRO-SIMULACIÓN DE TRÁFICO VEHICULAR Y
PEATONAL UTILIZANDO CUDA
DIEGO HERNANDO RODRÍGUEZ GAITÁN
Tesis para optar por el grado de:
Maestría en Ingeniería de Sistemas y Computación
Profesor asesor:
Pablo Alejandro Figueroa Forero, PhD.
Grupo de Investigación IMAGINE
Departamento de Ingeniería de Sistemas y Computación
Facultad de Ingeniería
Universidad de los Andes
Bogotá, Colombia
Enero 2012
AGRADECIMIENTOS
La presente Tesis es un proyecto en el que varias personas participaron de
manera directa o indirecta.
Agradezco a mis padres por su apoyo y comprensión durante estos años de
estudio.
A mi director de tesis Pablo Figueroa por su asesoramiento profesional, sus
comentarios y paciencia en el desarrollo de este proyecto.
Al grupo de investigación IMAGINE y sus integrantes por su ayuda, apoyo y
consejos y experiencias.
Y a mis compañeros de estudio Alejandro Triana, Miguel Camelo y Daniel
Wilches que me acompañaron durante el trayecto de la maestría y que con
su ayuda facilitaron el transcurso la Maestría.
TABLA DE CONTENIDO
I. RESUMEN....................................................................................................................... 9
II. INTRODUCCIÓN ......................................................................................................... 10
III. OBJETIVOS .................................................................................................................. 11
1. ESTADO DEL ARTE ................................................................................................... 12
1.1. MICROSIMULACIÓN .......................................................................................... 12
1.2. CARACTERÍSTICAS DE UN SIMULADOR DE CONDUCCIÓN .................. 12
1.2.1. Física .................................................................................................................. 12
1.2.2. Inteligencia Artificial ......................................................................................... 13
1.2.3. Modelos Gráficos y Sonido ............................................................................. 13
1.2.4. Escenarios de simulación especiales ........................................................... 13
1.3. SIMULADORES DE CONDUCCION ACTUALES .......................................... 14
1.3.1. PARAMICS (QUADSTONE) ........................................................................... 14
1.3.2. S-PARAMICS .................................................................................................... 15
1.3.3. DRACULA ......................................................................................................... 16
1.3.4. AIMSUN2 ........................................................................................................... 18
1.3.5. VISSIM ............................................................................................................... 19
1.3.6. SPIDER .............................................................................................................. 19
1.3.7. SIMULADOR CARWORLD ............................................................................ 21
1.3.8. ULTIMATE DRIVING SIMULATOR ............................................................... 22
1.3.9. JENTIG 50 ......................................................................................................... 23
1.3.10. SIMULADOR STISIM .................................................................................. 25
1.3.11. HONDA DRIVING SIMULATOR ................................................................ 27
1.3.12. TOYOTA DRIVING SIMULATOR .............................................................. 27
1.3.13. CITY BUS SIMULATOR 2010 (NEW YORK 42 STREET) .................... 30
1.3.14. BUS SIMULATOR ........................................................................................ 32
1.3.15. EURO TRUCK SIMULATOR ...................................................................... 33
1.3.16. Massive Ready To Run Agent .................................................................... 34
1.3.17. UC-win/Road Drive Simulator .................................................................... 35
1.3.18. Directing Crowd Simulations Using Navigation Fields ........................... 36
1.4. COMPARACIÓN TÉCNICA ENTRE SIMULADORES: .................................. 37
2. DISEÑO ......................................................................................................................... 40
2.1. CONTEXTO DEL SISTEMA DE TRANSMILENIO: ........................................ 40
2.2. ARQUITECTURA CUDA ..................................................................................... 42
2.3. VISUALIZACIÓN DE LA SIMULACIÓN ............................................................ 46
2.4. ORIGEN DE LOS DATOS .................................................................................. 46
3. IMPLEMENTACIÓN ..................................................................................................... 48
3.1. MODELO DE SIMULACIÓN ............................................................................... 48
3.2. COMPLEMENTACIÓN DE DATOS .................................................................. 49
3.3. MAPA DE TEXTURA ........................................................................................... 51
3.4. METAS LOCALES Y METAS GLOBALES ...................................................... 54
3.5. PROBLEMAS DE CONSISTENCIA. ................................................................. 56
4. RESULTADOS ............................................................................................................. 69
4.1 CARACTERÍSTICAS EQUIPO DE DESARROLLO ....................................... 69
4.2 COMPARACIÓN ENTRE CPU Y GPU: ............................................................ 71
5. LIMITACIONES ............................................................................................................ 74
5.1. LIMITACIONES POR HARDWARE .................................................................. 74
5.2. LIMITACIONES DE SOFTWARE ...................................................................... 74
6. TRABAJO FUTURO .................................................................................................... 77
7. CONCLUSIONES ......................................................................................................... 80
8. BIBLIOGRAFIA ............................................................................................................. 81
LISTA DE FIGURAS
Figura 1. Paramics Quadstone (Visualización en 3D) ................................... 14
Figura 2. Paramics Quadstone (Visualización en 2D) ................................... 15
Figura 3. Simulador S-Paramics ................................................................... 16
Figura 4. Simulador DRACULA ..................................................................... 17
Figura 5. Simulador AIMSUN2 ...................................................................... 18
Figura 6. Simulador VISSM .......................................................................... 19
Figura 7. Modelo de espacio discreto de SPIDER ........................................ 20
Figura 8. Regiones ocupadas por entes móviles de diferentes tamaños en
SPIDER ........................................................................................................ 20
Figura 9. Vista del simulador CARWORLD ................................................... 21
Figura 10. Vista del simulador ULTIMATE DRIVER SIMULATOR ................ 22
Figura 11. Vista interna de cabina del simulador de conducción Jentig 50 ... 23
Figura 12. Vista externa del simulador de conducción Jentig 50 .................. 24
Figura 13. Vista externa e interna del simulador STISIM .............................. 25
Figura 14. Vista externa del sistema Professional STISIM ........................... 26
Figura 15. Vista Externa del Simulador Honda Driving Simulator ................. 27
Figura 16. Vista interna del domo del simulador de conducción Toyota Driving
Simulator ....................................................................................................... 28
Figura 17. Vista del domo sobre la plataforma móvil de Toyota Driving
Simulator (izquierda) y con giro de 20º (derecha) ......................................... 28
Figura 18. Vista interna de la cabina del simulador Toyota Driving Simulator
(Izquierda) y del ambiente de entrenamiento virtual del simulador ............... 29
Figura 19. Vista interna del simulador City Bus Simulator 2010 en una parada
de pasajeros ................................................................................................. 30
Figura 20. Vista interna de la cabina virtual del simulador City Bus Simulator
2010 ante una solicitud de parada ................................................................ 31
Figura 21. Vista interna del simulador Bus Simulator en un escenario con
señales de tránsito ........................................................................................ 32
Figura 22. Vista del modelo de los camiones de Euro Truck Simulator ........ 33
Figura 23. Vista del simulador Euro Truck Simulator, Izquierda vista superior
del vehículo, derecha vista dentro de la cabina ............................................ 33
Figura 24. Vista del simulador Massive ........................................................ 34
Figura 25. Vista del simulador Road Drive Simulator .................................... 35
Figura 26. Vista de la cabina desarrollada por Subaru. ................................ 36
Figura 27. Vista de la lógica de Crowd Simulations. ..................................... 36
Figura 28. Imagen de un bus del sistema de Transmilenio ........................... 40
Figura 29.Arreglo de Multiprocesadores de la GPU ...................................... 43
Figura 30.Modelo de hilos de CUDA ............................................................. 44
Figura 31. Modelo de Memoria de CUDA ..................................................... 45
Figura 32.Datos proporcionados por Catastro .............................................. 47
Figura 33. Información original proporcionada por Catastro. ........................ 50
Figura 34.Información de Catastro enriquecida ............................................ 51
Figura 35. Mapa de Textura .......................................................................... 54
Figura 36. Las metas locales más cercanas a la meta local central ............. 55
Figura 37. Metas globales (inicial y final) de un peatón ................................ 56
Figura 38. Ejemplo de movimiento de peatones ........................................... 57
Figura 39. Ejemplo de asignación de segmentos ......................................... 58
Figura 40. Ejemplo de ejecución de segmentos de diferentes velocidades .. 58
Figura 41. Tiempo tomado para procesar un paso de simulación. ............... 62
Figura 42. Mapa de textura y mapa de entidades ......................................... 64
Figura 43. Vista global del paso de simulación. ............................................ 65
Figura 44. Comparación entre rendimiento de detección de conflictos en serie
y en paralelo para entidades de tipo peatón. ................................................ 66
Figura 45. Comparación entre rendimiento de detección de conflictos en serie
y en paralelo para entidades de tipo vehículo. .............................................. 67
Figura 46. Comparación entre rendimiento de detección de conflictos en serie
y en paralelo para entidades de tipo Transmilenio. ....................................... 68
Figura 47. Simulador en funcionamiento ...................................................... 70
Figura 48. Tiempo de paso de simulación de CPU y GPU para entidad tipo
peatón. .......................................................................................................... 72
Figura 49. Tiempo de paso de simulación de CPU y GPU para entidad tipo
vehículo. ....................................................................................................... 73
Figura 50. Tiempo de paso de simulación de CPU y GPU para entidad tipo
Transmilenio. ................................................................................................ 73
Figura 51. Problemas de aglomeración de entidades ................................... 75
Figura 52. Problema de meta global obstruida ............................................. 75
Figura 53. Modelo 3D de la región geográfica comprendida entre la Calle 53 y
Calle 63 ......................................................................................................... 77
Figura 54. Modelo en 3D de Transmilenios y estaciones. ............................ 78
9
I. RESUMEN
Este documento presenta el desarrollo de una plataforma de simulación de
tráfico vehicular para un ambiente urbano utilizando CUDA. La plataforma
utiliza algoritmos de micro-simulación y tiene una representación de espacio
discreto, por lo que se utiliza una grilla de celdas; cada celda contiene
información sobre el espacio discreto al que representa, y esta información
es guardada en una imagen de textura que es almacenada en la memoria de
la GPU. El documento inicia con un marco teórico que muestra diferentes
simuladores de conducción, éstos son comparados entre ellos para
determinar cuál cumple con la mayor cantidad de características necesarias.
Posteriormente se explica el contexto del ambiente a simular y se hace una
introducción a CUDA, explicando cómo esta arquitectura va a ser utilizada en
el simulador. Luego se explica el formato y origen de los datos geográficos
del ambiente a simular y la forma como estos datos son extendidos para dar
lugar a la utilización de metas locales y globales. Debido a que el simulador
ejecuta cada entidad de manera paralela, se explican las fases del paso de
simulación que evitan la aparición de inconsistencias en el simulador.
Posteriormente se hace un análisis de rendimiento, se muestran las
limitaciones y el trabajo futuro.
10
II. INTRODUCCIÓN
En los últimos años la creación y uso de diferentes tipos de simuladores se
ha incrementado; ya sea como medio de predicción y entendimiento de
fenómenos naturales (simuladores de Tsunami, terremotos, huracanes, entre
otros) o como herramientas de entrenamiento para operarios de un sistema
(simuladores de conducción, vuelo, tren, entre otros), donde el objetivo es
claro; modelar el comportamiento de un sistema complejo del mundo real
usando equipos que pueden ser o no complejos.
Específicamente, los simuladores de conducción se han vuelto muy
populares en la actualidad para las empresas automovilísticas y de
transporte, quienes los crean con el fin de disminuir los riesgos de
accidentes.
Algunos de estos simuladores, para conseguir un mayor nivel de exactitud y
complejidad, utilizan un modelo de micro-simulación que les permite operar a
nivel del individuo. Sin embargo, esto requiere de un alto nivel de
procesamiento computacional, que solo puede ser obtenido actualmente con
procesamiento en paralelo, pero para lograr esto es necesario que el
hardware en el que se ejecuta la simulación permita procesamiento en
paralelo. Las GPUs (Unidad de procesamiento gráfico) se han popularizado
bastante debido a que pueden cubrir altos requerimientos de procesamiento,
al tener una arquitectura de múltiples procesadores en paralelo.
El modelo de simulación propuesto en este documento busca crear una
herramienta que permita mostrar posibles escenarios a los que puede estar
expuesto el sistema de transporte Transmilenio. Para conseguir esto se han
tomado datos geográficos de las zonas de trabajo del sistema de transporte y
se ha implementado un modelo de micro-simulación que toma ventaja de las
GPUs, lo que permite realizar micro-simulaciones a velocidades superiores a
las CPUs actuales.
11
III. OBJETIVOS
Objetivo general:
Desarrollar un sistema que permita simular el comportamiento de
entidades urbanas comunes, para una sección de Bogotá que
involucra el sistema masivo de transporte Transmilenio.
Objetivos Específicos:
Generar una zona de simulación a partir de una sección de Bogotá
que contenga estaciones del sistema masivo Transmilenio.
Desarrollar modelos de simulación para vehículos y peatones en
CUDA.
12
1. ESTADO DEL ARTE
Muchas aproximaciones se han realizado para la realización de un simulador
de conducción realista, en cada una de las subsecciones siguientes se
discutirán diferentes simuladores comerciales y finalmente, una vez
mostrados los simuladores, se hará un cuadro de comparación que evidencie
sus principales características.
1.1. MICROSIMULACIÓN
Los modelos de micro simulación son modelos de computadora que operan a
nivel del comportamiento del individuo, tales como personas, familia o firmas.
Tales modelos simulan poblaciones representativas grandes de estas
entidades con el fin de extraer conclusiones que se puedan aplicar a niveles
más altos de agregación; un ejemplo puede ser la velocidad promedio de un
vehículo en una ciudad. Este tipo de modelo es distinto de los modelos
agregados cuyas variables explicadoras ya representan las propiedades
colectivas. Un ejemplo de una métrica puede ser la rata de desempleo
nacional [1].
1.2. CARACTERÍSTICAS DE UN SIMULADOR DE CONDUCCIÓN
Todo simulador realista debe contener una serie de características técnicas
que le permita asemejar los resultados de la simulación a los resultados que
se obtendría en la vida real para un escenario similar. Estas características
son [2]:
1.2.1. Física
Esta característica describe el comportamiento de los fenómenos que
ocurren en la vida real, mediante modelos matemáticos, estos modelos
matemáticos de física clásica (aceleración, velocidad, desplazamiento, fuerza
centrífuga, relación de ejes, entre otros) deben ser aplicados en el simulador,
entre más exactos sean el uso de estos modelos, más se asemejará el
13
comportamiento de los fenómenos físicos del simulador a la vida real. Esta
característica también incluye la realimentación mecánica que se genera
hacia el usuario calculado a partir de los modelos mismos.
1.2.2. Inteligencia Artificial
Esta característica describe el comportamiento de los peatones y
transeúntes. Decisiones como hacia dónde voy, qué camino tomo, cómo
tomo este camino sin violar las normas de tránsito; son decisiones que debe
tomar el modelo social usando inteligencia artificial. Sin embargo también es
necesario tener en cuenta que en la vida cotidiana estas normas no son
obedecidas el 100% de las veces, por tanto un modelo social preciso también
debe contemplar estos escenarios.
1.2.3. Modelos Gráficos y Sonido
Esta característica representa el nivel de inmersión del simulador; entre más
detalle haya en los modelos gráficos y sonido, mayor será el nivel de
inmersión del sistema, lo que se traduce en un simulador más agradable para
el usuario pero aún más importante, se traduce en un simulador que ante los
sentidos del usuario es más realista.
1.2.4. Escenarios de simulación especiales
Esta característica describe los escenarios especiales que no son muy
comunes en la vida real y que por lo tanto tampoco son comunes en el
comportamiento del simulador. Saber identificar estos escenarios es vital
para poder simular circunstancias que rara vez ocurren pero que son parte
importante del simulador. Casos en donde un peatón cruza repentinamente
por una calle sin tener la vía, hacen valioso al simulador.
14
1.3. SIMULADORES DE CONDUCCION ACTUALES
Los simuladores de conducción se han vuelto muy populares en la
actualidad, muchos de estos simuladores han sido creados con el fin de
disminuir los riegos de accidentes ocasionados por la baja adquisición de
habilidades de conducción cognitiva que son adquiridas a través de la
experiencia de la conducción en carreteras [3]. Las habilidades cognitivas
más influyentes en la disminución de la accidentalidad son la percepción de
riesgo y el control de atención. Un simulador de conducción puede ayudar a
adquirir estas habilidades al generar una experiencia de conducción similar a
las ocurridas en casos reales con autos. A continuación se mostrarán
algunos de los simuladores de conducción desarrollados en la actualidad.
1.3.1. PARAMICS (QUADSTONE)
Figura 1. ParamicsQuadstone (Visualización en 3D)[4]
Paramics es una suite de herramientas de software para simulación de tráfico
microscópico en donde se modela los vehículos individuales. Esta suite es
usada en aplicaciones del Reino Unido que involucra controles de tráfico en
tiempo real.
15
Figura 2.ParamicsQuadstone (Visualización en 2D)
La suite incluye los siguientes módulos:
Modeller- Que desarrolla la red
Analyser- Que extrae los datos y genera un análisis
Processer- Usado para correr las simulaciones.
La suite puede manejar hasta 4 millones de enlaces, 1 millón de nodos y 32
mil zonas y 1 millón de puntos de control. El programa funciona usando
pasos de 0.5 segundos por defecto. Los resultados son repetibles si se pone
la misma semilla aleatoria[4].
1.3.2. S-PARAMICS
S-Paramics es un sistema de modelaje del flujo del tráfico. Éste simula los
componentes individuales del flujo y congestión del tráfico, y presenta su
salida con un visualizador en tiempo-real para el manejo y diseño de las
redes de las carreteras[5].
Se representan las acciones e interacciones de los vehículos individuales
mientras viajan por la carretera. Además modela de manera detallada los
aspectos físicos de la carretera, y se incluyen características como
operaciones de buses, señales de tránsito, cinemática del vehículo y
comportamiento del conductor. En este sistema sobresale el modelo de las
16
redes de carreteras con peatones. Se puede apreciar el impacto de las
señales de tráfico sobre el flujo vehicular. El software ofrece funcionalidad en
las siguientes áreas: Simulación microscópica, software totalmente integrado,
un interfaz directo a formatos de datos macroscópicos, un sofisticado modelo
microscópico de seguimiento de carro y cambio de vía, funcionalidad de
enrutamiento inteligente, operación a modo de batch para estudios
estadísticos y un ambiente de visualización comprensivo.
Figura 3. Simulador S-Paramics[5]
1.3.3. DRACULA
Sistema desarrollado para observar la variación del tráfico día a día, y
evaluar estrategias para evitar la congestión vehicular. Las estrategias están
enfocadas a reducir el consumo de combustible y emisión de gases. El
modelo de microsimulación está escrito en el lenguaje C, y la simulación
está orientada al tiempo, siendo 1 segundo la unidad de tiempo[6].
17
Figura 4. Simulador DRACULA[6]
Características Técnicas:
El tráfico es considerado a nivel de vehículos individuales.
Los movimientos de los vehículos individuales son simulados cada segundo.
Los vehículos siguen rutas fijas desde su origen hasta su destino.
Hay 6 tipos de vehículos: carro, bus, bus guiado, taxi, vehículos de carga
largay vehículos de carga pesada.
Las características del vehículo son:
Tipo de vehículo
Largo del vehículo
Tiempo de reacción del conductor
Aceleración normal y máxima.
Desaceleración normal y máxima.
Velocidad deseada.
Gap aceptable.
18
1.3.4. AIMSUN2
AIMSUN2 es un modelo microscópico y estocástico para la simulación de
tráfico en redes viales. Hace parte de GETRAM
(GenericEnvironmentforTrafficAnalysis and Modelling) desarrollado en la
Universidad Politécnica de Catalunya en Barcelona, España[7].
Consiste de una interfaz gráfica amigable al usuario, un editor gráfico de
redes viales (TEDI) que soporta cualquier tipo de geometría de caminos o
redes, una base de datos de redes para guardar y presentar los resultados.
Incluye un visualizador de simulación animado, el cual muestra los vehículos
moviéndose a través de la red. El modelo puede simular un rango de
características de manejo de tráfico que incluye detección de accidentes y
sistemas de vigilancia, señales de tráfico y estrategias de control de tráfico.
Figura 5. Simulador AIMSUN2[7]
19
1.3.5. VISSIM
VISSIM es un modelo de simulación microscópico basado en
comportamiento y en pasos de tiempo, desarrollado para analizar el rango
completo de los caminos funcionalmente clasificados y operaciones de
tránsito. Es capaz de modelar el tráfico con varias medidas de control en
ambientes en 3D. El modelo ayuda a comparar diferentes alternativas en el
diseño de caminos, intersecciones en intercambios de tráfico.
El sistema contiene diversos componentes y estrategias para ser modelados,
como: Señales de tránsito variable (VMS), incidentes de tránsito, prioridad de
señales de tránsito, entre otros.
Figura 6. Simulador VISSM [8]
1.3.6. SPIDER
Es un modelo de microsimulación basado en un espacio de simulación
discreta. En donde se subdivide el espacio en pequeñas regiones, y cada
región tiene definido unos parámetros de movilidad. Este espacio permite
representar patologías estructurales como el estado de la malla vial[9].
20
Figura 7. Modelo de espacio discreto de SPIDER[9]
Los entes movibles (peatones y vehículos) pueden ocupar una o más
regiones del especio, la definición de su desplazamiento está definido por el
promedio de los parámetros de movilidad de las regiones que ocupa.
Figura 8. Regiones ocupadas por entes móviles de diferentes tamaños en
SPIDER[9]
21
1.3.7. SIMULADOR CARWORLD
Este es un simulador de código abierto usado para evaluar las dinámicas de
los vehículos de prueba y simulación completa de conducción[10].
El renderizado se hace utilizando OpenGL, con proyecciones de sombras en
tiempo real y mapeo de las texturas de los modelos con las normales
interpoladas.
Figura 9. Vista del simuladorCARWORLD[10]
La simulación está basada en mecánica clásica, usando medidas estándar
(metros, segundos) sin límites en la superficie del ambiente. Las siguientes
variables son modificables: masa, momento de inercia en el eje de rotación,
suspensión, torque del motor, fricción del aire y fricción de la superficie.
Para realizar las redes de las carreteras se usa el formato abierto Road XML.
22
1.3.8. ULTIMATEDRIVING SIMULATOR
Figura 10. Vista del simuladorULTIMATE DRIVER SIMULATOR [11]
Este es un simulador de conducción urbana ambientado en la ciudad de
Valladolid.
El simulador permite al usuario conducir por toda la ciudad de Valladolid de
forma libre, la ciudad esta recreada de forma foto-realista de manera que
facilita al conductor identificar las calles en la realidad y así poder orientarse.
Permite al conductor poner en práctica las normas de circulación y practicar
el manejo de vehículos de diferentes características y potencias, está
diseñado para permitir al usuario familiarizarse con:
Conducción de un turismo mediante acelerador, freno, embrague, y
cambio de marchas.
El usuario aprende como utilizar las diferentes señales de tráfico.
La conducción urbana en una ciudad.
Todo ello con una interfaz sencilla y efectiva.
23
1.3.9. JENTIG 50
Figura 11. Vista interna de cabina del simulador de conducción Jentig 50[12]
El simulador Jentig es un simulador diseñado específicamente como
simulador de entrenamiento. Este simulador cuenta con 3 pantallas de 50
pulgadas para generar un ambiente más inmersivo y puede ser extendido a 5
pantallas al agregar un computador adicional para así poder ver el tráfico
alrededor del auto. El simulador contiene diversas series de lecciones, que
pueden dividirse en básico y avanzado[12].
Las lecciones básicas cubren todos los escenarios básicos como arrancar el
motor, meter cambios, conducir en una calle desolada, entre otros. Las
lecciones avanzadas cubren aspectos más complejos en la conducción como
lo es la inclusión de tráfico externo y normas de tránsito (límite de velocidad,
adelantar otros vehículos, etc), y manejo en distintos tipos de carreteras.
24
Figura 12. Vista externa del simulador de conducción Jentig 50[12].
Entre las características técnicas del simulador tenemos:
Cabina con todos los actuadores.
ForceFeedback con cabrilla de 36cm.
Campo de visión de 200º (extensible)
3 pantallas plasma de 50 pulgadas.
Asiento ajustable y cinturón de seguridad con sensor.
Sistema de sonido 3D 5.1
2 PCsQuadCore.
25
1.3.10. SIMULADORSTISIM
Figura 13. Vista externa e interna del simulador STISIM [13]
El simulador STISIM es un sistema de entrenamiento de conductores con un
alto rango de escenarios de entrenamiento modificables. Éste se encuentra
dividido en 2 categorías principales: „Novice‟ y „Professional‟[13].
Categoría Novice (Novatos):
El simulador de la categoría Novice está diseñado para ser una alternativa
interactiva al entrenamiento en salas de clase para los conductores novatos.
En la simulación se da una realimentación sonora para facilitar el
reconocimiento de las áreas a trabajar en el conductor y situaciones de
riesgo. Además contiene alrededor de 50 escenarios predefinidos con
condiciones de visión limitadas, señales de tránsito, conducción en zonas
rurales, montañas, etc.
El hardware utilizado para este tipo de simulación contiene:
Una cabrilla con 90º de rotación y ForceFeedback.
Pedales para la aceleración y el freno.
2 Pantallas LCDs, una para la simulación y otra para el operador.
26
Professional (Profesional)
Dentro de esta categoría se encuentran 4 subcategorías: „Truck‟, „EMS‟,
„Police‟ y „Military‟. La principal diferencia entre las subcategorías son los
escenarios de entrenamiento que son únicos para cada tipo. Mediante el uso
de este simulador se puede obtener la licencia de conducción comercial
(CDL).
Esta categoría a diferencia de las demás categorías posee la visualización de
los controles del vehículo con una visualización realista del ambiente de
lugares reales.
El hardware de esta categoría contiene:
Una cabrilla con 90º de rotación y ForceFeedback.
Pedales para la aceleración y el freno.
4 Pantallas LCDs, una para el operador y 3 para la simulación
(formando un cabe con 135º de ángulo de visión).
Figura 14. Vista externa del sistema Professional STISIM[13]
27
1.3.11. HONDA DRIVING SIMULATOR
Figura 15. Vista Externa del Simulador Honda Driving Simulator[14]
El simulador de conducción de Honda cuenta con 3 pantallas panorámicas
de 42 pulgadas, dos o seis ejes de rotación para el asiento del conductor,
resultados de la simulación. Además cuenta con modo de visualización
nocturno, en neblina y en autopista[14].
El valor del sistema completo para la versión de 2 ejes es de US$60000
mientras que para la versión de 6 ejes es alrededor de US$101540.
1.3.12. TOYOTA DRIVING SIMULATOR
El simulador de Toyota consiste de un carro real posicionado dentro de una
plataforma mecánica de 7 metros de diámetro. El sistema contiene diversos
mecanismos de movimiento y vibración que manipulan un domo mientras el
conductor opera el vehículo. El domo, el cual actúa como una pantalla
gigante de 360º (utilizando 8 proyectores) visualiza el ambiente alrededor del
vehículo[15].
28
Figura 16. Vista interna del domo del simulador de conducción ToyotaDriving
Simulator[15]
Adicionalmente para simular las fuerzas que se experimentarían en un carro
actual, el domo se encuentra en una plataforma móvil, que puede moverse
35 metros de largo y 20 metros de lado. El domo puede girar como máximo
20º en cualquier dirección.
Figura 17. Vista del domo sobre la plataforma móvil de Toyota Driving
Simulator (izquierda) y con giro de 20º (derecha) [15]
La simulación permite identificar situaciones de peligro y permite generar
escenarios en donde se pongan a prueba las habilidades del conductor.
29
Figura 18. Vista interna de la cabina del simulador ToyotaDriving Simulator
(Izquierda) y del ambiente de entrenamiento virtual del simulador [15]
Especificaciones técnicas del simulador:
Tamaño del domo: Altura: 4.5m; diámetro: 7.1m
Movilidad del domo: Max. 35m a lo largo, 20m de lado.
Inclinación del domo: Max. 25º.
Nivel de vibración: Max. Vibración de 50mm arriba o abajo.
Sensación de velocidad: Max. 0.5G
Giro: Max. 330º en cualquier dirección.
En [16] se encuentra un video que muestra el simulador en funcionamiento.
30
1.3.13. CITY BUS SIMULATOR 2010 (NEW YORK 42 STREET)
Figura 19. Vista interna del simulador City Bus Simulator 2010 en una parada
de pasajeros [17].
El simulador City Bus Simulator se sitúa en la ciudad de Nueva York
(específicamente la Calle 42 y calles aledañas). Cuenta con 3 modos de
manejo: Misiones, Campaña y mundo abierto. En general la simulación se
basa en jugar el role de “Carlos” un conductor in Manhattan y manejar una
ruta de la ciudad[17].
Para el cumplimento de la ruta, se utilizan indicadores visuales para mostrar
el lugar de la siguiente parada.
31
Figura 20. Vista interna de la cabina virtual del simulador City Bus Simulator
2010 ante una solicitud de parada [17]
Dentro de las características técnicas del simulador tenemos:
Modelos 3D de alto detalle.
Física realista que simula la robustez del suelo.
Soporte para cabrillas de carreras con simulación de ForceFeedback.
Movimiento libre dentro del bus.
6 cámaras externas además de las vistas de los espejos.
Alta calidad de sonido.
Comunicación por radio.
Pasajeros animados entrando y saliendo del bus, con voz incluida.
IA dinámica del tráfico.
Clima dinámico con luz realista y sombras.
Simulación realista de lluvias.
32
1.3.14. BUS SIMULATOR
Figura 21. Vista interna del simulador Bus Simulator en un escenario con
señales de tránsito [18].
En este simulador, se juega el rol de un conductor de bus, en donde se debe
cumplir con un plan de tiempo y transportar tantos pasajeros como sea
posible. El manejo inadecuado del bus genera reducción de puntos y multas.
Hay 8 modelos de buses (incluyendo articulados) y 18 trayectos a través de
distintos distritos[18].
La simulación puede realizarse en diferentes ambientes (nublado, con lluvia,
nieve o mucha luz solar).
Es posible ver tanto por fuera como por dentro del bus, y se tienen
indicadores que permiten evidenciar el estado actual de la simulación y los
pasos a seguir.
33
1.3.15. EURO TRUCK SIMULATOR
Figura 22. Vista del modelo de los camionesde Euro Truck Simulator [19]
Este simulador se enfoca en la simulación de camiones de carga, con una
representación fiel de algunos caminos de Europa.
Los modelos de los camiones son muy realistas, al igual que el ambiente y
los modelos de tráfico[19].
Figura 23. Vista del simulador Euro Truck Simulator, Izquierda vista superior
del vehículo, derecha vista dentro de la cabina.
34
El interior de los camiones contiene indicadores reales como luces de
advertencia para la temperatura y el nivel de combustible, velocidad actual,
entre algunos otros.
1.3.16. MassiveReadyToRunAgent
Figura 24. Vista del simulador Massive
Massive es un simulador enfocado a la creación rápida de escenarios que
satisfagan tanto las necesidades de ingenieros, desde el punto de vista de la
fidelidad de movimiento y comportamiento de la simulación, como las
necesidades de los arquitectos desde el punto de vista de un alcance rápido
y fácil.
Este simulador permite la manipulación de 6 tipos de agentes:
Agente Locomotor, que contiene una libreria completa para correr, caminar,
sentarse y quedarse de pie.
Agente de Estadio, que contiene las acciones y reacciones utilizadas en
campos deportivos, como ver un partido quieto, animar a su equipo, entre
otros.
35
Agente Ambiente, este agente realiza actividades de fondo en la simulación,
como entablar una conversación con otros Agentes Ambiente, hablar por
celular o llenar un almacén.
Agente Alboroto, creado para generar desorden público como protestas,
pánico en masa, y escenarios de desastres.
Agente de Combate con espada, utilizado comunmente en campos de
batalla, éste utiliza un escudo para defenderse y una espada para atacar.
Agente Carro, utilizado para llenar las calles con diversos tipos de vehículos,
intenta evadir colisiones y obedece las señales de tránsito.
Una característica particular del simulador es que utiliza vida artificial
(Artificial Life) como aproximación para la inteligencia artificial, esta
tecnología de vida artificial proviene del proceso de la naturaleza más que de
metodologías de simulación tradicionales; de esta forma los Agentes actúan
por sí mismos utilizando los sentidos naturales simulados de la vista, el oido
y el tacto[20].
1.3.17. UC-win/Road Drive Simulator
Figura 25. Vista del simulador Road Drive Simulator
Este simulador permite crear diversas situaciones de conducción y recrearlas
bajo completo control, además permite la fácil creación de ambientes de
carreteras y simulación en tiempo real[21].
36
El simulador además cuenta con una cabina de movimiento de 6 grados de
libertad desarrollado por Subaru, el uso de esta cabina da un mayor realismo
en el simulador.
Figura 26. Vista de la cabina desarrollada por Subaru.
Entre las situaciones de conducción, es posible crear escenarios de
accidentes que obliguen a tomar nuevas acciones que permita superar la
nueva situación.
1.3.18. Directing Crowd Simulations Using Navigation Fields
Figura 27. Vista de la lógica de CrowdSimulations.
Este sistema permite el control de multitudes virtuales utilizando campos de
navegación. Esto se realiza a través de campos de dirección que dirigen a
los agentes a las metas deseadas lo que ayuda a evitar la aglomeración de
agentes que quieren llegar a sus metas[22].
37
Los campos de dirección pueden ser dibujados por los usuarios o ser
extraídos de una secuencia de video, el sistema representa éstos campos en
espacios libres del ambiente de simulación. Debido a que las trayectorias de
los agentes están codificadas implícitamente en estos campos, es necesario
que éstas cumplan las siguientes condiciones:
Los agentes deben crear caminos de menor esfuerzo para llegar a sus
metas.
Los campos deben poder pasar alrededor de objetos estáticos en el
ambiente.
Para la representación de los campos de dirección y navegación se discretiza
el espacio libre del ambiente, a través de una grilla, en donde cada celda
tiene almacenado un vector de dirección, un estado de libre u ocupado y
maneja conexión de 4 vecinos.
1.4. COMPARACIÓN TÉCNICA ENTRE SIMULADORES:
La comparación técnica de los simuladores se desarrollará teniendo en
cuenta el contexto global de sistema mencionado en la sección 1.2.
Como primera característica, que no debe faltar en un simulador, tenemos la
física que por facilidad de comparación está dividido en 5 items: Cálculo
físicos básicos que incluyen modelos de aceleración, velocidad y
desplazamiento de los vehículos. Cálculos físicos intermedios que incluyen
modelos de transferencia de energía de un vehículo y agarre de los
neumáticos ante diversas circunstancias. Cálculos avanzados como daños
en el motor, en la suspensión y en el chasis. Cálculos de Feedback que
permita generar una realimentación mecánica en la cabina donde se
encuentra el conductor. Y finalmente la capacidad realizar simulaciones con
vehículos articulados.
Como segunda característica, Inteligencia Artificial, tenemos 2 items. El
Modelo social de peatones se encarga de modelar el comportamiento de
cada peatón. El Modelo del tráfico modela el comportamiento de cada
transeúnte en la vía teniendo en cuenta las normas de tránsito.
Como tercera característica tenemos el ambiente gráfico, que se subdivide
en 3 items. Modelos de alta definición el cual define si los modelos tienen un
alto nivel de detalle. El Modelo de la cabina que permite visualizar los
38
controles del vehículo dentro del ambiente virtual. Y los Efectos visuales de
neblina, lluvia, noche y soleado que alteran el nivel de visibilidad del
conductor en diferentes magnitudes.
En la cuarta característica tenemos el sonido, que se divide en 3 items. El
sonido generado por los automóviles donde el más representativo es el
motor. El sonido generado por los peatones o pasajeros, principalmente del
habla. Y el sonido 3D que le permite al conductor saber aproximadamente de
qué lugar se generan los 2 sonidos mencionados anteriormente.
Y como última característica pero no menos importante se encuentra la
generación de escenarios especiales el cual contiene 4 items. El
obedecimiento de las normas de tránsito. La generación seudo-aleatoria de
accidentes de tránsito con otros vehículos o peatones y el cumplimiento de
rutas para la recolección de pasajeros.
A continuación, en la Tabla 1, se muestra un cuadro de comparación en el
que se resume las características de cada simulador presentado. Como se
puede apreciar, la mayoría de los simuladores cumplen con una gran
cantidad de las características de un simulador de conducción; dentro de los
cuales vale la pena resaltar al simulador “City Bus Simulator 2010” quien
cumple con la mayor cantidad de características requeridas. En la tabla
también se ubican las características del modelo propuesto en este
documento con la implementación en CUDA, y se observa que cumple con
algunas de las características necesarias. Vale la pena resaltar que el
objetivo principal de la implementación del modelo en CUDA es poder
paralelizar el procesamiento del modelo y de esta forma permitir que la
ejecución de la simulación sea más rápida.
39
Items
Para
mic
s (
Qu
ad
sto
ne)
S-P
ara
mic
s
Dra
cu
la
Aim
su
n2
Vis
sim
Sp
ider
Sim
ula
do
r C
arw
orl
d
Ult
ima
teD
rivin
g S
imu
lato
r
Th
eJe
nti
g 5
0 S
imu
lato
r
Sti
sim
Ho
nd
a D
rivin
g S
imu
lato
r
To
yo
ta D
rivin
g S
imu
lato
r
Cit
y B
us S
imu
lato
r
Bu
s S
imu
lato
r
Eu
ro T
ruck S
imu
lato
r
Massiv
e
Ro
ad
Dri
ve S
imu
lato
r
Dir
ecti
ng
Cro
wd
Imp
lem
en
tació
n C
UD
A
Fís
ica
Cálculos Físicos Básicos SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI
Cálculos Físicos Intermedios
NO NO SI SI SI NO SI NO SI SI SI SI SI SI SI SI SI NO NO
Cálculos Físicos Avanzados
NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO
Feedback y Cabina NO NO NO NO NO NO NO NO SI SI SI SI SI SI SI NO SI NO NO
Vehículo Articulado NO NO NO NO NO NO NO NO NO NO NO NO SI SI SI NO NO NO SI
Ejecución en paralelo - GPU
NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO SI
IA
Modelo social de peatones
SI NO NO NO NO SI NO NO NO SI SI SI SI SI NO SI SI SI SI
Modelo de tráfico SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI SI NO SI
Grá
fic
o Modelos de alta definición NO NO NO NO NO NO NO SI NO NO SI NO SI NO SI SI SI SI NO
Modelo interno de cabina NO NO NO NO NO NO NO NO SI SI SI SI SI SI SI NO SI NO NO
Efectos de lluvia, neblina, nocturno y soleado
NO NO NO NO NO NO NO NO NO SI NO NO SI SI NO NO NO NO NO
So
nid
o Tráfico SI NO NO NO NO NO NO NO SI SI SI SI SI SI SI SI SI NO NO
Peatones/Pasajeros NO NO NO NO NO NO NO NO NO NO NO NO SI SI NO SI SI NO NO
3D NO NO NO NO NO NO NO NO SI NO NO NO NO NO NO NO NO NO NO
Esce
nari
os
Esp
ecia
les
Normas de tránsito SI SI SI SI SI SI NO SI SI SI SI SI SI SI SI SI SI NO SI
Accidentes vehiculares NO NO NO SI SI NO NO NO SI SI SI SI SI SI NO SI SI NO NO
Accidentes con peatones NO NO NO NO NO NO NO NO NO NO NO SI NO NO NO SI NO NO NO
Rutas NO NO NO NO NO NO NO NO NO NO NO NO SI SI SI NO NO NO SI
Tabla 1. Comparación técnica entre los simuladores.
40
2. DISEÑO
2.1. CONTEXTO DEL SISTEMA DE TRANSMILENIO:
Transmilenio S.A. es una entidad dedicada a satisfacer las necesidades de
transporte público de la ciudad de Bogotá, gestionando la prestación de un
servicio “eficiente, seguro, rentable, y sostenible”, y revisando continuamente
los procesos internos, con el fin de mantener la eficacia de la entidad [23].
Figura 28. Imagen de un bus del sistema de Transmilenio
Transmilenio S.A. tiene 8 objetivos de Calidad importantes [23], de los que
destacaremos dos: „Mejorar el nivel de satisfacción de los clientes‟ y
„Disminuir la Accidentalidad‟. Estos dos objetivos, en particular, pueden ser
monitoreados y medidos en un simulador.
Dentro de las características más singulares del sistema Transmilenio
tenemos:
41
Transmilenio posee una vía exclusiva para el tránsito de sus buses.
Todos los buses de Transmilenio de una articulación, tienen
dimensiones ([31] 15.68m de largo y 2.52m de ancho) superiores a las
de los buses urbanos comunes ([32] 10.109m de largo y 2.15m de
ancho).
Los buses de Transmilenio solo hacen paradas para recoger o dejar
salir pasajeros en las estaciones de que cubre su ruta.
Los buses de Transmilenio están sujetos a toda la normatividad
impuesta por la Secretaría de Movilidad, lo que incluye normas de
tránsito y límites de velocidad.
Aunque las vías de Transmilenio son exclusivas, en caso de
emergencia, las Ambulancias y vehículos de la Policía pueden hacer
uso de éstas.
Adicional a estas características, también se debe divisar otros escenarios
poco usuales; donde el tráfico y peatones externos al sistema no siempre
cumplen con todas las normas de tránsito, por lo que hay casos en el que
algunos peatones pueden intentar cruzar un semáforo que está en luz verde
en un cruce, y unos vehículos pueden tratar de cruzar un semáforo en rojo de
un cruce.
Un simulador adecuado para el sistema de Transmilenio debe contemplar las
características particulares mencionadas anteriormente sin desatender las
características genéricas que todo simulador realista debe contener.
Sin embargo, vale la pena aclarar que el sistema propuesto en este
documento no pretende satisfacer todas las características ya mencionadas,
sino una pequeña parte, como se encuentra definido en los objetivos.
42
2.2. ARQUITECTURA CUDA
CUDA (Compute Unified Device Architecture) es la arquitectura de cómputo
en paralelo desarrollado por nVidia, y hace referencia tanto a
un compilador como a un conjunto de herramientas de desarrollo que
permiten a los programadores usar una variación del lenguaje de
programación C para codificar algoritmos en GPUs de nVidia.
CUDA intenta explotar las ventajas de las GPUs frente a las CPUs de
propósito general utilizando el paralelismo que ofrecen sus múltiples núcleos,
que permiten el lanzamiento de un altísimo número de hilos simultáneos. Por
ello, si una aplicación está diseñada utilizando numerosos hilos que realizan
tareas independientes (que es lo que hacen las GPUs al procesar gráficos,
su tarea natural), una GPU podrá ofrecer un gran rendimiento en campos que
podrían ir desde la biología computacional a la criptografía por ejemplo[24].
En la figura 29 se muestra el arreglo típico de una GPU con
multiprocesadores. En la figura se observa la trayectoria del flujo general de
datos a través de la GPU. Los flujos de datos van desde el host al
administrador de la ejecución de hilos, que genera y sincroniza los hilos de
cada procesadorStream (SP). Cada uno de losmulti-procesadores, en la
figura 29, contiene ocho procesadores Stream. Cada procesador Stream
tiene su propia memoria, y filtro de textura (TF). Cada par de procesadores
tiene compartida una memoria caché de nivel 1 (L1). La Memoria global es
una memoria compartida que se comparte entre todos los procesadores
Stream[24].
43
Figura 29.Arreglo de Multiprocesadores de la GPU[24].
Modelo de hilos de CUDA
En la programación CUDA, las operaciones seriales aún siguen manejados
por la CPU (procesador principal), mientras que los 'Kernels' paralelizables
son entregados a la GPU para su procesamiento. Es importante entender el
diseño de la arquitectura de CUDA y de la memoria. En la figura 30 se
muestra un diagrama de bloques simplificado de un modelo de hilos típico de
CUDA[25].
44
Figura 30.Modelo de hilos de CUDA[25]
A cada Kernel se le asigna una Grilla; cada Grilla contiene una serie de
Bloques; y cada Bloque contiene un conjunto de hilos (512máximo por
bloque)[25].
Es posible tener un máximo de 8 bloques de activos por cada
multiprocesador stream o un máximo de 24 warps activos (un warp es un
conjunto de hilos que son ejecutados físicamente de forma paralela) por cada
multiprocesador stream. Con 32 hilos por warp, tenemos máximo de 768
hilos activo por multiprocesador stream. En una tarjeta como la GTX285
tenemos 23.040 hilos activos. Hay que tener en cuenta que podría no tener
suficiente de otros recursos (registros, memoria compartida, etc) para realizar
45
las tareas de manera eficiente, por lo que no basta solo con tener suficientes
hilos[25].
Modelo de memoria de CUDA
Todos los bloques 'activos' son procesados al mismo tiempo. Los Registros y
la memoria compartida de un multiprocesador se dividen entre los hilos de
los bloques activos. Cada bloque activo se divide en grupos de hilos llamado
deformaciones (warps), donde cada warp contiene el mismo número de hilos
("tamaño de warp" actualmente 32)[26].
Figura 311. Modelo de Memoria de CUDA[26]
De los 6 tipos de memoria usables en CUDA, solo se requiere utilizar 2 tipos
de memoria: la memoria de textura, en donde se almacena la textura con
46
información espacial del escenario (se explica en detalle en la Sección 3.3) y
la memoria global, en donde se almacena la posición actual y anterior de la
entidad, sus metas locales y globales (explicadas en detalle en la Sección
3.4) y el tamaño de la entidad.
2.3. VISUALIZACIÓN DE LA SIMULACIÓN
Debido a la Interoperabilidad Gráfica de CUDA, algunos recursos de
OpenGLpueden ser mapeados en el espacio de direcciones de CUDA, ya
sea para permitir a CUDA leer los datos escritos por OpenGL, o para permitir
a CUDA para escribir datos leídos por OpenGL[28].
Esto posibilita el realizar procesamiento (desde CUDA) sobre datos
(imágenes) usados en OpenGL sin la necesidad de hacer operaciones de
transferencia de información entre la memoria de GPU y la memoria de CPU.
Debido a esta razón se ha optado por usar la especificaciónOpenGL para la
visualización de gráficos de 2D y 3D.
Además de esto,en el laboratorio COLIVRI de la Universidad de los Andes se
han desarrollado diversos simuladores que realizan su visualización a través
deOpenGL.Esto puede facilitarla integración del modelo propuesto con éstos
simuladores.
2.4. ORIGEN DE LOS DATOS
Los datos geográficos de la sección de Bogotá a analizar provienen de la
Unidad Administrativa Especial de Catastro Distrital[33], ésta es la entidad
oficial encargada de las actividades relacionadas con la formación,
conservación y actualización del inventario de los bienes inmuebles situados
dentro del Distrito a partir del estudio de sus elementos físico, económico y
jurídico.
47
Dentro de los datos disponibles se obtuvieron 2 zonas, la zona con ID J41D
que abarca la estación de Transmilenio “Calle 57” y la zona J41B que abarca
la estación de Transmilenio “Calle 63”. Estos datos fueron entregados en
archivos Shape (.shp) que contienen información específica sobre los
siguientes ítems:
Vías Peatonales
Perímetro de Manzana
Malla Vial
Loteo
Límite de Manzana
Construcción
Una sección de la información de las zonas se observa en la figura 32.
Figura 32.Datos proporcionados por Catastro
48
3. IMPLEMENTACIÓN
3.1. MODELO DE SIMULACIÓN
El modelo de simulación está basado en el modelo de Autómatas Celulares.
Un autómata celular es un modelo discreto que contiene una colección de
células dentro de una grilla de n-dimensiones de tamaño conocido, las
células "evolucionan" a través de un número de pasos discretos de tiempo de
acuerdo a un conjunto de reglas basadas en el estado de las celdas vecinas
y del estado mismo de la célula [29].
Este modelo de simulación requiere que el espacio geográfico sea
discretizado en una grilla de tamaño fijo. Esto se realiza a través de un
archivo de textura, en donde el color de cada pixel representa el estado de la
celda misma[34] (ver sección 3.3).
Las reglas de las entidades (células) son simples:
1. Las entidades tratan de llegar a una meta global (un destino), a través
de una o más metas locales (ver sección 3.4).
2. Ninguna entidad puede ocupar una celda (pixel) que está siendo
ocupada por otra entidad.
3. Las entidades tipo “Peatón” pueden pasar por cualquier celda excepto
aquellas que representan edificaciones o semáforos en rojo para
peatones.
4. Las entidades tipo “Vehículo” y “Transmilenio” solo pueden pasar por
vías vehiculares, y además solo pueden moverse en la dirección que
permita la vía (ver sección 3.3). Asimismo estas entidades deben
detenerse ante semáforos en rojo para vehículos.
49
5. Las entidades tipo “Transmilenio” deben además parar en sus metas
locales de acuerdo a un tiempo definido. Las metas locales de estas
entidades representan una ruta de Transmilenio, y sus paradas son
las estaciones de Transmilenio que cubre su ruta.
3.2. COMPLEMENTACIÓN DE DATOS
La información suministrada por Catastro es bastante completa en lo
referente a predios y edificaciones, no obstante, esta carece de información
en lo que se refiere a ubicación de señales de tránsito (semáforos), dirección
de las vías, ubicación de estaciones de Transmilenio yubicación de metas
locales y globales. Esto generó la necesidadde complementar la información
disponible con otras fuentes como Google Maps.
La adición de la información se realizó usando el programa libre “Quantum
GIS” [30], el cual permite cargar, modificar y guardar los archivos Shape.
El procedimiento se realiza de manera manual; el usuario define diferentes
capas en dependencia de la información que desea agregar, y crea regiones
en cada capa.
Entre las capas,de polígonos cerrados, agregadas a la información original
tenemos:
Vías para vehículos, con dirección
Vias de Transmilenio, con dirección
Vias para peatones
Zonas de influencia de los semáforos
Estaciones de Transmilenio.
Obstáculos (edificios)
Metas locales para los Transmilenios.
Metas locales para los vehículos
Metas locales para los peatones
50
Al agregar esta información se obtuvo un modelo por capas más simplificado
pero a su mismo tiempo más completo de la región a analizar. En la figura 33
se puede observar los datos proporcionados por Catastro, y en la figura 34
se observa un modelo más simple pero a su vez más completo, con
información de metal locales, semáforos y vías en general. El color amarillo
representan edificios, el color azul representa vías peatonales, el color verde,
naranja y rojo representan el nivel de acercamiento a un semáforo y los
demás colores indican las direcciones de las vías.
Figura 33. Información original proporcionada por Catastro.
51
Figura 34.Información de Catastro enriquecida
3.3. MAPA DE TEXTURA
Debido a la interoperabilidad gráfica entre CUDA yOpenGL, se optó por
tomar una solución que permitiera hace procesamiento sobre los datos a la
vez que se visualizaban los resultados. Teniendo esto en mente se ha
codificado las características de las zonas de interés en una textura (mapa
de textura), mostrada en la figura 35, lo que permite la implementación y
optimización del algoritmo de simulación.
Esto se ha hecho aprovechando el espacio RGB con el que se representa el
color de cada pixel de una textura.Un pixel de la textura representa un área
de aproximadamente 1m2.
Por lo tanto, cada combinación de color representa las características de la
zona que se está observando.
Codificación del espacio RGB: Los bits de cada capa del espacio RGB
tienen una función muy específica que se muestra a continuación:
52
Capa Roja
Los bits (7,6,5)representan el tipo de obstáculo
111: Edificio
110: Estación
101: ViaPeatonal
100: Trasmilenio+Carro
011: Transmilenio
010: Carro
001: Concavidad en vía(hueco)
000: Libre
Los bits (4,3,2,1,0)representan el ángulo de inclinación de la zona (ya que no
todas las calles o edificios están alineados en dirección norte u oriente).
Dado que se cuentan con 5 bits, tenemos una resolución de 11.25º.
Capa Verde
Los bits (7,6,5,4) representan la dirección en la que se puede mover un
objeto en la vía.
7: dirección arriba
6: dirección abajo
5: dirección izquierda
4: dirección derecha
Obsérvese que es posible que marcar más de una dirección en una zona,
incluyendo las diagonales, sin embargo previendo el uso de más direcciones
se ha dejado 4 bits adicionales para uso futuro.
Los bits (3,2,1,0) están reservados para uso futuro.
53
Capa Azul
El bit 7representa la orientación del semáforo
1: semáforo Norte-Sur
0: semáforo Este-Oeste.
Los bits (6,5) representan la distancia hacia el semáforo con influencia más
cercado
11: Cerca
10: Medio
01: Lejos
00: Distante
Los bits (4,3,2,1,0) están reservados para la identificación de los semáforos.
El mapa de textura es generado,en una etapa de pre-procesamiento,a partir
de las regiones creadas de cada capa; estas regiones son exportadas por el
programa Quantum GIS a un archivo KML, que es un archivo en formato
XML, el cual contiene la posición geográfica de las regiones creadas. Estos
archivos KMLsson leídos por un programa generador de texturas
implementadoque integra la información de todos los KMLs generados y crea
una textura unificada o mapa de textura.
54
Figura 35. Mapa de Textura
3.4. METAS LOCALES Y METAS GLOBALES
Las metas locales, aunque definidas en las capas enriquecidas de Catastro,
no hacen parte del mapa de textura debido a que su manejo y cálculo es más
complejo. Las metas locales representan los puntos de interés de una
55
entidad en particular, y debido a esto, hay definidas 3 grupos de metas
locales, un grupo para los Transmilenios, otro grupo para los vehículos y otro
grupo para los peatones. Cada meta local posee un identificador propio y los
4 identificadores de las metas locales más cercanas en dirección norte, sur,
oriente y occidente, por lo tanto una entidad que se encuentra en una meta
local puede tomar 1 de las 4 vías disponibles hasta llegar a la siguiente meta
local, en la figura 36 se observa en rojo las 4 posibles vías de la meta local.
Figura 36. Las metas locales más cercanas a la meta local central
Una meta global es el destino inicial y final de una entidad. Una entidad debe
pasar a través de diferentes metas locales (se calcula previamente un grafo
para cada entidad) antes de llegar a una meta global. En la figura 37 se
observa un ejemplo de una meta global, dado que una entidad no puede
llegar en línea recta a su meta global, éste utiliza un conjunto de metas
locales que lo llevan a su destino.
56
Figura 37. Metas globales (inicial y final) de un peatón
3.5. PROBLEMAS DE CONSISTENCIA.
En CUDA los hilos activos se ejecutan de manera paralela, esto conlleva a
ventajas en términos de tiempo de procesamiento pero también conlleva a
desventajas en términos de consistencia, dado que una de las reglas
57
definidas en la sección 3.1 (regla 2) especifica que 2 entidades no pueden
ocupar la misma celda.
En la figura 38 se muestra dos ejemplos de movimiento interacción entre 2
peatones, en el ejemplo de la izquierda ambos peatones intentan ocupar una
celda que no está siendo ocupada por otra entidad, por lo que no hay
conflictos y ambos peatones pueden proceder. Sin embargo al observar la
figura de la derecha, se observa que 2 peatones tratan de ocupar una celda
que no está siendo ocupada por otra entidad en ese instante de tiempo, si
ambos peatones proceden a ocupar la celda en cuestión se generará un
conflicto debido a que 2 peatones quedan ocupando la misma celda.
Figura 38.Ejemplo de movimiento de peatones (Lado izquierdo sin violación a la regla 2, lado derecho con probable violación a la regla 2)
Para corregir estos conflictos se definieron 2 soluciones posibles:
3.5.1 Solución con detección y solución de conflictos en serial
Esta solución ejecuta el paso de simulación de cada tipo de entidad (Peatón,
Vehículo y Transmilenio) en 6 fases: fase de control de velocidad, fase de
paso a la siguiente celda, fase de detección de conflictos de manera serial,
fase de solución de conflictos en paralelo, una segunda fase de detección de
conflictos de manera serial y fase de solución de conflictos en serial. Con
esta solución se espera que gran parte de los conflictos sean solucionados
58
en las primeras 4 etapas y que la etapa final solo sea ejecutada para una
cantidad muy baja de entidades.
Fase 1. Control de velocidad (Paralelo):Para variar la velocidad de las
clases de entidades se ha creadoel concepto de segmentos. En cada paso
de simulación se ejecuta un segmento por cada clase de entidad, un
segmento puede contener varias entidades, pero una entidad solo puede ser
contenida por un segmento.La velocidad de las entidades es igual para cada
clase de entidad, entre más velocidad tenga un tipo de entidad, menos
segmentos son creados y más veces es ejecutado cada segmento en un
segundo. Para la creación de segmentos se le asigna un identificador
numérico a cada entidad, y por orden numérico se asigna un segmento.
Segmento 1 2 3 4 …
Entidad 1 2 3 4 5 6 7 8 9 10 …
Figura 39. Ejemplo de asignación de segmentos
En la figura 39 se muestra un ejemplo de la asignación de entidades, el
segmento 1 contiene a las entidades 1, 2 y 3; el segmento 2 contiene a las
entidades 4, 5 y 6; y así sucesivamente. Cuando el segmento 1 es ejecutado,
solo las entidades 1, 2 y 3 son ejecutadas, de igual forma ocurre para la
ejecución de las entidades de otros segmentos.
Paso Simulación Segmento Paso Simulación Segmento
1 1 1 1
2 2 2 2
3 3 3 1
4 4 4 2
5 5 5 1
6 6 6 2
7 1 7 1
Figura 40. Ejemplo de ejecución de 2 segmentos de diferentes velocidades.
59
En la figura 40 se muestra un ejemplo de la ejecución de dos clases de
segmentos de diferentes velocidades en cada paso de simulación;en la tabla
izquierda se muestra la ejecución de los segmentos de un tipo de entidad de
baja velocidad (Peatones), y al lado derecho los segmentos de un tipo de
entidad de alta velocidad (Vehículos). Como se puede observar, para el tipo
de entidad Peatón se crea una mayor cantidad de segmentos, que son
ejecutados en cada paso de simulación; mientras que para el tipo de entidad
Vehículo se crea una menor cantidad de segmentos. Para este ejemplo dos
segmentos son ejecutados por paso de simulación (uno por cada clase de
entidad). Si se compara el segmento 1 para cata tipo de entidad, se puede
apreciar que éste segmento es ejecutado más veces para el tipo de entidad
Vehículo, lo que significa que las entidades tipo Vehículo se ejecutan/mueven
más rápido que las entidades tipo Peatón.
Fase 2.Paso a la siguiente celda (Paralelo):En la fase 2 se realiza
elmovimiento a celdas adyacentes libresde manera paralela para aquellos
segmentos que deban realizar su paso de simulación; sin embargo como se
mostró en la sección 3.5, esto puede generar conflictos. En esta fase, se
ejecuta el siguiente código simplificado, que se ejecuta de manera paralela
para todas las entidades del segmento activo:
for (cada entidad del segmento activo){
hallarSiguienteSaltoDeCelda();
ocuparSiguienteCelda();
}
En hallarSiguienteSaltoDeCelda(), Si la señal de tránsito lo permite se calcula
la ubicación de la celda adyacente que me acerca más a la próxima meta
local, sin embargo si la celda se encuentra ocupada por otra entidad, es un
60
obstáculo (como los edificios), o no es una vía permitida (vía en sentido
contrario para el caso de vehículos) se busca otra celda adyacente libre que
acerque la entidad a la meta local, si no se encuentra en este momento
celdas adyacentes libres, la entidad no realiza un salto de celda.
If(semáforo está muy lejos o en verde){
distanciaEnX=posiciónMetaLocalX-posiciónActualEntidadX;
distanciaEnY=posiciónMetaLocalY-posiciónActualEntidadY;
if(|distanciaEnX|>umbral)
calcularNuevoX();
if(|distanciaEnY|>umbral)
calcularNuevoY();
if(hay obstáculo en nuevoX y nuevoY o no es una via permitida)
calcularNuevaPosicion();
}
En ocuparSiguienteCelda(), se reescribe en el mapa de textura la posición de
la entidad, sin borrar la posición anterior de la entidad (la posición anterior no
se borra hasta que se puede estar seguro que no hay conflictos en la nueva
posición)
Fase 3. Detección de conflictos (Serial): Se detectan las entidades en
conflicto, producto de la realización de la fase 2.
for (cada entidad del segmento activo){
for (las demás entidades del segmento activo){
if(hay otras entidades ocupando el mismo espacio que ocupo)
marcarEnConflicto();
}
}
Fase 4. Solución de conflictos (Paralela):En esta fase se resuelven los
conflictos entre las entidades de manera paralela, esta fase hace que las
61
entidades evalúen una nueva posición para su desplazamiento; por supuesto
al realizar esta fase en paralelo las entidades pueden entrar en nuevos
conflictos (distintos al conflicto inicial).
for (cada entidad del segmento activo y marcada con conflicto){
if(entre las entidades en conflicto, ésta posee el id más bajo)
borrarPosicionAnterior(); //esto implica que esta entidad tiene prioridad y
toma posesión de la celda en conflicto
else //para todas las demás entidades
hallarSiguienteSaltoDeCelda();
ocuparSiguienteCelda();
}
Fase 5. Detección de conflictos (Serial):Se detectan las entidades en
conflicto, producto de la realización de la fase 3 (la implementación es
exactamente igual que la realizada en la fase 2).
Fase 6.Solución de conflictos (Serial): Se resuelven los conflictos entre las
entidades detectadas en la fase 4 de manera serial, esta fase hace que las
entidades reevalúen una nueva posición para realizar su desplazamiento, sin
embargo como esta fase se realiza de manera serial, no se vuelven a
presentar conflictos entre entidades (la implementación es exactamente igual
que la realizada en la fase 4, con la diferencia que se procesa de manera
serial).
En la figura 41 se puede observar el comportamiento de esta solución al ser
ejecutado con diferentes cantidades de entidades, y el tiempo tomado para
realizar un paso de simulación. Nótese que al aumentar la cantidad de
entidades, aumenta significativamente la cantidad de tiempo necesario para
ejecutar un paso de simulación. El tiempo del paso de simulación de las
62
entidades tipo peatones es significativamente más pequeño que el tiempo
utilizado por vehículos y Transmilenios, esto se debe principalmente al hecho
que las entidades tipo peatones ocupan menos celdas en el espacio de
simulación, lo que implica que hacen menos cálculos por paso.
Figura 41. Tiempo tomado para procesar un paso de simulación.
3.5.2 Solución con detección y solución de conflictos en paralelo
Esta solución ejecuta el paso de simulación de cada tipo de entidad (Peatón,
Vehículo y Transmilenio) en 4 fases: fase de control de velocidad, fase de
paso a la siguiente celda con detección de conflictos, fase de solución de
conflictos en paralelo con detección de nuevos conflictos y fase de solución
de conflictos final. Con esta solución se espera que el tiempo necesario para
ejecutar un paso de simulación disminuya debido a que no hay fases en
serie. La fase 1 posee el mismo algoritmo que el explicado en la sección
3.5.1, por esta razón se omitirá su explicación en esta sección.
63
Fase 2. Paso a la siguiente celda con detección de conflictos (Paralelo):
En esta fase se realiza el mismo procedimiento que en la fase 2 de la sección
3.5.1, con la única diferencia que, adicional al mapa de texturas, se utiliza un
mapa de entidades, en donde en la celda que se quiere ocupar se escribe el
número de identificación de la entidad:
For (cada entidad del segmento activo){
hallarSiguienteSaltoDeCelda();
ocuparSiguienteCelda();
escribirEnMapaDeIDs();
}
En escribirEnMapaDeIDs(), se escribe el identificador de la entidad en un
mapa similar al mapa de texturas. La idea de utilizar un mapa adicionar es el
permitir la realización de detección de conflictos en paralelo, en la figura 42
se puede observar el procedimiento, en (a) se puede apreciar cómo sería el
comportamiento con el mapa de textura; dos entidades con IDs 8 y 20
intentan ocupar la misma celda libre, y entran en conflicto, en (b) éstas dos
entidades intentan escribir su identificador en la misma celda del mapa de
entidades, sin embargo como la ejecución es en paralelo, una entidad
necesariamente sobrescribirá los datos de la otra entidad, quedando en (c)
un solo identificador en la celda.
Ahora para detectar los conflictos, cada entidad debe revisar el identificador
que ha quedado en las celdas del mapa de entidades. Si el identificador
escrito en la celda no corresponde a su identificador, significa que ha tenido
conflicto con otra entidad; de lo contrario, pudo pasar una de dos cosas: no
tuvo conflicto con otra entidad, o puede que sí pero tiene prioridad al el
momento de tomar la celda, y son las demás entidades las que deberán
recalcular sus posiciones.
64
Figura 42. Mapa de textura (a) y mapa de entidades (b) y (c).
Fase 3. Solución de conflictos (Paralela): En esta fase se resuelven los
conflictos entre las entidades de manera paralela, similar a la fase 4 de
3.5.1con la diferencia que se usa el mapa de entidades para detectar los
conflictos y se escribe en el mapa de entidades las nuevas posiciones
tomadas.
for (cada entidad del segmento activo){
if(celda en mapa de entidades posee el mismo id que la entidad)
borrarPosicionAnterior(); //esto implica que esta entidad no tiene conflictos o
tiene prioridad y puede tomar posesión de la celda
else //para todas las demás entidades
hallarSiguienteSaltoDeCelda();
ocuparSiguienteCelda();
escribirEnMapaDeIDs();
}
Fase 4. Solución final de conflictos (Paralela): En esta fase se resuelven
los conflictos entre las entidades de manera paralela, dado que esta fase se
realiza en paralelo, cualquier nuevo movimiento puede generar conflictos, por
esta razón no se generan movimientos nuevos, las entidades que no tienen
prioridad (cuyo id no está en la celda del mapa de entidades) se devuelven a
su posición anterior que es consistente y sin conflictos dado que su posición
20
8
65
no había sido liberada aún y las entidades con prioridad terminan de tomar
posesión de la nueva celda al borrar su posición anterior.
for (cada entidad del segmento activo){
if(celda en mapa de entidades posee el mismo id que la entidad)
borrarPosicionAnterior(); //esto implica que esta entidad no tiene conflictos o
tiene prioridad y puede tomar posesión de la celda
else //para todas las demás entidades
regresarPosiciónAnterior();
}
En la figura 43 se puede observar una vista global de un paso de
simulación.En un paso de simulación se ejecutan 3 kernels de manera
consecutiva, uno para cada tipo de entidad, en cada kernel se conforma las
fases mostradas en la sección 3.5.1, y cada fase es ejecutada por un thread
si es serial o N threads si es paralelo. Si una fase es ejecutada por N threads,
cada thread procesa la acciones de una entidad.
Figura 43. Vista global del paso de simulación.
A diferencia del Kernel Peatón, los Kernels Vehículo y Transmilenio, tienen
entidades de tamaño variable (actualmente 2x3 para vehículos y 2x18 para
Transmilenios), las fases se ejecutan de manera similar a la descrita en la
66
sección anterior, la única diferencia es que la toma de decisiones, en vez de
realizarse ocupando una celda, se realiza manipulando el conjunto de celdas
que representa la parte frontal del vehículo.
En la figura 44, se puede observar el tiempo necesario para realizar un paso
de simulación para la entidad tipo peatón, se aprecia que la solución con
detección de conflictos en paralelo requiere menos tiempo para realizar un
paso de simulación cuando la cantidad de entidades es alta y que el tiempo
se mantiene relativamente constante (inicial de 2.41ms y final de 2.8ms).
Realizando regresión lineal se obtiene que el incremento de tiempo por
entidad es aproximadamente 0,0560useg/entidad y 0,6542useg/entidad para
la solución de detección de conflictos en paralelo y en serial respectivamente.
Esto significa que la detección de conflictos en paralelo incrementa menos el
tiempo de simulación a medida que aumenta la cantidad de entidades.
Figura 44. Comparación entre rendimiento de detección de conflictos en serie y en paralelo para entidades de tipo peatón.
67
En la figura 45 y 46se aprecia el tiempo requerido para realizar un paso de
simulación de las entidades vehículo y Transmilenio respectivamente. Los
tiempos de los pasos de simulación de estas entidades es bastante similar
debido a que los algoritmos de sus pasos de simulación son igual de
complejos.
Figura 45. Comparación entre rendimiento de detección de conflictos en serie y en paralelo para entidades de tipo vehículo.
Realizando regresión lineal se obtuvo que el incremento de tiempo por
entidad es aproximadamente 0,0589useg/entidad y 1,6990useg/entidad para
la solución de detección de conflictos en paralelo y en serial respectivamente.
Esto demuestra que la solución con detección de conflictos en paralelo es
más eficiente.
68
Figura 46. Comparación entre rendimiento de detección de conflictos en serie y en paralelo para entidades de tipo Transmilenio.
69
4. RESULTADOS
4.1 CARACTERÍSTICAS EQUIPO DE DESARROLLO
Actualmente, el equipo en el que se está desarrollando el proyecto posee las
siguientes características técnicas para CUDA (obtenido usando
deviceQuery, un programa que viene en el SDK de CUDA) [27].
CPU: Intel Core 2 Duo CPU T9550 @2.66GHZ (2 CPUs)
RAM: 4GB
GPU: nVidiaQuadro 4600 FX
Global Memory: 766705664 bytes
Multiprocessor: 12 Multiprocessors X 8 Cores (96 Cores)
ConstantMemory: 65536 bytes
SharedMemory per Block: 16384 bytes
Registersavailable per block: 8192
WarpSize: 32
Maximummemory pitch: 2147483647 bytes
Texturealignment: 256 bytes
Clockrate: 1.2GHz
Max Gridsize (blocks): 65535x65535x1
Max Block size (threads): 512x512x64
El simulador ha sido probado bajo diferentes cantidades de entidades, y en
general la velocidad de los pasos de simulación es bastante alta, la medición
detecta cuantos cuadros por segundo puede ejecutar el simulador y cuánto
tiempo demora un paso de simulación. A continuación se muestran los
parámetros de simulación:
70
Número de peatones: 1000
Número de vehículos: 100
Número de Transmilenios: 40
Número de estaciones de Transmilenio: 2
Número de vagones por estación: 8
Número de semáforos: 10
Figura 47. Simulador en funcionamiento
Bajo estas condiciones, el simuladordemora aproximadamente 2.6ms (un
paso de simulación) en evaluar la toma de decisión de más de 1000
entidades, por lo tanto la velocidad de actualización del simulador es
aproximadamente 400FPS. En la figura 47 se observa una captura del
71
simulador en funcionamiento, los puntos verdes representan los peatones,
los puntos blancos representan los vehículos y los puntos rosados
representan los Transmilenios.
4.2 COMPARACIÓN ENTRE CPU Y GPU:
Para determinar qué tan eficiente es el procesamiento en GPU contra el
procesamiento en CPU, se ha realizado 2 versiones del paso de simulación,
una en GPU y otra en CPU, y se ha tomado el tiempo necesario para realizar
un paso de simulación y visualizar los resultados. Hay que tener presente
que el procesamiento en CPU es completamente serial, por lo tanto el paso
de simulación puede ser realizado en una única fase dado que no se
presentan conflictos (a diferencia de las versión en GPU que para solucionar
los conflictos se deben realizar 4 fases).
En la figura 48, figura 49 y figura 50 se observa la gráfica del comportamiento
de cada versión para los diferentes tipos de entidades, junto con unos límites
inferiores que no pueden ser superados. Para entender estos límites hay que
tener en cuenta que el mapa de textura se visualiza utilizando OpenGL y que
si no se realizan cambios en la textura, OpenGL demora alrededor de 1.61ms
redibujando la textura en la pantalla por lo tanto este es un límite inferior que
no se puede ser sobrepasado por la versión de GPU ni por versión de
CPU.Asimismo para el otro límite se ha hecho un kernel para la actualización
del mapa de textura por GPU, en donde cada pixel del mapa de textura es
actualizado por un hilo de la GPU y tiene un conjunto de instrucciones
mínimas, esta actualización demora alrededor de 2.13ms por lo tanto la
versión de GPU no puede ir más rápido que este valor.
La figura 48muestra que el tiempo de paso de simulación para la versión de
GPU es más bajo que la versión de CPU y a medida que aumenta el número
72
de peatones el tiempo de paso de simulación aumenta más para la versión
de CPU que para la versión en GPU. Al realizar regresión lineal se encuentra
que el incremento de tiempo es aproximadamente 0,0560useg/entidad y
0,1228useg/entidad para la versión de GPU y CPU respectivamente; esto
hace más adecuada la versión de GPU para un número mayor de entidades.
Figura 48. Tiempo de paso de simulación de CPU y GPU para entidad tipo peatón.
En la figura 49 y figura 50, se observa el mismo comportamiento para las
entidades tipo vehículo y Transmilenio, con incrementos de tiempo de
0,0589useg/entidad y 0,1252useg/entidad para las versiones de GPU y CPU
respectivamente en la entidad tipo vehículo; y 0,0582useg/entidad y
0,1369useg/entidad para la entidad tipo Transmilenio.
73
Figura 49. Tiempo de paso de simulación de CPU y GPU para entidad tipo vehículo.
Figura 50. Tiempo de paso de simulación de CPU y GPU para entidad tipo Transmilenio.
74
5. LIMITACIONES
5.1. LIMITACIONES POR HARDWARE
El simulador ha sido desarrollado utilizando arquitectura CUDA, por lo
que solo puede ser ejecutado en equipos con tarjetas gráficas nVidia
de la serie 8XXX o superior.
Además hay que tener en cuenta que aunque la arquitectura de CUDA
permite crear una gran cantidad de hilos para ser ejecutados de
manera paralela, físicamente la GPU tiene una cantidad limitada de
núcleos (la tarjeta gráfica nVidiaQuadro 4600 FX tiene 96 núcleos); la
cantidad de hilos que se ejecutan paralelamente tiene una relacióncon
la cantidad de núcleos físicos, y esta cantidad varía de tarjeta a tarjeta.
Esto implica que si se crea un número de hilos superior a la cantidad
de núcleos físicos, el desempeño del simulador puede disminuir
significativamente dado que algunos hilos tendrán que esperar para
ser ejecutados;y esto se refleja directamente en la cantidad de
entidades que se pueden crear en el simulador. No obstante este
límite puede ser mejorado atacar al mejorar la tarjeta gráfica o
distribuir el procesamiento entre múltiples tarjetas gráficas, pero esto
no hace parte de los objetivos de este trabajo.
5.2. LIMITACIONES DE SOFTWARE
Debido a la cantidad tan alta de entidades a veces se generan
problemas leves de aglomeración en ciertas zonas de la simulación,
como se aprecia en la figura 51.
75
Figura 51. Problemas de aglomeración de entidades
Se ha observado que generalmente estas aglomeraciones se generan
principalmente cuando muchas entidades intentan ir por una misma
vía lo que hace que las entidades tengan que moverse de su ruta
original y terminen en algún punto bloqueadas.
Una de las razones de posibles aglomeraciones se muestra en la
figura 52.
Figura 52. Problema de meta global obstruida
76
En la figura 52se observa a un peatón cuya siguiente meta local se
encuentra en la esquina inferior izquierda, sin embargo hay un
obstáculo en el medio, por lo que el peatón intenta rodear, en el caso
de la imagen de la izquierda, al no poder acercarse más el peatón
opta por moverse a la celda de la derecha, quedando en la posición
que se muestra en la imagen de la derecha, en este punto el peatón
evalúa de nuevo las opciones para llegar a su meta local, y encuentra
que la celda de la izquierda lo acerca más a su meta global, dado que
entre todos sus vecinos, éste tiene la distancia más corta hacia la
meta local. Cuando el peatón se mueve a su izquierda queda en
posición igual a la imagen de la izquierda, haciendo que suceda un
lazo sin fin, por lo que el peatón no puede llegar a su meta local, y se
vuelve un obstáculo para otros peatones que pasen por esta vía.
El simulador solo contiene 2 valores para los semáforos, rojo y verde,
no se ha implementado un valor intermedio (amarillo) para éstos.
Además no cuenta con otros tipos de señales de tránsito.
Las entidades toman decisiones para su movimiento solo analizando
las celdas vecinas más cercanas (8 celdas vecinas), por lo que las
decisiones que pueden tomar son limitadas y no pueden solucionar
problemas como el mostrado la figura 52; esto requiere ampliar el
campo de visión de las entidades para que tengan en cuenta celdas
más lejanas y poder tomar decisiones más inteligentes.
Los vehículosno poseen control de aceleración y frenado.
77
6. TRABAJO FUTURO
Además de solucionar las limitaciones de software mostradas en la
sección 5.2 sería interesante realizar la visualización de las entidades
en un modelo en 3D, como el proyecto de grado “Desarrollo de
visualización realista para ambiente urbano en Nvidiascenix ”[38]
que posee el modelo 3D de las región geográfica que utiliza este
proyecto, como se muestra en la figura53.
Figura 53. Modelo 3D de la región geográfica comprendida entre la
Calle 53 y Calle 63
Además el proyecto posee los modelos de los Transmilenios y sus
estaciones como se observa en la figura 54, estos modelos no son
animados debido a la falta de un modelo de simulación.
78
Figura 54. Modelo en 3D de Transmilenios y estaciones.
El laboratorio Colivri posee diversos simuladores de tráfico con
complejos modelos que requieren alto nivel de procesamiento,
realizados en CPU. Este proyecto muestra un conjunto de técnicas
con el que se puede aprovechar el procesamiento en paralelo
característico de las GPUs y cómo solucionar los conflictos que
pueden presentarse, producto del procesamiento paralelo.
Cada entidad tiene una ruta precalculada que sigue en el momento de
ejecución, sin embargo esta ruta no varía una vez una entidad llega a
su meta global, por lo que sería interesante poder asignar de manera
dinámica rutas alternas una vez la entidad ha llegado a su meta, ya
sean rutas aleatorias, o definidas por el usuario.
Una carretera normalmente posee 2 o más carriles (o lanes),
actualmente no hay control para el cambio de carriles, por lo que
puede presentarse más aglomeración de vehículos en un carril que en
otro. Una manera de solucionar esto puede ser definiendo un carril de
79
alta velocidad y otro de baja velocidad para que los vehículos puedan
transitar sin obstaculizar tanto a otros que tienen una ruta distinta.
Los semáforos no cuentan con una “luz” amarilla, que sirva como un
paso intermedio entre la luz roja y verde. Este paso intermedio puede
ayudar a que el cambio de aceleración de los vehículos sea más
suave (ya sea para avanzar o frenar), sin embargo es necesario tener
en cuenta el estado anterior del semáforo para tomar una decisión
más adecuada.
Los 3 Kernels para cada tipo de entidad se ejecutan globalmente en el
paso de simulación de forma serial, una gran optimización que podría
realizarse es unificar los 3 Kernels en solo uno para que el paso de
simulación no contenga ningún tipo de serialización. Sin embargo hay
que tener presente que el comportamiento de cada entidad es
diferente, y hay que representar correctamente este comportamiento,
aún si es un solo Kernel.
El proyecto no tiene en cuenta el intercambio peatonal que se da en
las estaciones de Transmilenio, lo cual sería interesante de
implementar, de tal forma que un peatón pueda tomar una ruta de
Transmilenio para acercarse más a su meta global, y que este
intercambio peatonal se refleje en los tiempos de espera de los
Transmilenios y en la congestión que se puede generar en las
estaciones.
80
7. CONCLUSIONES
La implementación del simulador en base a CUDA ha mostrado
buenos tiempos de procesamiento, sobre todo al realizarse la
detección de conflictos de manera paralela y no serial.
La versión en GPU es significativamente más rápida que la versión en
CPU, aun cuando la versión en CPU se realiza con tan solo una fase
para el paso de simulación y no con 4 fases como es el caso de la
versión en GPU.
Aunque el simulador no cuenta con una gran cantidad de parámetros
de tráfico, es una buena aproximación que puede ser expandido para
satisfacer otro tipo de requerimientos funcionales.
81
8. BIBLIOGRAFIA
[1]Statistics Canada (2010).Microsimulation.Canadá.
Disponible en:
http://www.statcan.gc.ca/microsimulation/index-eng.htm
[2]ViknashvaranNarayanasamy, KokWai Wong, Chun Che Fung y Arnold
Depickere. Distinguishing Simulation Games from Simulators by considering
Design Characteristics.Proceedings of the second Australasian conference
on Interactive entertainment.Páginas: 141-144. 2005. ISBN: 0-9751533-2-3.
[3]MONASH University Accident Research Centre (2010).Driving simulators
and instrumented vehicles.Australia.
Disponible en:
http://www.monash.edu.au/muarc/projects/simulator/history.html
[4]QuadstoneParamics (2010). Paramics (Quadstone).Reino Unido.
Disponible en:
http://www.paramics-online.com/complex-junctions.php
[5]SIAS TransportPlanners (2010). SIAS.Reino Unido.
Disponible en:
http://www.sias.com/ng/sparamicshome/sparamicshome.htm
[6]Ronghui Liu, Ian Wright (2010). DRACULA.Reino Unido.
Disponible en:
http://www.its.leeds.ac.uk/software/dracula/
[7]John T Hughes (2010). AIMSUN2 Simulation of a Congested Auckland
Freeway.Nueva Zelanda.
Disponible en:
http://www.aimsun.com/hughes.pdf
[8]The Traffic Group, Inc. Services (2010).VISSIM. Estados Unidos.
Disponible en:
http://www.trafficgroup.com/services/vissim.html
82
[9]Sergio Arturo Ordóñez (2010).Plataforma de Micro-Simulación Escalable y
Multimodal para Evaluar Movilidad Urbana en Escenarios no
Convencionales. Colombia.
Disponible en:
http://biblioteca.uniandes.edu.co/
[10]Marcus Hewat (2010). Simulador CarWorld. Francia.
Disponible en:
http://carworld.sourceforge.net/
[11]UCDS (2010). UltimateDriving Simulator. España.
Disponible en:
http://www.ucds.es/index.php
[12]ST Software (2010). Car Driving Simulator Software.Países Bajos.
Disponible en:
http://www.stsoftware.nl/lessons.html
[13]Systems Technology, Inc (2010). STISIM.EstadosUnidos.
Disponible en:
http://www.stisimdrive.com/our-solutions.html
[14]Honda (2010). Honda Driving Simulator.Japón.
Disponible en:
http://world.honda.com/news/2010/c100302Automobile-Driving-Simulator/
[15]Toyota (2010). Driving Simulator. Japón.
Disponible en:
http://www.toyota-future.com/EN/#/technology_library/top/synap_a6/detaila6
[16]Toyota (2010). Toyota's Driving Simulator.Japón.
Disponible en:
http://www.youtube.com/watch?v=Bi_GkDqON_s
[17]TML-Studios (2010). City Bus Simulator 2010.Alemania. Disponible en:
http://www.citybussimulator.com/index.php?id=265&L=1
83
[18]TML-Studios (2010). Bus Simulator.Alemania.
Disponible en:
http://www.bussimulatorgame.com/
[19] SCS Software (2010). EURO Truck Simulator.República Checa.
Disponible en:
http://www.eurotrucksimulator.com/
[20] MASSIVE SOFTWARE (2011). Massive Ready To Run Agents
Disponible en: http://www.massivesoftware.com/massiveagents.html
[21] FORUM8 (2011). UC-win/Road Drive Simulator
Disponible en: http://www.forum8.co.jp/english/uc-win/road-drive-e.htm
[22]SachinPatil,Jur van den Berg,SeanCurtis,MingLin,DineshManocha,
(2010). Directing Crowd Simulations Using Navigation Fields.IEEE
Transactions on Visualization and Computer Graphics.
[23]Transmilenio S.A. (2010). Gestión de Calidad. Colombia.
Disponible en:
http://www.transmilenio.gov.co/WebSite/Contenido.aspx?ID=TransmilenioSA
_QuienesSomos_MisionVisionValoresCorporativos
[24] NVIDIA (2010). CUDA Zone. Estados Unidos.
Disponible en:
http://www.nvidia.com/object/cuda_home_new.html
[25]NC STATE University (2010). CSC/ECE.Estados Unidos.
Disponible en:
http://pg-
server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_506_Spring_2011/
ch2a_mc&printable=yes
[26]University of Illinois at Chicago (2010). GPGPU Concepts and CUDA.
Estados Unidos.
Disponible en:
84
http://www.evl.uic.edu/aej/525/lecture05.html
[27]NVIDIA (2010). CUDA Toolkit 3.2. Estados Unidos.
Disponible en:
http://developer.nvidia.com/cuda-toolkit-32-downloads
[28]NVIDIA (2010). NVIDIA CUDA programming Guide. Estados Unidos.
Disponible en:
http://developer.download.nvidia.com/compute/cuda/3_0/toolkit/docs/NVIDIA_
CUDA_ProgrammingGuide.pdf
[29]WolframMathWorld (2010). CellularAutomaton. Estados Unidos.
Disponible en:
http://mathworld.wolfram.com/CellularAutomaton.html
[30]QGIS (2010). Quantum GIS. Canadá/Estados Unidos.
Disponible en:
http://www.qgis.org/
[31]Volvo S.A. (2010). B9S Articulado Piso Bajo. Brasil.
Disponible en:
http://www.volvobuses.com/SiteCollectionDocuments/VBC/Brasil%20-
%20ILF/Downloads/l%C3%A2mina%20B9SALF_esp_final.pdf
[32]Navistar Inc. (2010). 3000 RE. Estados Unidos.
Disponible en:
http://www.internationalcamiones.com/LatinAmerica/3000RE_detail.html
[33]Catastro (2010). Unidad Administrativa Especial de Catastro Distrital.
Colombia.
Disponible en:
http://www.catastrobogota.gov.co/libreria/php/decide.php?patron=01.0107&di
vs=true
[34]InnovaTecno (2010). Autómata Celular. España.
Disponible en:
http://www.innovatecno.com/Automata.php
85
[35] Jason Sanders, Edward Kandrot (2010). CUDA by Example - An
Introduction to General-Purpose GPU Programming, Ed. Addison-Wesley
[36] David B. Kirk, Wen-meiW.Hwu (2010). Programming Massively Parallel
Processors, A Hands-on Approach, Ed. Morgan Kaufmann.
[37] Gabriel A. Wainer (2009). Discrete-Event Modeling and Simulation - A
practitioner‟s Approach. Ed Taylor & Francis Group.
[38] German A. Florez (2010). Desarrollo de visualización realista para
ambiente urbano en NvidiaScenix . Biblioteca Universidad de los Andes,
Colombia.
