Embed Size (px)
Citation preview
CENTRO DE CIENCIAS BÁSICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN
TESIS
DISEÑO DE MODELO ARQUITECTÓNICO PARA LA IMPLEMENTACIÓN DE TRANSPORTE URBANO BAJO LAS ARQUITECTURAS DE MOVILIDAD
INTELIGENTE DE SMART CITIES Y EL USO DE CLOUD COMPUTING
PRESENTA
Ing. Raul Alejandro Velasquez Ortiz
PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS EN LA
COMPUTACIÓN
TUTOR
Dr. Francisco Javier Álvarez Rodríguez
INTEGRANTES DEL COMITÉ TUTORAL
Dr. Miguel Vargas Martin Dr. Julio César Ponce Gallegos
Aguascalientes, Ags, 24 de enero del 2020
AUTORIZACIONES
AGRADECIMIENTO
Agradezco a la Universidad Autónoma de Aguascalientes por admitirme en tan hermoso
programa de posgrado, el cual cambio mi vida y al Consejo Nacional de Ciencia y
Tecnología (CONACYT) por financiar y becar esta investigación con número 825092.
A mi comité tutoral, comenzando con mi tutor, el Dr. Francisco Javier Álvarez Rodríguez,
por su apoyo en todo momento, por la confianza en aceptarme como alumno a asesorar
durante esta estancia y por la dirección y apoyo en todo momento al proyecto de tesis, así
como la confianza en que podría realizar una estancia de investigación internacional,
De igual manera a mi cotutor, el Dr. Miguel Vargas Martin, el cual me dio la dirección y
grandes consejos a mi trabajo de investigación, así como nuevos objetivos de vida
profesional a seguir desarrollando. De igual manera a la Ontario Tech University por
recibirme por un periodo de 120 días y del mismo modo a la ciudad de Oshawa, en Canadá.
Para finalizar a mi asesor, el Dr. Julio Cesar Ponce Gallegos por su siempre correcta
corrección e ideas al proyecto, por su paciencia y el interés siempre atinado y puntual al
trabajo realizado.
A mi nueva familia, la familia MCCMA, mis compañeros de generación de la maestría
que siempre me apoyaron y vivimos grandes aventuras juntos, nunca los olvidare, siempre
estarán en mi corazón: José, Vanessa, Liliana, Aldo, Eduardo, Jorge, Yair y Rubén.
A mi familia y amigos por siempre obtener su apoyo incondicional durante la estancia de la maestría.
DEDICATORIAS
A Dios, por darme la oportunidad de vivir esta experiencia y completarla, sin él, nada de
esto hubiera sido posible.
A mi madre Antonia Ortiz Lara y a mi padre Raul Velasquez López, por haberme guiado
y forjado a ser la persona que soy en la actualidad; muchos de mis logros se los debo a
ustedes, incluyendo este. Gracias, padres míos, gracias de verdad por todo lo que me han
dado. Así mismo a mis hermanas, por siempre escuchar mis problemas y apoyarme.
A mis amigos por siempre estar apoyándome en todo momento, por escucharme y no
dudar de mí en ningún momento.
Y, por último, por motivarme a estudiar la maestría, y que, si bien no estas presente
físicamente, gracias por creer en mí, en que podría ingresar y lograr este nuevo grado
académico, muchísimas gracias por todo, Giselle Adriana Torres Hernández.
1
ÍNDICE GENERAL
INTRODUCCIÓN ......................................................................................................... 10
CAPÍTULO I: FORMULACIÓN DE LA INVESTIGACIÓN .................................. 14 1.1. Antecedentes .................................................................................................... 14
1.2. Planteamiento del Problema ........................................................................... 18
1.3. Preguntas de Investigación ............................................................................. 20
1.4. Justificación ..................................................................................................... 21
1.5. Hipótesis ........................................................................................................... 22 1.6. Objetivo General ............................................................................................. 23
1.7. Objetivos Específicos ....................................................................................... 24
1.8. Comentarios sobre el capítulo ........................................................................ 25
CAPÍTULO II: MARCO TEÓRICO ........................................................................... 26 2.1. ¿Qué es una ciudad? ........................................................................................ 26
2.2. Ciudad Inteligente (Smart City) .................................................................... 27
2.2.1. Capa de Servicios ..................................................................................... 30
2.2.2. Capa Digital o de Datos ........................................................................... 30 2.2.3. Capa de Infraestructura .......................................................................... 30
2.2.4. Big Data ..................................................................................................... 30
2.2.5. Big Data Analitics ..................................................................................... 31
2.2.6. Internet de las Cosas ................................................................................ 32 2.2.7. Protocolos de comunicación .................................................................... 33
2.2.8. Red abierta ................................................................................................ 33
2.3. Global Positioning System (GPS) ................................................................... 35
2.4. Digitalización ................................................................................................... 35 2.5. Implicación de Smart Cities ........................................................................... 36
2.6. Smart Mobility ................................................................................................. 37
2.7. Cloud Computing ............................................................................................ 38
2.7.1. Cliente........................................................................................................ 40
2.7.2. Software como servicio (SaaS) ................................................................ 41 2.7.3. Plataforma como Servicio (PaaS) ........................................................... 41
2
2.7.4. Infraestructura como Servicio (IaaS) ..................................................... 41
2.7.5. Servidor ..................................................................................................... 41 2.7.6. Seguridad en Cloud Computing.............................................................. 42
2.8. Arquitectura de seguridad en Cloud Computing ......................................... 46
2.9. Arquitectura Cloud Computing implementado en Smart Cities ................ 47
2.10. Arquitecturas para Smart Cities .................................................................... 49 2.10.1. Capas Arquitectónicas ............................................................................. 49
2.10.2. Arquitectura Orientada a Servicios ........................................................ 49
2.10.3. Arquitectura Basada en Evento .............................................................. 50
2.10.4. Internet of Things ..................................................................................... 50 2.10.5. Arquitecturas Combinadas ..................................................................... 50
2.10.6. Internet of Everything ............................................................................. 52
2.11. Modelo de Sistemas de Trasporte Urbano Inteligente ................................. 52
2.12. Arquitectura para movilidad en Smart Cities .............................................. 53 2.13. Métodos de evaluación de arquitecturas ....................................................... 55
2.13. Framework de Smart Cities ............................................................................ 59
2.14. Framework de Cloud Computing .................................................................. 65
2.15. General Transit Feed Specification (GTFS) ................................................. 70 2.16. OneBusAway .................................................................................................... 73
2.17. Comentarios sobre el capítulo ........................................................................ 78
CAPÍTULO III: GOBERNANZA E INTERACCIÓN SOCIAL SOBRE EL TRANSPORTE PÚBLICO EN AGUASCALIENTES, MÉXICO ............................ 79
3.1. Sistema de Transporte Publico en la ciudad de Aguascalientes .................. 79
3.2. Uso, recepción y aceptación de usuarios al STP ........................................... 81 3.3. Concesionaria del STP y su relación con el gobierno ................................... 88
3.4. Comentarios sobre el capítulo ........................................................................ 90
CAPÍTULO IV: DEFINICIÓN DE MODELO ARQUITECTÓNICO BAJO LA ARQUITECTURA DE MOVILIDAD INTELIGENTE DE SMART CITIES Y EL USO DE CLOUD COMPUTING ................................................................................. 92
4.1. Modelo arquitectónico para el desarrollo de un sistema urbano inteligente 92
4.2. Aportación de la tesis ................................................................................. 95
3
4.2. Descripción del modelo arquitectónico para el desarrollo de un sistema urbano inteligente ....................................................................................................... 96
4.3. Arquitectura TUI .......................................................................................... 108 4.4. Comentarios sobre el capítulo ...................................................................... 114
CAPÍTULO V: CASO DE ESTUDIO - ONE BUS AWAY - DESARROLLO TÉCNICO DE LA APLICACIÓN ............................................................................. 115
5.1. Implementación del estándar GTFS ............................................................ 115
5.2. Mockups de la aplicación .............................................................................. 121
5.3. Arquitectura de la aplicación basada en OBA ........................................... 125 5.4. Arquitectura básica para la construcción de aplicaciones con GTFS-rt.. 126
5.5. Desarrollo de la aplicación OBA .................................................................. 128
5.6. Instalación del servidor ................................................................................ 129
5.7. Comentarios sobre el capítulo ...................................................................... 132 CAPÍTULO VI: PRUEBAS Y RESULTADOS ........................................................ 133
6.1. Pruebas realizadas ......................................................................................... 133
6.2. Resultados obtenidos ..................................................................................... 135
6.2.1 Resultados aplicados sobre Google Maps ............................................ 135 6.2.2 Resultados aplicados sobre el caso de estudio ..................................... 140
6.4. Comentarios sobre el capítulo ...................................................................... 151
DISCUSIÓN DE RESULTADOS ............................................................................... 152
CONCLUSIONES ........................................................................................................ 154 Objetivos alcanzados ................................................................................................ 155
Preposiciones demostradas hacia la hipótesis ........................................................ 156
Contribuciones de la investigación ......................................................................... 159
Trabajos publicados ................................................................................................. 160 Comentarios de la sección ........................................................................................ 161
GLOSARIO .................................................................................................................. 162
BILIOGRAFÍA ............................................................................................................ 164
ANEXOS ....................................................................................................................... 170
4
ÍNDICE DE TABLAS
Tabla 1. Capas de la arquitectura Cloud Computing (Carlin & Curran, 2013). ...............40
Tabla 2. Aplicaciones correspondientes en las diferentes capas de Cloud Computing (Carlin & Curran, 2013). ..................................................................................................42
Tabla 3. Plataformas para el desarrollo de aplicaciones de planeación de viajes (Elaboración del autor). ....................................................................................................74
Tabla 4. Ediciones personalizadas de OneBusAway (OneBusAway, 2010).. .................77
Tabla 5. Horario de las rutas del STP (Movilidad, 2016). ...............................................83
Tabla 6. Árbol de utilidad generado con ATAM (Elaboración del autor). ................... 106
Tabla 7. Escenarios priorizados para la evaluación con ATAM (Elaboración del autor). ....................................................................................................................................... 107
5
ÍNDICE DE FIGURAS Figura 1. Divisiones del paradigma Smart City (Arroub, Zahi, Sabir, & Sadik, 2016). .. 28
Figura 2. Principales capas del paradigma Smart Cities (Smart Cities MOOC, 2018). .. 29
Figura 3. El modelo de red abierta y su cadena de valor de acceso abierto. (Forzati, Larsen, & Mattsson, 2010). .............................................................................................. 34
Figura 4. Principales áreas de Smart Mobility (Faria et al., 2017). ................................. 37
Figura 5. Modelo de seguridad de Cloud Computing (Yang, Wei, Liu, & Li, 2016). ..... 46
Figura 6. Arquitectura de Cloud Computing segura (Tripathi & Mishra, 2011). ............ 47
Figura 7. Arquitectura de procesamiento analítico de datos de Smart Cities (Wieclaw et al., 2017). ......................................................................................................................... 48
Figura 8. Categorías de servicios basados en la nube en los diseños de Smart City (Wieclaw et al., 2017). ..................................................................................................... 48
Figura 9. Modelo de factores para transición hacia el transporte urbano inteligente (Elaboración del autor). .................................................................................................... 53
Figura 10. Arquitectura de sistema de recomendación de movilidad (Di Martino, Sergio & Rossi, Silvia, 2016). ..................................................................................................... 54
Figura 11. Factores conceptuales en los diferentes métodos. (Bass & Nord, 2012). ....... 56
Figura 12. Framework de Smart Cities (Hozaim & Akre, 2017). .................................... 60
Figura 13. Framework del ecosistema Smart Cities (Paramel, 2018). ............................. 61
Figura 14. Framework de Cloud Computing (Singh et al., 2016). .................................. 65
Figura 15. Tablas comunes del GTFS (Elaboración del autor). ....................................... 70
Figura 16. Modelo GTFS. (Krambeck, 2018). ................................................................. 71
Figura 17.Google Maps Logo (Google, 2016). ................................................................ 73
Figura 18. Moovit Logo (Moovit, 2015). ......................................................................... 73
Figura 19. Chalo Logo (Chalo, 2018). ............................................................................. 73
Figura 20. Citymapper Logo (Citymapper, 2018). .......................................................... 74
Figura 21. Transit Logo (Transit, 2012). ......................................................................... 74
Figura 22. Logo de OneBusAway (OneBusAway, 2010)................................................ 75
Figura 23.MTA Bus Time Logo (MTA, 2014). ............................................................... 76
Figura 24.York Region Transit Logo (YRT, 2016). ........................................................ 76
Figura 25. busETA Logo (busETA, 2016). ..................................................................... 76
Figura 26. KIEDY BUS Logo (kiedybus, 2016). ............................................................ 77
Figura 27. Transporte público de Aguascalientes en 1930. (Delgado Aguilar, 2017). .... 80
Figura 28. Tiempo invertido en una ruta (Elaboración del autor).................................... 86
Figura 29. Tiempo establecido de parada a parada (Elaboración del autor). ................... 86
Figura 30. Uso de una aplicación para la gestión del transporte (Elaboración del autor). .......................................................................................................................................... 87
Figura 31. Porcentaje de aumento de calidad de servicio (Elaboración del autor). ......... 87
6
Figura 32. Modelo arquitectónico para el desarrollo de transporte público inteligente (R. A. Velasquez Ortiz, F. Álvarez Rodríguez, J.C. Ponce Gallegos, 2018). ........................94
Figura 33. Framework para el diseño de transporte inteligente (Elaboración del autor). 95
Figura 34. Principales factores hacia la transición de Transporte Público Inteligente (R. A. Velasquez Ortiz, F. Álvarez Rodríguez, J.C. Ponce Gallegos, 2018). ........................97
Figura 35. Modelo de los niveles de servicio (R. A. Velasquez Ortiz, F. Álvarez Rodríguez, J.C. Ponce Gallegos, 2018). ...........................................................................98
Figura 36. Resultados principales de la transformación hacia Transporte Público Inteligente (R. A. Velasquez Ortiz, F. Álvarez Rodríguez, J.C. Ponce Gallegos, 2018). 99
Figura 37. Modelo de los niveles de entrega de servicios (Elaboración del autor).. ..... 100
Figura 38. Framework para Sistema de Transporte Inteligente. (Elaboración del autor). ....................................................................................................................................... 101
Figura 39. Arquitectura TUI para la implementación de transporte inteligente (Elaboración del autor). ................................................................................................. 108
Figura 40. Modulo 1 -Seguimiento- (Elaboración del autor). ....................................... 110
Figura 41. Modulo 2 -Aseguramiento de calidad de datos- (Elaboración del autor). ... 111
Figura 42. Modulo 3 -Estandarización- (Elaboración del autor). ................................. 112
Figura 43. Modulo 4 -Accesibilidad de datos- (Elaboración del autor). ....................... 113
Figura 44. Diagrama Entidad-Relación sobre GTFS (R. A. Velasquez Ortiz, F. Álvarez Rodríguez, M. Vargas Martin, J.C. Ponce Gallegos, 2019). ......................................... 116
Figura 45. Dataset Stop (Elaboración del autor). .......................................................... 117
Figura 46. Dataset Trips (Elaboración del autor). ......................................................... 117
Figura 47. Dataset Stop_time (Elaboración del autor). ................................................. 118
Figura 48. Dataset Calendar (Elaboración del autor). ................................................... 118
Figura 49. Dataset Routes (Elaboración del autor). ...................................................... 119
Figura 50. Relación entre tablas stop, stop_time y Trips (Elaboración del autor). ....... 119
Figura 51. Mockups ingreso a la aplicación (Elaboración del autor). ........................... 121
Figura 52.Mockups registro de paradas y rutas (Elaboración del autor). ..................... 123
Figura 53. Mockups información detallada (Elaboración del autor). ........................... 124
Figura 54. Arquitectura OneBusAway (OneBusAway, 2010). ..................................... 125
Figura 55. Arquitectura base para la construcción de aplicaciones con GTFS-rt. (Krambeck, 2018). ......................................................................................................... 126
Figura 56. Screenshots de la aplicación (Elaboración del autor). ................................. 128
Figura 57. Servidor OBA (Elaboración del autor). ....................................................... 129
Figura 58. API Key (Elaboración del autor). ................................................................ 130
Figura 59. API key de servidor a aplicación (Elaboración del autor). .......................... 131
Figura 60. Prueba de la ruta 1 con los archivos GTFS dentro del servidor (Elaboración del autor). ...................................................................................................................... 134
Figura 61. Detalle de las paradas en el servidor (Elaboración del autor). ..................... 135
Figura 62. Google Transit, Partnerdash (Elaboración del autor). ................................. 136
7
Figura 63. Previsualización privada de la ruta 1 en Google Maps (Elaboración del autor). ........................................................................................................................................ 137
Figura 64. Ruta 1 y sus puntos de parada en Google Maps (Elaboración del autor). .... 138
Figura 65. Ruta 1 completa (Elaboración del autor). ..................................................... 139
Figura 66. Visualización Gómez Portugal (Elaboración del autor). .............................. 140
Figura 67.Visualización Vicente Guerrero (Elaboración del autor). ............................. 141
Figura 68. Paradas y rutas recientes (Elaboración del autor). ........................................ 142
Figura 69. Paradas específicas (Elaboración del autor). ................................................ 143
Figura 70. Detalle de parada (Elaboración del autor). ................................................... 144
Figura 71. Detalle de parada en mapa (Elaboración del autor). ..................................... 145
Figura 72. Información de parada (Elaboración del autor). ........................................... 146
Figura 73. Desglose de horarios de ruta (Elaboración del autor). .................................. 147
Figura 74. Sentido de orientación del autobús (Elaboración del autor). ........................ 148
Figura 75. Horarios en tiempo real. (Elaboración del autor). ........................................ 149
Figura 76. Autobuses sobre una misma ruta en tiempo real (Elaboración del autor). ... 150
8
RESUMEN
A lo largo del tiempo, el uso de la tecnología ha favorecido el crecimiento de las ciudades,
ayudando a generar no solo una manera más cómoda de vivir, sino crear un ambiente
sostenible donde los servicios esta interconectados y que si bien dan solución a las
necesidades diarias de la ciudad, se interconectan entre ellos para dar solución a infinidad
de conflictos, generando de esta manera una relación de tecnología con ciudadanos,
gobierno y los diferentes enfoques sociales, dando origen a la denominada Smart Cities o
Ciudad 2.0.
Fundamentando los trabajos realizados previamente sobre Smart Cities y enfocando
especial atención en el problema de transporte público que sufre la ciudad de
Aguascalientes, este trabajo de investigación aplicada de tesis muestra el Diseño de
Modelo Arquitectónico para la Implementación de Transporte Urbano bajo las
Arquitecturas de Movilidad Inteligente de Smart Cities y el uso de Cloud Computing. En
seguida se define así mismo un modelo tanto arquitectónico como su respectivo
framework para la implementación de Smart City en la ciudad, así como una evaluación
sobre el mismo para comprobar la calidad ofrecida y respaldar su desarrollo. Por último,
se definen las normas gubernamentales y sociales que este proceso conlleva y la
construcción de la aplicación, su uso, compatibilidad en dispositivos y aceptación del
software según las métricas definidas, dando como resultado la solución a las preguntas
de investigación definidas y el cumplimiento de los objetivos declarados en la
investigación presente.
Palabras clave: Smart Cities, Cloud Computing, Smart Mobility, Transporte Inteligente,
Software as a Service.
9
ABSTRACT
Over time, the use of technology has favored the growth of cities, helping to generate not
only a more comfortable way of living, but to create a sustainable environment where
services are interconnected and that while they provide solutions to the daily needs of the
city, are interconnected among them to provide solutions to countless conflicts, thus
generating a relationship of technology with citizens, government and different social
approaches, giving rise to the so-called Smart Cities or City 2.0.
Building on the work previously done on Smart Cities and focusing special attention on
the problem of public transportation that suffers the city of Aguascalientes, this applied
research thesis shows the Architectural Model Design for the Implementation of Urban
Transportation under the Smart Cities Intelligent Mobility Architectures and the use of
Cloud Computing. It then defines an architectural model and its respective framework for
the implementation of Smart City in the city, as well as an evaluation of it to verify the
quality offered and support its development. Finally, the governmental and social norms
that this process entails and the construction of the application, its use, compatibility in
devices and acceptance of the software according to the defined metrics are defined,
resulting in the solution to the defined research questions and the fulfillment of the
objectives declared in the present research.
Keywords: Smart Cities, Cloud Computing, Smart Mobility, Intelligent Transport,
Software as a Service.
10
INTRODUCCIÓN
La presente investigación hace referencia al tema de transporte público de la ciudad de
Aguascalientes, el cual se divide en el uso de taxi, bicicletas y el transporte urbano
generado por autobuses. El trabajo de investigación está enfocado hacia los autobuses, el
cual apoya a la ciudadanía a través de una dependencia de gobierno, para poder trasladar
a los pasajeros a los diferentes lugares de la ciudad, haciendo que los usuarios tengan que
aprender una serie de rutas y horarios establecidos por una concesionaria para de esta
manera tener una medida aproximada del arribo de cada unidad o autobús a las distintas
paradas (Smart Cities MOOC, 2018).
El principal aspecto por analizar en esta investigación es el tiempo que se invierte para los
usuarios o pasajeros del servicio de transporte público, ya que no existe como tal una
medida exacta o segura de que el transporte llegue a la parada establecida en cierta
cantidad de tiempo y no se lleva de igual manera una gestión sobre los chóferes de cada
unidad siendo estos responsables de detenerse en una parada establecida o no.
Debido a esta problemática, se hizo un enfoque sobre la misma y es la falta tanto de
logística por parte de los chóferes y la misma gestión de unidades que hace imposible que
un usuario del transporte público pueda conocer el horario en que llegará la unidad o si se
detendrá en su parada oficial, ya que muchos chóferes pueden optar por saltar la parada y
hacer una ruta irregular, generando más pasajeros en una parada y por consiguiente ofrecer
un mal servicio a la ciudadanía.
La investigación sobre esta problemática social se realizó con un único fin, poder resolver
un problema que viene afectando a la sociedad de Aguascalientes por décadas y que a
pesar de tener antecedentes sólidos, no se ha realizado una solución sobre el mismo, lo
cual genera una mala experiencia al momento de utilizar el servicio de transporte público,
y si bien han existido propuestas, ninguna ha logrado ofrecer la solución, así mismo en
gran parte del territorio de México, se cuenta con la misma situación y aún más en regiones
rurales.
11
Generar una mejor calidad del servicio de transporte publico haciendo uso de la tecnología
actual, fue el interés académico que origino esta investigación y por la cual se ha de
generar una serie de documentos del tipo estadístico para cuantificar los resultados y así
mismo corroborar y dar por prueba el mejoramiento del servicio una vez se aplique el uso
de la aplicación.
El objeto de estudio e investigación de este trabajo es el diseño de un modelo
arquitectónico para implementar transporte urbano inteligente el cual de como resultante
el desarrollo e implementación de una aplicación para las plataformas operativas Android,
la cual pueda localizar a través del GPS (Sistema de Posicionamiento Global) las
diferentes unidades de transporte colectivo o camiones de la ciudad de Aguascalientes, así
como su ruta y ubicación en tiempo real. Esto con el objetivo de mejorar la calidad del
servicio en la ciudad y mejorar la gestión de este por parte de los concesionarios
respectivos, así mismo optimizar el tiempo de espera de unidad o ruta, solucionando un
problema que tanto el estado como los diversos estados en gran parte de la república no
se tiene finalizado.
El presente documento se divide y estructura en los siguientes capítulos:
En el Capítulo 1 se estableció la definición de la investigación a detalle los diferentes
antecedentes con los que se partirán hacia la investigación, así como la declaración de la
hipótesis y por último la definición del objetivo general a cumplir y los diferentes
objetivos específicos a completar con la finalidad de completar el trabajo de investigación
y mantenerlo respaldado.
En el Capítulo 2 se desarrolló el Marco Teórico el cual mostrará el estado del arte y
antecedentes de dicha investigación, así como el problema planteado a resolver y los
objetivos generales y sus respectivos objetivos específicos a cumplir durante dicha
investigación. Se abordarán los aspectos metodológicos y de relevancia sobre la
investigación y por último se dará la aportación del trabajo de tesis, quedando plasmado
12
de manera clara y detallada, así como algunas evaluaciones iniciales para la confiabilidad
de esta.
Así pues, el Capítulo 3, Gobernanza e interacción social sobre el transporte público en
Aguascalientes, da una visión de los elementos que se involucran en la creación de una
Smart Cities en Aguascalientes y los efectos que se relacionan, no solo en el ámbito
tecnológico sino social y gubernamental, dando aún más bases para su construcción y
generando evaluaciones sobre el servicio actual.
El Capítulo 4 propone el modelo arquitectónico, el cual, como propuesta de tesis, indica
detalladamente los pasos a seguir para proporcionar la transformación a transporte
inteligente. Cabe mencionar que el desarrollo de esta arquitectura es compatible para
cualquier estado para su posterior integración.
El Capítulo 5 desarrolló la gestión y mantenimiento sobre el modelo GTFS a utilizar. Se
explicará cómo funciona y se relacionará con el desarrollo de la aplicación, así como su
intervención con el modelo arquitectónico que se describe en el capítulo anterior y su
importancia en el momento de su implementación. Se define el uso del estándar GTFS
tanto para la aplicación como su importancia para la arquitectura. Este estándar de igual
manera será reflejado en el sistema de Google Maps por medio del sistema de Google
Transit Partnerdash.
A continuación, se encuentra el Capítulo 6, donde se establecieron las pruebas finales
realizadas por la aplicación, realizando la correlación con el modelo arquitectónico
desarrollo y su importancia reflejada en el caso práctico, la aplicación.
En seguida, se encuentra la sección de Discusión de Resultados, en la cual, a partir del
capítulo anterior, se discute sobre los resultados obtenidos de la aplicación y sobre las
ventajas adquiridas sobre la misma. Así mismo se discute los resultados de haber utilizado
el modelo arquitectónico, así como las oportunidades y limitaciones con las que se
encontró.
13
Para finalizar, la sección Conclusiones contiene su respectiva conclusión al tema de
investigación, así como la manera en que logro cumplir con los objetivos específicos y el
soporte resuelto hacia la hipótesis brindada anteriormente.
El presente trabajo de investigación de tesis concluye haciendo énfasis en las respuestas
obtenidas para el cumplimiento de los objetivos específicos y el objetivo general
estipulados en el Capítulo 1 de la presente investigación, así como la discusión de los
resultados obtenidos.
14
CAPÍTULO I: FORMULACIÓN DE LA INVESTIGACIÓN
Para dar inicio con la investigación propuesta, se da un comienzo hacia los antecedentes,
preguntas y objetivos para definir, con la finalidad de comprender la problemática que
sugiere este proyecto de tesis relacionado en particular en el área de mejora del transporte
público. Por lo tanto, es fundamental ver el desarrollo correcto de este capítulo para su
posterior resolución en capítulos posteriores.
1.1. Antecedentes
El desarrollo de las ciudades, su constante crecimiento, y la gran cantidad de servicios que
han nacido a partir de este crecimiento ha generado oportunidades, como problemas de
gestión y control de recursos y por lo tanto ha dado oportunidad a la tecnología de generar
soluciones prácticas y sobre todo innovadoras para mantener o incrementar la calidad de
vida de sus ciudadanos.
Según indica la investigación Ciudades Inteligentes: La mitificación de las nuevas
tecnologías como respuesta a los retos de las ciudades contemporáneas (Fernández Güell,
2015). Smart Cities es más que solo un concepto acuñado desde los años 90’s, es una
oportunidad de mejorar el ecosistema de la ciudad y solucionar los problemas que se han
generado por el abuso en el consumo tanto energéticos como naturales. El estudio de igual
manera establece tres áreas fundamentales con las que cuentan las ciudades
contemporáneas siendo la complejidad, haciendo referencia a los diferentes tamaños que
puede tener una ciudad y que puede ir de mediana a grande, le sigue la diversidad que
hace caso a las diferentes manera de desarrollo de cada ciudad y de su posición y tamaño
geográfico, pues tiende ser diferente de una ciudad a otra y por lo tanto y desde un punto
funcional, sus requerimientos serán diferentes y únicos de ciudad a ciudad. Por último, se
tiene la incertidumbre que es la previsión, ver a futuro sobre la ciudad, y a partir de eso
generar las siguientes soluciones para evitar y prevenir problemas a futuro.
15
Los primeros indicios de Smart Cities se originan en los años noventa y según nos marca
(Fernández Güell, 2015) “Smart Cities es un modelo urbano basado en tecnología para
mejorar la eficiencia energética, disminuir las emisiones contaminantes y reconducir el
cambio climático. Así mismo, la Comisión Europea en su Comunicación sobre «Smart
Cities and Communities» (COMMISSION, 2012) hizo suyo el modelo de Ciudad
Inteligente basado en la conjunción de innovaciones tecnológicas en las áreas de energía
transporte y tecnologías de información y comunicación (TIC’s)”.
Como puede observarse, las ventajas obtenidas al usar la metodología de Smart Cities,
son incontables, y haciendo énfasis en la infraestructura en el aspecto de transporte. Si
bien Smart Cities tiene una gran diversidad de enfoques, uno de ellos es el subsistema
espacial, el cual da respuesta a problemas y necesidades urbanas, siendo las del transporte,
las de mayor interés.
La investigación sugiere las conclusiones de que, si bien existe una diversidad de
iniciativas tecnológicas, si no se tiene una buena comprensión de la tecnología, y un
compromiso social para resolver los problemas a partir de la misma, podría ser muy difícil
la comprensión y gestione que las ciudades actuales requieren, por lo tanto, se hace énfasis
en el entendimiento tanto de la conceptualización como del compromiso que se genera.
Un primer trabajo realizado por Madeira Interactive Technologies Institute (Faria, Brito,
Baras, & Silva, 2017) indica la importancia sobre la implementación de Smart Cities, y a
su vez el uso de Smart Mobility, dirigido hacia el diverso uso del transporte,
optimizándolo y provocando un transporte inteligente que pueda resolver las necesidades
de la población así como problemas que van desde la innovación a problemas de tráfico y
el desarrollo de una infraestructura para el transporte.
La investigación indica proyectos factibles para la solución de problemas de transporte
tales como en la ciudad de Berlín/Wolfsburg, en donde la ciudad se ha instalado una red
WLAN que sirve para rastrear las unidades de transporte público si como estaciones de
bicicletas en tiempo real. Así mismo se indica el desarrollo de una aplicación para el
16
rastreo de ciclistas, a través de la plataforma Android con la finalidad de obtener
localización, velocidad y dirección vía GPS. Los teléfonos se sincronizaron a su vez con
las luces del semáforo y el objetivo de dicha aplicación es rastrear que ciclistas cruzan
estos semáforos. Estos son solo algunos de los trabajos presentados en el artículo
mencionado.
Estos trabajos en especial se vinculan y relacionan con el trabajo de investigación debido
a que el objetivo es generar a través de la filosofía Smart Cities, el concepto de Smart
Mobility a las unidades de transporte público de la ciudad de Aguascalientes. Así mismo
muestra la importancia de las Smart Cities, el paradigma de Internet of Things y su uso
para la resolución de problemas con la finalidad de mejorar la calidad de vida de las
personas.
Un segundo trabajo de Smart Cities Symposium Prague 2018 (Horažďovský, Novotný, &
Svítek, 2018) se denomina “Data-driven Management of Dynamic Public Transport” el
cual trata de la optimización del transporte público a través del uso de Analitics, en este
caso herramientas como Big Data, poder gestionar la información de los autobuses. Se
llegó a la capa de digitalización para implementar Smart Cities dentro de una pequeña
área con municipios pequeños.
El estudio de esta investigación fue el de implementar un medio de transporte inteligente
para una serie de municipios con demanda baja de este servicio, para mejorar su calidad.
Se utilizaron algoritmos tanto para su optimización, así como para poder rastrear su
posición. La idea era que los usuarios solicitaran una ruta, al realizar esta acción, el sistema
procesaría esa solicitud y generaría las rutas más cercanas, esto claro contando con las
solicitudes de los demás usuarios activos en ese momento. Fue desarrollo bajo la
plataforma de celulares o dispositivos móviles con el sistema operativo Android.
Como se indicó, se aplicó la herramienta de Big Data, debido a la gran cantidad de
dispositivos móviles, a partir de esta técnica, se decidió recolectar datos para la
localización de los usuarios, tomando coordenadas GPS. También se utilizó los datos
17
móviles, para la parte del transporte, para poder indicar no solo posición, sino su
comportamiento en caso de que tuviera alguna falla, o se enfrentara al tráfico poder hacer
algo al respecto en cuanto al retardo que eso generaría en los autobuses.
Así mismo creando un sistema dinámico, logro obtener datos como geolocalización y
horario de rutas basado en datos estadísticos, de esta manera, según indica optimiza el
servicio ya que se pueden modificar rutas en tiempo real o incrementar el número de rutas
en cierta área con la ayuda de Big Data, o ajustarlo según sea necesario, de esta manera
puede predecir el comportamiento de los vehículos y dar respuesta a la situación.
Este trabajo se relaciona con la investigación en curso debido a que indica cómo se debe
estructurar un proyecto de esta naturaleza desde el enfoque de diferentes etapas, además
que ofrece una visión clara sobre cómo funciona y se aplica una Smart Cities, su necesidad
de aplicarse en el área de transporte y la importancia de generar mejores servicios para la
población en general. De igual manera y remarcando, hace uso de los servicios de Big
Data, herramienta de inteligencia artificial para optimización, aplicada en esta
investigación a la generación de un transporte inteligente.
18
1.2. Planteamiento del Problema
La insuficiencia y gestión del medio de transporte ha sido uno de los problemas más
importantes en la mayoría de las ciudades del mundo. Según el trabajo de (Pečar & Papa,
2017), “Muchos sistemas de transporte público, o partes de ellos, están sobre o
subutilizados. Durante las horas pico, el exceso de usuarios crea molestias a medida que
el sistema hace frente a un aumento temporal de la demanda. El bajo número de usuarios
hace que muchos servicios sean económicamente insostenibles, especialmente en las
zonas suburbanas”.
Frente a esta situación, y al incremento de la sociedad en el mundo, ha comenzado a
generar una mayor demanda sobre el servicio de transporte, el cual se ha dividido en
diferentes tipos, desde automóviles, bicicletas, trenes y, sobre todo, autobuses, siendo
estos los más comunes alrededor del mundo, por su capacidad de transportar una gran
cantidad de personas. Según refiere (Csiszár & Földes, 2015) “En los países desarrollados,
la tasa de urbanización es superior al 70%. El número de vehículos y el rendimiento del
transporte están aumentando a un ritmo vertiginoso. Este tema es relevante hoy en día
debido a la calidad de sistema de transporte tiene un impacto significativo tanto en la
ciudad y la vida de los ciudadanos”.
Así mismo se puede observar que en México, a pesar del aumento de la población, se tiene
una calidad de servicio deficiente, así como en sus diferentes estados, con poco o nulo
apoyo para mejorar o mantener un estándar de calidad en los servicios de transporte,
siendo necesario para comunidades que pueden estar muy alejadas.
La ciudad de Aguascalientes tiene una deficiencia de espera indeterminada para la toma
de una ruta de autobús por parte del usuario. Las rutas no cuentan con un horario
establecido de salida, lo cual sugiere que el usuario este esperando por tiempos
prolongados, y por lo tanto se vea afectada su productividad, de la misma manera la
calidad de servicio disminuye, y no se asegura que estas unidades se detengan una vez
lleguen a su parada establecida, lo cual genera frustración en el usuario final. Según cifras
19
de La Jornada Aguascalientes (Aguascalientes, 2015), el 36% de la población de
Aguascalientes se desplaza en camión urbano, contando con un total de 700 unidades en
el estado.
De la misma manera debido al crecimiento de la población en la ciudad se ha complicado
cada vez más el abastecimiento y control de las unidades dando como resultado un servicio
deficiente. En un estudio realizado por Irina (Makarova, Shubenkova, Mavrin, Boyko, &
Katunin, 2017) indica que la urbanización es una de las causas de la mayoría de los
problemas que se enfrentan en este milenio.
Por lo expuesto anteriormente, es necesario resolver y optimizar el transporte público, de
lo contrario se generará un problema aun mayor, teniendo al final un servicio deficiente y
que no cumpla con los requerimientos que una ciudad inteligente solicita. En concordancia
con la metodología de Smart City y sus enfoques al transporte inteligente, la cual tiene
solo la finalidad de mejorar la calidad del servicio a los usuarios de la ciudad.
20
1.3. Preguntas de Investigación
¿Cómo optimiza el diseño de un modelo arquitectónico para la implementación de
transporte urbano inteligente a la ciudad de Aguascalientes?
¿Qué elementos debe contener el modelo arquitectónico para la construcción de transporte
público inteligente una Smart City?
¿Qué elementos debe contener una aplicación inteligente enfocada al transporte público
para la visualización de los elementos?
¿Qué tecnologías o herramientas son necesarias para la implementación del modelo
arquitectónico de manera que sea funcional y de bajo costo?
21
1.4. Justificación
El sistema de posicionamiento global (GPS) ha contribuido a la solución de diversos
problemas, mejorando tanto ahorro de índole monetario como de recurso de tiempo,
logístico y de control de personal, así mismo, las funciones de rastreo satelital de dicha
tecnología han contribuido al mejoramiento de la calidad de los servicios, siendo los más
notorios, el transporte.
En este caso en particular, se desarrollará una aplicación que localice las rutas de los
camiones urbanos de la ciudad de Aguascalientes, debido a que se ha convertido en un
problema que consume tiempo por parte de los usuarios de este servicio, y de la misma
manera afecta y reduce la calidad de este por parte de los operadores.
El objetivo es lograr optimizar los tiempos de espera, y lograr reducirlos al mínimo
posible, mejorando significativamente el servicio, sin la necesidad de que el usuario
invierta sus recursos económicos para el uso de esta y de la parte de los concesionarios,
se pretende no solo agilizar el servicio, sino mejorar la logística entre sus empleados y el
control sobre las unidades de una manera que signifique un mayor ahorro y crecimiento
de la empresa concesionaria de autobuses.
Se ha tomado la decisión de desarrollar en sistemas operativos basados en Android debido
a que la población en gran medida utiliza celulares que cuentan con este sistema operativo
por ser más económicos que otros derivados como Apple, que implica una inversión
económica más fuerte, así mismo se pretende usar el protocolo MQTT, debido a su poco
grado de consumo de recursos y su incremento en el uso de IoT (Internet of Things), lo
cual facilitara las operaciones para cualquier usuario sin necesidad de perdida de dinero.
Se elige el uso de una aplicación móvil debido a la creciente cantidad de usuarios que
utilizan un smartphone para comunicarse y obtener información. Según datos del INEGI
(INEGI, 2019), 69.8 millones de personas en el 2018 de manera nacional disponen de esta
tecnología y de estos, 45.5 millones descargan aplicaciones para su uso.
22
1.5. Hipótesis
El uso de aplicación generada a partir un modelo arquitectónico para la implementación
de transporte urbano inteligente puede optimizar la cantidad de tiempo invertido en una
parada de autobús por medio de sugerencia de rutas y estimación de tiempos de llegada.
Esta hipótesis se construyó a partir de variable cuantificable siendo la variable
independiente el tiempo.
23
1.6. Objetivo General
Definir un modelo arquitectónico para el desarrollo de una aplicación inteligente de
geolocalización para transporte público con el fin de optimizar el tiempo del servicio en
la sociedad de Aguascalientes.
24
1.7. Objetivos Específicos
El objetivo general cuenta con cuatro objetivos específicos a cumplir para lograr su
completo desarrollo, los cuales se expondrán de la siguiente manera.
Objetivos específicos para el objetivo general.
1) Análisis de arquitecturas para la concepción de un modelo arquitectónico para
transporte inteligente siguiendo las normas de Smart City y Cloud Computing.
2) Desarrollo de un modelo arquitectónico para transporte inteligente siguiendo
las normas de Smart City y Cloud Computing.
3) Desarrollo de aplicación inteligente de geolocalización para la ubicación del
transporte público bajo el modelo arquitectónico desarrollado.
4) Desarrollo y ejecución de pruebas de la aplicación con el modelo
arquitectónico desarrollado.
25
1.8. Comentarios sobre el capítulo
Este capítulo abarco los fundamentos con los cuales se sustentará toda la investigación.
Es necesario remarcar que estos estarán entrelazados a lo largo del desarrollo del trabajo
de investigación y se irán respondiendo tanto las preguntas de investigación, así como los
objetivos específicos planteados, con la finalidad de llegar al Capítulo 7 donde se
justificara el cumplimiento de los mencionados.
26
CAPÍTULO II: MARCO TEÓRICO
Para dar soporte conceptual al resto de la investigación, se proporciona dentro de este
capítulo, las diferentes arquitecturas a investigar, relacionadas tanto en Smart Cities como
transporte inteligente para, de esa manera, integrar los módulos más trascendentes y
generar posteriormente una propuesta arquitectónica. De igual manera se tomarán en
cuenta los elementos tales como tecnologías y métodos de pruebas que se utilizarán en el
desarrollo del trabajo de tesis.
2.1. ¿Qué es una ciudad?
Antes de comenzar con el desarrollo del marco teórico y la conceptualización de Smart
City y Smart Mobility, se definirá la base en la cual se desarrollan los conceptos
posteriores, en este sentido, el concepto de ciudad. Una ciudad es un conjunto de diversos
sistemas que se relacionan y crecen entre sí. Como lo indica (Smart Cities MOOC, 2018),
son sistemas sociotécnicos donde las personas viven y trabajan juntas.
Así mismo y de acuerdo con el artículo de Smart Cities, es el conjunto o concentración de
personas resulta en una concentración de conocimiento e innovación, así como en una
diversidad de especializaciones.
Las ciudades pueden entenderse como sistemas sociotécnicos, un lugar donde las personas
viven y trabajan juntas. Las ciudades pueden ser entendidas a través de diferentes
dimensiones; pueden ser un sistema económico, un lugar en el que se genere riqueza y un
lugar en el que se generen puestos de trabajo. Debido a la naturaleza de la concentración
de personas y empresas en las ciudades, se produce un aumento de la eficiencia de la
producción y, por lo tanto, de la competitividad de las empresas. Las ciudades también
pueden ser vistas como un sistema social, una forma de vida, y con una cultura separada,
con sus propias actividades, tradiciones y más.
27
2.2. Ciudad Inteligente (Smart City)
Es una ciudad que combina servicios tecnológicos para su mejor desempeño, estos pueden
combinarse en las diferentes áreas de esta, sea en el área de gobiernos, industrial, servicios
energéticos y transporte. Según (Faria et al., 2017), es la unión de una red urbana con una
modernización tecnológica.
Si bien esta definición no basta para conceptualizar el paradigma de Smart Cities y lo que
representa, según indica (Nam & Pardo, 2011) una definición aún más aceptable es y cita
como "Una ciudad puede definirse como "inteligente" cuando las inversiones en capital
humano y social y en infraestructuras modernas de transporte y comunicación alimentan
un crecimiento económico sostenible y una alta calidad de vida, con una gestión
inteligente de los recursos naturales, a través de una gobernanza participativa".
Smart Cities tiene a su vez un gran alcance que va desde diferente enfoques y necesidades,
como se aprecia en la imagen (Ver Figura 1) Smart Cities es un paradigma que según el
área donde se aplique tendrá efectos no solo en esa área en particular sino en las demás.
Se puede observar 6 principales áreas de Smart Cities y son: Smart Economy, Smart
Environment, Smart Governance, Smart People, Smart Living, Smart Economy y Smart
Mobility, siendo esta ultima el campo de acción que profundizaremos en siguientes
capítulos (Arroub, Zahi, Sabir, & Sadik, 2016).
28
Figura 1. Divisiones del paradigma Smart City (Arroub, Zahi, Sabir, & Sadik, 2016).
.
A su vez está dividida en diferentes capas (Ver Figura 2), siendo la capa de Servicio e
infraestructura la base para identificar la posibilidad de tornar una ciudad a una ciudad
inteligente.
Smart Cities
Smart Environment
Smart Governance
Smart People
Smart Living
Smart Mobility
Smart Economy
29
Así mismo hay una tercera capa, la capa de datos que influye en las dos anteriores y
digitaliza los servicios para mejorar de esa manera la calidad de los mismos (Smart Cities
MOOC, 2018).
Smart Cities
Datos/Digital
ServiciosInfraestuctura
Figura 2. Principales capas del paradigma Smart Cities (Smart Cities
MOOC, 2018).
30
2.2.1. Capa de Servicios
La capa de servicio es la encargada de a partir de los servicios existentes, como el servicio
de energía, agua, de transporte, ofrecer soluciones a las ciudades, ofreciendo la demando
que estos generan y generando nuevas maneras de optimizar los mismo.
2.2.2. Capa Digital o de Datos
La capa de datos es la novedad que cumple con la función de Smart Cities. Esta capa
realiza comunicación directa con las otras capas de servicios e infraestructura y digitaliza
todos los procesos para a partir de esto, pueda generar una conversión a nivel de ciudad y
por lo tanto de ciudadanía. Llega a niveles de digital divide o brecha digital en algunos
casos. Para esta capa se hace uso de los dispositivos como teléfonos, cámaras, GPS, etc.
2.2.3. Capa de Infraestructura
Esta capa es la encargada de cómo se ofrecerán los servicios, son los medios para llevarlos
a cabo, desde automóviles, o nuevos generadores de energía, así como las mismas casa o
edificios comerciales.
2.2.4. Big Data
Desde siempre, los datos se acumulan en la organización mediante la introducción de
datos en el sistema informático, pero a la medida que evoluciona el Internet de las cosas
(IoT), los usuarios son capaces de generar sus propios datos. El uso excesivo de Internet
aumentaría con el IoT debido a la integración de todos los objetos a través de sistemas
integrados. Esto conduce a una alta distribución de la red de dispositivos que se comunican
con las personas, así como con otros dispositivos. Estos datos proceden de cualquier cosa
y en cualquier lugar, como clientes, dispositivos móviles inteligentes, sensores, registros
31
de transacciones de compra, medios sociales, imágenes digitales, CCTV, GPS, audio que
se pueden utilizar para recopilar información específica.
Por lo tanto, y según indica (Zulkarnain & Anshari, 2016), Big Data se define como una
cantidad masiva de datos, que se procesan de maneras muy veloces desde muchas formas
diferentes para apoyar la toma de decisiones. Por lo tanto, es ampliamente conocido por
su volumen, velocidad y variedad.
Los medios sociales forman parte de los grandes datos, en los que el número de personas
que utilizan los medios sociales es elevado. Ha demostrado que 3.419 millones son
usuarios de Internet, de los cuales 2.307 millones son usuarios activos de los medios
sociales.
2.2.5. Big Data Analitics
Así mismo y según indica los autores (Zulkarnain & Anshari, 2016), el análisis de grandes
datos es un proceso de descubrimiento de patrones y tendencias a partir de una gran
cantidad de datos para extraer su valor y correlaciones.
Las etapas que se deben realizar en la recuperación de datos para Big Data son las
siguientes:
1) Adquisición de datos: Datos adquiridos del medio donde la generación de datos está
creciendo exponencialmente. Aunque los datos que se producen continuamente están
compuestos en su mayoría de datos no procesados que son inútiles y debido a su forma no
estructurada, la selección y el descarte de datos innecesarios puede ser bastante difícil.
2) Extracción de datos: La mayoría de los datos brutos adquiridos no son útiles. Por lo
tanto, decidir qué datos son necesarios para ser conservados y cuáles deben ser descartados
es una tarea difícil de llevar a cabo, ya que hay una gran cantidad de ellos.
32
3) Recopilación de datos: La mayoría de las veces, la utilización de datos de una muestra
es inadecuada para ser utilizada en un análisis o predicción. Por lo tanto, los datos se
recuperan de diferentes fuentes y se combinan o superponen para formar una imagen más
grande y detallada. A partir de este punto, los datos pueden ser analizados más
adecuadamente.
4) Estructuración de datos: Es importante que los datos analizados se organicen de
forma estructurada. Esto permite que la recuperación de la información sea más fácil.
5) Visualización de datos: Los datos que se extraen de estas áreas se analizan y se
convierten en un formato más específico y visual.
6) Interpretación de datos: Aquí es donde se extraerá información valiosa. Hay dos tipos
de información que se pueden adquirir: Análisis retrospectivo y análisis prospectivo. La
retrospectiva implica obtener información de los eventos y acciones del pasado. El análisis
prospectivo consiste en distinguir patrones y descubrir tendencias para el futuro basándose
en los datos registrados.
2.2.6. Internet de las Cosas
El Internet de las Cosas (IoT) amplía el concepto existente de Internet. Este paradigma
como indica (Lee & Lee, 2015), es la próxima generación de Internet que abarca incluso
una red entre los objetos y los seres humanos, de modo que los diversos objetos
circundantes puedan conectarse a través de Internet. La IoT consta de tres elementos
básicos: humano, objetos y servicio. El máximo efecto se obtendrá a medida que la
vinculación entre los elementos.
Una vez que IoT se ha establecido, es posible desarrollar y difundir diversas tecnologías
relacionadas, como redes inalámbricas, módulos de comunicación, sensores y terminales
inteligentes, lo que ampliará el efecto de IoT a casi todos los campos de la industria, así
como a las actividades cotidianas. A medida que esta tecnología se introduce en diversas
33
áreas como la ciencia médica, el transporte, la fabricación y la educación, los procesos y
servicios existentes se enfrentarán a cambios innovadores.
2.2.7. Protocolos de comunicación
WiFi (Wireless Fidelity)
Según lo afirma (Rafiei, Elmi, & Zare, 2012) WiFi es un protocolo de comunicación que
nos permite intercambiar datos de forma inalámbrica a través de una red. Este protocolo
es una marca registrada de WiFi Alliance y utiliza la familia de estándares IEEE 802.11.
La WiFi Alliance es una asociación internacional sin ánimo de lucro creada en 1999 para
certificar la interoperabilidad de los productos de redes de área local inalámbricas.
Las principales ventajas de WiFi son las siguientes:
• Utiliza espectro radioeléctrico sin licencia
• Reduce los costes asociados a la red, conexiones y ampliaciones.
• Están ampliamente disponibles en cualquier lugar.
• Las redes WiFi pueden soportar roaming.
• WiFi tiene un conjunto de estándares globales.
2.2.8. Red abierta
El modelo de red abierta según lo indica el artículo de Marco Forzati (Forzati et al., 2010),
en el cual los servicios se proporcionan de manera justa y no discriminatoria a los usuarios
de la red, se hace posible mediante la separación conceptual de las funciones del proveedor
de servicios (SP) y del operador de la red y de las comunicaciones. Debido a la naturaleza
técnica y económica distintas de las diferentes partes de la red, se pueden identificar
diferentes roles y actores.
34
La idea fundamental del modelo de acceso abierto es fomentar el máximo grado de
competitividad para maximizar la libertad de elección de los usuarios finales y evitar el
monopolio como se detalla en el grafico (Ver Figura 3). Sin embargo, un principio
implícito importante de las redes abiertas es el de construir una infraestructura para la
sociedad, no solamente un sistema basado en los beneficios, y existe un gran interés
político en las redes de acceso abierto.
Otro factor importante ha sido la imposibilidad de los operadores tradicionales de gran
tamaño de proporcionar acceso a la banda ancha a precios asequibles en zonas apartadas.
Esta es una de las muchas razones por las que las comunidades rurales han desplegado
redes de acceso abierto.
Figura 3. El modelo de red abierta y su cadena de valor de acceso abierto. (Forzati, Larsen, & Mattsson, 2010).
35
2.3. Global Positioning System (GPS)
El Global Positioning System (GPS) según la literatura (Elleuch, Wali, & Alimi, 2015)
montado en los teléfonos móviles o en los automóviles, los automóviles pueden ser
considerados como sensores móviles. Por tanto, los investigadores se centran en utilizarlos
en el campo como la presentación de mapas digitales, la previsión de la ubicación de los
atascos y la predicción de los comportamientos de los conductores.
Además, gracias al bajo coste del GPS y a su mayor precisión, muchas personas optan por
utilizar el receptor GPS en sus vehículos para aprovechar sus ventajas. A pesar de que el
GPS tiene varios beneficios y se utiliza más hoy en día, podemos observar que solamente
un número restringido de vehículos, especialmente en los países pobres, contienen un
sistema GPS, generalmente servicios de gestión de flotas. De hecho, a menudo en trabajos
anteriores, la información de tráfico recopilada de vehículos comerciales y camiones
puede ser más apropiada para predecir el comportamiento y el estado del tráfico en
autopistas y zonas rurales. Mientras que los vehículos de taxi son muy interesantes porque
son útiles para describir el tráfico urbano.
Los estudios y sistemas existentes utilizaban datos basados en la localización para resolver
los problemas de atascos de tráfico o predecir el trayecto más corto y rápido. Por ejemplo,
la previsión de la congestión consiste en analizar la densidad del flujo de datos, que es una
información espacial. Sin embargo, los datos espaciales junto con la información temporal
son esenciales para mejorar la precisión y la eficiencia del sistema.
2.4. Digitalización
Mediante la digitalización, las cadenas de valor físicas pueden reflejarse en una dimensión
digital, lo que significa que los clientes pueden seguir e influir en esta cadena de valor
(por ejemplo, con el seguimiento) mediante la creación de interfaces de cliente. Además,
la información de esta capa de datos puede ser utilizada para mejorar la cadena de valor o
crear nuevos servicios y modelos de negocio que permitan a las empresas encontrar
36
nuevas formas de beneficiarse de ella. Esto afecta a un gran número de industrias, que se
clasifican en cuatro categorías. En primer lugar, afecta a industrias muy necesitadas de
información, como la salud, ya que ahora la información puede ser recopilada, almacenada
y analizada de forma más eficiente. En segundo lugar, afecta a muchas industrias que no
son escalables, como la del taxi. Esto se debe a que su tamaño es limitado y la
digitalización les ayuda a desarrollar nuevos servicios para rentabilizarlos. En tercer lugar,
influye en industrias dispersas, como la logística, ya que ayuda a conectar a los diferentes
agentes. Por último, afecta a sectores de información asimétrica, como el gobierno, al
convertir a los consumidores en prosumidores y empoderar a los usuarios.
2.5. Implicación de Smart Cities
Como ya se ha definido la digitalización y sus efectos, ahora se explora cómo se relaciona
con el concepto de Smart City. Una Smart City puede ser vista a partir de las dimensiones
de una ciudad convencional, pero con distintas características. Desde una visión
económica, se la puede ver como una economía digital, que puede ayudar a reactivar y
fomentar la economía local a través de la tecnología. Desde una visión social, una Smart
City es una forma de impulsar las comunidades en línea y revitalizar la vida social. La
economía de compartir puede verse como una unión de las dimensiones sociales y
económicas. Además, las Smart Cities también pueden definirse desde una visión política,
la cual estimula la implicación y la participación de los ciudadanos a través de los procesos
de toma de decisiones en línea. Por último, un canal de ciudad inteligente debe ser visto
desde una perspectiva tecnológica, que se refiere a sus infraestructuras y servicios,
dimensión de interés de este MOOC. Algunos ejemplos de la dimensión tecnológica de
una ciudad inteligente son, por ejemplo, el uso de herramientas digitales para la
recaudación del peaje, la medición inteligente, la detección de fugas de agua o los sistemas
de seguridad.
37
Hay cuatro aspectos principales del desarrollo y la transición a ciudades inteligentes. El
primero es la gestión y la gobernanza de las infraestructuras, que ahora deben incluir una
combinación de gestión de las antiguas infraestructuras heredadas con las ahora más
inteligentes.
En segundo lugar, la gestión de la nueva capa de servicios, que plantea muchos retos en
términos de: ejecución, regulación y otros. En tercer lugar, por su parte, está el reto de
gobernar los sistemas sociotécnicos, que son los que gobiernan las instituciones urbanas
y las reglas de este sistema.
Por último, también hay un reto innovador, que es la gestión y la gobernanza de la capa
de datos, un papel que normalmente no es asumido por las ciudades, sino que ahora deben
adaptarse.
2.6. Smart Mobility
Como indica el articulo (Faria et al., 2017), a medida que la población mundial se
concentra en las ciudades, la movilidad en los entornos urbanos se está convirtiendo en
uno de los campos de investigación más prominentes e interesantes en el contexto de
Smart City (Ver Figura 4). Básicamente, el sueño de los investigadores es dar a las zonas
urbanas una actualización tecnológica y crear un entorno urbano plenamente conectado.
Figura 4. Principales áreas de Smart Mobility (Faria et al., 2017).
38
El concepto de Smart City ha sido expresado con algunas metáforas y visto como un gran
sistema orgánico.
Según (Hall et al., 2000), indica que una Smart Cities es “una ciudad que supervisa e
integra las condiciones de todas sus infraestructuras críticas, incluyendo carreteras,
puentes, túneles, ferrocarriles/metro, aeropuertos, puertos marítimos, comunicaciones,
agua, energía e incluso edificios importantes, puede optimizar mejor sus recursos,
planificar sus actividades de mantenimiento preventivo y supervisar los aspectos de
seguridad al tiempo que maximiza los servicios a sus ciudadanos”.
2.7. Cloud Computing
El término nube (Cloud) según (Jadeja & Modi, 2012) se origina en el mundo de las
telecomunicaciones cuando los proveedores empezaron a utilizar servicios de red privada
virtual (VPN) para las comunicaciones de datos. La computación en nube se ocupa de
servicios de computación, software, acceso a datos y almacenamiento que pueden no
exigir que el usuario final conozca la ubicación física y la configuración del sistema que
está suministrando los servicios.
El objetivo principal del Cloud Computing es hacer un mejor aprovechamiento de los
recursos distribuidos, combinarlos para conseguir un mayor rendimiento y ser capaces de
resolver problemas de computación a gran escala. El Cloud Computing se centra en la
virtualización, la escalabilidad, la interoperabilidad, la calidad del servicio y los modelos
de entrega de la nube, es decir, privados, públicos e híbridos.
39
Atributos de Cloud Computing
La computación en nube tiene cinco atributos clave según indica el autor (Carlin &
Curran, 2013), entre las que se encuentran:
Multiusuario (recursos compartidos): La computación en nube se basa en un modelo
de negocio en el que los recursos se comparten a nivel de red, host y aplicación.
Escalabilidad masiva: La computación en nube proporciona la capacidad de escalar a
decenas de miles de sistemas, así como la capacidad de escalar masivamente el ancho de
banda y el espacio de almacenamiento.
Elasticidad: Los usuarios pueden aumentar y disminuir rápidamente sus recursos
informáticos según sea necesario, así como liberar recursos para otros usos cuando ya no
sean necesarios.
Pago por uso: Los usuarios pagan sólo por los recursos que realmente utilizan y sólo por
el tiempo que los necesitan.
Autoabastecimiento de recursos: Recursos de autoabastecimiento de los usuarios, como
sistemas adicionales y recursos de red.
Modelo de despliegue en nube: Existen tres tipos principales de modelos de despliegue
de nubes: nubes públicas, privadas e híbridas.
Nubes públicas: Son el tipo de nube más común. Aquí es donde múltiples clientes pueden
acceder a aplicaciones y servicios web a través de Internet. Cada cliente individual tiene
sus propios recursos que son aprovisionados de forma dinámica por un proveedor externo.
Este proveedor externo aloja la nube para múltiples clientes desde múltiples centros de
datos, administra toda la seguridad y provee el hardware y la infraestructura para que la
40
nube funcione. El cliente no tiene control ni conocimiento de cómo se gestiona la nube ni
de la infraestructura disponible.
Nubes Privadas: Permiten a los usuarios beneficiarse de los servicios de computación en
nube sin algunas de las trampas. Las nubes privadas garantizan un control total sobre cómo
se administran los datos y qué medidas de seguridad se aplican. Esto puede llevar a que
los usuarios tengan más confianza y control.
Nubes Híbridas: Incorporan nubes públicas como privadas (ver Figura 3) dentro de la
misma red. Les permite a las organizaciones aprovechar ambos modelos de despliegue.
Por ejemplo, una organización podría retener información confidencial en su nube privada
y usar la nube pública para administrar grandes volúmenes de trabajo y situaciones de
demanda.
Capas y Servicios de la Arquitectura Cloud Computing
Las capas que conforman la arquitectura de Cloud Computing se conforman de las
siguientes 5 capas tal y como puede observarse en la tabla correspondiente (Ver Tabla 1):
Cliente Aplicación Plataforma Infraestructura Servidor
Tabla 1. Capas de la arquitectura Cloud Computing (Carlin & Curran, 2013).
2.7.1. Cliente
Un cliente en la nube consiste en hardware y/o software informático que depende del
Cloud Computing para la distribución de aplicaciones, o que está especialmente diseñado
para la prestación de servicios en la nube.
41
2.7.2. Software como servicio (SaaS)
Un cliente en la nube consiste en hardware y/o software informático que depende del
Cloud Computing para la distribución de aplicaciones, o que está especialmente diseñado
para la prestación de servicios en la nube.
2.7.3. Plataforma como Servicio (PaaS)
Los servicios de plataforma proporcionan una base informática que utiliza la
infraestructura de la nube. Tiene toda la aplicación que típicamente requiere el cliente
desplegado en él. De esta forma, el cliente no tendrá que pasar por las molestias de
comprar e instalar el software y hardware necesarios para ello. A través de este servicio
los desarrolladores pueden conseguir todos los sistemas y entornos necesarios para el ciclo
de vida del software, ya sea para el desarrollo, prueba, despliegue y alojamiento de
aplicaciones web.
2.7.4. Infraestructura como Servicio (IaaS)
Los servicios de infraestructura proporcionan la infraestructura necesaria como servicio.
El cliente no tiene necesidad de comprar los servidores, el centro de datos o los recursos
de red necesarios. También la ventaja clave aquí es que los clientes necesitan pagar sólo
por el tiempo que utilizan el servicio. Como resultado, los clientes pueden lograr una
mejor entrega de servicios con un menor costo.
2.7.5. Servidor
El servidor consiste en el hardware y/o software característico necesario para la provisión
de los servicios mencionados en los párrafos anteriores. En la siguiente tabla (Ver Tabla
2) se muestra imagen del tipo de servicio que se prestan dependiendo del tipo de capa que
se elija de las tres principales, SaaS, IaaS, SaaS.
42
Software como Servicio (SaaS)
Plataforma como Servicio (PaaS)
Infraestructura como Servicio (IaaS)
Gov-Apps Comunicación (email) Colaboración Herramientas de Productividad (Oficina) ERP
Desarrollo de Aplicaciones Servicios de Seguridad Gestión de Bases de Datos
Servidores Redes Almacenamiento Gestión Informes
Tabla 2. Aplicaciones correspondientes en las diferentes capas de Cloud Computing
(Carlin & Curran, 2013).
2.7.6. Seguridad en Cloud Computing
Cloud Computing indudablemente proporciona un excelente servicio al usuario, pero aun
así muchas organizaciones no lo adoptan a causa de los problemas de seguridad. Las
principales preocupaciones en materia de seguridad según lo indica (Narula, Jain, &
Prachi, 2015) son la protección de datos y la confidencialidad. Estos problemas de
seguridad impiden a los gestores o clientes dar soporte a los servicios que ofrece el Cloud
Computing, por lo que computo en la nube no está adquiriendo el tamaño de mercado
esperado. La seguridad en la nube es responsabilidad tanto del proveedor como del
consumidor. Debe existir una relación de confianza entre ellos antes de hacer uso de
cualquier servicio en la nube. Existen muchos riesgos asociados al Cloud Computing,
algunos de los cuales son: seguridad, proveedores de servicios, gestión y control, leyes y
regulaciones, riesgos de virtualización, falta de estándares y auditorías, costes viables
incontrolados, etc.; el riesgo que más preocupa es la seguridad.
El Cloud Computing es un entorno virtual para el cliente que está utilizando los servicios
Cloud en el cual entregará sus datos a la nube sin saber siquiera la ubicación de estos. Los
datos pueden estar allí con miles de otros datos en la nube. Por lo tanto, las instalaciones
más importantes que debe proporcionar el proveedor de almacenamiento son las de
Confidencialidad, Integridad y Disponibilidad.
43
Amenazas a la seguridad en Cloud Computing
Hay varios problemas de seguridad que impiden que los usuarios se beneficien de la nube.
La CSA-Cloud Security Alliance (Alliance, 2013) ha identificado las nueve principales
amenazas de Cloud Computing. Estas amenazas son las más fundamentales que pueden
ser posibles en el moderno entorno de nube. Estas amenazas son las siguientes de acuerdo
con su grado de severidad:
1. Violaciones de datos
El concepto de violación de datos es que cualquier persona maliciosa o no autorizada entra
en una red corporativa y roba los datos sensibles o confidenciales.
2. Pérdida de datos
La otra amenaza grave es la incapacidad para prevenir la pérdida de datos porque muchas
de las compañías tratan sus datos como un recurso valioso.
3. Secuestro de cuentas
En el secuestro de cuentas, un intruso malicioso puede utilizar las credenciales robadas
para secuestrar servicios de computación en la nube y puede entrar en las operaciones de
otros, insertar información falsa y desviar a los usuarios a sitios web ofensivos, lo que
resulta en problemas legales para los proveedores de servicios de computación en la nube.
4. API’s inseguras
Si las interfaces de programación de aplicaciones (API’s) que utilizan los usuarios para
poder comunicarse con los servicios en la nube son débiles o no están suficientemente
protegidas, un intento accidental o malintencionado de violarlas puede exponer los datos
44
de la nube a muchas amenazas de seguridad relacionadas con el control de acceso
inflexible, la escalabilidad y la monitorización limitada, así como a muchos otros
problemas.
5. Negación de servicio
La negación de servicio se ha convertido en una amenaza muy seria cuando las
organizaciones dependen de los servicios las 24 horas del día, los 7 días de la semana.
Deniega temporalmente el acceso de los datos almacenados en la nube a los usuarios
autorizados mediante un ataque al servidor a través del envío de miles de peticiones a éste,
imposibilitándole responder a los clientes habituales.
6. Información privilegiada maliciosa
Una persona que entra en la red de la nube para dañar los datos y activos confidenciales
de la organización, dañar marcas valiosas, penalizar los daños financieros, detener la
productividad es conocida como una persona con información privilegiada maliciosa.
7. Abuso de los servicios Cloud Computing
Esta amenaza es más importante para los proveedores de servicios de Cloud Computing
que para los consumidores de Cloud Computing. A un atacante le puede tomar años
descifrar una clave de encriptación usando su propio hardware, pero usando una serie de
servidores en nube, podría ser capaz de descifrarla en cuestión de minutos.
45
8. Diligencia Debida Insuficiente
El consejo básico de CSA es que las organizaciones se aseguren de contar con los recursos
suficientes y que realicen una diligencia debida exhaustiva antes de saltar a la nube.
9. Problemas tecnológicos compartidos
El Cloud Computing es conocido por su tecnología de compartimentación, por lo que es
muy difícil obtener una fuerte propiedad de aislamiento para una arquitectura
multiusuario.
Medidas de seguridad de información en Cloud Computing
La seguridad de la computación en nube es proporcionar servicios a los usuarios en la
plataforma abierta y sofisticada de computación en nube, y garantizar la seguridad y
confiabilidad de la información de los usuarios. Los problemas de seguridad de la
computación en la nube deben ser atendidos desde muchos ángulos, especialmente desde
el nivel técnico. Como se muestra (Ver Figura 5), se trata de un modelo de seguridad
de la tecnología de computación en nube.
46
Figura 5. Modelo de seguridad de Cloud Computing (Yang, Wei, Liu, & Li,
2016).
2.8. Arquitectura de seguridad en Cloud Computing
Cloud Computing involucra en su mayoría la implementación de tecnologías de
virtualización. La mayor parte de las compañías tienden a implantar tecnologías de
virtualización mediante la readaptación de sus redes virtuales con la red física existente.
Esto se debe principalmente a la falta de involucramiento de los equipos de seguridad de
información y de las redes en etapas iniciales de planificación. Debido a esta falta de
preparación tecnológica, la seguridad de la red se debilita y esto es un factor clave para el
éxito del Cloud Computing con organizaciones de gran escala.
A continuación, se presenta una arquitectura de seguridad en nube (Ver Figura 6), en la
cual las organizaciones pueden protegerse contra las amenazas a la seguridad y ataques.
47
Figura 6. Arquitectura de Cloud Computing segura (Tripathi & Mishra, 2011).
2.9. Arquitectura Cloud Computing implementado en Smart Cities
Como se indica en la imagen (Ver Figura 7), la arquitectura de procesamiento analítico de
datos de Smart Cities se basa en el uso de Cloud Computing. Como se indicó previamente,
el paradigma de Smart Cities se divide en las capas de Servicios, Digital/Datos e
Infraestructura (Ver Figura 2). Según (Wieclaw et al., 2017) las capas mencionadas se les
realiza una conversión a la arquitectura de servicio, quedando como se indica, Capa de
Infraestructura como servicio, capa de Datos como servicios y capa de servicios o en este
caso de software como servicios; de esta manera se agregan componentes de la
arquitectura Cloud Computing a las capas para generar un modelo analítico de datos en la
conversión de proyectos orientados a los servicios.
48
Figura 7. Arquitectura de procesamiento analítico de datos de Smart Cities (Wieclaw et al., 2017).
Figura 8. Categorías de servicios basados en la nube en los diseños de Smart City (Wieclaw et al., 2017).
49
2.10. Arquitecturas para Smart Cities
A continuación, según se cita en la investigación de (Kyriazopoulou, 2015) se revisaran
varias arquitecturas y sus tecnologías incluidas. Aunque la literatura contiene muchas
revisiones y sugerencias sobre las arquitecturas que participan en el diseño y operación de
un Smart City, todavía no existe uno estándar que integre todas las funcionalidades. Las
arquitecturas analizadas son 5 y son las siguientes: Capas Arquitectónicas, Arquitectura
Orientada a Servicios, Arquitectura basada en eventos, Internet of Things, Arquitecturas
Combinadas y finalmente el nuevo concepto de Internet of Everything.
2.10.1. Capas Arquitectónicas
Capas Arquitectónicas (Architectural Layers - AL) proporciona un marco para el
desarrollo de servicios y aplicaciones en Smart Cities a través de su fragmentación en
piezas (capas) que pueden ser fácilmente modificadas y ajustadas en lugar de transformar
todo el sistema. Cada capa se disocia física y lógicamente de las demás. Esta característica
es la que hace que la perspectiva sea única y explica su elección y gran aceptación por
parte de un gran número de investigadores. En este apartado se mencionan algunas de las
obras más destacadas que optan por implementar esta arquitectura con el fin de crear
instalaciones útiles para el Smart Cities.
2.10.2. Arquitectura Orientada a Servicios
La Arquitectura Orientada a Servicios (SOA) es un enfoque que tiene como objetivo la
recopilación, comunicación e interacción entre servicios y su prestación a los usuarios
teniendo en cuenta sus necesidades y peticiones. La comunicación entre los diferentes
servicios de un sistema informático se realiza mediante el intercambio de datos entre ellos
y la capacidad de cada servicio para actuar como una actividad completa en nombre de
otro servicio. Toda interacción se considera no restringida, ya que los servicios no están
relacionados entre sí, no están vinculados entre sí y son autosuficientes.
50
2.10.3. Arquitectura Basada en Evento
La arquitectura Basada en Eventos (Event Driven Architecture - EDA) es un marco que
se ocupa de la creación, identificación, utilización y respuesta a los eventos. Estos eventos
suelen ser poco comunes, extraordinarios y están relacionados con cambios inciertos y
condiciones asincrónicas. El resultado de las acciones que EDA ejecuta provoca la
generación de notificaciones de eventos (y no de un evento), que en realidad son un efecto
de la ocurrencia de cambios.
2.10.4. Internet of Things
El Internet of Things (IoT) es un paradigma que combina una gran cantidad de dispositivos
heterogéneos, que están conectados a Internet y pueden identificarse a través de
direcciones IP y protocolos. Todos los dispositivos están integrados con sensores y
actuadores y suelen estar conectados de forma inalámbrica a la red. IoT permite la
conectividad y la comunicación entre sensores y despliega la información entrante para
proporcionar diversas aplicaciones a las personas.
2.10.5. Arquitecturas Combinadas
A excepción de las perspectivas que analizamos anteriormente y la presentación de las
obras más subyacentes que ya han sido publicadas en la literatura, existe también la
perspectiva de las arquitecturas combinadas, que logra integrar las características y
tecnologías de las mencionadas anteriormente. Es un fenómeno común para que los
investigadores combinen tecnologías y plataformas en para crear una arquitectura que
probablemente pueda ser implementado en un SC. En esta sección, citamos algunos de
estos trabajos distinguiéndolos en categorías.
51
1) IoT – AL
Los ciudadanos actúan como proveedores de datos mediante el uso de sus teléfonos
móviles, y también como consumidores de los servicios en desarrollo después de procesar
la información recogida. La arquitectura propuesta, que se basa en un entorno de nube, se
divide en siete capas (cinco horizontales y dos verticales) y contiene el elemento de
conocimiento del contexto.
2) IoT – SOA
El concepto de SOA, que combina el IoT y la geolocalización para promover el acceso a
los servicios de Smart Cities.
3) IoT – SOA – AL
Una novedosa arquitectura de Vitalización de Datos (DV) con el fin de indicar una forma
más efectiva de gestionar los heterogéneos datos entrantes procedentes de los sensores.
La arquitectura DV, que se divide en celdas (maestras, de datos y especiales), utiliza
principalmente las tecnologías SOA y Cloud Computing. Una aplicación de DV es la
Smart Service Platform (SSP), la cual se distingue en cuatro capas de datos: capa de
recolección y almacenamiento, capa de soporte para Servicio de DV, capa de aplicación
para DV y capa de aplicación para el desarrollo.
4) IoT – EDA
Implementación de comunicaciones Máquina a Máquina (M2M) para mejorar las
aplicaciones de SC. La tecnología M2M tiene la capacidad de facilitar la conexión entre
personas, ordenadores y dispositivos móviles, así como entre sensores y actuadores.
52
5) IoT – SOA – AL – EDA
Una arquitectura para el Smart Cities desde la perspectiva de la gestión de datos. Su
arquitectura se divide en seis capas: capa de adquisición de datos, capa de transmisión de
datos, capa de almacenamiento de datos y capa de vitalización, capa de servicio de soporte,
capa de servicio de dominio y capa de aplicación dirigida por eventos.
2.10.6. Internet of Everything
El Internet of Everything (IoE) es una perspectiva de futuro que se está diseñando para
ampliar, superar y sustituir al IoT. Cisco define el IoE para Smart Cities como la
tecnología que conecta personas, procesos, datos y cosas para mejorar la calidad de vida
de las ciudades y comunidades. IoE proporciona no sólo dispositivos de computación,
sino que cada objeto (todo) tiene la capacidad de una alta conectividad e inteligencia para
operar varias instalaciones.
2.11. Modelo de Sistemas de Trasporte Urbano Inteligente
Al generar este modelo se han identificado los siguientes componentes
Factores para la transición para transporte inteligente
Al dividirse en 3 capas, Infraestructura, servicios y digitalización, se genera el siguiente
esquema (Ver Figura 9) el cual explica los factores a tomar en cuenta para la transición.
En primer lugar, se identifica en la capa de Infraestructura la ineficiencia del servicio y la
poca o nula relación que tiene el usuario con el mismo, generando una falta de experiencia.
Así mismo este factor ira incrementado debido al crecimiento de la población. Como
segundo factor se identifica el cambio climático, siendo este el más importante, y al mismo
tiempo una oportunidad para migrar hacia sistemas energéticos más estables e inteligentes.
53
Para finalizar, se tiene la capa de digitalización, la cual funcionara como puente entre las
dos capas mencionadas para la conversión.
2.12. Arquitectura para movilidad en Smart Cities
Para el desarrollo de propuesta de arquitectura, primeramente y una vez realizada la
investigación de los elementos a tomar por parte de la arquitectura de Cloud Computing
y Smart Cities, es la evaluación de un trabajo previo para realizar un análisis sobre el
mismo y una evaluación de que elementos se pueden llegar a utilizar.
El estudio realizado por (Di Martino, Sergio & Rossi, Silvia, 2016) describe una
arquitectura distribuida de IoT hacia la definición de un sistema de recomendación de
movilidad. En particular, se centra en una multimodalidad basada en el automóvil, en la
que el usuario siempre comienza un viaje con su vehículo privado, pero también puede
dejar el coche en infraestructuras de Park-and-Ride y llegar al destino con transporte
Transporte
Urbano
Inteligente
Ineficiencia
Pobre experiencia de usuario
Digitalización
Cambio
Climático
Eficiencia de
Recursos
Figura 9. Modelo de factores para transición hacia el transporte urbano inteligente (Elaboración del autor).
54
público. Este tipo de enrutamiento en un área de búsqueda más amplia y, por lo tanto, se
beneficiará especialmente de una solución de arquitectura computacional paralela.
Figura 10. Arquitectura de sistema de recomendación de movilidad (Di Martino, Sergio & Rossi, Silvia, 2016).
La arquitectura que proponen está dividida en varias capas, comenzando con la capa de
recurso de datos, la cual a su vez está dividida en dos subáreas, dinámica y estática. La
subárea estática hace referencia a los mapas donde se visualizará la información de los
diferentes medios de transporte y la parte dinámica, la cual con a poyo de tecnología,
proporcionará la información en tiempo real. En seguida el sistema recomendador el cual
realizara el análisis de rutas a partir de los perfiles de usuario y las consultas que estos
generen; esta parte a su vez comprende una segunda capa que es la capa del sistema
recomendador. Para finalizar, un usuario podrá consultar los resultados por medio de
alguna aplicación móvil y visualizar la lista de rutas.
55
2.13. Métodos de evaluación de arquitecturas
En el artículo de Métodos de Evaluación de Arquitecturas (Bass & Nord, 2012) expresa y
estudia varios métodos de evaluación de la arquitectura de software industrial desde la
perspectiva de sus elementos contextuales. Los elementos contextuales son el tiempo
disponible para la evaluación, el personal disponible, la disponibilidad de los resultados,
la participación de las partes interesadas, etc. El objetivo de este análisis es reportar a los
directivos y a los responsables técnicos sobre las diferentes posibilidades de una
evaluación de la arquitectura dado su contexto.
Los métodos de la industria que existen y se comparan son los siguientes: el Architecture
Tradeoff Analysis Method® (ATAM®), Tiny Architectural Review Approach (TARA),
Lightweight Architecture Alternative Assessment Method (LAAAM), y revisiones por
pares basadas en escenarios.
El ATAM es un método que permite a las partes involucradas en el sistema entender las
implicaciones de las decisiones arquitectónicas con relación a los requerimientos de los
atributos de calidad del sistema. Es el método de evaluación que TARA, LAAAM y
Scenario-based peer reviews utilizan como punto de referencia y ocupa un lugar especial
en nuestra metodología para definir un marco de comparación.
La TARA definida por Eoin Woods se basa en la experiencia industrial con el objetivo de
ofrecer orientación sobre la forma de llevar a cabo una revisión arquitectónica sencilla
para mostrar la factibilidad y el mérito de las revisiones en entornos industriales en los
que es poco probable que los métodos basados en escenarios tengan éxito.
El LAAAM definido por Jeromy Carriere se basa en la adaptación del ATAM; se basa en
escenarios y reúne a las partes involucradas para determinar lo que para el sistema
significa calidad y para participar en un proceso de toma de decisiones racional.
56
Como se observa (Ver Figura 11) los diferentes métodos propuestos nos indica según la
arquitectura, un camino por el cual desarrollar, aunque dependerá mucho del contexto que
se esté revisando.
Figura 11. Factores conceptuales en los diferentes métodos. (Bass & Nord, 2012).
57
La elección de un método depende de una serie de factores ajenos a los que se han
identificado. Los factores contextuales proceden del examen de los diversos métodos, pero
el apoyo organizativo para la evaluación de la arquitectura puede cambiar el método más
apropiado.
2.14. Evaluación de Arquitecturas de Software con ATAM
La evaluación mediante ATAM (Architecture Tradeoff Analysis Method) según lo
expone (Delgado, Castro, & Martín, 2007) en su artículo; es una metodología para evaluar
Arquitecturas de Software que principalmente evalúa la adecuación de la Arquitectura de
Software definida con respecto a los atributos de calidad especificados para el sistema.
Surge confluyendo ideas y técnicas de tres áreas: la noción de estilos o patrones de
arquitectura, el análisis de atributos de calidad y el método Software Architecture Analysis
Method (SAAM), que es el predecesor del ATAM.
Para evaluar un diseño arquitectónico contra los requerimientos de atributos de calidad es
necesario contar con una caracterización de los atributos de calidad.
El corazón de ATAM consiste en la ejecución de nueve pasos que se dividen en cuatro
grupos que su vez, se realizan en el tiempo en cuatro Fases diferenciadas. Estos cuatro
grupos no se corresponden uno a uno con las Fases, sino que se realizan en las Fases 1 y
2, y se agrega una Fase 0 previa de preparación y una Fase 3 posterior de finalización del
proyecto. Los cuatro grupos en que se dividen los nueve pasos definidos consisten en un
primer grupo de presentación, donde se intercambia información del sistema, un segundo
grupo de investigación y análisis, donde se valoran los atributos de calidad claves uno a
uno con las propuestas arquitectónicas, un tercer grupo de pruebas donde se revisan los
resultados obtenidos contra las necesidades relevantes de los Skateholders, y un cuarto y
último grupo donde se presentan los resultados del ATAM.
58
Fase 1: En la Fase 1 se realizan las actividades correspondientes a los grupos de
presentación e investigación y análisis. El grupo de presentación se compone de tres pasos:
1 – Presentar el ATAM, 2 – Presentar las pautas del negocio y 3 –Presentar la
Arquitectura.
El segundo grupo de investigación y análisis se compone también de tres pasos: 4 –
Identificar las propuestas arquitectónicas, 5 – Generar el árbol de utilidad de los atributos
de calidad y 6 – Analizar las propuestas arquitectónicas.
Fase 2: En la Fase 2 se realizan las actividades incluidas en el tercer grupo de pruebas y
el cuarto grupo de informes, que completan los tres pasos restantes. El grupo de pruebas
se compone de dos pasos: 7 – Lluvia de ideas y 8 – Analizar las propuestas arquitectónicas
y el grupo de Informes se compone de un solo paso: 9 – Presentar los resultados.
59
2.13. Framework de Smart Cities
El marco propuesto sugiere tres aspectos de una ciudad inteligente, con sus características
como lo establece el autor (Hozaim & Akre, 2017) y que se observan en la imagen (Ver
Figura 12). Los aspectos son:
1) La digitalización de la ciudad:
La ciudad debe estar cubierta con acceso Wi Fi y siempre conectada a Internet.
a) Nodos de sensores (sensores de hogar, ciudad y de desastres)
b) Smart Grids (Medidores inteligentes en el hogar y en el trabajo, facturación
inversa)
c) M-Gobierno (Seguridad, Proveedores de Servicios Públicos, Transporte)
2) Citizen Centric:
Smart City es una iniciativa para la felicidad de los ciudadanos y la sostenibilidad
futura.
a) Mejorar la calidad de vida (Reducir los delitos y la contaminación, vigilar la
salud y proteger el medio ambiente).
3) Colaboración abierta:
Acceso abierto a los datos para todos los habitantes de la ciudad.
a) Participación Ciudadana (Conectar con el Gobierno, Interactuar y
Transaccionar).
b) Oportunidad para nuevos modelos de negocio (Red social de jóvenes
emprendedores, creación de aplicaciones para empresas y fomento de la
innovación).
60
c) Compartir y reutilizar los activos y servicios de la ciudad (Reducir la
duplicación de infraestructura y Cloud (SOA)).
Figura 12. Framework de Smart Cities (Hozaim & Akre, 2017).
Una ciudad vibrante y sostenible es un ecosistema compuesto de personas, organizaciones
y empresas, políticas, leyes y procesos integrados para crear los resultados deseados. Esta
ciudad es adaptable, receptiva y siempre relevante para todos aquellos que viven, trabajan
y visitan la ciudad tal como lo muestra el framework indicado (Ver Figura 13). Una ciudad
inteligente integra la tecnología para acelerar, facilitar y transformar este ecosistema
(Paramel, 2018).
Smart Cities
Digitalización de la ciudad
Nodos sensoriales
Redes inteligentes
M-Government
Ciudadano céntricoMejorar la calidad de
vida
Reducir crimenes
Reducir Polución
Monitoreo de salud
Protección del medio ambiente
Colaboración abierta
Ciudadanos involucrados
Oportunidad para nuevos modelos de
negocios
Compartir y reutilizar los bienes y servicios
de la ciudad
61
Figura 13. Framework del ecosistema Smart Cities (Paramel, 2018).
Cinco tipos de generadores de valor
Hay cinco tipos de generadores de valor en el ecosistema de la ciudad inteligente.
Cities: Cuando la gente piensa en una ciudad inteligente, automáticamente piensa en los
servicios proporcionados por las agencias municipales y cuasi gubernamentales, como el
estacionamiento inteligente, la gestión inteligente del agua, la iluminación inteligente, etc.
Utilities: Las empresas de servicios públicos son proveedores de infraestructura y
capacidades críticas para la ciudad inteligente. En muchas comunidades, la compañía
eléctrica es propietaria de la iluminación de las calles y los postes, que cada vez se
consideran más como un valioso espacio vertical para montar una serie de sensores y
equipos de telecomunicaciones (antenas, pequeñas células y hardware de 5G, y puntos de
acceso Wi-Fi). Son dueños de los medidores inteligentes (gas, agua y electricidad) y de
su red inalámbrica. Las empresas de servicios eléctricos están invirtiendo cada vez más
62
en energía distribuida, redes inteligentes y tecnologías de microrredes que serán una parte
esencial de la moderna ciudad inteligente.
Corporations: Las empresas y organizaciones pueden crear servicios que utilizan y crean
información para crear resultados para sus grupos de interés.
Communities: Las comunidades son ciudades inteligentes en miniatura, pero con
necesidades muy localizadas. Algunos ejemplos de comunidades inteligentes potenciales
incluyen campus universitarios, parques de oficinas, aeropuertos, puertos de carga,
unidades de vivienda múltiple (MDU) o complejos de apartamentos,
urbanizaciones/vecindarios, distritos de negocios e incluso edificios "inteligentes"
individuales. Necesitan servicios inteligentes que puedan adaptarse específicamente a las
partes interesadas.
Citizens: Los residentes o ciudadanos individuales también son proveedores de servicios
inteligentes en la ciudad inteligente. Un residente que vive cerca de una intersección
peligrosa puede apuntar con una cámara a la intersección y transmitir esa información en
vivo a los planificadores de tráfico y a la policía. Los residentes colocan sensores de
medición de la calidad del aire en sus propiedades para monitorear la contaminación y los
niveles de polen durante ciertas épocas del año, y ponen esa información a disposición de
otros miembros de la comunidad. Los residentes pueden elegir hacer que estos servicios
inteligentes sean temporales o permanentes, y gratuitos o de pago.
La ciudad inteligente se construye sobre capas
Una ciudad inteligente es un ecosistema compuesto de múltiples "capas de capacidad". Si
bien la tecnología es un factor crítico, es sólo una de las muchas capacidades
fundamentales que toda ciudad inteligente debe tener. Ninguna capacidad es más
importante que el resto. Cada capacidad juega un papel diferente en la ciudad inteligente.
Estas capacidades deben integrarse y coordinarse entre sí para llevar a cabo su misión.
63
Capa de valores: Esta es la capa más visible para los residentes de la ciudad, empresas,
visitantes, trabajadores, estudiantes, turistas y otros. Esta capa es el catálogo de servicios
urbanos inteligentes o "casos de uso", y ofrecidos por los creadores de valor y consumidos
por los actores de la ciudad.
Capa de innovación: Para mantener su relevancia, los creadores de valor de la ciudad
inteligente deben innovar y actualizar continuamente sus servicios para sus grupos de
interés. Las ciudades inteligentes facilitan esto proactivamente a través de una variedad
de programas de innovación, incluyendo laboratorios, zonas de innovación, capacitación,
talleres de ideas, desarrollo de habilidades y asociaciones con universidades y empresas.
Capa de gobierno, gestión y operaciones: La ciudad inteligente crea interrupciones y
resulta en la transformación digital de los procesos y servicios existentes. Los modelos
inteligentes de gestión de ciudades deben integrar un nuevo ecosistema de creadores de
valor e innovadores. Deben planificar, apoyar y monetizar nuevos modelos de negocio,
procesos y servicios. Deben actualizar su infraestructura y sus procesos de gestión
existentes para apoyar los servicios "inteligentes". Finalmente, deben medir el desempeño
de la ciudad con un nuevo conjunto de métricas.
Capa de financiación: Para construir, operar y mantener la ciudad inteligente se requiere
un conjunto completamente nuevo de modelos de compromiso, reglas, fuentes de
financiamiento y socios.
Capa de información y datos: La ciudad inteligente debe facilitar esto de varias maneras,
incluyendo iniciativas de datos abiertos, mercados de datos, servicios de análisis y
políticas de monetización. Igualmente, deben tener programas que fomenten el
intercambio de datos y políticas de privacidad para proteger qué y cómo se recopilan los
datos.
64
Capa de conectividad, accesibilidad y seguridad: Las personas, cosas y sistemas están
interconectados en la ciudad inteligente. La capacidad de conectar sin problemas a los
tres, gestionar y verificar quién y qué está conectado y qué se comparte, a la vez que se
protege la información y a los usuarios es crucial. Las máximas prioridades de las ciudades
inteligentes son proporcionar una capa sin fisuras de conexiones de confianza.
Capa de infraestructura tecnológica inteligente de la ciudad: La mayoría de la gente
piensa automáticamente en la tecnología cuando habla de ciudades inteligentes. La
infraestructura tecnológica de las ciudades inteligentes debe escalar más allá de los
usuarios municipales tradicionales y apoyar a una nueva clase de creadores de valor y a
las partes interesadas de la ciudad/usuario.
65
2.14. Framework de Cloud Computing
Modelos de prestación de servicios de la nube
Después de numerosas investigaciones, los tres modelos principales de entrega son IaaS,
PaaS y SaaS. Según indica el autor (Singh, Jeong, & Hyuk park, 2016), todavía hay
numerosos modelos de servicio disponibles en función de su operatividad y de sus
capacidades de prestación de servicios, que han llevado a la creación de los modelos de
prestación de servicios Anything-as-a-service 'AaaS' tal y como se puede observar en la
imagen (Ver Figura 14).
Figura 14. Framework de Cloud Computing (Singh et al., 2016).
• Infrastructure as a Service (IaaS): pertenece a la parte inferior del modelo. IaaS
se ocupa del hardware informático (almacenamiento en red, servidor/máquina
virtual, centro de datos, procesador y memoria) como un servicio. IaaS respalda la
revolución en la inversión empresarial en infraestructura de TI.
66
• Platform as a Service (PaaS): Está en el modelo de middleware de servicio y
entrega los servicios en forma de herramientas de desarrollo, frameworks,
arquitecturas, programas y Entornos de Desarrollo Integrado (IDE). En otras
palabras, los clientes pueden controlar las aplicaciones, pero no tienen ningún
medio para controlar la infraestructura subyacente.
• Software as a Service (SaaS): es una colección de servicios de cómputo remoto.
SaaS se encuentra en la parte superior de los modelos de entrega. Permite que las
aplicaciones se distribuyan de forma descentralizada a través de terceros. Permite
al cliente utilizar la aplicación del prestador de servicios en la nube (CSP) que se
ejecuta en la infraestructura de la nube a través de Internet. El SaaS es el mercado
predominante de la nube y sigue creciendo rápidamente.
• Anything as a service (AaaS): es un término colectivo que combina una serie de
cosas como X as a service. X puede ser cualquier cosa o todo como un servicio.
Este servicio se vuelve intercambiable en el entorno de la nube.
Modelo de implementación de nube
Cloud Computing generalmente depende de recursos compartidos por servidores locales
o dispositivos independientes. Por lo tanto, es posible lograr la coherencia aprovechando
las ventajas de la distribución de recursos. El modelo implementado indica el objetivo y
la índole de la nube.
Nube privada: La computación en nube funciona y se administra con el centro de datos
de una organización, que se denomina nube privada. Muchos consumidores de
infraestructura de Cloud (por ejemplo, unidades de negocio) han incluido cláusulas para
uso exclusivo de una única organización. En la nube privada, es mucho más fácil
identificar la relación entre cliente y proveedor porque la infraestructura es propiedad de
67
la misma organización y está operada por ella. Por lo tanto, los riesgos de seguridad son
más fáciles de detectar.
Nube pública: Es la auténtica representación del alojamiento en nube donde el cliente y
el proveedor tienen un fuerte acuerdo de nivel de servicio (SLA) para mantener la
confianza entre ellos. En esta infraestructura de nube, el acceso abierto al público y a la
organización está garantizado.
Nube comunitaria: La infraestructura de nube de las organizaciones comparten
preocupaciones (misión, requisitos de seguridad, políticas y consideraciones de
cumplimiento) de los consumidores, se ha hecho una provisión especial para uso exclusivo
del modelo de comunidad. En pocas palabras, una nube comunitaria está siendo
compartida y controlada por múltiples organizaciones. También reduce el riesgo de
seguridad en la nube pública y reduce el coste de la nube privada.
Nube híbrida: Es la asociación de dos o más nubes (públicas, privadas, comunitarias).
Por lo general, los datos y la aplicación están unidos por una tecnología estandarizada y
propia. La nube híbrida ofrece las ventajas de diferentes modelos de implementación de
nubes. Sin embargo, está bien organizado y es más seguro que la nube pública mientras
accede a las entidades a través de Internet.
Cloud Computing virtual: Se trata de una nube semiprivada, con menos recursos, y
consiste en una red privada virtual (VPN). Es un paquete configurable de recursos
compartidos asignados dentro del entorno de la nube.
Componentes básicos de Cloud Computing
Los elementos básicos sobre los que se despliega el Cloud Computing. Estos elementos
constan de una amplia variedad de servicios que podemos utilizar en todo el mundo a
través de Internet.
68
Virtualization: Desempeña un rol importante en el momento de implementar la nube. Es
el elemento estratégico en la nube, que posibilita la utilización de los recursos físicos por
parte de múltiples consumidores. Crea la instancia virtual de recurso o dispositivo como
sistema operativo, servidores, recursos de red y dispositivos de almacenamiento donde en
el framework se utilizan los recursos en más de un entorno de ejecución.
Multi-tenancy: El entorno multi-tenant puede tener múltiples clientes o usuarios que no
ven ni comparten la base de datos de los demás, pero pueden compartir recursos o
aplicaciones en un entorno de ejecución, incluso si no pertenecen a la misma organización.
Multi-tenancy resulta en una óptima utilización del hardware y del mecanismo de
almacenamiento de datos.
Cloud storage: Es un elemento que conserva, administra y respalda de forma remota y
que está disponible a través de la red, donde los usuarios pueden tener acceso a los datos.
El hypervisor: El denominado monitor o gestor de máquinas virtuales es un módulo clave
de la virtualización. Éste permite que varias máquinas virtuales (VM) se ejecuten en un
único host de hardware. Administra y monitorea los distintos sistemas operativos, que se
ejecutan en un sistema físico compartido.
Cloud Network: Puede controlar más de un datacenter convencional; un datacenter
común contiene cientos o miles de servidores. Para crear y administrar de forma eficiente
los almacenamientos, la nube necesita una infraestructura de red segura llamada cloud
networking. Para ello se requiere una conexión a Internet y similar con una red privada
virtual que facilite al usuario el acceso seguro a impresoras, aplicaciones, archivos, etc.
69
Concepto de seguridad en Cloud Computing
Hoy en día, la guerra cibernética es posiblemente el desafío más complejo en un entorno
distribuido y multiusuario. Es un trabajo complejo dentro de la arquitectura cliente-
servidor. Cuando los datos se transfieren a los servicios Cloud, los requisitos de seguridad
deben ser los más importantes. En esta sección, presentamos brevemente las principales
preocupaciones de seguridad del Cloud Computing.
Software security: Ofrece una idea básica de la seguridad del software, que surge del
departamento de ingeniería de software y que se coordina para que funcione correctamente
en el marco de las actividades malintencionadas. La creación de un entorno de nube es un
problema central y crítico para la seguridad del software. Defectos de seguridad,
incluyendo errores de ejecución, desbordamiento de búfer, leyes diseñadas, promesas de
manejo de errores y mucho más.
Infrastructure security: El reto más común y fundamental es demostrar que se puede
confiar en la infraestructura física y virtual de la nube. La certificación del tercero no es
suficiente para el proceso de negocio crucial. Es absolutamente imprescindible para que
la organización compruebe los requisitos de negocio que la infraestructura base es segura.
Storage security: En el sistema de almacenamiento en nube, el usuario final almacena
los datos en la nube y ya no es propietario de los datos ni de dónde están almacenados.
Este ha sido siempre un aspecto importante de la calidad del servicio garantiza la exactitud
de los datos de los usuarios en la nube y mediante la utilización de tokens con verificación
distribuida de datos codificados.
Network security: En Cloud Computing, la comunicación se produce a través de Internet
y es la columna vertebral del ambiente de la nube. La seguridad de la red se ve afectada
por los ataques internos y externos. Estos ataques en la red pueden ocurrir en la red virtual
o física.
70
2.15. General Transit Feed Specification (GTFS)
En 2005, con el fin de crear un planificador de viajes de tránsito utilizando la aplicación
web Google Maps, Google y TriMet en Portland formularon el General Transit Feed
Specification (GTFS).
En 2007, Google publicó las especificaciones de las fuentes de tránsito y animó a las
agencias de tránsito a emplear el formato GTFS para generar datos de tránsito y publicar
estos datos en la web como fuentes abiertas para el uso público.
Debido a su creciente popularidad, el formato GTFS ha sido adoptado por la industria del
tránsito como un estándar para compartir datos de programación, y más y más agencias
de tránsito están subiendo datos GTFS a Google. Hoy en día, más de 170 agencias de
tránsito en los Estados Unidos y Canadá generan y publican sus horarios como GTFS.
Por lo general, sobre la base del formato GTFS, una agencia de tránsito debe crear 13
tablas, en las que la tabla de agencia, de parada, de rutas, de viajes, de tiempos de parada
y de calendario son obligatorias; las tablas opcionales incluyen la tabla de tarifas, la tabla
de transferencias, la tabla de alimentación (Ver Figura 15). En cada tabla, se requieren y
atributos opcionales. Los atributos obligatorios son datos generalmente importantes para
identificar la información básica. (Zhang, Chen, & Lawson, 2014).
Figura 15. Tablas comunes del GTFS (Elaboración del autor).
71
Otra aplicación de los datos del GTFS es la visualización de datos por medio de la web o
aplicaciones móviles.
Entonces, ¿qué es exactamente GTFS? GTFS es un estándar de datos para organizar datos
de tránsito abierto. Los datos están organizados en archivos de texto, como el conjunto de
archivos que se muestran aquí, que juntos crean una base de datos relacional. Esta imagen
muestra cómo los archivos de un feed GTFS se conectan para formar una base de datos;
ciertos campos, o entradas, en cada archivo se conectan a campos en otros archivos. Un
feed GTFS tiene seis archivos necesarios, aquí mostrados en verde, y otros archivos
opcionales, aquí mostrados en púrpura (Ver Figura 16). Nos centramos en algunos de los
archivos necesarios. (Krambeck, 2018).
Figura 16. Modelo GTFS. (Krambeck, 2018).
Fortalezas del GTFS
Para un principiante en GTFS, la estructura de archivos explicada puede parecer
complicada, pero a medida que se usa, tiene mucho sentido y es fácil de implementar. Esta
es la mayor fortaleza de GTFS, ya que permitió que el formato se extendiera por todo el
mundo sin ninguna legislación ni organización que lo impulsara.
72
Además, el formato permite flexibilidad en forma de archivos opcionales, y un feed GTFS
puede contener información para múltiples modos de tránsito - como información de
autobuses y trenes - haciendo posible que una agencia de tránsito tenga un feed que
contenga todos sus datos de tránsito.
La estructura del GTFS también permite que se construya sobre ella, añadiendo nueva
información que no está contenida en un feed del GTFS, como la información de llegada
en tiempo real.
Finalmente, como formato de datos de código abierto, GTFS está siendo constantemente
mejorado por los usuarios.
Debilidades del GTFS
Por supuesto, todavía existen algunas limitaciones en el GTFS. Desde que fue creado en
los Estados Unidos, la estructura del GTFS está diseñada para sistemas de tránsito fijos
formalizados. Esto significa que muchas ciudades del mundo que dependen del tránsito
semiformal o informal necesitan ser innovadoras para que el GTFS funcione en sus
sistemas. Sin embargo, no es imposible. Es un paso crítico para mejorar el tránsito en estas
ciudades.
73
2.16. OneBusAway
Para este caso se utilizará OneBusAway para el desarrollo de la aplicación, no solo por su
sencillez de uso, sino por la documentación extensa que existe en el mismo. No se utiliza
alguna de las marcas anteriormente mencionada debido a diferentes factores mencionados
(Ver Tabla 3).
Figura 17.Google Maps Logo (Google, 2016).
Aplicación que incluye Google
Maps, en ella se pueden ver las
rutas agregadas por GTFS, se
utiliza para el desarrollo de
aplicaciones de terceros, aunque
se requiere contrato con la
agencia de movilidad de la
ciudad correspondiente para
subir los archivos GFTS y
convertirse en Partner con
Google Transit (Google, 2016).
Moovit
Figura 18. Moovit Logo (Moovit, 2015).
Empresa que requiere contacto
para poder subir la información.
Ofrece un panel para agregar
Los datos en lugar de edición de
código. No utiliza los mapas de
Google Maps (Moovit, 2015).
Chalo App
Figura 19. Chalo Logo (Chalo, 2018).
Utiliza tecnología GTFS para la
localización de las rutas de
manera estática y no ofrece
herramientas de desarrollo. Se
requiere hacer contacto con la
74
empresa para poder hacer un
contrato (Chalo, 2018).
Citymapper
Figura 20. Citymapper Logo (Citymapper, 2018).
No se puede personalizar la
aplicación, aparte de generar un
contrato con la empresa para
agregar las funcionalidades. Las
API no cuentan con soporte al
desarrollo de aplicaciones
(Citymapper, 2018).
Transit App
Figura 21. Transit Logo (Transit, 2012).
No cuenta con open source del
código para ediciones
personalizadas, aunque se
requiere contrato con la empresa
para publicar la ciudad en la
aplicación (Transit, 2012).
Tabla 3. Plataformas para el desarrollo de aplicaciones de planeación de viajes
(Elaboración del autor). Como se indica en la información posterior, se decidió optar por el desarrollo de la
aplicación con el Open Source para agilizar la implementación, pero sobre todo para una
inclusión más estable a los usuarios finales (OneBusAway, 2010).
75
OneBusAway – Open Source para el desarrollo de aplicaciones para planeación de transporte público.
Figura 22. Logo de OneBusAway (OneBusAway, 2010).
OneBusAway (OBA) es un proyecto de distribución libre el cual a partir del 2010 ha
logrado generar impacto debido a la gran sencillez de modificación además de contar con
una gran comunidad que respalda a los usuarios de las diversas agencias de movilidad que
requieran desarrollar la propia sin la necesidad de empezar un proyecto desde cero.
Actualmente el equipo de desarrollo de OBA se extiende no solo al gubernamental sino
académica contando con el apoyo de las universidades de Washington, South Florida, City
College of New York, solo por mencionar algunos, así como diferentes agencias de
movilidad que contribuyen al desarrollo de la aplicación y a su crecimiento, contando con
una variedad de ellas entre los Estados Unidos y Canadá.
Si bien OBA es una organización sin fines de lucro y la cual tiene su aplicación disponible
en diversas plataformas, una serie de ciudades han optado por personalizar el sistema de
OBA para adaptarlo a sus necesidades, generando nuevas marcas totalmente
independientes de la aplicación original, ofreciendo finalmente, más opciones de
aplicaciones. Si bien OBA se distingue por tener una serie de ciudades registradas en su
base de datos, con información agregada a través de las diferentes agencias, las ciudades
que han decidido modifican el código con tal de generar sus propias aplicaciones son las
que se exponen en seguida (Ver Tabla 4).
76
New York, NY
Figura 23.MTA Bus Time Logo (MTA, 2014).
MTA Bus Time es una versión
personalizada de OneBusAway de
la MTA de Nueva York. Se amplió
para cubrir la totalidad de la ciudad
de Nueva York en marzo de 2014.
Durante los períodos de mayor
demanda, el MTA Bus Time
responde a 30,000 consultas por
minuto. La información en tiempo
real ha incrementado el número de
usuarios anuales en un estimado de
8 millones. (MTA, 2014)
York, Canadá
Figura 24.York Region Transit Logo (YRT,
2016).
York Region Transit / VIVA ha
presentado OneBusAway en York,
Canadá. York cuenta con versiones
personalizadas de las aplicaciones
para Android y iOS, y además está
presente en las apps para
OneBusAway (YRT, 2016).
Washington, DC
Figura 25. busETA Logo (busETA, 2016).
Washington Metropolitan Area
Transit Authority (WMATA)
introdujo busETA, una versión
personalizada de OneBusAway, en
febrero de 2016 (busETA, 2016).
77
Poznań region, Poland
Figura 26. KIEDY BUS Logo (kiedybus, 2016).
goEuropa renombró a las
aplicaciones móviles
OneBusAway y a su sitio web
como "KiedyBus" y las lanzó en
mayo de 2016. Actualmente, el
despliege proporciona información
en tiempo real para Środa
Wielkopolska y Kórnik, e incluye
información sobre la programación
de toda la región Poznań
(kiedybus, 2016).
Tabla 4. Ediciones personalizadas de OneBusAway (OneBusAway, 2010).
78
2.17. Comentarios sobre el capítulo
La base teórica ha sido establecida de tal manera que se puede proceder con el diseño
tanto del modelo arquitectónico como de su posterior aplicación y exposición en diferentes
casos de usos. Este capítulo de igual manera muestra un gran enfoque a la revisión de
literatura orientada al uso de aplicaciones, el cual tomara un rol importante durante la
construcción del modelo arquitectónico.
79
CAPÍTULO III: GOBERNANZA E INTERACCIÓN SOCIAL
SOBRE EL TRANSPORTE PÚBLICO EN AGUASCALIENTES,
MÉXICO
El sistema de transporte público ha tenido a lo largo del tiempo una presencia muy concisa
en el estado de Aguascalientes. En este capítulo se retomará un poco de historia para
entender la importancia del transporte y sus mejoras a través del paso del tiempo. Este
capítulo es crítico pues nos proporciona una visión de cómo se encuentra actualmente este
servicio y las áreas de oportunidad a solucionar que están debidamente relacionados a las
preguntas de investigación definidas previamente.
3.1. Sistema de Transporte Publico en la ciudad de Aguascalientes
A partir del problema de investigación planteado, y con la finalidad de proporcionar un
escenario para la comprensión de este, se decide conceptualizar parte de la historia
fundamental sobre el Sistema de Transporte Publico (STP) en la ciudad de Aguascalientes.
El caso del transporte público se origina en el estado a mediados del 1930, Esta línea de
transportes tomó el nombre de Camiones de los Altos y fue originaria entre por una
sociedad entre las ciudades de Aguascalientes y Jalisco, siendo su primera terminal estaba
en la esquina de Madero y Morelos. (Delgado Aguilar, 2017).
Así mismo para la asistencia y uso del transporte en el interior del estado se abandonó el
uso del ferrocarril para el transporte de pasajeros dentro de la ciudad y se sustituyó por
camiones Ford de cuatro cilindros y la terminal conectaba con el actual mercado Terán.
Este servicio se utilizaba tanto para la capital como para los municipios, siendo el primero
Jesús María.
80
Figura 27. Transporte público de Aguascalientes en 1930. (Delgado Aguilar,
2017).
Según se indica (Batres García, 2012) la construcción y establecimiento de una
concesionaria por parte del gobierno fue instalada en el estado, con el nombre de “Alianza
de Transporte Urbano y Suburbano de Aguascalientes” (ATUSA) aproximadamente en
los años de 1990, siendo la encargada de ofrecer el servicio dentro del estado.
Esta concesionaria desde entonces ha sido la responsable de ofrecer el servicio y si bien
al comienzo de sus operaciones lograba desempeñar sus funciones de una manera correcta,
han pasado décadas desde su concepción y las unidades de transporte se han descuidado,
llegando a expirar su vida útil.
Previamente a la consolidación de ATUSA, existían diversas empresas que se
desempeñaban en el servicio de transporte publico siendo estas las siguientes: Ruta
Madero, Oriente, Apostolado, Petróleos y Los Brujos. Además, todo se establecía a partir
de la empresa, logrando de esta manera otorgar seguridad social a los empleados de las
unidades de transporte, cuestión que con el paso del tiempo y aunque lo adopto ATUSA,
fue abandonado.
Siendo una empresa que fue bien vista en la sociedad y en algunos estados de la república
mexicana por su excelente trabajo cuando comenzó operaciones, por alguna razón siendo
la económica la principal de estas, se aprecia que fue disminuyendo, sin embargo, es
81
posible incrementar nuevamente el servicio de la concesionaria y que si bien es la única
empresa encargada del manejo de las unidades de transporte público y la que ofrece este
tipo de servicios en el estado, en la actualidad está siendo castigada por diversos factores
debido a la falta de calidad en el servicio. (Heraldo, 2018).
Actualmente la organización de ATUSA enfrenta diversas dificultades siendo las más
apremiantes la urgente renovación de unidades, debido a que las unidades existentes
superan su tiempo de vida útil y generan aparte de contaminación, una serie de dificultades
para el usuario, tanto para su movilidad, haciendo más complicado el traslado de la ruta
debido a problemas técnicos de la unidad así como de seguridad, pues algunas unidades
cuentan con asientos poco estables, lo cual puede generar algún accidente (Cerbón, 2018).
Si bien la concesionaria ha tratado de realizar aumentos en los costos del servicio para de
esta manera resolver sus dificultades, la cuestión es que ha logrado tener la negativa con
la parte del gobierno lo cual genera un desprestigio que no es válido a pesar de las
dificultades que pueda tener ATUSA como empresa. De igual manera la creación de
nuevas propuestas de movilidad termina por ser desechadas debido a los cambios de poder
que tiene el estado cada tres años, haciendo una transformación en el servicio mucho más
lenta.
Por lo tanto, la actual administración y gestión de las unidades urbanas ha complicado un
uso correcto de las mismas, pero, sobre todo, ha ocasionado el descontento de la sociedad
del estado, logrando colocar este servicio como uno de los más deficientes al momento de
solicitarlos debido sobre todo a la gran espera que se requiere para poder abordar una
unidad y a la gestión sin control de unidades en especial cuando más se solicitan.
3.2. Uso, recepción y aceptación de usuarios al STP
El estado de Aguascalientes en la fecha del 2015 según el censo realizado por el Instituto
Nacional de Estadística y Geografía INEGI (INEGI, 2018), informa que el total de
personas que habita el estado es de 1,316.032 personas. Así mismo por la información que
82
se indica la cantidad de vehículos de camión de pasajeros establecido para la ciudad son
700 unidades.
Según lo reporta la fuente escrita de La Jornada Aguascalientes (Aguascalientes, 2015),
el 36 por ciento de la población de la ciudad de Aguascalientes se transporta por medio de
los autobuses de la concesionaria ATUSA, siendo un total aproximado de 473,772
personas que utilizan este servicio diariamente. La concesionaria para cumplir con la
demanda que se solicita por la ciudad cuenta con 50 diferentes rutas con diversos horarios
de pasaje establecidos, más sin embargo la diferencia de tiempo de espera real se prolonga
por más de media hora, más tiempo de lo que inicialmente se propone y tal como se puede
observar a continuación (Ver Tabla 5).
Rutas de Transporte de Aguascalientes
Rutas Tiempo de recorrido en horas/minutos
Frecuencia en minutos
1 1:18 10
2 1:54 9
3 1:10 11
4 2:40 10
5 1:14 10
6 1:30 12
7 1:42 9
8 1:16 12
9 1:26 8
10 1:20 10
11 1:35 11
12 1:00 12
13 1:30 10
14 1:40 14
15 1:15 12
16 1:20 12
17 1:30 10
18 2:00 13
19 1:05 8
20 1:30 6
21 2:00 8
22 1:30 10
23-23B 1:10 9
24 1:10 16
25 1:04 10
83
26 1:30 20
27 1:06 10
28 2:48 10
29 1:48 9
30 1:15 12
31 1:17 14
32 1:00 10
33 2:26 12
34 1:15 9
35 1:54 9
36 1:40 9
37 1:23 9
38 1:00 15
39 1:42 12
40 1:40 7
41 0:42 10
42 2:00 9
43 1:26 13
44 1:13 16
45 2:30 12
46 1:10 15
47 1:45 10
48 1:26 12
50 1:27 7
Tabla 5. Horario de las rutas del STP (Movilidad, 2016).
Como se puede apreciar, la problemática del tiempo que se invierte en espera según lo que
indica la tabla previamente señalada no es exacta a la realidad, pues actualmente no se
tiene un tiempo definido real, por lo cual la información que se proporciona por parte del
gobierno del estado sobre los tiempos y recorridos no es precisa.
Las unidades de transporte publico tienen un costo que hasta el día de hoy va de $7.50
para los usuarios y un precio especial de $2.50 para alumnos de cualquier institución, esto
haciendo uso de una tarjeta inteligente la cual es necesario activar en las oficinas de
ATUSA. El uso de este esquema ha complicado la usabilidad del servicio por parte de los
usuarios debido a los altos costos, derivados a que aumentan cada año. (Movilidad, 2016)
84
La recepción por parte de los usuarios indica una gran falta de calidad debido a diferentes
factores, tales como el mantenimiento de la unidad, el modo de manejar de los chóferes,
pues algunos no respetan señalamientos de tráfico y viales, problemas de contaminación
y siendo uno de los más importantes, la espera que se invierte para poder abordar las
unidades.
Tales problemas se han originado según se indica por la misma empresa ATUSA, ya que,
al ser la única proveedora de servicios de esta índole en el estado, según indican usuarios
y diputados, tienden a exigir aumentos sin mejora alguno en el servicio.
Esto aunado al paso de los años ha terminado por ser un conflicto para los usuarios que
desde tempranas horas de la mañana sufren con la tardanza de las unidades, siendo estas
abarrotadas desde las primeras paradas de la ruta, imposibilitando la subida de más
usuarios en el trascurso de la ruta, lo que da como resultado más usuarios con una solicitud
de demanda sobre el servicio y que las unidades, al demorar en su salida y tener poca
gestión o control de estas, se sale de control el número de unidades que se deben enviar
para reducir la demanda mencionada (Hidrocalidodigital, 2018).
Por lo tanto, la aceptación que se tiene del servicio por parte de los usuarios es deficiente,
y hace falta la realización de un nuevo proceso tanto de gestión como de control de
unidades. Así mismo, en el reglamento establecido en la ley de movilidad de la ciudad de
Aguascalientes, en el artículo 76 consultado (Gobierno, 2018) cito: “Las personas con
discapacidad, estudiantes y adultos mayores gozarán de tarifas preferenciales en el
transporte público colectivo urbano y foráneo, equivalente al cincuenta por ciento de la
tarifa pública, previa identificación vigente expedida por instituciones que acrediten tal
carácter, conforme a los Acuerdos y Decretos que en su caso se publiquen en Periódico
Oficial del Estado.”
Si bien para los usuarios la calidad del servicio de transporte puede mejorar en diferentes
aspectos, el más importante sería al menos conocer cuando llegara la ruta al destino y la
espera en su defecto para una siguiente ruta, pues muchas personas, especialmente en
85
horas de la madrugada y horas pico, para llegar al trabajo o escuelas se convierte en un
problema que al final recae en su desempeño y pone en peligro su estabilidad laboral o
estudiantil según sea el caso.
También se hace presente a continuación datos cuantitativos referentes a la opinión que
tienen los usuarios al problema al que se enfrentan, así como la referencia a la solución
más factible que es la de poder contar con alguna medición respecto al tiempo de partida
de una unidad, así como retroalimentación ofrecida por los mismos usuarios que
respondieron el formulario.
Si bien la muestra se realizó al azar a más de 100 personas del estado de Aguascalientes,
solo se dará un resumen de esas respuestas con las gráficas que se consideran
fundamentales para la compresión y análisis del problema y las cuales se presentan a
continuación.
De igual manera, se puede observar en la sección de Anexos (Ver Anexo A), el
cuestionario que se realizó con el fin de obtener los resultados plasmados en las gráficas
siguientes:
86
Se tomo en cuenta el tiempo de espera como un determinante como se aprecia (Ver Figura
28) donde se visualiza una gran cantidad de tiempo invertido.
Figura 28. Tiempo invertido en una ruta (Elaboración del autor).
A su vez para correlacionar lo anterior, los tiempos no son de conocimiento público y la
relación con el tiempo de traslados, dificulta mucho el tiempo que el usuario tiene que
invertir tanto en espera como en su viaje (Ver Figura 29).
Figura 29. Tiempo establecido de parada a parada (Elaboración del autor).
87
La gran mayoría de los encuestados consideran que el uso de una aplicación podría
mejorar sustancialmente el servicio (Ver Figura 30) ya que se tendría una mejor
gestión desde la vista del usuario al momento de planear viajes a través del
transporte urbano.
Figura 30. Uso de una aplicación para la gestión del transporte (Elaboración del autor).
De igual manera y para generar la relación con la pregunta anterior, la calidad del
servicio aumentaría en un gran porcentaje (Ver Figura 31). La calidad que los
usuarios ven no está relacionada al uso de la aplicación misma, sino al control del
tiempo, como se observó en imágenes anteriores sobre esta encuesta.
Figura 31. Porcentaje de aumento de calidad de servicio (Elaboración del autor).
88
3.3. Concesionaria del STP y su relación con el gobierno
ATUSA y gobierno del estado de Aguascalientes han generado diferentes situaciones de
inconformidad respecto a la situación de un sustentable servicio de transporte público.
ATUSA es una empresa que es apoyada por Gobierno del estado, pero la situación se ha
complicado con el pasar de los años debido a irregularidades que se presentan en ambas
dependencias.
Por una parte, los concesionarios mencionan en una carta entregada a gobierno del estado
sobre sus problemas y si bien reconocen que existen y son conscientes de la situación,
mencionan que el poco apoyo que reciben por medio de la dependencia mencionada los
obliga a aumentar los costos en el servicio con la finalidad de gestionar el mantenimiento
que requieren las unidades.
De la misma manera expresan que el poco o nulo aumento en unidades renovadas, según
expresa el comunicado, gran parte de las actualizaciones deben de ser financiadas por el
gobierno del estado, pero ante la negativa de esto, se tienen que tomar acciones como
empresa para de alguna manera respaldar esas situaciones (Contralinea, 2018).
Por otra parte, gobierno del estado menciona una serie de diversos argumentos sobre el no
aumentar las tarifas de los servicios debido a la poca actualización de las unidades siendo
estas obsoletas para su uso y las implicaciones que repercuten en diferentes áreas como la
ambiental, así como la del servicio mismo. También se menciona de una revocación a la
concesionaria para de esta manera poder integrar nuevas empresas que se puedan encargar
de esta situación y al mismo tiempo generar una competencia, eliminado el monopolio
existente hasta el día de hoy.
Esta situación ha llevado varios años entre estos dos organismos siendo el que tiene más
dificultades para defenderse el de la concesionaria debido a que inclusive llegaron a
realizar un paro del servicio debido a la solicitud de aumento rechazada, ocasionando
89
diversos problemas en la población, hecho que a su vez el gobierno manifestó desacuerdo
debido a que realizan acción de manera arbitraria y sin algún tipo de consentimiento.
Diferentes partidos políticos y asociaciones como COPARMEX han estado de acuerdo en
la urgencia de modernizar las unidades y el mismo sistema de transporte público, esto
debido a las malas condiciones en las que se encuentran las unidades, pues se indica que
al menos el 50% de todas las unidades han expirado su vida útil y aún siguen operando,
así como en sus empleados, al trabajar jornadas laborales con tantas horas, y con un salario
muy bajo, no solo pueden presentar problemas de salud sino que permite la entrada al mal
servicio.(Rodríguez Loera, 2018)
Si bien el problema de transporte con el gobierno es marcado y aún se está estableciendo
una solución con una nueva implementación en cuestión de movilidad, lo cierto es que se
siguen analizando diferentes opciones para ofrecer el servicio por medio de diferentes
empresas interesadas.
90
3.4. Comentarios sobre el capítulo
Tanto el gobierno del estado como la concesionaria ATUSA han trabajado dentro de sus
posibilidades para ofrecer un transporte público de calidad para la sociedad de
Aguascalientes, pero no han logrado conseguirlo debido a diferentes problemas que, si
bien son justificables, los más afectados al final son los usuarios que dependen de este
servicio para su traslado diario.
El STP de la ciudad tiene deficiencias notables que debe ser atendidas con urgencia, y está
claro que existen soluciones implementadas en diferentes partes del mundo, pero debido
a diferentes situaciones, siendo la económica la más importante, es que no se han logrado
implementar. Es correcto que se trabaja actualmente en una nueva estrategia de movilidad
para la ciudad, pero va más allá del simple hecho de actualizar las unidades por nuevas,
se requiere un verdadero compromiso que, aunado con el apoyo de la tecnología, nos
ofrezca una transformación, una transformación al servicio y a la misma ciudad.
Actualmente si bien vivimos conectados con diversos servicios de manera digital, es
necesario que el transporte urbano sufra esa transformación con la finalidad de, poco a
poco, ofrecer una verdadera estrategia de mejoramiento, que, si bien los usuarios felicitan
el uso de nuevas unidades, es necesario conocer más información sobre el servicio, y en
este sentido al conocer información de sus viajes y tiempo, se añade más valor a este.
De igual manera, el soporte y mantenimiento de las unidades no solo depende de las áreas
gubernamentales encargadas de la misma concesionaria, que es su obligación del cuidado
de estos autobuses, sino de al mismo tiempo generar un cambio en la cultura de la
población, logrando generar conocimiento sobre el uso correcto de las unidades, ya que si
bien el cambio debe realizarse por las dos partes ya mencionadas, los ciudadanos tenemos
la responsabilidad de cuidar y mejorar igualmente los servicios que tenemos prestados en
nuestra ciudad.
91
Por lo tanto, los ciudadanos somos responsables del crecimiento de la ciudad, no podemos
dejar todo en manos de las instituciones, o del gobierno para generar un cambio positivo,
se debe trabajar constantemente para obtener resultados favorables que se vean reflejados,
en este caso en el uso de un mejor servicio dotado de calidad y que se pueda seguir
mejorando con el pasar del tiempo.
No es un problema que se tenga un culpable, es una situación que debe de analizarse con
cuidado y a partir de eso, generar la solución que se requiere, que si bien son distintas
soluciones que el servicio de transporte de la ciudad de Aguascalientes requiere, se debe
adecuar por la más urgente y entre todos, organizaciones, concesionarias y la misma
sociedad, transformar, generar y mantener un servicio, el cual poco a poco se irá
cambiando y mejorando, y a su vez transforme diferentes servicios para dar origen a una
ciudad inteligente.
92
CAPÍTULO IV: DEFINICIÓN DE MODELO ARQUITECTÓNICO
BAJO LA ARQUITECTURA DE MOVILIDAD INTELIGENTE DE
SMART CITIES Y EL USO DE CLOUD COMPUTING
Un modelo arquitectónico sugiere los pasos a seguir para la implementación de un servicio
y la mejora de este. En este sentido, una vez evaluado las arquitecturas expuestas en el
marco teórico, se define un modelo único, que propone la mejora del sistema de transporte
público, adaptado a diferentes estándares y tecnologías, ofreciendo posibilidades de
integración relativamente sencillas y sin generar costo alguno en su desarrollo.
4.1. Modelo arquitectónico para el desarrollo de un sistema urbano inteligente
Los servicios que mejoraran al implementarse el transporte inteligente están ligados a la
digitalización. Así mismo la parte de Cloud Computing está ligada a ellos y es necesario
su uso para la creación de Smart Cities basada en Cloud Computing como se muestra (Ver
Figura 32).
Es importante primeramente definir cuáles son los servicios que ofrece un transporte
inteligente y como estos son proporcionados. Como se observa y además de la capa de
servicios y los factores de transición hacia un transporte inteligente que la componen, se
pueden identificar cuatro tipos de áreas o clientes para el transporte urbano inteligente y
estos son: seguimiento, aseguramiento de calidad de datos, estandarización y accesibilidad
de datos.
Con estos elementos podemos identificar cuales servicios de transporte urbano inteligente
se proporcionan a la capa de servicios. El primero es seguimiento el cual es dirigido al
usuario y gestores de servicio para llevar un control de una correcta distribución de los
servicios. La segunda es aseguramiento de calidad de datos, generada para poder ser capaz
de realizar cambios dependiendo de la demanda y otorgando calidad en los mismos. El
tercero es estandarización, el cual establece los protocolos de intercambio de información
93
y facilita el intercambio de esta. La cuarta es accesibilidad de los datos, el cual hace
referencia al acceso de información de las diferentes rutas a través de la aplicación.
Estos servicios a su vez son procesados por la parte de Cloud Computing, como se observa
y estos en conjunto realizan la virtualización, parte fundamental para la transición
requerida en Smart Cities.
En primer lugar, se encuentra SaaS, que es el nivel en el que se enfoca al software que
proporcionara el servicio a los usuarios. En según lugar DaaS es la virtualización a un
nivel de arquitectura de los servicios. En tercer lugar, se encuentra PaaS la cual permitirá
el funcionamiento de la aplicación a implementar y que los servicios se encuentren
disponibles en internet. Por último, IaaS otorgara una infraestructura con acceso directo a
la nube, virtualizando la parte de hardware.
Estos elementos de Cloud Computing están presentes durante todo el modelo y su
construcción, y en constante mejora continua del mismo. No se deben de aislar ningún
elemento de Cloud Computing del modelo.
94
Computing
Transporte
Urbano
Inteligente
Optimización de
Servicio
Personalización
del Servicio
Aceptación
Social
Seguimiento
Aseguramiento
de calidad de
datos
Accesibilidad en
los datos
Mejora Continua
SaaS
DaaS
PaaS
IaaS
Estandarización
Servicios
basados en
Cloud para S.C.
Cloud
Computing Servicios
Figura 32. Modelo arquitectónico para el desarrollo de transporte público inteligente (R. A. Velasquez Ortiz, F. Álvarez Rodríguez, J.C. Ponce Gallegos, 2018).
95
4.2. Aportación de la tesis
Si bien el desarrollo de un modelo de transporte inteligente cubre una serie de módulos
que abarcan un gran número de procesos, se decidió por trabajar un modelo basado en
servicios que, implementado con Cloud Computing, se conoce como Software como
Servicio (SaaS). La aportación del proyecto de tesis se dirigirá entonces hacia el área de
optimización de datos geoespaciales y se reflejaran dentro de la aplicación móvil que se
desarrollara.
Esta investigación pretende evaluar el desempeño del servicio de transporte público a
partir de la recolección de datos de geoposicionamiento, en este caso de las unidades de
transporte, a partir del uso de los datos analíticos que se implementan en Cloud Computing
(Ver Figura 33).
Figura 33. Framework para el diseño de transporte inteligente (Elaboración del autor).
96
4.2. Descripción del modelo arquitectónico para el desarrollo de un sistema
urbano inteligente
Modelación de factores para transición a Smart City.
En esta sección una versión preliminar del modelado de transporte inteligente será
descrito. Según (Wieclaw et al., 2017) Smart Cities debe contemplar tres niveles de su
arquitectura para generar esta transición y estas según el autor son las siguientes:
➢ Nivel 1. En este nivel se enfoca en las diferentes recursos y servicios que ofrece
la ciudad y que pueden ser gestionados a través de dispositivos como sensores de
celulares o dispositivos especiales.
➢ Nivel 2. Este nivel es el intermediario de procesar la información de manera
analítica con técnicas de Cloud Computing por mencionar algunas y de igual
manera se encarga de la gestión y actualización de información. Es la capa más
importante, necesaria e innovadora para la transición a Smart Cities.
➢ Nivel 3. Portales de información que contienen y desplieguen la presentación de
los datos, conteniendo interfaces e interacción con la implementación de los
servicios digitalizados.
Para el correcto funcionamiento de esta primera versión del modelo, los siguientes puntos
son considerados. Como se observa (Ver Figura 34), detalla la construcción del modelado.
97
Se identificaron los tres factores principales para la generación una transición hacia un
Transporte Publico Inteligente. El primer factor es la optimización de servicio el cual
permite un mejor entendimiento del comportamiento del usuario dentro del sistema de
transporte urbano. El segundo factor es la personalización de servicio en la cual el usuario
podrá monitorear la infraestructura y la entrega del servicio. Y por último el factor de
aceptación social y la necesidad de adaptación de la plataforma tecnológica de servicio y
la facilidad en su uso. En la siguiente figura (Ver Figura 35) mencionada se puede apreciar
el modelado de transición propuesto.
Accesibilidad
Disponibilidad de datos
Optimización de rutas
Generar cambios
según demanda
Clase social
Facilidad de uso
Optimización de Servicio
Personalización de Servicio
Aceptación Social
Figura 34. Principales factores hacia la transición de Transporte Público Inteligente (R. A. Velasquez Ortiz, F. Álvarez Rodríguez, J.C. Ponce Gallegos, 2018).
98
Figura 35. Modelo de los niveles de servicio (R. A. Velasquez Ortiz, F. Álvarez Rodríguez, J.C. Ponce Gallegos, 2018).
Como se aprecia estos elementos, una vez relacionados con la parte de Cloud Computing
y SaaS en específico, se puede plantear a partir de estos modelos, un modelo general para
realizar la transición a un sistema de transporte urbano inteligente el cual se definirá en la
siguiente sección de resultados.
99
Así mismo, y continuando con la descripción de la arquitectura propuesta anteriormente,
se describen los factores o módulos correspondientes a la entrega de los servicios
analizados previamente y su resultante a través del transporte público inteligente.
Se identificaron 4 factores que comprenden los siguientes aspectos y estos se exponen tal
como se muestra el grafico (Ver Figura 36).
Seguimiento: Se le da un rastreo a la administración y conservación de datos que se
generen a través de SaaS obtenido anteriormente, asegurando su entrega y disponibilidad.
El segundo factor, Aseguramiento de calidad de datos, se encargará de desplegar la
información que se requiera utilizando los dispositivos para la realización de la consulta
de información, en este caso, los dispositivos móviles. Para el tercer factor indicado como
estandarización se requiere que los datos obtenido en el primer parte de la descripción de
la arquitectura estén validados y protegidos a través de un estándar de seguridad de Cloud
Computing. Y por último el factor de Accesibilidad de los datos, al ser una red abierta la
que entregara el servicio del rastreo de unidades de transporte, se implementara el uso de
una nube publica para garantizar el acceso al servicio público.
Figura 36. Resultados principales de la transformación hacia Transporte Público Inteligente (R. A. Velasquez Ortiz, F. Álvarez Rodríguez, J.C. Ponce Gallegos, 2018).
Seguimiento
S
Aseguramiento de calidad
de datos
Estandarización
Accesibilidad de los datos
100
Como se indicó previamente, estos resultados se esperan una vez obtenidos los factores
descritos anteriormente. Cabe mencionar que estos resultantes están enfocados a cubrir el
área de cómputo en la nube (Cloud Computing) y de esta manera, dirigirlos hacia SaaS
para dar coherencia a la arquitectura propuesta anteriormente.
Como se puede apreciar en la siguiente ilustración (Ver Figura 37) los diferentes factores
definidos y explicados están orientados al área de Cloud Computing, logrando de esa
manera, cumplir con lo establecido en la arquitectura.
Como se puede apreciar, cada uno de los factores ya contiene servicios de Software as a
Service (SaaS) heredados a partir de la primer parte de la descripción de la arquitectura y
expuestos en la imagen indicada (Ver Figura 36) y de igual manera logrando empatar al
framework realizado sobre Smart Cities con la inclusión de Computo en la nube y que
será explicado posteriormente y con el cual se le da solución a la arquitectura presente.
Figura 37. Modelo de los niveles de entrega de servicios (Elaboración del autor).
101
Framework propuesto para la solución de la arquitectura de transporte inteligente.
El siguiente framework resuelve la arquitectura definida anteriormente (Ver Figura 38).
La construcción de este framework se implementa directamente en la arquitectura basada
en transporte público.
El siguiente framework se divide en 3 capas basadas en la arquitectura de Smart Cities,
siendo las necesarias para la solución a la arquitectura propuesta en la imagen tal. Las
capas expuestas van desde un enfoque general a uno especifico, la primera capa es la
encargada del despliegue de los servicios de una ciudad, pasando a través de los
ciudadanos y, por último, generando la digitalización de esa ciudad, una vez resuelto las
anteriores.
Estas capas a su vez contienen los elementos primordiales de cómputo en la nube para el
despliegue tanto de los servicios como mejora en la construcción de una ciudad inteligente
debido que involucra a la ciudad en su totalidad independientemente de la trasformación
del transporte público a un servicio inteligente.
Figura 38. Framework para Sistema de Transporte Inteligente. (Elaboración del autor).
Digitalización de ciudad
Ciudadanos
Cities SaaS
SaaS
SaaS Virtualización
Nube Pública
Software Security
102
Cities:
Esta capa está relacionada con el entorno de la ciudad, como tal los servicios prestados y
la importancia de estos deben ser encapsulados a través de la capa SaaS de Cloud
Computing. La importancia de esto se refleja en la siguiente sección.
• SaaS: El servicio se ofrecerá directamente por Software as a Service, su
importancia es tal que se va heredando a cada una de las capas inferiores, pues el
fin es dirigido al área de servicios. Sobre esta capa, los servicios se expandirán
hasta que la cobertura de la ciudad lo permita.
Ciudadano:
Esta capa está directamente enlazada a los ciudadanos de la ciudad, ya que no solo son
consumidores, sino proveedores de servicios ligados a la ciudad, por lo cual se genera no
solo una retroalimentación, sino una transformación digital del individuo.
• SaaS: Los servicios que se implementaron en la capa anterior, se heredan a esta,
ya que los ciudadanos son los que realizan uso sobre ellos, de esta manera se
reflejan en el uso de ambas capas y generan el desarrollo de la capa de
digitalización.
• Nube Publica: Para ofrecer los servicios a este nivel es necesario la
implementación de una capa del modelo de Cloud Computing, en este caso se
decidió por la nube publica debido a la facilidad que existe entre usuario y el
proveedor del servicio para el mejor uso de este.
103
Digitalización de ciudad:
Esta capa define el final de framework, en esta se realiza la digitalización de los individuos
de una ciudad, el definir esta capa genera sustentabilidad sobre la ciudad en el área de
transporte, creando un transporte inteligente que a su vez resuelva problemas de tráfico y
de otra índole (involucrando servicios eléctricos o de emisión de combustible), pues al
digitalizar parte de la ciudad, esta tiende a afectar más sectores de la ciudad.
• SaaS: El servicio proporcionado en esta capa se hereda de las capas anteriores y a
su vez este cumple su función de digitalizar el transporte público para una mejora
optimización de este, generando una ciudad digital en ese aspecto.
• Virtualización: Una capa utilizada de Cloud Computing es el uso de Virtualización
ya que a partir de los diferentes dispositivos de los usuarios se generará la
ejecución del framework correspondiente y por lo tanto la utilización de los
recursos o servicios físicos a digitales. Es fundamental para el desarrollo de la
nube, y esta viene dentro de la nube publica generada en la capa anterior.
• Software Security: Debido a que los servicios otorgados serán a través de
plataformas de software y al involucrarse partes del modelo Cloud Computing, es
necesario incluir una capa de seguridad orientada a software, el cual permitirá
seguridad en los datos tanto de usuarios como de la misma aplicación y evitar de
esta manera alguna filtración o modificación a los mismos.
104
Experimentación de framework para el desarrollo de diseños arquitectónico:
Para realizar la experimentación entre los frameworks señalados anteriormente se
seleccionó un modelo de evaluación, siendo ATAM (Architecture Trade-Off Analysis
Method) debido a que se enfoca a en la calidad de los módulos de la arquitectura y se logra
evaluar las decisiones y consecuencias arquitectónicas, de esta manera se consigue
verificar la confiabilidad y aceptabilidad de la arquitectura o de ser posible realización de
cambios en la misma para su corrección.
Para lograr esta evaluación, según lo marca la documentación por la Universidad
Politécnica de Valencia sobre el ATAM (Valencia, 2013) se deben seguir los nueves pasos
establecidos y comentados previamente.
Fase 1
• Presentar ATAM
o Evaluadores y Skateholders: Raul Alejandro Velasquez Ortiz, Agencia
General de Movilidad (CMOV).
• Presentación de objetivos
o Alta disponibilidad y aseguramiento de calidad del sistema.
o Desempeño adecuado del sistema, así como modificabilidad de este.
• Presentación de arquitectura
o La arquitectura cuenta con cuatros divisiones. Estas divisiones hacen
énfasis en su utilización en áreas específicas.
Seguimiento: Es la primera capa del módulo, esta capa es la encargada de
realizar las notificaciones a enviar a los usuarios, así como alertas del
servicio.
Aseguramiento de calidad de datos: El segundo modulo verificara la
conexión con la aplicación y su funcionamiento, con relación al servidor
de la agencia de movilidad.
105
Estandarización: El módulo tres se encarga de distribuir los datos de la
agencia, a través de la aplicación, por medio un estándar establecido.
Accesibilidad de los datos: El módulo cuatro garantiza la publicación de
datos, tanto en aplicación de terceros como en su propio servidor (Véase
Figura 21) para el análisis de la arquitectura planteada a más detalle.
106
Fase 2
• Identificación de enfoques arquitectónicos
o Se desprende de los atributos de calidad que se desean obtenga el sistema,
y que serán consultados posteriormente.
• Generación de árbol de utilidad
Tabla 6. Árbol de utilidad generado con ATAM (Elaboración del autor).
Como se puede observar (Ver Tabla 6), los diferentes atributos son evaluados a partir de
escenarios establecidos y ponderados por necesidad de alcanzar el objetivo y la dificultad
de lograrlo, ambos patrones de ponderación se incluyen dentro de un paréntesis y se les
califica de menor a mayor, según sea el caso como Low (L), Medium (M) y High (H),
siendo L, el de menor prioridad y H el de mayor prioridad. Así mismo, el primer parámetro
que se obtiene dentro de los corchetes son la prioridad de ese objetivo a evaluar, y el
107
segundo es el riesgo que tiene el no resolver ese escenario. Como se observa la mayoría
de los escenarios requieren necesidades de lograrse muy altas, así como una dificultad
promedio de baja para la mayoría de estos.
• Analizar enfoques arquitectónicos
o Se evaluaron los diferentes enfoques diseñados según su atributo, y no se
indica por el momento una actualización
Fase 3
• Priorización de escenarios
o Una vez generados los escenarios se establece un ranking de importancia
y se indica cual debe de cumplir primero a partir de los escenarios definidos
previamente.
Ranking Escenarios Observaciones 1 Informar aceptación de
carga de proceso en menos de 0.3 segundos.
Performance
2 El fallo del sistema debe ser <1%.
Fiabilidad
3 Cambiar el motor de una base de datos implica cambiar un subsistema.
Mantenibilidad
4 Los conceptos del negocio son utilizables en otras aplicaciones.
Reusabilidad
Tabla 7. Escenarios priorizados para la evaluación con ATAM (Elaboración del autor).
• Analizar enfoques arquitectónicos
o Se analizaron los enfoques definidos a partir de la arquitectura definida y
a los escenarios y por el momento no se indica actualización como se
aprecia (Ver Tabla 7).
108
4.3. Arquitectura TUI
Una vez realizada la arquitectura presentada (Ver Figura 33) y la establecida por OBA en
el capítulo 5 (Ver Figura 54), se ha de definir una arquitectura que complemente ambas
funcionalidades previamente explicadas en ambas arquitecturas, para dar origen a una
arquitectura funcional que es la sé utilizara para la comprobación final, una vez se originen
resultados. Esta arquitectura es la base la para todo transporte inteligente que esté basado
en el estándar GTFS y se muestra a continuación (Ver Figura 39).
Figura 39. Arquitectura TUI para la implementación de transporte inteligente (Elaboración del autor).
Una vez realizada la fusión de las arquitecturas mencionadas se puede apreciar el
comportamiento que se divide en dos grupos, el primer grupo de características están
definidas por recuadros de color verde, estas son seguimiento, Aseguramiento de calidad
de datos, estandarización y accesibilidad de los datos. En seguida hay un segundo nivel
correspondiente a los recuadros azules y que encajan en el desarrollo de la arquitectura de
109
OBA los cuales son servicio de alertas y estimaciones, Servidor OBA, GTFS y Servidor
de la agencia de movilidad.
La interacción entre cada uno de ellos debe generar los resultados en específicos para el
origen de transporte inteligente. Comenzando con el primer módulo, seguimiento y
servicios de alertas y notificaciones, estos dos interactúan de tal manera que las diferentes
alertas de la aplicación se reflejan en el sistema, provocando un seguimiento de
funcionamiento sobre la misma lo cual se requiere para cambios imprevistos. Como
segundo modulo se tiene la relación de Aseguramiento de calidad y servidor OBA, estos
dos son importantes, la peticiones y respuestas dadas entre la aplicación y el servidor
deben de sincronizarse de tal manera que se puedan resolver la comunicación con el
usuario. En el tercer modulo, la estandarización que propone la arquitectura es el modelo
GTFS, un modelo fundamental para el nacimiento de un sistema urbano inteligente y que
logra satisfacer las demandas que se puedan solicitar por parte del usuario. Por último, se
tiene el módulo accesibilidad de datos con el cual se conjuga con la agencia o
concesionaria, los datos tanto en GTFS, así como información de del sistema de transporte
y las diversas unidades deben ser expuestas de manera pública para su mejoramiento o
actualización.
Como se puede observar una vez cubierta estas cuatro etapas o módulos, estos se estarán
retroalimentando constantemente, debido a las constantes solicitudes que se realizaran por
parte del usuario y las respuestas del servidor, cabe aclarar que es necesaria esta
actualización constante debido a que las solicitudes se procesan en tiempo real. Estas
actualizaciones se procesan en un servidor en la nube que contiene OBA, facilitando el
consumo de estas.
Por último, toda la arquitectura se estará actualizando contantemente en cada uno de sus
módulos, para de esa manera generar el transporte urbano inteligente. Este punto es
importante, debido a los constantes cambios que puede sufrir el transporte por medio de
la agencia encargada, y en específico en datos como horarios o días en circulación, solo
mencionando algunos ejemplos.
110
Esta arquitectura satisface las necesidades básicas para la generación del transporte urbano
inteligente haciendo uso del modelo de aplicación OBA, realizando una adaptación a la
ciudad que se requiera y logrando hacer uso de ella. Es un modelo de igual manera
adaptable al surgimiento de aplicaciones externas o sin el apoyo de aplicación de tercero,
pero es necesario la implementación de GTFS, debido al comportamiento y fin de esta
investigación.
Abstracción de la arquitectura TUI
Una vez desarrollada y explicada previamente la arquitectura TUI, se logra realizar una
subdivisión en cada uno de sus módulos, con la finalidad de crear una abstracción de esta,
y por lo tanto un mayor entendimiento del funcionamiento interno de la ya mencionada.
Los módulos que se comprenden corresponden a los siguientes: modulo: seguimiento,
aseguramiento de calidad de datos, estandarización y accesibilidad de los datos. Cada uno
de ellos será desplegado de manera arquitectónica para profundizar en su comprensión.
Modulo 1 -Seguimiento-
Figura 40. Modulo 1 -Seguimiento- (Elaboración del autor).
111
Como se observa en la imagen (Ver Figura 40), la interacción del módulo aseguramiento
de calidad se relaciona directamente con la captura de los datos del GPS-AVL System, el
cual a su voz va como resultado, los datos necesarios para formar el archivo GTFS-
realtime y con esto, a su vez, reflejarlos dentro de las aplicaciones, sea de terceros o propia.
Modulo 2 -Aseguramiento de calidad de datos-
Para este segundo modulo, enfocado en el aseguramiento de calidad de datos, se puede
observar en la imagen (Ver Figura 41), la manera en que se desarrolla. Primeramente, el
servidor OBA se relacionará con el servidor de la agencia de movilidad con la finalidad
de obtener la información sobre alertas del servicio, las cuales se podrán ingresar por
medio de la Web App que se tenga en la agencia y proporcionado por OBA.
Figura 41. Modulo 2 -Aseguramiento de calidad de datos- (Elaboración del autor).
112
Modulo 3 -Estandarización-
El tercer modulo hace referencia a como se realiza la estandarización aplicada a esta
arquitectura (Ver Figura 42). Todo sistema de transporte debe contar con su información
disponible y a su vez adaptarla al estándar GTFS, para de esa manera generar una
compatibilidad a las diferentes plataformas y aplicaciones. Esta a su vez se debe
transformar en el estándar GTFS-realtime.proto, un archivo de tipo protocolo de buffer el
cual es el que permite la transferencia en tiempo real de las unidades de transporte. Este
módulo es el más sencillo, pero al mismo tiempo, es la base fundamental para generar los
demás módulos.
Figura 42. Modulo 3 -Estandarización- (Elaboración del autor).
Modulo 4 -Accesibilidad de datos-
Por último, se tiene el módulo cuatro referenciando a la accesibilidad de los datos, y como
se aprecia (Ver Figura 43), el servidor de la agencia hace uso del servidor OBA para poder
levantar los datos del sistema de transporte público a su aplicación. Así mismo, ya con
estos datos, se realiza una actualización de datos dentro del panel de control de Google
Transit Team, el cual se encarga de proveer la información en tiempo real dentro de
Google Maps, asegurando de esta manera diferentes vías para el uso y consumo de la
113
información. Es puntual hacer mención que este módulo 4 y el módulo 2 se correlacionan
entre sí, tal como se observa en la arquitectura TUI.
Figura 43. Modulo 4 -Accesibilidad de datos- (Elaboración del autor).
114
4.4. Comentarios sobre el capítulo
Este capítulo establece pilares fundamentales en el desarrollo del modelo arquitectónico
TUI. Este modelo a su vez pasa por una abstracción para comprender de manera más clara
su funcionamiento interno y los pasos que toma este, así como elementos para su
interacción. Es remarcable ver lo compleja que es la interacción y lo básico de su
construcción, ofreciendo diversas capacidades de adaptación dentro de las agencias de
movilidad. La arquitectura TUI es un modelo factible y en capítulos posteriores a este, se
podrá comprender su modo de adaptación.
115
CAPÍTULO V: CASO DE ESTUDIO - ONE BUS AWAY -
DESARROLLO TÉCNICO DE LA APLICACIÓN
Este capítulo pondrá a prueba un caso específico relacionado con el modelo
arquitectónico, la implementación de la aplicación open source OneBusAway, con el
objetivo de justificar la ejecución tanto de la aplicación como la relación de los servidores
y la conjugación hacia el modelo GTFS.
Una vez con una arquitectura definida, se define el uso y explotación del modelo estándar
GTFS. GTFS es un modelo que permite con mucha facilidad importar información
geográfica de tal manera que pueda ser consumido a través de aplicaciones de tercero o
inclusive Google Maps con mucha facilidad. Este capítulo abordara los diferentes archivos
GTFS a utilizar y su posterior consumo por parte de las aplicaciones.
5.1. Implementación del estándar GTFS
Para la implementación del GTFS se comenzó con el desarrollo de las seis principales
tablas, siendo la primera la de stops como se plasma en (R. A. Velasquez Ortiz, F. Álvarez
Rodríguez, M. Vargas Martin, J.C. Ponce Gallegos, 2019). Como se indica en la imagen,
la relación de los principales 6 archivos debe relacionarse a través de un diagrama entidad-
relación (Ver Figura 44).
116
Figura 44. Diagrama Entidad-Relación sobre GTFS (R. A. Velasquez Ortiz, F. Álvarez
Rodríguez, M. Vargas Martin, J.C. Ponce Gallegos, 2019). Esta tabla cuenta con 4 atributos como muestra (Ver Figura 45), si bien los atributos
pueden variar, los obligatorios como se indica en (G. Transit, 2012) para esta tabla en
específico son stop_id, stop_code, stop_name, stop_lat y stop_lon. Estos atributos en
conjunto nos dan la información pertinente a la ubicación exacta de una parada específica,
generando un ID que se utilizara en el siguiente dataset o tabla.
117
Figura 45. Dataset Stop (Elaboración del autor).
La siguiente tabla es Trips, donde a partir de la información solicitada, se puede generar
los viajes que realiza cada unidad o ruta por día. El atributo trip_id lo obtiene de la tabla
stop_times como se observa (Ver Figura 46).
Figura 46. Dataset Trips (Elaboración del autor).
La tabla stop_times hace referencia a los tiempos en que cada unidad de transporte publico
hará su arribo y salida de cada parada señalizada, generando un trip_id, que identificará
esa acción y a su vez un stop_id donde se refleja el lugar donde se hará esa parada. El
stop_id hace referencia al id establecido previamente en la tabla stops y el trip_id como
se mencionó, se hará referencia en la tabla trips. Como se observa (Ver Figura 47) la tabla
requiere cinco atributos obligatorios.
118
Figura 47. Dataset Stop_time (Elaboración del autor).
Como indica la figura (Ver Figura 48), se muestra información sobre cada ruta asignada
con el ID service_id de la tabla trips, de esa manera se asigna la actividad de esas rutas
durante los 7 días de la semana y las fechas donde iniciaran y terminaran con ese ritmo de
trabajo.
Figura 48. Dataset Calendar (Elaboración del autor).
Para finalizar, se obtiene los datos de sobre la ruta, el nombre que se le asignara a las
mismas y el tipo de transporte que manejara, en este caso, el parámetro 3 indica transporte
público concesionado o urbano de una ciudad. Así mismo para planear los viajes, se hará
119
Figura 50. Relación entre tablas stop, stop_time y Trips (Elaboración del autor).
uso del ID route_id y se le asignará en la tabla de trips para crear la relación entre las
tablas (Ver Figura 49).
Figura 49. Dataset Routes (Elaboración del autor).
Las relaciones entre las diversas tablas son necesarias en el formato GTFS, como se
aprecia (Ver Figura 50), debido a que se solicitara esta información, para poder reflejarlas
dentro del mapa de Google Maps, una vez se den de alta.
El archivo stop_times conecta a las
paradas de cada viaje individual,
en el orden en que van saliendo.
El archivo stop_times
conecta a las paradas de
cada viaje individual, en el
orden en que van saliendo.
120
Una vez finalizados los archivos principales del GTFS, se considera seguir con el
desarrollo de la aplicación. Para este paso se cuenta con mucha información y
herramientas open source para la fabricación de aplicaciones. Hay una gran cantidad de
productos para el consumo de GTFS. Las aplicaciones se pueden generar a través de
agencias de tránsito o por medio de third party o empresas externas a la misma, tal como
se indica en (Girish, 2019).
La cantidad de aplicaciones de distribución libre u open source son muy variadas, desde
el uso de Google como gestor de los archivos GTFS, hasta aplicaciones como lo son
Moovit, Challo App, Citymapper, Transit App, OneBusAway, por mencionar algunos.
La facilidad de uso de estas aplicaciones gratuitas implica una producción de aplicaciones
en un periodo de tiempo muy corto a que si se tuviera que desarrollar desde cero como se
menciona en (Krambeck, 2017).
121
5.2. Mockups de la aplicación
La manera en que estará establecida la aplicación y las funciones que se requerirán
inicialmente para la ciudad de Aguascalientes se presentan a continuación por medio de
varios mockups que representas dichas funcionalidades y una breve descripción de estos.
El estudio de estos mockups será necesario una vez se desarrolle el servidor y por lo tanto
su arquitectura. (Ver Figura 51).
Figura 51. Mockups ingreso a la aplicación (Elaboración del autor).
122
La imagen contempla la señalización de las paradas localizadas a través de la posición
actual del usuario, lo cual podrá agilizar la búsqueda de rutas que requiera abordar en ese
momento. Al presionar cualquiera de las rutas se podrá obtener información de cada
parada, como tiempo de llegada y localización, así mismo se podrá desplegar una variedad
de horarios establecidos para dar más opciones al usuario y pueda planear su tiempo con
antelación. De igual forma se tiene una barra de búsqueda donde se puede localizar alguna
parada por localización o número de ruta.
A continuación (Ver Figura 52) se puede observar que, al ingresar al menú de búsqueda
de rutas o parada, nos proporciona un menú donde se registraran las paradas que más
utilicemos y así mismo las rutas que se utilicen más. Esto facilitara aún más la búsqueda
de determinadas paradas debido a que no será necesario buscarla dos o más veces, al
realizarlo una sola vez, se almacenara la información solicitada.
Para evitar la saturación de información, se agrega la opción Limpiar, la cual borrara los
registros ya sé que estemos en rutas o paradas, esto con la finalidad de poder agregar más
o simplemente tener un espacio de registro más ordenado. Se contará por último con la
opción de regresar para que la aplicación nos redirija al menú principal de la aplicación.
123
Cabe destacar que, al presionar una ruta o paradas guardadas en sus respectivas secciones,
nos arrojara sus horarios o trayectos oficiales, para simplificar la planeación de los viajes
del usuario.
Para finalizar (Ver Figura 53), al presionar dentro del menú de rutas almacenadas, se nos
da la opción de elegir tanto de una orientación (sur o norte) o viceversa. Al seleccionar
una orientación, se nos indicará el número de veces que saldrá esa ruta en el día desde su
terminal y la hora de salida.
Figura 52.Mockups registro de paradas y rutas (Elaboración del autor).
124
Con esta información, se puede gestionar la planeación de viajes con mucha anticipación
y tomando en cuenta que por el momento no existe algo así en la ciudad, se puede
optimizar el servicio en gran medida.
También se incluye botón para cargar más llegadas o salidas de las unidades si se llega a
requerir, así como el horario de dichas rutas.
Figura 53. Mockups información detallada (Elaboración del autor).
125
5.3. Arquitectura de la aplicación basada en OBA
El sistema básico de la arquitectura que utiliza OBA, que se indica en su literatura es el
siguiente (Ver Figura 54). Esta arquitectura es simple, detalla simplemente los tiempos
de llegada de los autobuses y alertas del servicio en tiempo real.
Figura 54. Arquitectura OneBusAway (OneBusAway, 2010).
Una vez se tienen los tiempos de llegada y las alertas, el servidor OBA, junto con los datos
GTFS que obtiene de Google u otro servicio de almacenamiento y gestión de archivos
GTFS, se realiza una petición para la obtención del GTFS-rt cada 10 segundos a los
servidores de la agencia de movilidad y esta a su vez regresa la respuesta de esa solicitud
cada 10 segundo, de tal manera que regresa a los servidores OBA y a la actualización de
los datos GTFS y se despliegan en la aplicación, sea OBA o una distribución OBA
personalizada.
126
La arquitectura que OBA presenta se establece a partir de una base sólida, sugerida por el
estándar de GTFS-rt, el cual nos indica, que al tener o llevar a cabo una instancia que nos
indique la posición en tiempo real, habremos de seguir un modelo arquitectónico como se
indica a continuación (Ver Figura 55).
5.4. Arquitectura básica para la construcción de aplicaciones con GTFS-rt
Figura 55. Arquitectura base para la construcción de aplicaciones con GTFS-rt. (Krambeck, 2018).
La construcción de una aplicación con el uso del estándar GTFS-rt requiere del uso de un
servidor que en tiempo real gestione las peticiones que se requieran o soliciten por parte
del usuario, estas actualizan el GTFS almacenado en algún servidor como Google, en
seguida se utiliza un servidor donde se almacena la aplicación, en este caso OBA, la cual
procesara los datos actualizados y los convertirá en archivos XML o JSON, y los redirija
hacia el smartphone que contenga la aplicación utilizada por parte del servidor de
aplicación.
Servidores en Tiempo
RealGTFS-RT
Servidores de
AplicacionXML/JSON Smartphone
127
Las ventajas de construir la aplicación bajo esta arquitectura base es debido a que el
dispositivo móvil, no puede actualizar y manejar en un mapa en tiempo real los datos
GTFS-rt, sería una consulta que sobrecargaría al dispositivo, por eso es por lo que se
realiza esta subdivisión de eventos con el apoyo de dos servidores, logrando la
transformación final a XML o JSON, que son archivos ligeros y que utilizarían el menor
costo para la visualización de la información en los dispositivos.
128
5.5. Desarrollo de la aplicación OBA Para el desarrollo de la aplicación, se realizarán las modificaciones pertinentes para el uso
en la ciudad de Aguascalientes. Como se puede apreciar, estas imágenes corresponden a
los mockups previamente expuestos en el capítulo 6.
En la siguiente imagen (Ver Figura 56) su puede observar una serie de capturas de pantalla
que nos indica la fase principal de la aplicación, donde se nos muestra el mapa con
posicionamiento en automático, al igual que un botón para localización GPS. Al presionar
los puntos de la parte superior izquierda, nos dará acceso a las diferentes rutas y paradas
que se tengan registradas, y para esto se desplegará un menú para mayor organización.
Figura 56. Screenshots de la aplicación (Elaboración del autor).
129
En las siguientes capturas se podrá ver la visualización de las rutas no sin antes exponer
su funcionamiento a través del servidor OBA y en conjunto con los datos GTFS, realiza
la comunicación requerida para recoger y responder a los datos.
5.6. Instalación del servidor
Una vez Instalado el servidor como se indica en la imagen (Ver Figura 57), podemos
apreciar varias opciones que nos servirán para establecer las alertas. Este servidor cumple
con la parte de la arquitectura referente al servidor OBA.
Figura 57. Servidor OBA (Elaboración del autor).
Aun así, es necesario levantar el servicio por medio a la región que se está trabajando, en
este caso, la ciudad de Aguascalientes. Para la realizar este levantamiento se debe realizar
un cuestionario proporcionado por el equipo de OBA, el cual se puede ver referenciado
en el anexo (Ver Anexo D).
130
Una vez generado el levantamiento, el servidor OBA proporciona una API key necesaria
para la ejecución de los servicios una vez se realice la validación de los datos entregado
en el cuestionario. Como se indica en la imagen (Ver Figura 58).
Figura 58. API Key (Elaboración del autor).
La API key será la responsable de trasladar los datos GTFS obtenidos previamente durante
el levantamiento de este y, por lo tanto, nos habilitará a poder visualizar esta información
dentro de la aplicación.
Dentro del sistema de la aplicación, es necesario realizar el vínculo con la API key que
nos otorga el servidor OBA, como se indica en la imagen (Ver Figura 59).
131
Figura 59. API key de servidor a aplicación (Elaboración del autor).
Una vez dada de alta esta llave dentro de la aplicación, se requiere la aprobación del
cuestionario para generar una región nueva dentro del sistema de OneBusAway, la cual
nos permitirá trabajar en el estado de Aguascalientes, y de igual manera ver
automáticamente el reflejo de la ruta y las paradas establecidas.
132
5.7. Comentarios sobre el capítulo
Este comprende y ejecuta el modelo arquitectónico TUI, de tal forma que genera una
aplicación móvil, en este caso, se utiliza como estudio, la aplicación denominada
OneBusAway (OBA) la cual al ser OpenSource, ofrece una versatilidad al momento de
adaptarlo con la arquitectura, lo cual facilita el trabajo. Se ha logrado realizar conexión y
funcionamiento con el servidor OBA.
En el siguiente capítulo, se realizarán diferentes pruebas en dos diferentes aplicaciones y
la importancia del modelo arquitectónico con dichas aplicaciones.
133
CAPÍTULO VI: PRUEBAS Y RESULTADOS
Los resultados presentados corresponden al reflejo de los archivos GTFS en las diferentes
plataformas donde se almacenan y consumen, siendo las primeras en el servidor que se ha
de desarrollar con las herramientas de OBA, con la finalidad de lograr una buena
comunicación con ellos y así mismo eliminar posibles errores dentro de la configuración
de los mismos archivos. Así mismo se mencionará el apoyo de Google Transit Team pata
el almacenamiento de los archivos GTFS y su uso posterior dentro de la aplicación a
desarrollar, pero con la ventaja de agregar al mismo tiempo esta información dentro de
Google Maps, logrando hacer el reflejo de la aplicación dentro del sistema de Google y
presentando más opciones a para la localización y gestión del sistema de transporte.
Ese capítulo se divide en dos puntos, unos donde se realizaron pruebas directamente con
el servidor OBA creado y en el cual se realizaron diferentes pruebas con el archivo GTFS,
así como consultas para corroborar el funcionamiento de los datos GTFS antes de ser
enviado a la base de datos de Google.
Un segundo punto en el capítulo conserva información sobre la implementación de los
archivos GTFS directamente en Google Maps para su posterior uso en la aplicación. De
igual manera Google refleja estos datos en su sistema Google Maps, por lo que el capítulo
tendrá resultados referentes a este proceso, claro está con el apoyo de estas dos entidades,
Google Transit Team y la Coordinación General de Movilidad.
6.1. Pruebas realizadas
Una vez desarrollado el servidor y almacenando los archivos GTFS de manera local, se
puede apreciar por medio de un ambiente de desarrollo de Google y OBA la
previsualización de la ruta y las correspondientes paradas, mismas que serían identificadas
de igual manera dentro de la aplicación. Para usos de corrección de problemas con los
datos GTFS se realizaron estas pruebas.
134
Como se puede observar (Ver Figura 60), una vez implementado el servidor con el soporte
de OBA, se puede ver como se apreciaría la ruta dentro de la aplicación, usando los mapas
de Google Maps. Como se mencionó, esto ayuda a buscar errores al momento de trabajar
con los archivos GTFS y al poderlos subir a la plataforma de Google.
El servidor ofrece herramientas para revisión de datos por ruta y como se indica en la
imagen (Ver Figura 60). Esta acción se muestra de manera detalla y muestra las paradas
que contiene la ruta.
Figura 60. Prueba de la ruta 1 con los archivos GTFS dentro del servidor (Elaboración del autor).
La definición gráfica de la ruta permite verificar la posición correcta de las paradas de
autobús como lo maneja la CMOV. En la siguiente imagen se indica a detalle información
de cada parada (Ver Figura 61).
135
Figura 61. Detalle de las paradas en el servidor (Elaboración del autor).
El detalle de la parada indica el nombre de las intersecciones donde se encuentra la parada
y el numero de la misma, esta información se verá reflejada en el uso de la aplicación. Así
mismo se hicieron algunas consultas con JSON para el correcto funcionamiento de los
datos GTFS y que se encuentran en la sección de anexos.
6.2. Resultados obtenidos
6.2.1 Resultados aplicados sobre Google Maps
Una vez realizadas las pruebas mencionadas anteriormente, se decide implementarlo los
archivos GTFS para iniciar con el proceso de reflejo de los datos en los servidores de
Google, en específico Google Maps y de la misma manera tener la relación para la
aplicación a desarrollar.
Para realizar la subida de los datos, fue necesario realizar contacto a Google Transit Team,
que son el equipo especifico de Google para la solución a problemas de transportes
alrededor del mundo. Así pues, en conjunto con la Coordinación General de movilidad
(CMOV) del estado de Aguascalientes se accedió a la oportunidad de lograr el subir los
136
datos GTFS estáticos al sistema de nube de Google Transit, denominado Partnerdash (Ver
Figura 62).
Figura 62. Google Transit, Partnerdash (Elaboración del autor).
El sistema Partnerdash contiene una configuración para el feed o los archivos a subir, los
cuales una vez se han subido sea a algún servidor FTP o Google Drive, se comienza una
revisión por parte de los administradores del sistema para dar de alta un modo de
previsualización de los datos, pero de manera privada. Esta previsualización privada solo
es accesible por medio de la cuenta que se estableció por medio de la coordinación de
movilidad del estado y sus empleados autorizados.
La previsualización marca en tiempo real como los datos se ven reflejados dentro del mapa
de Google Maps y los tiempos estimados generados al crear los archivos GTFS (Ver
Figura 63).
Como se puede apreciar, las coordenadas establecen el recorrido total de la ruta 1, esta
esta denominada con el código clave “Vice” la cual nos indica la duración del viaje, dando
un total de una hora con 5 min. De igual manera nos da un informe de cada una de las
paradas y su localización puntual y especifica se muestra al desplegar la ruta seleccionada.
137
Figura 63. Previsualización privada de la ruta 1 en Google Maps (Elaboración del autor).
La ruta a su vez genera la agenda del día y la programación semanal, dando soporte a la
actualización de horarios de manera semanal. De igual manera si se selecciona solo una
parcialidad del trayecto definirá la mejor ruta para acceder a la ruta.
Como se logra analizar (Ver Figura 64) se indica cada uno de los puntos blancos, que
representan las paradas marcadas en el mapa y según los tiempos establecidos previamente
en los archivos GTFS estos se completaran en un determinado tiempo estimado. El tiempo
indicado en esta fase de resultado es estático, y en las siguientes etapas se podrá verificar
los resultados con los tiempos reales y el aumento en la optimización del servicio.
138
Figura 64. Ruta 1 y sus puntos de parada en Google Maps (Elaboración del autor).
El trabajo reflejado está disponible en el modo privado, sin embargo, se está realizando la
autorización por la parte de la coordinación de movilidad para autorizar el levantamiento
de la ruta y de esa manera, hacer pública la información. Se pretende terminar las 47 rutas
existentes para este proyecto, pero se indica la ruta 1 para el fin de mostrar los resultados
reflejados.
139
Como se indica a continuación (Ver Figura 65), la ruta 1 ha sido completamente
establecida, con lo cual, se puede apreciar una mejora en esa ruta en específico.
Figura 65. Ruta 1 completa (Elaboración del autor).
Los puntos que se aprecian dentro de la polilínea establecida son los puntos de parada que
estará realizando la ruta durante su trayecto, así mismo los nombres “Gomez” y “Vice”
hacen referencia al punto de origen de esa ruta, indicando los dos sentidos por los que
pasa, norte y sur. Se han establecido de igual manera una serie de horarios para la ruta que
se desplegaran durante el transcurso del día y que previamente ya se habían establecido
por medio del formato GTFS.
140
6.2.2 Resultados aplicados sobre el caso de estudio
Los resultados obtenidos una vez ejecutado el servidor y realizando la conexión con la
aplicación, pueden observarse como se indica (Ver Figura 66). Como se aprecia, se trabajó
con una ruta, en este caso la ruta 1 del sistema urbano de la ciudad de Aguascalientes.
Figura 66. Visualización Gómez Portugal (Elaboración del autor).
Esta ruta se despliega gracias a los datos GTFS ingresados al servidor y así mismo
genera una lista de paradas, podemos ver que indica el origen y final de la ruta y un
código de identificación, siendo “Gomez” el indicado para esta ruta.
141
De igual manera y contemplando su contraparte, se puede observar (Ver Figura 67) que
la distribución es idéntica a la anterior, cambiando solo el sentido y la distribución de cada
parada. El servidor OBA nuevamente procesa los datos GTFS ingresados y los refleja en
el mapa.
Figura 67.Visualización Vicente Guerrero (Elaboración del autor).
De igual manera de lado derecho se localiza un ID que es el mostrado en el archivo
ruoute.txt (Ver Anexo B), el cual a su vez muestra información correspondiente a las
paradas y la agencia que dispone de los mismos.
142
En la siguiente imagen (Ver Figura 68) se puede observar cómo dentro del menú de
búsqueda integrado en la aplicación, este nos muestra las paradas y rutas recientes en la
búsqueda que este generado automáticamente.
Figura 68. Paradas y rutas recientes (Elaboración del autor).
Esta pantalla resuelve de igual manera lo descrito en el capítulo anterior sobre el mockup
de paradas (Ver Figura 52) estableciendo una búsqueda mucho más simplificada, así como
la posibilidad de agregar paradas específicas como favoritas.
143
A continuación, se detallará el funcionamiento de la sección de paradas (Figura 69). Esta
sección almacena las paradas que se visiten desde el mapa, una vez se seleccionan, se
guardan en esta lista para su posterior uso. El uso de este complemento gestiona en mayor
medida la planeación de usuarios en destinos específicos.
Figura 69. Paradas específicas (Elaboración del autor).
De igual no solo se pueden establecer como paradas preferidas, sino obtener información
de horarios y actividades durante el día sobre esa parada en específico.
144
Una presionada la parada que se registra, esta puede desplegar información sobre los
tiempos de llegada o si esta fuera o no disponible hasta cierto horario indicado. Como se
aprecia (Ver Figura 70). Esta información no es exclusiva solo de un tiempo, al presionar
el botón de cargar más llegadas se visualizarán todas las que el usuario requiera conocer
y llevar un control en su programación de viajes.
Figura 70. Detalle de parada (Elaboración del autor).
145
En la siguiente imagen (Figura 71) se muestra la manera que se visualiza la información
al presionar una de las paradas, sea directamente de la ruta indicada o almacenada en el
menú aradas. Como se observa, se nos da el tiempo que llegara esta unidad a pasar por el
punto, así como sus paradas en sentido contrario.
Figura 71. Detalle de parada en mapa (Elaboración del autor).
En ejemplo podemos ver que al desplegar dicho menú podemos seguir cargando más
llegadas de unidades a ese punto, contemplando más información al usuario y facilidad
146
en el uso, lo cual al mismo tiempo simplifica el trabajo de ver horarios por adelantado y
mejora la experiencia por parte del usuario en el servicio.
Por último, la última pantalla del sistema (Ver Figura 72) no indica el número de parada
dentro de la ruta, y la ruta que la almacena. Esta tiene el propósito de gestión por parte de
la agencia de movilidad y llevar un control sobre los números reales de paradas oficiales
dentro de las rutas, así como seguimiento de las unidades al pararse sobre cada una de
ellas.
Figura 72. Información de parada (Elaboración del autor).
147
El desglose de las paradas se realiza de manera simplificada, seleccionando cualesquiera
que indique el usuario, se indicara el nombre de la ruta el sentido, en este caso “Gomez”
y la frecuencia en la que está desplazándose. Se puede ver una lista de horarios completa
para mayor gestión en la programación del viaje, lo cual facilita la organización del
usuario en ese aspecto (Ver Figura 73).
Figura 73. Desglose de horarios de ruta (Elaboración del autor).
Los horarios también se van actualizando en tiempo real, por lo que va generando
información confiable con el paso del tiempo y genera una mejor experiencia de consumo
en el usuario.
148
Cuando se selecciona un viaje planificado, nos señalizara la ruta, y su sentido, norte o sur,
en este caso esta denominado como “Vicente Guerrero – Gómez Portugal”, en sentido
norte.
La orientación se puede averiguar debido que, al seleccionar el viaje, el sistema nos arroja
el icono de un autobús el cual contiene una flecha blanca que indica el sentido hacia donde
se dirige y como lo indica la imagen (Ver Figura 74), esta está mirando hacia el norte.
Figura 74. Sentido de orientación del autobús (Elaboración del autor).
149
El icono como se mencionó, se nos muestra un autobús el cual en tiempo real va reflejando
el trayecto que tiene designado de la ruta, este trayecto, puede verse de dos maneras, de la
manera gráfica, o en forma de lista.
La lista nos indica la parada en la que se encuentra y los horarios que le tomara llegar a la
siguiente, dejando más clara la información que el usuario desee contemplar.
Figura 75. Horarios en tiempo real. (Elaboración del autor).
Cabe mencionar que la distribución de horarios en su modalidad de lista, de igual manera
que en el modo gráfico, se van actualizando según la velocidad del autobús y estos a su
vez se reflejan dentro de la lista ya mencionada (Ver Figura 75).
150
Al seleccionar un viaje planificado, no solo nos mostrara el símbolo del autobús más
cercano de acuerdo con nuestra posición, sino de los diferentes autobuses que están
realizando la misma ruta en ese momento, con la diferencia que estos autobuses estarán
más adelantados en su ruta debido a que han salido previamente de terminal. (Ver Figura
76).
Esta medida le podrá indicar más información al usuario cuando sean más rutas las que
debe de seleccionar, pues podrá moverse de acuerdo con las posiciones de diferentes
autobuses en diferentes rutas.
Figura 76. Autobuses sobre una misma ruta en tiempo real (Elaboración del autor).
151
6.4. Comentarios sobre el capítulo
Este capítulo, como se indicó anteriormente, relaciona de manera estrecha el
funcionamiento del modelo arquitectónico TUI con el desarrollo de la aplicación. Desde
el uso del formato GTFS hasta su implementación y resultante, una aplicación, sea de
tercero, como se vio en el caso de estudio o una aplicación destinada directamente en
Google Maps.
Como se aprecia, las pruebas generadas respaldan conjuntamente el diseño de la
arquitectura TUI y reflejan cada uno de sus módulos, es módulos completamente
funcionales, lo cual garantiza no solo una mejora en cuestión de tiempos del servicio, sino
una manera viable de uso del modelo en diferentes esquemas sociales, en diferentes
estados o ciudades.
152
DISCUSIÓN DE RESULTADOS
Los resultados obtenidos durante la ejecución del software Open Source OBA y el
software de Google Maps son convenientes, debido a que, a pesar de ser plataformas
diferentes, estas se adaptan con mucha facilidad al modelo arquitectónico TUI.
Los resultados referentes a la aplicación cumplen con lo establecido con el modelo
arquitectónico TUI, la relación del servidor OBA, así como la notificación de las alertas
del servicio, logran cumplir satisfactoriamente al modelo, generando la confiabilidad en
el mismo.
La aplicación por su parte y de manera independiente, cumple con una mayor
optimización sobre el servicio de transporte público, al hacer de conocimiento público, la
información sobres las diferentes rutas, paradas y unidades activas en la ruta en tiempo
real, logrando establecer una constante comunicación, no solo con un autobús, sino con
varios al mismo tiempo.
Como se indicó, ambas utilizan el formato de datos GTFS, y estos a su vez son gestionados
por servidores, en este caso dos, uno que hace referencia al de la agencia de movilidad, y
uno que puede variar según sea el caso. Exponiendo este último, si se está utilizando el
sistema de Google Transit, se utilizará el servidor que asigna la compañía para el alta de
los archivos o alertas. Si se utiliza en su defecto el establecido por el caso de estudio, se
hará uso del servidor OBA, una webapp que podrá consumir los archivos GTFS, así como
la creación y edición de alertas del servicio.
Como se explica, ambos métodos cumplen con la arquitectura TUI establecida logrando
justificar su funcionamiento y estableciendo un precedente de uso de un modelo
arquitectónico tal, que puede generar transporte inteligente de calidad a las diversas
agencias de movilidad de las diferentes ciudades.
153
Si bien los resultados son convenientes en lo que se refiere al modelo arquitectónico, sus
elementos y su resultante, el desarrollo tecnológico, se logra encontrar una área de
limitación, y esta hace referencia al apoyo con el que se cuente por parte del área
gubernamental de la ciudad donde se desee establecer la adaptación y uso del modelo y
posterior transformación a transporte inteligente, debido a que se requieren permisos para
dar de alta las rutas o los diferentes horarios a registrar por ejemplo en servicios como
Google Transit.
154
CONCLUSIONES
Las conclusiones pertinentes al proyecto tendrán lugar en este último capítulo, dividendo
las misma en 3 subáreas, especificando resultados a partir de los objetivos específicos, así
como de las preposiciones dadas en la hipótesis planteada. Para finalizar las
contribuciones que realiza este trabajo hacia las diferentes áreas sociales como
tecnológicas.
Esta sección comienza con objetivos alcanzados, se analiza cada uno de los objetivos
específicos y su cumplimiento a través del trabajo de investigación, todo enfocado hacia
el modelo arquitectónico TUI desarrollado.
Enseguida se establecerán los objetivos tanto generales como específicos como
preposiciones y se detallara su cumplimiento haciendo referencia a los capítulos donde se
logran completar y marcando referencias hacia las figuras correspondientes.
Después se realiza un breve análisis de contribuciones generadas a partir del trabajo
realizado y los puntos a puntos en los que el modelo arquitectónico TUI ofrece para la
construcción de ciudades inteligentes, específicamente en el área de transporte público
urbano.
La siguiente sección, mostrara la serie de trabajos publicados a lo largo de la investigación
en diferentes congresos y su correspondiente referencia hacia los anexos establecidos.
Para finalizar se da comentarios finales de la sección correspondiente, así como el soporte
final de resolución de los objetivos específicos y por consecuencia del objetivo general
establecido.
155
Objetivos alcanzados
Se diseño un modelo arquitectónico para el desarrollo de una aplicación inteligente de
geolocalización para transporte público con el fin de optimizar el tiempo del servicio en
la sociedad de Aguascalientes, tomando en cuenta dos arquitecturas, la arquitectura
enfocada a Smart Cities y Cloud Computing, y tomando elementos de estas se definió el
modelo arquitectónico TUI.
Este modelo a su vez se definió en modo de abstracción lo cual muestra elementos
fundamentales en las arquitecturas mencionadas previamente, lo cual cumple el
funcionamiento del modelo, definiendo y detallando de manera específica el modelo y
estableciendo las respuestas a los objetivos específicos.
Dando como resultante y con respecto a lo mencionado, lo siguiente:
1) Se realizaron análisis de arquitecturas para la concepción de un modelo
arquitectónico para transporte inteligente siguiendo las normas de Smart City
y Cloud Computing.
2) Se desarrollo de un modelo arquitectónico para transporte inteligente siguiendo
las normas de Smart City y Cloud Computing.
3) Se desarrollo una aplicación inteligente de geolocalización para la ubicación
del transporte público bajo el modelo arquitectónico desarrollado.
4) Se desarrollaron y ejecutaron pruebas de la aplicación con el modelo
arquitectónico desarrollado.
Con los resultados conseguidos, los cuales se desarrollan desde el capítulo II hasta el
VI se puede confirmar el cumplimiento del objetivo general en su totalidad.
156
Preposiciones demostradas hacia la hipótesis
Para realizar lo siguiente, se toma en cuenta tanto la hipótesis, así como el objetivo general
y especifico y se plantean de manera de preposición para visualizar si es factible obtener
el resultado que se requiere en dicha preposición. Esto nos ayudara a esclarecer más la
resolución de estos.
Respecto a la preposición 1 de esta investigación haciendo referencia a la hipótesis “Es
factible el uso de aplicación generada a partir de un modelo arquitectónico para la
implementación de transporte urbano inteligente puede optimizar la cantidad de tiempo
invertido en una parada de autobús por medio de sugerencia de rutas y estimación de
tiempos de llegada”, se ha demostrado que si es posible y factible resolver un problema
de optimización de tiempo por medio de una aplicación generada a partir de un modelo
arquitectónico. Esto puede observarse tanto en la plataforma de Google (Ver Figura 65)
así como en el desarrollo de la aplicación (Ver Figura 73), las cuales resuelven el problema
de optimización y sugerencia de tiempos, entrando en detalle en el capítulo 6.
Respecto a la preposición 2 de esta investigación haciendo referencia al objetivo general
“Es factible definir un modelo arquitectónico para el desarrollo de una aplicación
inteligente de geolocalización para transporte público con el fin de optimizar el tiempo
del servicio en la sociedad de Aguascalientes”, se ha demostrado que es factible construir
un modelo arquitectónico para mejorar el servicio de transporte público de la ciudad de
Aguascalientes. Esta proposición, al ser el objetivo general, se resuelve a través de todos
los objetivos específicos en detalle. Cabe mencionar que el modelo TUI (Ver Figura 39)
resuelve el objetivo, pues se logra, a partir de su resultante, una aplicación móvil, resolver
el problema de optimización de tiempos.
Respecto a la preposición 3 de esta investigación haciendo referencia al objetivo
específico 1 “Es factible el análisis de arquitecturas para la concepción de un modelo
arquitectónico para transporte inteligente siguiendo las normas de Smart City y Cloud
Computing”, se ha demostrado que es factible el estudio de diversas arquitecturas para dar
157
origen a una nueva a partir de elementos ya existentes. Las arquitecturas revisadas para el
desarrollo del modelo arquitectónico son la de Smart Cities (Ver Figura 2) y Cloud
Computing (Ver Tabla 1). Estas arquitecturas, al tomar elementos tales como la
digitalización de Smart Cities y los servicios de entrega de datos de Cloud Computing, se
pudo generar el modelo.
Respecto a la preposición 4 de esta investigación haciendo referencia al objetivo
específico 2 “Es factible el desarrollo de un modelo arquitectónico para transporte
inteligente siguiendo las normas de Smart City y Cloud Computing”, se ha demostrado
que al utilizar elementos de diversas arquitecturas se puede desarrollar una nueva
arquitectura. Este modelo arquitectónico TUI (Ver Figura 39), define las normas a seguir
la para la construcción del transporte urbano inteligente y otorga las pautas para su diseño.
Respecto a la preposición 5 de esta investigación haciendo referencia al objetivo
específico 3 “Es factible el desarrollo de aplicación inteligente de geolocalización para
la ubicación del transporte público bajo el modelo arquitectónico desarrollado”, se ha
demostrado que es factible debido a que, a partir del modelo arquitectónico, se genera
como resultado una aplicación. Una vez diseñado el modelo TUI (Ver Figura 39), se
procede a realizar el desarrollo de la aplicación, tanto plataformas como Google (Ver
Tabla 3) o aplicaciones opensource o de diseño libre como OneBusAway para este caso
de estudio (Ver Tabla 4).
Respecto a la preposición 6 de esta investigación haciendo referencia al objetivo
específico 4 “Es factible el desarrollo y ejecución de pruebas de la aplicación con el
modelo arquitectónico desarrollado”, se ha demostrado que es factible una vez realizadas
las pruebas tanto a las aplicaciones como a la abstracción del modelo arquitectónico. Se
realizaron en las diferentes plataformas, tanto Google (Ver Figura 65) como OneBusAway
(Ver Figura 73) para revisar el rendimiento de ambas, comprobando su uso, con el
desempeño del modelo arquitectónico TUI (Ver Figura 39).
158
Todo lo previamente mencionado se menciona en la extensión del trabajo, comenzando
desde el capítulo 2 hasta el capítulo 6, donde se puede apreciar las diferentes etapas de
resolución de objetivos hasta su resolución. De igual manera en la sección de anexos se
detalla parte de la sección de pruebas realizadas.
Por lo tanto y para finalizar, desde un enfoque especifico quedaría de la siguiente manera:
• Para la resolución del objetivo específico 1 hace referencia en el capítulo 2.
Específicamente en las arquitecturas Smart Cities (Ver Figura 2) y Cloud
Computing (Ver Tabla 1)
• Para la resolución del objetivo específico 2, hace referencia en el capítulo 4.
Específicamente en el modelo arquitectónico TUI (Ver Figura 39).
• Para la resolución del objetivo específico 3, hace referencia en el capítulo 5.
Específicamente en el uso de las plataformas (Ver Tabla 3) y aplicaciones (Ver
Tabla 4).
• Para la resolución del objetivo específico 4, hace referencia en el capítulo 6.
Específicamente en el uso y comparación de aplicaciones, todo de acuerdo con el
modelo TUI (Ver Figura 39).
El seguimiento de los capítulos en el orden asignado resuelve cada objetivo específico y,
por lo tanto, el objetivo general, así como su hipótesis se cumplen.
159
Contribuciones de la investigación
Las contribuciones generadas a partir de este trabajo de investigación son los siguientes:
• Modelo arquitectónico para la implementación de transporte urbano inteligente
TUI. Diseñado para ser adaptado en diferentes ciudades a partir de bajos
requerimientos.
• El modelo arquitectónico TUI puede ser utilizado por diferentes agencias de
movilidad para su pronta implementación. De igual manera aporta la guía para la
transformación de transporte inteligente de las ciudades.
• El modelo arquitectónico TUI da el conocimiento e indicio en el área de
investigación referente a ciudades inteligentes, enfocadas en el área de transporte
público.
• El modelo arquitectónico TUI puede adaptarse para el uso de tecnologías distintas
a las que establece, por lo que generar cambios dentro del modelo es sencillo.
160
Trabajos publicados
Durante el desarrollo de esta tesis y del trabajo de investigación, se generaron y publicaron
los siguientes trabajos:
Articulo/ponencia Anexo
Velasquez Ortiz, R. A., Álvarez Rodríguez, F. J., & Ponce Gallegos, J.C.
(octubre de 2018), Ponencia: “Modelo para la implementación de Transporte
Público Inteligente basado en la arquitectura Smart City y utilizando las
herramientas de Cloud Computing”, XXXI Congreso Nacional y XVII
Congreso Internacional de Informática y Computación de la ANIEI 2018,
CUCEI, Universidad de Guadalajara. Guadalajara, Jalisco, México.
E
Velasquez Ortiz, R. A., Álvarez Rodríguez, F. J., Vargas Martin, M., & Ponce
Gallegos, J.C. (mayo de 2019), Ponencia: “Mapping of the transport system of
the city of Aguascalientes using GTFS Data for the generation of Intelligent
Transport based on the Smart Cities paradigm”, 1st International Conference
on Advances in Emerging Trends and Technologies ICAETT 2019,
Universidad Tecnológica Israel, Quito, Ecuador.
I
Velasquez Ortiz, R. A., Álvarez Rodríguez, F. J., Vargas Martin, M., & Ponce
Gallegos, J.C. (octubre de 2019), Póster: “Mapeo de Rutas de Transporte
Público Concesionado de la Ciudad de Aguascalientes Mediante el uso de
GTFS para la Generación de Transporte Inteligente Basado en el Paradigma de
Smart Cities”, Décimo Congreso Internacional La Investigación en el Posgrado
2019, Unidad de Estudios Avanzados, Universidad Autónoma de
Aguascalientes. Aguascalientes, Aguascalientes, México.
M
Velasquez Ortiz, R. A., Álvarez Rodríguez, F. J., Monrreal Salazar, B., & Pérez
Corona, O. (octubre de 2019), Ponencia: “Diseño de arquitectura TUI para la
implementación de Transporte Inteligente y validación mediante series de
tiempo”, XXXII Congreso Nacional y XVIII Congreso Internacional de
Informática y Computación de la ANIEI 2019, Centro de Convenciones,
Benemérita Universidad Autónoma de Puebla, Puebla, México.
Q
161
Comentarios de la sección
Con esta sección, se da seguimiento al capítulo 1, formulación de la investigación, en el
cual se estableció las bases que se estarían cumpliendo a lo largo del trabajo de
investigación y de sus diferentes capítulos.
Esta sección resuelve y justifica el cumplimiento de cada uno de las cláusulas y objetivos
declarados en el primer capítulo, dando un cierre a la investigación realizada de manera
sólida y asegurando obtener las respuestas requeridas a la solución de las preguntas
realizadas con anterioridad.
162
GLOSARIO
Arquitectura de Software: Hace referencia a la estructuración del sistema que,
idealmente, se crea en etapas tempranas del desarrollo. Esta estructuración representa un
diseño de alto nivel del sistema que tiene dos propósitos primarios: satisfacer los atributos
de calidad (desempeño, seguridad, modificabilidad), y servir como guía en el desarrollo.
Cloud Computing: Se ocupa de servicios de computación, software, acceso a datos y
almacenamiento que pueden no exigir que el usuario final conozca la ubicación física y la
configuración del sistema que está suministrando los servicios.
Framework: Entorno de trabajo o marco de trabajo es un conjunto estandarizado de
conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve
como referencia, para enfrentar y resolver nuevos problemas de índole similar.
Internet of Things: Paradigma que combina una gran cantidad de dispositivos
heterogéneos, que están conectados a Internet y pueden identificarse a través de
direcciones IP y protocolos.
Smart Cities: una ciudad que supervisa e integra las condiciones de todas sus
infraestructuras críticas, incluyendo carreteras, puentes, túneles, ferrocarriles/metro,
aeropuertos, puertos marítimos, comunicaciones, agua, energía e incluso edificios
importantes, puede optimizar mejor sus recursos, planificar sus actividades de
mantenimiento preventivo y supervisar los aspectos de seguridad al tiempo que maximiza
los servicios a sus ciudadanos
Smart Mobility: Se refiere al uso de medios de transporte alternativos al uso individual
del vehículo privado.
163
Software as a Service: Es una colección de servicios de cómputo remoto. SaaS se
encuentra en la parte superior de los modelos de entrega. Permite que las aplicaciones se
distribuyan de forma descentralizada a través de terceros.
164
BILIOGRAFÍA Aguascalientes, L. J. (2015). EL 36 POR CIENTO DE LA POBLACIÓN SE DESPLAZA
EN CAMIÓN URBANO. Retrieved from http://www.lja.mx/2015/01/el-36-por-ciento-de-la-poblacion-se-desplaza-en-camion-urbano/
Alliance, C. S. (2013). The Threats Working Group-The Notorious Nine Cloud
Computing Top Threats in 2013 21. Retrieved from Cloud Security Alliance website:https://downloads.cloudsecurityalliance.org/initiatives/top_threats/The_Notorious_Nine_Cloud_Computing_Top_Threats_in_2013.pdf.
Arroub, A., Zahi, B., Sabir, E., & Sadik, M. (2016, 26-29 Oct. 2016). A literature review
on Smart Cities: Paradigms, opportunities and open problems. Paper presented at the 2016 International Conference on Wireless Networks and Mobile Communications (WINCOM).
Bass, L., & Nord, R. L. (2012, 20-24 Aug. 2012). Understanding the Context of
Architecture Evaluation Methods. Paper presented at the 2012 Joint Working IEEE/IFIP Conference on Software Architecture and European Conference on Software Architecture.
Batres García, M. (2012). Demanda FTA poner fin al monopolio de ATUSA para mejorar
transporte urbano. Retrieved from http://www.hidrocalidodigital.com/local/articulo.php?idnota=29724
busETA. (2016). Washington Metropolitan Area Transit Authority. Retrieved from
http://buseta.wmata.com/
Carlin, S., & Curran, K. (2013). Cloud computing security. In Pervasive and Ubiquitous
Technology Innovations for Ambient Intelligence Environments (pp. 12-17): IGI Global.
Cerbón, M. (2018). Se tambalea concesión de ATUSA sobre transporte público. Retrieved
from https://newsweekespanol.com/2018/06/se-tambalea-concesion-de-atusa-sobre-transporte-publico/
Chalo. (2018). Never wait at a bus stop ever again. Retrieved from
https://www.chalo.com/
165
Citymapper. (2018). La app definitiva de transportes. Retrieved from https://citymapper.com/
COMMISSION, E. (2012). Smart Cities and Communities. 2018(09/09/2018).
https://ec.europa.eu/digital-single-market/en/news/smart-cities-and-communities-european-innovation-partnership-communication-commission-c2012
Contralinea. (2018). Gobierno busca el colapso del transporte urbano: ATUSA. Retrieved
from http://www.acontralinea.com/gobierno-busca-colapso-del-transporte-urbano-atusa/
Csiszár, C., & Földes, D. (2015, 24-25 June 2015). Analysis and modelling methods of
urban integrated information system of transportation. Paper presented at the 2015 Smart Cities Symposium Prague (SCSP).
Delgado, A., Castro, A., & Martín, G. (2007). Evaluación de Arquitecturas de Software
con ATAM (Architecture Tradeoff Analysis Method): un caso de estudio. Reportes Técnicos 07-01.
Delgado Aguilar, F. J. (2017). Historia De Los Caminos y El Transporte En
Aguascalientes. Retrieved from http://www.aguascalientes.gob.mx/segob/archivohistorico/transportes_8.aspx
Di Martino, Sergio & Rossi, Silvia. (2016). An Architecture for a Mobility Recommender System in Smart Cities. Procedia Computer Science. 98. 425 - 430. 10.1016/j.procs.2016.09.066.
Elleuch, W., Wali, A., & Alimi, A. M. (2015, 20-22 May 2015). Collection and
exploration of GPS based vehicle traces database. Paper presented at the 2015 4th International Conference on Advanced Logistics and Transport (ICALT).
Faria, R., Brito, L., Baras, K., & Silva, J. (2017, 10-13 July 2017). Smart mobility: A
survey. Paper presented at the 2017 International Conference on Internet of Things for the Global Community (IoTGC).
Fernández Güell, J. M. (2015). Ciudades Inteligentes: La mitificación de las nuevas
tecnologías como respuesta a los retos de las ciudades contemporáneas. Economía Industrial(395), 17-28.
Forzati, M., Larsen, C. P., & Mattsson, C. (2010, 27 June-1 July 2010). Open access networks, the Swedish experience. Paper presented at the 2010 12th International Conference on Transparent Optical Networks.
166
Girish, M. (2019). Better Bus Implementing Bus Tracking App with GTFS data. In G.
Maiyah (Ed.), (pp. 137). Retrieved from https://www.amazon.com/BetterBus-Implementing-Tracking-GTFS-data-ebook/dp/B07QDCWHTP/ref=sr_1_1?keywords=betterbus&qid=1556889659&s=gateway&sr=8-1
Gobierno, S. G. d. (2018). Ley de Movilidad del Estado de Aguascalientes. Primera
Sección del Periódico Oficial del Estado: Periódico Oficial del Estado Retrieved from http://eservicios2.aguascalientes.gob.mx/NormatecaAdministrador/archivos/EDO-18-141.pdf.
Google. (2016). Programa de partners de Google Transit. Retrieved from
http://maps.google.com/help/maps/mapcontent/transit/
Hall, R. E., Bowerman, B., Braverman, J., Taylor, J., Todosow, H., & Von Wimmersperg,
U. (2000). The vision of a smart city. Retrieved from Heraldo, E. (2018). Piden choferes urbanos volver el tiempo al pasado. Retrieved from
http://www.heraldo.mx/piden-choferes-de-urbanos-volver-el-tiempo-al-pasado/
Hidrocalidodigital. (2018). Obreros se quejan de llegar tarde por culpa de urbaneros.
Retrieved from http://www.hidrocalidodigital.com/local/articulo.php?idnota=146923
Horažďovský, P., Novotný, V., & Svítek, M. (2018, 24-25 May 2018). Data-driven
management of dynamic public transport. Paper presented at the 2018 Smart City Symposium Prague (SCSP).
Hozaim, A. B., & Akre, V. L. (2017, 25-26 Oct. 2017). A framework for transforming
Dubai into a smart city. Paper presented at the 2017 Fourth HCT Information Technology Trends (ITT).
INEGI. (2018). México en cifras. Retrieved from
https://www.inegi.org.mx/app/areasgeograficas/?ag=01
INEGI. (2019). EN MÉXICO HAY 74.3 MILLONES DE USUARIOS DEINTERNET Y
18.3 MILLONES DE HOGARES CONCONEXIÓN A ESTE SERVICIO: ENDUTIH 2018. 25/11/2019, de INEGI Sitio web:
167
https://www.inegi.org.mx/contenidos/saladeprensa/boletines/2019/OtrTemEcon/ENDUTIH_2018.pdf
Jadeja, Y., & Modi, K. (2012, 21-22 March 2012). Cloud computing - concepts, architecture and challenges. Paper presented at the 2012 International Conference on Computing, Electronics and Electrical Technologies (ICCEET).
kiedybus. (2016). kiedybus. Retrieved from https://www.kiedybus.pl/
Krambeck, H. (2017). Introduction to the General Transit Feed Specification (GTFS) and
Informal Transit System Mapping (Self-Paced). Retrieved from https://olc.worldbank.org/content/introduction-general-transit-feed-specification-gtfs-and-informal-transit-system-mapping
Krambeck, H. (2018). Introduction to the General Transit Feed Specification (GTFS) and
Informal Transit System Mapping (Self-Paced). In. Open Learning Campus: World Bank Group.
Kyriazopoulou, C. (2015, 20-22 May 2015). Smart city technologies and architectures: A
literature review. Paper presented at the 2015 International Conference on Smart Cities and Green ICT Systems (SMARTGREENS).
Lee, S., & Lee, D. (2015, 25-28 Nov. 2015). Review on Current Situations for Internet of
Things. Paper presented at the 2015 7th International Conference on Multimedia, Computer Graphics and Broadcasting (MulGraB).
Makarova, I., Shubenkova, K., Mavrin, V., Boyko, A., & Katunin, A. (2017, 11-13 Sept.
2017). Development of sustainable transport in smart cities. Paper presented at the 2017 IEEE 3rd International Forum on Research and Technologies for Society and Industry (RTSI).
Moovit. (2015). The #1 Urban Mobility App Worldwide. Retrieved from
https://www.company.moovit.com/
Movilidad, C. G. d. (2016). Rutas de Transporte. Retrieved from
http://www.aguascalientes.gob.mx/CMOV/transporte/DGTPrutasdetransporte.aspx
MTA. (2014). MTA BusTime. Retrieved from http://bustime.mta.info/
168
Nam, T., & Pardo, T. A. (2011). Conceptualizing Smart City with Dimensions of Technology, People, and Institutions.
Narula, S., Jain, A., & Prachi. (2015, 21-22 Feb. 2015). Cloud Computing Security:
Amazon Web Service. Paper presented at the 2015 Fifth International Conference on Advanced Computing & Communication Technologies.
OneBusAway. (2010). The Open Source platform for Real Time Transit Info. Retrieved
from https://onebusaway.org/
Paramel, R. (2018, January 24, 2018). Planning Sustainable Smart Cities with the Smart
City Ecosystem Framework. Retrieved from https://strategyofthings.io/smart-city-ecosystem
Pečar, M., & Papa, G. (2017, 18-20 Oct. 2017). Transportation problems and their
potential solutions in smart cities. Paper presented at the 2017 International Conference on Smart Systems and Technologies (SST).
Rafiei, M., Elmi, S. M., & Zare, A. (2012, 2-3 May 2012). Wireless communication
protocols for smart metering applications in power distribution networks. Paper presented at the 2012 Proceedings of 17th Conference on Electrical Power Distribution.
R. A. Velasquez Ortiz, F. Álvarez Rodríguez, J.C. Ponce Gallegos, Modelo para la implementación de Transporte Público Inteligente basado en la arquitectura Smart City y utilizando las herramientas de Cloud Computing, in: S. G. M. de Lourdes, G. G. A. Rosa, F. J. Álvarez Rodríguez (Eds.), Emprendiendo Innovaciones con Tecnologías Exponenciales, ALFA OMEGA GRUPO EDITOR S.A. DE C.V., 2018, pp. 401-406. URL http://www.aniei.org.mx/Archivos/Memorias/L_Electronico_CNCIIC2018.pdf
R. A. Velasquez Ortiz, F. Álvarez Rodríguez, M. Vargas Martin, J.C. Ponce Gallegos, Mapping of the transport system of the city of Aguascalientes using GTFS Data for the generation of Intelligent Transport based on the Smart Cities paradigm, in: M. Botto-Tobar, J. León-Acurio, A. Díaz Cadena, P. Montiel Díaz (Eds.), Advances in Emerging Trends and Technologies, Springer Nature Switzerland AG, Switzerland, 2020, pp. 1-9. doi:https://doi.org/10.1007/978-3-030-32022-5_17. URL
Rodríguez Loera, C. (2018). Están de acuerdo empresarios de Aguascalientes en que
gobierno no debo acceder a chantajes de ATUSA. Retrieved from http://www.lja.mx/2018/10/estan-de-acuerdo-empresarios-de-aguascalientes-en-que-gobierno-no-debe-acceder-a-chantajes-de-atusa/
169
Singh, S., Jeong, Y.-S., & Hyuk park, J. (2016). A Survey on Cloud Computing Security:
Issues, Threats, and Solutions (Vol. 75).
Smart Cities MOOC. (2018). In (pp. 14). Retrieved from www.iglus.org Transit. (2012). Go your own way. Retrieved from https://transitapp.com/
Transit, G. (2012). Referencia de la Especificación general de feeds de transporte público.
Retrieved from https://developers.google.com/transit/gtfs/reference
Tripathi, A., & Mishra, A. (2011, 14-16 Sept. 2011). Cloud computing security
considerations. Paper presented at the 2011 IEEE International Conference on Signal Processing, Communications and Computing (ICSPCC).
Valencia, U. P. d. (2013). Introducción a ATAM. Retrieved from
http://users.dsic.upv.es/~jagonzalez/JISBD2013/files/IntroductionATAM.pdf
Wieclaw, L., Pasichnyk, V., Kunanets, N., Duda, O., Matsiuk, O., & Falat, P. (2017, 21-
23 Sept. 2017). Cloud computing technologies in “smart city” projects. Paper presented at the 2017 9th IEEE International Conference on Intelligent Data Acquisition and Advanced Computing Systems: Technology and Applications (IDAACS).
Yang, W., Wei, Q., Liu, H., & Li, H. (2016, 17-18 Dec. 2016). Research on Information
Resources Sharing Security Based on Cloud Computing. Paper presented at the 2016 International Conference on Intelligent Transportation, Big Data & Smart City (ICITBS).
YRT. (2016). York Region Transit / VIVA. Retrieved from
https://www.yrt.ca/en/index.aspx
Zhang, T., Chen, M., & Lawson, C. (2014, 25-27 June 2014). General Transit Feed
Specification data visualization. Paper presented at the 2014 22nd International Conference on Geoinformatics.
Zulkarnain, N., & Anshari, M. (2016, 16-18 Nov. 2016). Big data: Concept, applications,
& challenges. Paper presented at the 2016 International Conference on Information Management and Technology (ICIMTech).
170
ANEXOS
ANEXO A – CUESTIONARIO: Opinión sobre el Sistema de Transporte Público de la ciudad de Aguascalientes.
Para la consulta del cuestionario se puede seguir el siguiente hipervínculo:
https://docs.google.com/forms/d/1CoytES95A8bTtkiXh_h6zNHc-yFottrABW0b7mgC244/edit
1.- Genero
Femenino
Masculino
2.- ¿Qué edad tienes?
De 18-25 años
De 26-32 años
De 33-40 años
De 41-48 años
De 49-56 años
De 57-64 años
De 65+ años
3.- ¿Eres usuario regular del Sistema de Transporte Público?
Si
No
4.- ¿Cuánto tiempo aproximado inviertes en la espera de que una ruta llegue a una parada establecida?
10 minutos
20 minutos
30 minutos
40 minutos
50 minutos
1 hora
Más de una hora
5.- ¿Considera que existen tiempos establecidos para la espera y traslado a su punto de destino?
Si
No
Quizás
6.- ¿Considera que la relación precio-calidad que usted está pagando por el servicio de transporte público es el correcto? Seleccione un porcentaje de calidad, siendo 0 la más baja calidad a 100 siendo la más alta.
0%
20%
40%
60%
80%
100%
7.- ¿Te seria de utilidad saber el tiempo en que llegara una unidad en un determinado tiempo sin esperar necesariamente en una parada establecida?
Si
No
8.- Con respecto al problema de transporte relacionado con el tiempo de llegada, proporciona tu opinión
Texto de respuesta larga
9.- ¿Utilizarías una app para poder ver a las unidades en tiempo real y su tiempo de llegada a las diferentes paradas establecidas, así como rutas activas e inactivas?
Si
No
10.- ¿Qué porcentaje de calidad de servicio crees aumentaría con esta aplicación?
20%
40%
60%
80%
100%
ANEXO B – ARCHIVOS GTFS
agency.txt agency_name, agency_url, agency_timezone Coordinación General de Movilidad, http://www.aguascalientes.gob.mx/CMOV/, America/Mexico_City calendar.txt service_id, monday, tuesday, wednesday, thursday, friday, saturday, sunday, start_date,end_date 101_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 700_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 710_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 720_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 730_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 740_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 750_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 800_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 810_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 820_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 830_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 840_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 850_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 910_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 920_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 930_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 940_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 950_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1000_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1010_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1020_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1030_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1040_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1050_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1100_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1110_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1130_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1150_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1210_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1230_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1250_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807
1310_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1330_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1350_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1410_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1420_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1430_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1440_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1450_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1500_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1510_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1520_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1530_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1540_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1550_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1600_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1610_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1620_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1630_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1640_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1650_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1700_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1710_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1750_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1810_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1830_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1850_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1910_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1930_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 1950_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 2010_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 2030_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 2050_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 2110_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 2120_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 2130_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 2140_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 2150_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 2200_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 2210_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 2230_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 0700_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 0710_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 0720_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807
0730_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 0740_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 0750_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 0800_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 0810_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 0820_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 0830_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 0840_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 0850_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 0910_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 0920_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 0930_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 0940_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 0950_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01000_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01010_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01020_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01030_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01040_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01050_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01100_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01110_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01130_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01150_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01210_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01230_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01250_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01310_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01330_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01350_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01410_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01420_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01430_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01440_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01450_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01500_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01510_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01520_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01530_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01540_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01550_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01600_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01610_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807
01620_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01630_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01640_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01650_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01700_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01710_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01750_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01810_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01830_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01850_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01910_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01930_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 01950_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 02010_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 02030_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 02050_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 02110_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 02120_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 02130_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 02140_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 02150_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 02200_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 02210_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 02230_Timetable_--_2019-01, 1, 1, 1, 1, 1, 1, 1, 20190107, 20190807 routes.txt route_id, route_short_name, route_long_name, route_type 1, Vice, "Vicente Guerrero - Gómez Portugal", 3 1B, Gomez, "Gómez Portugal - Vicente Guerrero", 3 trip_id, arrival_time, departure_time, stop_id, stop_sequence 101550_700_Timetable_--_2019-01, 05:50:00, 05:50:00, Gral Term1:1, 1 101550_700_Timetable_--_2019-01, 05:54:00, 05:54:00, Maes Cami1:1, 2 101550_700_Timetable_--_2019-01, 05:57:00, 05:57:00, Maes Baran1:1, 3 101550_700_Timetable_--_2019-01, 06:00:10, 06:00:10, SiXXI Bode1:1, 4 101550_700_Timetable_--_2019-01, 06:02:15, 06:02:15, SiXXI SanMo1:1, 5 101550_700_Timetable_--_2019-01, 06:03:35, 06:03:35, SiXXI Pante1:1, 6 101550_700_Timetable_--_2019-01, 06:05:05, 06:05:05, SiXXI Oxxo1:1, 7 101550_700_Timetable_--_2019-01, 06:08:42, 06:08:42, SiXXI DolR1:1, 8 101550_700_Timetable_--_2019-01, 06:10:07, 06:10:07, Pilar Prol1_1:1, 9 101550_700_Timetable_--_2019-01, 06:12:17, 06:12:17, Pilar Prol2_1:1, 10 101550_700_Timetable_--_2019-01, 06:13:10, 06:13:10, Pilar Prol3_1:1, 11
101550_700_Timetable_--_2019-01, 06:13:50, 06:13:50, Pilar Prol4_1:1, 12 101550_700_Timetable_--_2019-01, 06:14:30, 06:14:30, Pilar Prol5_1:1, 13 101550_700_Timetable_--_2019-01, 06:15:30, 06:15:30, Prol Paseo_1:1, 14 101550_700_Timetable_--_2019-01, 06:16:20, 06:16:20, AvAgsSur1:1, 15 101550_700_Timetable_--_2019-01, 06:17:45, 06:17:45, Quint Fray1:1, 16 101550_700_Timetable_--_2019-01, 06:18:30, 06:18:30, Quint RepH1:1, 17 101550_700_Timetable_--_2019-01, 06:19:45, 06:19:45, RepB RepG1:1, 18 101550_700_Timetable_--_2019-01, 06:19:46, 06:19:46, CentralCam1:1, 19 101550_700_Timetable_--_2019-01, 06:19:50, 06:19:50, AvCon Quint1:1, 20 101550_700_Timetable_--_2019-01, 06:20:20, 06:20:20, AvJos Clin1_1:1, 21 101550_700_Timetable_--_2019-01, 06:21:00, 06:21:00, AvJos Her1:1, 22 101550_700_Timetable_--_2019-01, 06:22:00, 06:22:00, AvJos Salon1:1, 23 101550_700_Timetable_--_2019-01, 06:23:00, 06:23:00, AvJos AvCruz1:1, 24 101550_700_Timetable_--_2019-01, 06:24:05, 06:24:05, Chav Pimen1:1, 25 101550_700_Timetable_--_2019-01, 06:24:55, 06:24:55, Chav Vicen1:1, 26 101550_700_Timetable_--_2019-01, 06:26:00, 06:26:00, 5May ZCen1:1, 27 101550_700_Timetable_--_2019-01, 06:27:10, 06:27:10, 5May Mari1:1, 28 101550_700_Timetable_--_2019-01, 06:28:16, 06:28:16, 5May JesMa1:1, 29 101550_700_Timetable_--_2019-01, 06:29:24, 06:29:24, PetMex Enr1:1, 30 101550_700_Timetable_--_2019-01, 06:30:44, 06:30:44, Jose Barrag1:1, 31 101550_700_Timetable_--_2019-01, 06:31:00, 06:31:00, Barrag Alfred1:1, 32 101550_700_Timetable_--_2019-01, 06:33:15, 06:33:15, Zac Celso1:1, 33 101550_700_Timetable_--_2019-01, 06:33:20, 06:33:20, Zac Eba1:1, 34 101550_700_Timetable_--_2019-01, 06:33:23, 06:33:23, Zac Agla1:1, 35 101550_700_Timetable_--_2019-01, 06:34:37, 06:34:37, Nacoz Nort1:1, 36 101550_700_Timetable_--_2019-01, 06:36:47, 06:36:47, Zac Altaria1:1, 37 101550_700_Timetable_--_2019-01, 06:37:20, 06:37:20, Zac Espec1_1:1, 38 101550_700_Timetable_--_2019-01, 06:40:10, 06:40:10, Zac Espec2_1:1, 39 101550_700_Timetable_--_2019-01, 06:41:00, 06:41:00, Zac Espec3_1:1, 40 101550_700_Timetable_--_2019-01, 06:43:17, 06:43:17, Zac Flex1:1, 41 101550_700_Timetable_--_2019-01, 06:44:10, 06:44:10, Carre45 Parq1:1, 42 101550_700_Timetable_--_2019-01, 06:45:15, 06:45:15, Carre45 Sfr1:1, 43 101550_700_Timetable_--_2019-01, 06:46:35, 06:46:35, Carre45 Viñ1:1, 44 101550_700_Timetable_--_2019-01, 06:47:28, 06:47:28, Panam1:1, 45 101550_700_Timetable_--_2019-01, 06:49:14, 06:49:14, Panam Buga1:1, 46 101550_700_Timetable_--_2019-01, 06:51:55, 06:51:55, Marg Port1:1, 47 101550_700_Timetable_--_2019-01, 06:54:00, 06:54:00, GomeTerm1:1, 48 101600_710_Timetable_--_2019-01, 06:00:10, 06:00:10, Gral Term1:1, 1 101600_710_Timetable_--_2019-01, 06:04:00, 06:04:00, Maes Cami1:1, 2 101600_710_Timetable_--_2019-01, 06:07:00, 06:07:00, Maes Baran1:1, 3 101600_710_Timetable_--_2019-01, 06:10:10, 06:10:10, SiXXI Bode1:1, 4 101600_710_Timetable_--_2019-01, 06:12:15, 06:12:15, SiXXI SanMo1:1, 5 101600_710_Timetable_--_2019-01, 06:13:35, 06:13:35, SiXXI Pante1:1, 6
101600_710_Timetable_--_2019-01, 06:15:05, 06:15:05, SiXXI Oxxo1:1, 7 101600_710_Timetable_--_2019-01, 06:18:42, 06:18:42, SiXXI DolR1:1, 8 101600_710_Timetable_--_2019-01, 06:20:07, 06:20:07, Pilar Prol1_1:1, 9 101600_710_Timetable_--_2019-01, 06:22:17, 06:22:17, Pilar Prol2_1:1, 10 101600_710_Timetable_--_2019-01, 06:23:10, 06:23:10, Pilar Prol3_1:1, 11 101600_710_Timetable_--_2019-01, 06:23:50, 06:23:50, Pilar Prol4_1:1, 12 101600_710_Timetable_--_2019-01, 06:24:30, 06:24:30, Pilar Prol5_1:1, 13 101600_710_Timetable_--_2019-01, 06:25:30, 06:25:30, Prol Paseo_1:1, 14 101600_710_Timetable_--_2019-01, 06:26:20, 06:26:20, AvAgsSur1:1, 15 101600_710_Timetable_--_2019-01, 06:27:45, 06:27:45, Quint Fray1:1, 16 101600_710_Timetable_--_2019-01, 06:28:30, 06:28:30, Quint RepH1:1, 17 101600_710_Timetable_--_2019-01, 06:29:45, 06:29:45, RepB RepG1:1, 18 101600_710_Timetable_--_2019-01, 06:30:00, 06:30:00, CentralCam1:1, 19 101600_710_Timetable_--_2019-01, 06:31:20, 06:31:20, AvCon Quint1:1, 20 101600_710_Timetable_--_2019-01, 06:32:50, 06:32:50, AvJos Clin1_1:1, 21 101600_710_Timetable_--_2019-01, 06:33:20, 06:33:20, AvJos Her1:1, 22 101600_710_Timetable_--_2019-01, 06:34:20, 06:34:20, AvJos Salon1:1, 23 101600_710_Timetable_--_2019-01, 06:35:20, 06:35:20, AvJos AvCruz1:1, 24 101600_710_Timetable_--_2019-01, 06:36:25, 06:36:25, Chav Pimen1:1, 25 101600_710_Timetable_--_2019-01, 06:37:10, 06:37:10, Chav Vicen1:1, 26 101600_710_Timetable_--_2019-01, 06:38:05, 06:38:05, 5May ZCen1:1, 27 101600_710_Timetable_--_2019-01, 06:39:15, 06:39:15, 5May Mari1:1, 28 101600_710_Timetable_--_2019-01, 06:40:21, 06:40:21, 5May JesMa1:1, 29 101600_710_Timetable_--_2019-01, 06:41:29, 06:41:29, PetMex Enr1:1, 30 101600_710_Timetable_--_2019-01, 06:42:49, 06:42:49, Jose Barrag1:1, 31 101600_710_Timetable_--_2019-01, 06:43:05, 06:43:05, Barrag Alfred1:1, 32 101600_710_Timetable_--_2019-01, 06:45:20, 06:45:20, Zac Celso1:1, 33 101600_710_Timetable_--_2019-01, 06:45:50, 06:45:50, Zac Eba1:1, 34 101600_710_Timetable_--_2019-01, 06:46:50, 06:46:50, Zac Agla1:1, 35 101600_710_Timetable_--_2019-01, 06:47:07, 06:47:07, Nacoz Nort1:1, 36 101600_710_Timetable_--_2019-01, 06:49:24, 06:49:24, Zac Altaria1:1, 37 101600_710_Timetable_--_2019-01, 06:50:01, 06:50:01, Zac Espec1_1:1, 38 101600_710_Timetable_--_2019-01, 06:53:01, 06:53:01, Zac Espec2_1:1, 39 101600_710_Timetable_--_2019-01, 06:53:59, 06:53:59, Zac Espec3_1:1, 40 101600_710_Timetable_--_2019-01, 06:55:16, 06:55:16, Zac Flex1:1, 41 101600_710_Timetable_--_2019-01, 06:56:09, 06:56:09, Carre45 Parq1:1, 42 101600_710_Timetable_--_2019-01, 06:57:14, 06:57:14, Carre45 Sfr1:1, 43 101600_710_Timetable_--_2019-01, 06:58:34, 06:58:34, Carre45 Viñ1:1, 44 101600_710_Timetable_--_2019-01, 06:59:27, 06:59:27, Panam1:1, 45 101600_710_Timetable_--_2019-01, 07:01:04, 07:01:04, Panam Buga1:1, 46 101600_710_Timetable_--_2019-01, 07:03:34, 07:03:34, Marg Port1:1, 47 101600_710_Timetable_--_2019-01, 07:05:50, 07:05:50, GomeTerm1:1, 48 101610_720_Timetable_--_2019-01, 06:10:10, 06:10:10, Gral Term1:1, 1
101610_720_Timetable_--_2019-01, 06:14:00, 06:14:00, Maes Cami1:1, 2 101610_720_Timetable_--_2019-01, 06:17:00, 06:17:00, Maes Baran1:1, 3 trips.txt route_id, service_id, trip_id 1, 700_Timetable_--_2019-01, 101550_700_Timetable_--_2019-01 1, 710_Timetable_--_2019-01, 101600_710_Timetable_--_2019-01 1, 720_Timetable_--_2019-01, 101610_720_Timetable_--_2019-01 1, 730_Timetable_--_2019-01, 101620_730_Timetable_--_2019-01 1, 740_Timetable_--_2019-01, 101630_740_Timetable_--_2019-01 1, 750_Timetable_--_2019-01, 101640_750_Timetable_--_2019-01 1, 800_Timetable_--_2019-01, 101650_800_Timetable_--_2019-01 1, 810_Timetable_--_2019-01, 101700_810_Timetable_--_2019-01 1, 820_Timetable_--_2019-01, 101710_820_Timetable_--_2019-01 1, 830_Timetable_--_2019-01, 101720_830_Timetable_--_2019-01 1, 840_Timetable_--_2019-01, 101730_840_Timetable_--_2019-01 1, 850_Timetable_--_2019-01, 101740_850_Timetable_--_2019-01 1, 800_Timetable_--_2019-01, 101750_900_Timetable_--_2019-01 1, 910_Timetable_--_2019-01, 101800_910_Timetable_--_2019-01 1, 920_Timetable_--_2019-01, 101810_920_Timetable_--_2019-01 1, 930_Timetable_--_2019-01, 101820_930_Timetable_--_2019-01 1, 940_Timetable_--_2019-01, 101830_940_Timetable_--_2019-01 1, 950_Timetable_--_2019-01, 101840_950_Timetable_--_2019-01 1, 1000_Timetable_--_2019-01, 101850_1000_Timetable_--_2019-01 1, 1010_Timetable_--_2019-01, 101900_1010_Timetable_--_2019-01 1, 1020_Timetable_--_2019-01, 101910_1020_Timetable_--_2019-01 1, 1030_Timetable_--_2019-01, 101920_1030_Timetable_--_2019-01 1, 1040_Timetable_--_2019-01, 101930_1040_Timetable_--_2019-01 1, 1050_Timetable_--_2019-01, 101940_1050_Timetable_--_2019-01 1, 1100_Timetable_--_2019-01, 101950_1100_Timetable_--_2019-01 1, 1110_Timetable_--_2019-01, 1011000_1110_Timetable_--_2019-01 1, 1130_Timetable_--_2019-01, 1011020_1130_Timetable_--_2019-01 1, 1150_Timetable_--_2019-01, 1011040_1150_Timetable_--_2019-01 1, 1210_Timetable_--_2019-01, 1011100_1210_Timetable_--_2019-01 1, 1230_Timetable_--_2019-01, 1011120_1230_Timetable_--_2019-01 1, 1250_Timetable_--_2019-01, 1011140_1250_Timetable_--_2019-01 1, 1310_Timetable_--_2019-01, 1011200_1310_Timetable_--_2019-01 1, 1330_Timetable_--_2019-01, 1011220_1330_Timetable_--_2019-01 1, 1350_Timetable_--_2019-01, 1011240_1350_Timetable_--_2019-01 1, 1410_Timetable_--_2019-01, 1011300_1410_Timetable_--_2019-01 1, 1420_Timetable_--_2019-01, 1011310_1420_Timetable_--_2019-01 1, 1430_Timetable_--_2019-01, 1011320_1430_Timetable_--_2019-01
1, 1440_Timetable_--_2019-01, 1011330_1440_Timetable_--_2019-01 1, 1450_Timetable_--_2019-01, 1011340_1450_Timetable_--_2019-01 1, 1500_Timetable_--_2019-01, 1011350_1500_Timetable_--_2019-01 1, 1510_Timetable_--_2019-01, 1011400_1510_Timetable_--_2019-01 1, 1520_Timetable_--_2019-01, 1011410_1520_Timetable_--_2019-01 1, 1530_Timetable_--_2019-01, 1011420_1530_Timetable_--_2019-01 1, 1540_Timetable_--_2019-01, 1011430_1540_Timetable_--_2019-01 1, 1550_Timetable_--_2019-01, 1011440_1550_Timetable_--_2019-01 1, 1600_Timetable_--_2019-01, 1011450_1600_Timetable_--_2019-01 1, 1610_Timetable_--_2019-01, 1011500_1610_Timetable_--_2019-01 1, 1620_Timetable_--_2019-01, 1011510_1620_Timetable_--_2019-01 1, 1630_Timetable_--_2019-01, 1011520_1630_Timetable_--_2019-01 1, 1640_Timetable_--_2019-01, 1011530_1640_Timetable_--_2019-01 1, 1650_Timetable_--_2019-01, 1011540_1650_Timetable_--_2019-01 1, 1700_Timetable_--_2019-01, 1011550_1700_Timetable_--_2019-01 1, 1710_Timetable_--_2019-01, 1011600_1710_Timetable_--_2019-01 1, 1750_Timetable_--_2019-01, 1011640_1750_Timetable_--_2019-01 1, 1810_Timetable_--_2019-01, 1011700_1810_Timetable_--_2019-01 1, 1830_Timetable_--_2019-01, 1011720_1830_Timetable_--_2019-01 1, 1850_Timetable_--_2019-01, 1011740_1850_Timetable_--_2019-01 1, 1910_Timetable_--_2019-01, 1011800_1910_Timetable_--_2019-01 1, 1930_Timetable_--_2019-01, 1011820_1930_Timetable_--_2019-01 1, 1950_Timetable_--_2019-01, 1011840_1950_Timetable_--_2019-01 1, 2010_Timetable_--_2019-01, 1011900_2010_Timetable_--_2019-01 1, 2030_Timetable_--_2019-01, 1011920_2030_Timetable_--_2019-01 1, 2050_Timetable_--_2019-01, 1011940_2050_Timetable_--_2019-01 1, 2110_Timetable_--_2019-01, 1012000_2110_Timetable_--_2019-01 1, 2120_Timetable_--_2019-01, 1012010_2120_Timetable_--_2019-01 1, 2130_Timetable_--_2019-01, 1012020_2130_Timetable_--_2019-01 1, 2140_Timetable_--_2019-01, 1012030_2140_Timetable_--_2019-01 1, 2150_Timetable_--_2019-01, 1012040_2150_Timetable_--_2019-01 1, 2200_Timetable_--_2019-01, 1012050_2200_Timetable_--_2019-01 1, 2210_Timetable_--_2019-01, 1012100_2210_Timetable_--_2019-01 1, 2230_Timetable_--_2019-01, 1012120_2230_Timetable_--_2019-01 1, 0700_Timetable_--_2019-01, 001550_700_Timetable_--_2019-01 1, 0710_Timetable_--_2019-01, 001600_710_Timetable_--_2019-01 1, 0720_Timetable_--_2019-01, 001610_720_Timetable_--_2019-01 1, 0730_Timetable_--_2019-01, 001620_730_Timetable_--_2019-01 1, 0740_Timetable_--_2019-01, 001630_740_Timetable_--_2019-01 1, 0750_Timetable_--_2019-01, 001640_750_Timetable_--_2019-01 1, 0800_Timetable_--_2019-01, 001650_800_Timetable_--_2019-01 1, 0810_Timetable_--_2019-01, 001700_810_Timetable_--_2019-01 1, 0820_Timetable_--_2019-01, 001710_820_Timetable_--_2019-01
1, 0830_Timetable_--_2019-01, 001720_830_Timetable_--_2019-01 1, 0840_Timetable_--_2019-01, 001730_840_Timetable_--_2019-01 1, 0850_Timetable_--_2019-01, 001740_850_Timetable_--_2019-01 1, 0800_Timetable_--_2019-01, 001750_900_Timetable_--_2019-01 1, 0910_Timetable_--_2019-01, 001800_910_Timetable_--_2019-01 1, 0920_Timetable_--_2019-01, 001810_920_Timetable_--_2019-01 1, 0930_Timetable_--_2019-01, 001820_930_Timetable_--_2019-01 1, 0940_Timetable_--_2019-01, 001830_940_Timetable_--_2019-01 1, 0950_Timetable_--_2019-01, 001840_950_Timetable_--_2019-01 1, 01000_Timetable_--_2019-01, 001850_1000_Timetable_--_2019-01 1, 01010_Timetable_--_2019-01, 001900_1010_Timetable_--_2019-01 1, 01020_Timetable_--_2019-01, 001910_1020_Timetable_--_2019-01 1, 01030_Timetable_--_2019-01, 001920_1030_Timetable_--_2019-01 1, 01040_Timetable_--_2019-01, 001930_1040_Timetable_--_2019-01 1, 01050_Timetable_--_2019-01, 001940_1050_Timetable_--_2019-01 1, 01100_Timetable_--_2019-01, 001950_1100_Timetable_--_2019-01 1, 01110_Timetable_--_2019-01, 0011000_1110_Timetable_--_2019-01 1, 01130_Timetable_--_2019-01, 0011020_1130_Timetable_--_2019-01 1, 01150_Timetable_--_2019-01, 0011040_1150_Timetable_--_2019-01 1, 01210_Timetable_--_2019-01, 0011100_1210_Timetable_--_2019-01 1, 01230_Timetable_--_2019-01, 0011120_1230_Timetable_--_2019-01 1, 01250_Timetable_--_2019-01, 0011140_1250_Timetable_--_2019-01 1, 01310_Timetable_--_2019-01, 0011200_1310_Timetable_--_2019-01 1, 01330_Timetable_--_2019-01, 0011220_1330_Timetable_--_2019-01 1, 01350_Timetable_--_2019-01, 0011240_1350_Timetable_--_2019-01 1, 01410_Timetable_--_2019-01, 0011300_1410_Timetable_--_2019-01 1, 01420_Timetable_--_2019-01, 0011310_1420_Timetable_--_2019-01 1, 01430_Timetable_--_2019-01, 0011320_1430_Timetable_--_2019-01 1, 01440_Timetable_--_2019-01, 0011330_1440_Timetable_--_2019-01 1, 01450_Timetable_--_2019-01, 0011340_1450_Timetable_--_2019-01 1, 01500_Timetable_--_2019-01, 0011350_1500_Timetable_--_2019-01 1, 01510_Timetable_--_2019-01, 0011400_1510_Timetable_--_2019-01 1, 01520_Timetable_--_2019-01, 0011410_1520_Timetable_--_2019-01 1, 01530_Timetable_--_2019-01, 0011420_1530_Timetable_--_2019-01 1, 01540_Timetable_--_2019-01, 0011430_1540_Timetable_--_2019-01 1, 01550_Timetable_--_2019-01, 0011440_1550_Timetable_--_2019-01 1, 01600_Timetable_--_2019-01, 0011450_1600_Timetable_--_2019-01 1, 01610_Timetable_--_2019-01, 0011500_1610_Timetable_--_2019-01 1, 01620_Timetable_--_2019-01, 0011510_1620_Timetable_--_2019-01 1, 01630_Timetable_--_2019-01, 0011520_1630_Timetable_--_2019-01 1, 01640_Timetable_--_2019-01, 0011530_1640_Timetable_--_2019-01 1, 01650_Timetable_--_2019-01, 0011540_1650_Timetable_--_2019-01 1, 01700_Timetable_--_2019-01, 0011550_1700_Timetable_--_2019-01
1, 01710_Timetable_--_2019-01, 0011600_1710_Timetable_--_2019-01 1, 01750_Timetable_--_2019-01, 0011640_1750_Timetable_--_2019-01 1, 01810_Timetable_--_2019-01, 0011700_1810_Timetable_--_2019-01 1, 01830_Timetable_--_2019-01, 0011720_1830_Timetable_--_2019-01 1, 01850_Timetable_--_2019-01, 0011740_1850_Timetable_--_2019-01 1, 01910_Timetable_--_2019-01, 0011800_1910_Timetable_--_2019-01 1, 01930_Timetable_--_2019-01, 0011820_1930_Timetable_--_2019-01 1, 01950_Timetable_--_2019-01, 0011840_1950_Timetable_--_2019-01 1, 02010_Timetable_--_2019-01, 0011900_2010_Timetable_--_2019-01 1, 02030_Timetable_--_2019-01, 0011920_2030_Timetable_--_2019-01 1, 02050_Timetable_--_2019-01, 0011940_2050_Timetable_--_2019-01 1, 02110_Timetable_--_2019-01, 0012000_2110_Timetable_--_2019-01 1, 02120_Timetable_--_2019-01, 0012010_2120_Timetable_--_2019-01 1, 02130_Timetable_--_2019-01, 0012020_2130_Timetable_--_2019-01 1, 02140_Timetable_--_2019-01, 0012030_2140_Timetable_--_2019-01 1, 02150_Timetable_--_2019-01, 0012040_2150_Timetable_--_2019-01 1, 02200_Timetable_--_2019-01, 0012050_2200_Timetable_--_2019-01 1, 02210_Timetable_--_2019-01, 0012100_2210_Timetable_--_2019-01 1, 02230_Timetable_--_2019-01, 0012120_2230_Timetable_--_2019-01
stops.txt stop_id, stop_code, stop_name, stop_lat, stop_lon, location_type, wheelchair_boarding Gral Term1:1, 1, Terminal de Camiones Vicente Guerrero, 21.848902, -102.319622, 0, 0 Maes Cami1:1, 2, Av. de los Maestros - Camilo López,21.847298, -102.320171, 0, 0 Maes Baran1:1, 3, Av. de los Maestros - Barandales de San José, 21.844891, -102.322029, 0, 0 SiXXI Bode1:1, 4, Avenida Siglo XXI - Bodega Aurrerá Santa Mónica, 21.842834, -102.321841, 0, 0 SiXXI SanMo1:1, 5, Avenida Siglo XXI - Santa Monica, 21.842582, -102.316844, 0, 0 SiXXI Pante1:1, 6, Avenida Siglo XXI - Panteón San Francisco, 21.843731, -102.312764, 0, 0 SiXXI Oxxo1:1, 7, Avenida Siglo XXI - Oxxo Gas Cualli, 21.844904, -102.308338, 0, 0 SiXXI DolR1:1, 8, Avenida Siglo XXI - Dolores Del Río, 21.845488, -102.305053, 0, 0 Pilar Prol1_1:1, 9, Pilar Blanco - Prol. Paseo de la Asunción, 21.847021, -102.301243, 0, 0 Pilar Prol2_1:1, 10, Pilar Blanco - Prol. Paseo de la Asunción, 21.850157, -102.301036, 0, 0 Pilar Prol3_1:1, 11, Pilar Blanco - Prol. Paseo de la Asunción, 21.852397, -102.300823, 0, 0 Pilar Prol4_1:1, 12, Pilar Blanco - Prol. Paseo de la Asunción, 21.855403, -102.300817, 0, 0 Pilar Prol5_1:1, 13, Pilar Blanco - Prol. Paseo de la Asunción, 21.856226, -102.300658, 0, 0 Prol Paseo_1:1, 14, Prol Paseo de la Asunción - Nevado de Colima, 21.858879, -102.299629, 0, 0 AvAgsSur1:1, 15, Avenida Aguascalientes Sur - Prol Paseo de la Asunción, 21.859921, -102.299171, 0, 0 Quint Fray1:1, 16, Quinta Avenida - Fray Antonio de Segovia, 21.861551, -102.299916, 0, 0 Quint RepH1:1, 17, Quinta Avenida - República de Honduras, 21.863251, -102.298829, 0, 0 RepB RepG1:1, 18, República de Brasil - República de Guatemala, 21.865665, -102.299521, 0, 0 CentralCam1:1, 19, Central Camionera Aguascalientes, 21.866035, -102.298977, 0, 0 AvCon Quint1:1, 20, Av de la Convención de 1914 - Quinta Avenida, 21.865811, -102.297687, 0, 0 AvJos Clin1_1:1, 21, Av José Ma. Chávez - IMSS Zona 1, 21.866094, -102.294141, 0, 0 AvJos Her1:1, 22, Av José Ma. Chávez - Hernán González, 21.868342, -102.294518, 0, 0 AvJos Salon1:1, 23, Av José Ma. Chávez - Centro de Convenciones Medrano, 21.870678, -102.294912, 0, 0
AvJos AvCruz1:1, 24, Av José Ma. Chávez - Av Paseo de la Cruz, 21.871421, -102.295023, 0, 0 Chav Pimen1:1, 25, Av José Ma. Chávez - Pimentel, 21.875193, -102.294875, 0, 0 Chav Vicen1:1, 26, Av José Ma. Chávez - Profra. Vicenta Trujillo, 21.876502, -102.295194, 0, 0 5May ZCen1:1, 27, 5 de Mayo - Zona Centro, 21.884737, -102.297688, 0, 0 5May Mari1:1, 28, 5 de Mayo - Plaza del Mariachi, 21.887224, -102.296695, 0, 0 5May JesMa1:1, 29, 5 de Mayo - Jesús María, 21.889261, -102.295444, 0, 0 PetMex Enr1:1, 30, Petróleos Mexicanos - Gral. Enrique Estrada, 21.892725, -102.293659, 0, 0 Jose Barrag1:1, 31, Prof Jose Reyes Martinez - General Miguel Barragan, 21.896351, -102.291923, 0, 0 Barrag Alfred1:1, 32, General Miguel Barragan - Calle Alfredo Lewis, 21.899434, -102.292305, 0, 0 Zac Celso1:1, 33, Blvd. A Zacatecas - Celso Bernal, 21.903032, -102.292382, 0, 0 Zac Eba1:1, 34, Blvd. A Zacatecas - Ébano, 21.904559, -102.292337, 0, 0 Zac Agla1:1, 35, Blvd. A Zacatecas - Aglaya, 21.907435, -102.292227, 0, 0 Nacoz Nort1:1, 36, Av. Héroe de Nacozari Nte, 21.911552, -102.291545, 0, 0 Zac Altaria1:1, 37, Blvd. A Zacatecas - Centro Comercial Altaria, 21.924528, -102.291201, 0, 0 Zac Espec1_1:1, 38, Blvd. A Zacatecas - Pasteurizadora Aguascalientes, 21.929363, -102.291237, 0, 0 Zac Espec2_1:1, 39, Blvd. A Zacatecas - Duragas, 21.933354, -102.291051, 0, 0 Zac Espec3_1:1, 40, Blvd. A Zacatecas - San Francisco de los Romos, 21.942322, -102.290691, 0, 0 Zac Flex1:1, 41, Blvd. A Zacatecas - Flextronics, 21.961448, -102.289271, 0, 0 Carre45 Parq1:1, 42, Carretera Federal 45 - Parque Industrial, 21.966009, -102.289553, 0, 0 Carre45 Sfr1:1, 43, Carretera Federal 45 - San Francisco de los Romos, 21.969405, -102.289431, 0, 0 Carre45 Viñ1:1, 44, Carretera Federal 45 - Viñedos Rivier, 21.973318, -102.289231, 0, 0 Panam1:1, 45, Carretera Panamericana, 21.990386, -102.290761, 0, 0 Panam Buga1:1, 46, Carretera Panamericana - Bugambilia, 21.998119, -102.288154, 0, 0 Marg Port1:1, 47, Calle Paseo Margaritas - Paseos Gómez Portugal, 22.003071, -102.291168, 0, 0 GomeTerm1:1, 48, Terminal de Camiones Gómez Portugal, 22.001229, -102.295569, 0, 0 Marg Ant1:2, 49, Calle Paseo Margaritas - Calle Paseo San Antonio, 22.002467, -102.289374, 0, 0 Marg Port2_1:2, 50, Calle Paseo Margaritas - Paseos Gómez Portugal, 22.001401, -102.288511, 0, 0
Panam1:2, 51, Carretera Panamericana, 21.999081, -102.288491, 0, 0 Panam Mor1:2, 52, Carretera Panamericana - Morelos, 21.993331, -102.288709, 0, 0 Arge Real1:2, 53, Paseo de Argenta - Los Reales, 21.987991, -102.290013, 0, 0 Nagro San1:2, 54, Nuevo Agropecuario - Viñedos San Marcos, 21.969947, -102.289912, 0, 0 Zac Marav1:2, 55, Blvd. A Zacatecas - Calle Paseos de Maravillas, 21.968447, -102.290021, 0, 0 Venad Pase1:2, 56, Calle Paseos de Venaderos - Calle Paseo de Frutilandia, 21.963279, -102.292356, 0, 0 Flextronix1:2, 57, Flextronics, 21.960241, -102.29024, 0, 0 NiHer Zac1:2, 58, Av. Niños Heroes - Blvd. A Zacatecas, 21.938811, -102.29141, 0, 0 Zac Bode1:2, 59, Blvd. A Zacatecas - Mini bodegas GuardaBox, 21.933391, -102.291399, 0, 0 Luis Zac1:2, 60, Luis Gil - Blvd. A Zacatecas, 21.930933, -102.291932, 0, 0 Zac TrojeH1:2, 61, Blvd. A Zacatecas - Hotel Las Trojes, 21.926336, -102.291823, 0, 0 Zac Galer1:2, 62, Blvd. A Zacatecas - Galerias, 21.923876, -102.291981, 0, 0 Zac Agrope1:2, 63, Blvd. A Zacatecas - Agropecuario, 21.913825, -102.292272, 0, 0 Zac Plat1:2, 64, Blvd. A Zacatecas - El Plateado, 21.908305, -102.292428, 0, 0 Zac Eba1:2, 65, Blvd. A Zacatecas -Ébano, 21.904247, -102.292659, 0, 0 PetMex Lew1:2, 66, Petróleos Mexicanos - Calle Alfredo Lewis, 21.899338, -102.292568, 0, 0 PetMex Gert1:2, 67, Petróleos Mexicanos - Gertrudis Berkefer, 21.896516, -102.292983, 0, 0 PetMex Horn1:2, 68, Petróleos Mexicanos - Calle Privada Norberto Gómez Hornedo, 21.893517, -102.293187, 0, 0 PetMex GrAv1:2, 69, Petróleos Mexicanos - Gran Avenida, 21.892438, -102.293957, 0, 0 Mex Fresni1:2, 70, México - Fresnillo, 21.890351, -102.293908, 0, 0 JoMa Zarag1:2, 71, Gral. José María Artega - Calle Gral. Ignacio Zaragoza, 21.889383, -102.293862, 0, 0 JoMa Jard1:2, 72, Gral. José María Artega - Jardín de Zaragoza, 21.886806, -102.296544, 0, 0 JoPav Mer1:2, 73, José María Morelos y Pavon - Mercado Morelos, 21.884691, -102.295681, 0, 0 Diaz Acev1:2, 74, Dr Jesús Díaz de León - Antonio Acevedo E, 21.880077, -102.294179, 0, 0 Diaz Sol1:2, 75, Dr Jesús Díaz de León - Del Sol, 21.877746, -102.293392, 0, 0 Diaz Encino1:2, 76, Dr Jesús Díaz de León - Jardín del Encino, 21.875071, -102.292555, 0, 0 AvCr Colon1:2, 77, Av Paseo de la Cruz - Calle Cristobal Colon, 21.872444, -102.292382, 0, 0 AvJos Gand1:2, 78, Av José Ma. Chávez - Av Mahatma Gandhi, 21.870279, -102.295192, 0, 0
AvJos LeAgs1:2, 79, Av José Ma. Chávez - León Aguascalientes, 21.866991, -102.294622, 0, 0 AvConS AvJos1:2, 80, Av de la Convención de 1914 Sur - Av José Ma. Chávez, 21.865296, -102.293684, 0, 0 QuAve Guate1:2, 81, Quinta Avenida - República de Guatemala, 21.865448, -102.298288, 0, 0 QuAve RepM1:2, 82, Quinta Avenida - República Mexicana, 21.863204, -102.299232, 0, 0 Prol Nevado_1:2, 83, Prol Paseo de la Asunción - Nevado de Colima, 21.858916, -102.299469, 0, 0 Prol Diego1:2, 84, Prol Paseo de la Asunción - Prol. Diego Fernández Villa, 21.855972, -102.301123, 0, 0 Prol Oliva1:2, 85, Prol Paseo de la Asunción - Prof. Enrique Olivares Santana, 21.853423, -102.301211, 0, 0 Prol Marian1:2, 86, Prol Paseo de la Asunción - Av Dr Mariano Azuela, 21.851071, -102.301164, 0, 0 Prol Julian1:2, 87, Prol Paseo de la Asunción - Gral. Julián Medina, 21.847127, -102.301451, 0, 0 Prol SiXXI1:2, 88, Prol Paseo de la Asunción - Avenida Siglo XXI, 21.845615, -102.301619, 0, 0 SiXXI LazCar1:2, 89, Avenida Siglo XXI - Lázaro Cardenas, 21.844834, -102.310305, 0, 0 SiXXI Padua1:2, 90, Avenida Siglo XXI - Padua, 21.844246, -102.312324, 0, 0 SiXXI SanAnt1:2, 91, Avenida Siglo XXI - San Antonio, 21.842781, -102.31767, 0, 0 Maes Morel1:2, 92, Av. de los Maestros - Morelos, 21.846433, -102.320257, 0, 0 Maes Rev1:2, 93, Av. de los Maestros - Av Revolución, 21.848691, -102.319305, 0, 0 Cami Luis1:2, 94, Ing. Camilo Arriaga -Gral. Maclovio Herrera, 21.849711, -102.316358, 0, 0 Cact Term2:1, 95, Terminal de Camiones Valle de los Cactus, 21.865234, -102.228267, 0, 0 Bizna Juven2:1, 96, Paseo de la Biznaga - Juventino de Torre Torres, 21.866325, -102.230674, 0, 0 Bizna Salva2:1, 97, Paseo de la Biznaga - Salvador Ramírez Martín del Campo, 21.869864, -102.233306, 0, 0 Salva Garam2:1, 98, Salvador Ramírez Martín del Campo - Garambullo, 21.870546, -102.230523, 0, 0 Reci Lech2:1, 99, Recinto Pitayo - Lechugilla, 21.873864, -102.229874, 0, 0 JoVe2:1, 100, José Trinidad Velas Salas, 21.872504, -102.235461, 0, 0 RecinC Bizna2:1, 101, Recinto Cactus - Paseo de la Biznaga, 21.873147, -102.234935, 0, 0 Calix Proce2:1, 102, Calixto Serna Valdivia - Próceres de la Enseñanza, 21.873851, -102.238029, 0, 0
Proce Colla2:1, 103, Próceres de la Enseñanza - Felipe Collazo García, 21.872071, -102.237802, 0, 0 Proce Corral2:1, 104, Próceres de la Enseñanza - Carlos Corral Chavero, 21.869211, -102.237014, 0, 0 Proce SecT35_2:1, 105, Próceres de la Enseñanza - Escuela Secundaria Técnica No 35, 21.867899, -102.236691, 0, 0 Proce Adeli2:1, 106, Próceres de la Enseñanza - Adelina Hernández Reynoso, 21.866126, -102.236178, 0, 0 Hotel Pedra2:1, 107, Av Tecnológico - Motel Pedra, 21.866116, -102.239148, 0, 0 AvTec Segu2:1, 108, Av Tecnológico - Seguridad, 21.867751, -102.243576, 0, 0 SiXXI AvTec2:1, 109, Avenida Siglo XXI - Av Tecnológico, 21.866753, -102.245168, 0, 0 SiXXI Leo2:1, 110, Avenida Siglo XXI - Leonardo Murialdo, 21.862647, -102.248399, 0, 0 SiXXI Hosp2:1, 111, ISSEA Hospital General Tercer Milenio, 21.855815, -102.255011, 0, 0 SiXXI 22Dic2:1, 112, Avenida Siglo XXI - 22 de Diciembre, 21.854885, -102.259018, 0, 0 SiXXI Mayo2:1, 113, Avenida Siglo XXI - Mayo de 1812, 21.854479, -102.260499, 0, 0 SiXXI PrimaM2:1, 114, Avenida Siglo XXI - Escuela Primaria Mariano Jiménez, 21.853358, -102.265161, 0, 0 SiXXI AvHero2:1, 115, Avenida Siglo XXI - Av Heroe Inmortal, 21.852421, -102.268881, 0, 0 AvHero Artill2:1, 116, Av Heroe Inmortal - Artillero Mier, 21.854189, -102.269236, 0, 0 AvHero Sold2:1, 117, Av Heroe Inmortal - Soldado Insurgente, 21.856082, -102.269278, 0, 0 AvHero Caud2:1, 118, Av Heroe Inmortal - Caudillos, 21.858847, -102.269311, 0, 0 AvAgsS AvArq2:1, 119, Av Aguascalientes Sur - Av Arqueros, 21.860241, -102.269973, 0, 0 AvAgsS Mari2:1, 120, Av Aguascalientes Sur - Av. Gral. Mariano Escobedo, 21.860194, -102.273528, 0, 0 AvAgsS Coah2:1, 121, Av Aguascalientes Sur - Coahuila, 21.860269, -102.278285, 0, 0 AvAgs Naya2:1, 122, Av Aguascalientes - Nayarit, 21.860271, -102.280447, 0, 0 NacozS Casa2:1, 123, Av. Héroe de Nacozari Sur - Casa Blanca, 21.862769, -102.28251, 0, 0 NacozS Jesus2:1, 124, Av. Heroé de Nacozari Sur - Jesús Yurem, 21.864847, -102.282299, 0, 0 NacozS Salud2:1, 125, Av. Heroé de Nacozari Sur - La Salud, 21.867529, -102.281734, 0, 0 NacozS Funda2:1, 126, Av. Heroé de Nacozari Sur - Av De Los Fundadores, 21.870723, -102.281732, 0, 0
NacozS Norm2:1, 127, Av. Heroé de Nacozari Sur - Escuela Normal de Aguascalientes, 21.873255, -102.281521, 0, 0 NacozS Milit2:1, 128, Av. Heroé de Nacozari Sur - Servicio Militar, 21.875206, -102.281374, 0, 0 NacozS Crista2:1, 129, Av. Heroé de Nacozari Sur - Plaza Cristal, 21.878098, -102.281234, 0, 0 NacozN Dama2:1, 130, Av. Heroé de Nacozari Nte - Damasco, 21.881041, -102.282022, 0, 0 NacozN Arq2:1, 131, Av. Heroé de Nacozari Nte - Arq. J. Refugio Reyes, 21.884113, -102.282535, 0, 0 Madero Ejido2:1, 132, Av. Francisco I. Madero - Ejido, 21.884716, -102.283281, 0, 0 Madero Eze2:1, 133, Av. Francisco I. Madero - Nte. Ezequiel A. Chávez, 21.884021, -102.285704, 0, 0 Madero Cona2:1, 134, Av. Francisco I. Madero - Conalep José Refugio Esparza, 21.883559, -102.287433, 0, 0 Zarag Pag2:1, 135, Calle Gral. Ignacio Zaragoza - Página 24, 21.882985, -102.290369, 0, 0 Alvaro Zarag2:2, 136, Gral. Álvaro Obregón - Calle Gral. Ignacio Zaragoza, 21.886643, -102.293135, 0, 0 Alvaro Ramo2:2, 137, Gral. Álvaro Obregón - Ramón López Velarde, 21.885553, -102.294527, 0, 0 Benit Merca2:2, 138, Lic. Benito Juárez - Mercado Terán, 21.885027, -102.296642, 0, 0 Plate Conce2:2, 139, Plateros - J. Concepción Saucedo, 21.891673, -102.293343, 0, 0 Geron Barrag2:2, 140, Dr Geronimo de Orozco - General Miguel Barragan, 21.892704, -102.289413, 0, 0 Geron 20Nov2:2, 141, Dr Geronimo de Orozco - 20 de Noviembre, 21.893595, -102.286387, 0, 0 NacozN Geron2:2, 142, Av. Heroé de Nacozari Nte - Dr Geronimo de Orozco, 21.893555, -102.285756, 0, 0 NacozN Pino2:2, 143, Av. Heroé de Nacozari Nte - Pino Suárez, 21.889834, -102.284535, 0, 0 NacozN Vazq2:2, 144, Av. Heroé de Nacozari Nte - Vázquez del Mercado, 21.887247, -102.283659, 0, 0 NacozN Crista2:2, 145, Av. Heroé de Nacozari Sur - Plaza Cristal, 21.878219, -102.281488, 0, 0 NacozS Milit2:2, 146, Av. Heroé de Nacozari Sur - Servicio Militar, 21.874635, -102.281644, 0, 0 NacozS Norm2:2, 147, Av. Heroé de Nacozari Sur - Escuela Normal de Aguascalientes, 21.873083, -102.281745, 0, 0 NacozS Funda2:2, 148, Av. Heroé de Nacozari Sur - Av De Los Fundadores, 21.870794, -102.281928, 0, 0 NacozS Salud2:2, 149, Av. Heroé de Nacozari Sur - La Salud, 21.867404, -102.281928, 0, 0
NacozS Fuente2:2, 150, Av. Heroé de Nacozari Sur - Fuente del Ebro, 21.865106, -102.282563, 0, 0 AvAgsS Tamau2:2, 151, Av Aguascalientes Sur - Tamaulipas, 21.860022, -102.280882, 0, 0 AvAgss Coah2:2, 152,Av Aguascalientes Sur - Coahuila, 21.859915, -102.278283, 0, 0 AvAgsS Mari2:2, 153, Av Aguascalientes Sur - Av. Gral. Mariano Escobedo, 21.859839, -102.274985, 0, 0 AvHero Caud2:2, 154, Av Heroe Inmortal - Caudillos, 21.859524, -102.269546, 0, 0 AvHero Sold2:2, 155, Av Heroe Inmortal - Soldado Insurgente, 21.855646, -102.269485, 0, 0 AvHero Pedr2:2, 156, Av Heroe Inmortal - Pedro Ascencio, 21.853019, -102.269449, 0, 0 SiXXI Fonapo2:2, 157, Avenida Siglo XXI - Parque FONAPO II, 21.852702, -102.266038, 0, 0 SiXXI Herma2:2, 158, Avenida Siglo XXI - Hermanos Galeana, 21.853429, -102.262951, 0, 0 SiXXI Marian2:2, 159, Avenida Siglo XXI - Av Mariano Hidalgo, 21.854877, -102.257251, 0, 0 SiXXI Hosp2:2, 160, ISSEA Hospital General Tercer Milenio, 21.855508, -102.254664, 0, 0 SiXXI MariSa2:2, 161, Avenida Siglo XXI - Mariano Salas, 21.862121, -102.248219, 0, 0 SiXXI Mixton2:2, 162, Avenida Siglo XXI - Cerro del Mixtón, 21.864292, -102.247047, 0, 0 SiXXI Tecuex2:2, 163, Avenida Siglo XXI - Tecuexe, 21.866162, -102.242453, 0, 0 AvTec PalMex2:2, 164, Av Tecnológico - Palma Mexicana, 21.866017, -102.240112, 0, 0 Proce Anto2:2, 165, Próceres de la Enseñanza - Antonio Leal y Romero, 21.866148, -102.235591, 0, 0 Proce Salud2:2, 166, Próceres de la Enseñanza - Salud, 21.867791, -102.236033, 0, 0 Proce Corral2:2, 167, Próceres de la Enseñanza - Carlos Corral Chavero, 21.869384, -102.236487, 0, 0 Proce Colla2:2, 168, Póceres de la Enseñanza - Felipe Collazo García, 21.872139, -102.237241, 0, 0 RecinC Bizna2:2, 169, Recinto Cactus - Paseo de la Biznaga, 21.873868, -102.235339, 0, 0 JoVe2:2, 170, José Trinidad Velas Salas, 21.873554, -102.233317, 0, 0 Salva Garam2:2, 171, Salvador Ramírez Martín del Campo - Garambullo, 21.870366, -102.230788, 0, 0 Campo Bizna2:2, 172, Salvador Ramírez Martín del Campo - Biznaga, 21.870005, -102.233185, 0, 0 Bizna Juven2:2, 173, Paseo de la Biznaga - Juventino de Torre Torres, 21.866224, -102.230721, 0, 0
AvSoto Bizna2:2, 174, Av Sotol - Paseo de la Biznaga, 21.864427, -102.228967, 0, 0 Monica Term3:1, 175, Terminal de Camiones Santa Comiones, 21.846377, -102.288918, 0, 0 Maha Prima3:1, 176, Av Mahatma Gandhi - Escuela Primaria Niños Heroes, 21.827369, -102.293764, 0, 0 Maha Enri3:1, 177, Av Mahatma Gandhi - Enrique Olivares Santana, 21.829541, -102.293615, 0, 0 Maha Abast3:1, 178, Av Mahatma Gandhi - Central de Abastos, 21.832781, -102.293433, 0, 0 Maha Casas3:1, 179, Av Mahatma Gandhi - San Cristóbal de las Casas, 21.840154, -102.293392, 0, 0 Maha Rabasa3:1, 180, Av Mahatma Gandhi - Emilio Rabasa, 21.842173, -102.293429, 0, 0 Maha Girasol3:1, 181, Av Mahatma Gandhi - Centro de Desarrollo Infantil Girasol, 21.845746, -102.293587, 0, 0 Maha Villas3:1, 182, Av Mahatma Gandhi - Centro Comercial Villa Asunción, 21.849691, -102.293811, 0, 0 Aguila Buho3:1, 183, Blvd. Aguila - Del Búho, 21.849904, -102.299101, 0, 0 Prol Aguila3:1, 184, Prol Paseo de la Asunción - Blvd. Aguila, 21.849899, -102.301011, 0, 0 Prol Avest3:1, 185, Prol Paseo de la Asunción - Avestruz, 21.852406, -102.300789, 0, 0 Prof Fernan3:1, 186, Prof. Enrique Olivares Santana - Prol. Diego Fernández Villa, 21.855053, -102.304138, 0, 0 Prof Rebsa3:1, 187, Prof. Enrique Olivares Santana - Enrique C. Rébsamen, 21.857449, -102.304953, 0, 0 AvAgsS Col3:1, 188, Av Aguascalientes Sur - La Colonial, 21.858931, -102.304176, 0, 0 NacozN Berna3:1, 189, Av. Heroé de Nacozari Nte - Celso Bernal, 21.902569, -102.288564, 0, 0 NacozN Ferro3:1, 190, Av. Heroé de Nacozari Nte - Ferrocarril, 21.904461, -102.289141, 0, 0 NacozN Agla3:1, 191, Av. Heroé de Nacozari Nte - Aglaya, 21.907391, -102.290156, 0, 0 NacozN Talia3:1, 192, Av. Heroé de Nacozari Nte - Talia, 21.909286, -102.290797, 0, 0 NacozN Agrop3:1, 193, Av. Heroé de Nacozari Nte - Agropecuario, 21.911539, -102.291586, 0, 0 AvAgsN Mazda3:1, 194, Av Aguascalientes Nte - Prol Paseo de la Asunción, 21.915193, -102.290437, 0, 0 Consti AvAgsN3:1, 195, Av Constitución - Av Aguascalientes Nte, 21.916513, -102.286129, 0, 0 Consti GasPem3:1, 196, Av Constitución - Gasolineria Pemex, 21.921019, -102.285332, 0, 0 Consti Platino3:1, 197, Av Constitución - Pozo de Platino, 21.925606, -102.284303, 0, 0
ANEXO C – Consultas al servidor OBA
Información sobre la agencia
http://localhost:8080/api/where/agencies-with-coverage.json?key=TEST
{"code":200,
"currentTime":1560096914600,
"data":{
"limitExceeded":false,
"list":[
{"agencyId":"Coordinación General de Movilidad",
"lat":21.9228265,
"latSpan":0.16048899999999833,
"lon":-102.3050915,
"lonSpan":0.03387499999999477}],
"references":{
"agencies":[
{"disclaimer":"",
"email":"",
"fareUrl":"",
"id":"Coordinación General de Movilidad",
"lang":"es",
"name":"Coordinación General de Movilidad",
"phone":"",
"privateService":false,
"timezone":"America/Mexico_City",
"url":"http://www.aguascalientes.gob.mx/CMOV/"}
],
"routes":[],"situations":[],"stops":[],"trips":[]}},"text":"OK","version":2}
URL para obtener rutas cercanas a la localización mediante coordenadas
http://localhost:8080/api/where/stops-for-location.xml?key=TEST&lat=21.880559&lon=-
102.294478
<version>2</version> <code>200</code> <currentTime>1560142954966</currentTime> <text>OK</text> <data class="org.onebusaway.api.model.transit.ListWithRangeAndReferencesBean"> <references> <agencies> <org.onebusaway.api.model.transit.AgencyV2Bean>
<id>Coordinación General de Movilidad</id> <name>Coordinación General de Movilidad</name> <url>http://www.aguascalientes.gob.mx/CMOV/</url> <timezone>America/Mexico_City</timezone> <lang>es</lang> <privateService>false</privateService> </org.onebusaway.api.model.transit.AgencyV2Bean> </agencies> <routes> <org.onebusaway.api.model.transit.RouteV2Bean> <id>Coordinación General de Movilidad_1</id> <shortName>Vice</shortName> <longName>Vicente Guerrero - Gómez Portugal</longName> <type>3</type> <agencyId>Coordinación General de Movilidad</agencyId> </org.onebusaway.api.model.transit.RouteV2Bean> <org.onebusaway.api.model.transit.RouteV2Bean> <id>Coordinación General de Movilidad_1B</id> <shortName>Gomez</shortName> <longName>Gómez Portugal - Vicente Guerrero</longName> <type>3</type> <agencyId>Coordinación General de Movilidad</agencyId> </org.onebusaway.api.model.transit.RouteV2Bean> </routes> </references> <list> <org.onebusaway.api.model.transit.StopV2Bean> <id>Coordinación General de Movilidad_5May ZCen1:1</id> <lat>21.884737</lat> <lon>-102.297688</lon> <name>5 de Mayo - Zona Centro</name> <code>27</code> <locationType>0</locationType> <wheelchairBoarding>UNKNOWN</wheelchairBoarding> <routeIds> <string>Coordinación General de Movilidad_1</string> </routeIds> </org.onebusaway.api.model.transit.StopV2Bean> <org.onebusaway.api.model.transit.StopV2Bean> <id>Coordinación General de Movilidad_Chav Vicen1:1</id> <lat>21.876502</lat> <lon>-102.295194</lon> <name>Av José Ma. Chávez - Profra. Vicenta Trujillo</name> <code>26</code> <locationType>0</locationType> <wheelchairBoarding>UNKNOWN</wheelchairBoarding> <routeIds>
<string>Coordinación General de Movilidad_1</string> </routeIds> </org.onebusaway.api.model.transit.StopV2Bean> <org.onebusaway.api.model.transit.StopV2Bean> <id>Coordinación General de Movilidad_Diaz Acev1:2</id> <lat>21.880077</lat> <lon>-102.294179</lon> <name>Dr Jesús DÃaz de León - Antonio Acevedo E</name> <code>74</code> <locationType>0</locationType> <wheelchairBoarding>UNKNOWN</wheelchairBoarding> <routeIds> <string>Coordinación General de Movilidad_1B</string> </routeIds> </org.onebusaway.api.model.transit.StopV2Bean> <org.onebusaway.api.model.transit.StopV2Bean> <id>Coordinación General de Movilidad_Diaz Sol1:2</id> <lat>21.877746</lat> <lon>-102.293392</lon> <name>Dr Jesús DÃaz de León - Del Sol</name> <code>75</code> <locationType>0</locationType> <wheelchairBoarding>UNKNOWN</wheelchairBoarding> <routeIds> <string>Coordinación General de Movilidad_1B</string> </routeIds> </org.onebusaway.api.model.transit.StopV2Bean> <org.onebusaway.api.model.transit.StopV2Bean> <id>Coordinación General de Movilidad_JoPav Mer1:2</id> <lat>21.884691</lat> <lon>-102.295681</lon> <name>José MarÃa Morelos y Pavon - Mercado Morelos</name> <code>73</code> <locationType>0</locationType> <wheelchairBoarding>UNKNOWN</wheelchairBoarding> <routeIds> <string>Coordinación General de Movilidad_1B</string> </routeIds> </org.onebusaway.api.model.transit.StopV2Bean> </list> <limitExceeded>false</limitExceeded> <outOfRange>false</outOfRange> </data> </org.onebusaway.api.model.ResponseBean>
ANEXO D – Acceso a multirregión en servidor OBA
Acceso al cuestionario:
https://docs.google.com/spreadsheets/d/11WpYOQn__NDjtvWgW0tjyqeLFoqxnZmmjklF9yP9ioU/edit#gid=1
Region_Name Aguascalientes (Beta)
OBA_Base_URL http://52.88.188.196:8080/api
SIRI_Base_URL N/A
Bounds 27.976910:82.445:0.5424:0.5763|21.230:82.841:0.24994:0.5632
Language es
Contact_Email [email protected]
Supports_OBA_Discovery_APIs?
TRUE
Supports_OBA_Realtime_APIs?
TRUE
Supports_SIRI_Realtime_APIs?
FALSE
Active? TRUE
OBA_Version_Info 1.1.8 SNAPSHOT|1|1|8|SNAPSHOT|877d870ac5c5f64607113d08d6d362925839719e
Twitter_URL (Optional) The URL of the Twitter feed for the region (e.g., http://mobile.twitter.com/onebusaway). This URL will be accessible to users in the "Contact Us" portion of the apps, where they will be directed to this Twitter page in a web browser or mobile Twitter app.
Experimental? TRUE
Supports_Embedded_Social?
FALSE
ANEXO E – Articulo: Modelo para la implementación de Transporte Público Inteligente basado en la arquitectura Smart City y utilizando las herramientas de Cloud Computing.
Modelo para la implementación de Transporte Público
Inteligente basado en la arquitectura Smart City y
utilizando las herramientas de Cloud Computing
Raul Alejandro Velasquez Ortiz 1, Francisco Javier Álvarez Rodríguez 2 y Julio
Cesar Ponce Gallegos 3
1 Universidad Autónoma de Aguascalientes, Departamento de ciencia de la
computación. Av. Universidad, Ciudad Universitaria, C.P: 20131, Aguascalientes,
Aguascalientes, [email protected] 2 Universidad Autónoma de Aguascalientes, Departamento de ciencia de la
computación. Av. Universidad, Ciudad Universitaria, C.P: 20131, Aguascalientes,
Aguascalientes, [email protected] 3 Universidad Autónoma de Aguascalientes, Departamento de ciencia de la
computación. Av. Universidad, Ciudad Universitaria, C.P: 20131, Aguascalientes,
Aguascalientes, [email protected]
Resumen. Uno de los elementos más importantes de una ciudad es la
movilidad y por lo tanto el uso e integración de un transporte publico
inteligente se requiere para hacer posible la transición a una Ciudad
Inteligente (Smart City). Actualmente, con la falta de un sistema de
información apropiado en el sistema de transporte, los usuarios se ven en la
necesidad de esperar demasiado tiempo ya que desconocen cuando arribara
un autobús. Optimizar el servicio de transporte público en la ciudad de
Aguascalientes por medio del desarrollo de una aplicación inteligente y
proponer un sistema el cual localice la posición actual de los autobuses por
medio de GPS se hace necesario. Por lo tanto y como objetivo principal de
este artículo es presentar un modelo preliminar para la transición a transporte
inteligente mezclando las herramientas de cloud computing y sus
prestaciones, así como arquitectura de Smart Cities.
Abstract. One of the most important elements of a city is mobility and
therefore the use and integration of intelligent public transport is required to
make the transition to a Smart City possible. Currently, with the lack of an
appropriate information system in the transportation system, users are forced
to wait too long because they do not know when a bus will arrive. Optimising
the public transport service in the city of Aguascalientes by developing an
intelligent application and proposing a system which locates the current
position of buses by means of GPS becomes necessary. Therefore, the main
objective of this article is to present a preliminary model for the transition to
intelligent transport by mixing cloud computing tools and their features and
the architecture of Smart Cities.
Palabras Claves: Smart Cities, Cloud Computing, Transporte Inteligente,
Smart Mobility, Software as a Service.
1 Introducción
En términos generales Smart City (SC) es una región urbana enriquecida con la
tecnología más reciente que utiliza sus recursos para generar comunicación fiable y
seguridad inteligente. Así mismo la construcción de una SC debe considerarse a partir
de aspectos como lo son la sostenibilidad ambiental, la viabilidad económica y la
igualdad social. La meta más importante al construir una SC es mejorar la calidad de
vida y no solo de sus habitantes sino de sus servicios, ofertándolos y entregándolos
con el uso de la tecnología, mejorando no solo la gestión de estos, sino otorgando
una mayor flexibilidad y control sobre los mismos. (Vakula & Raviteja, 2017).
Smart City como lo menciona (Strasser & Albayrak, 2016) se relaciona con
Internet of Things and Services (IoTS), donde se pretende facilitar el acceso a los
datos que pueden ser incorporados a las aplicaciones inteligentes lo cual contribuye
a la disminución de problemas relacionados con transporte.
Los principales sectores donde SC aplica su mejora varían desde el área de
movilidad inteligente, economía inteligente, ambiente inteligente y gobierno
inteligente, siendo el área de movilidad, la premisa a mejorar. Así mismo para obtener
la información que dispongan estos recursos se ocupa aplicar técnicas que puedan
generar información puntual por lo cual el uso de una arquitectura es crucial para
establecer ese intercambio de datos, siendo esta la de Cloud Computing y en
específico la plataforma de Software as a Service (SaaS), como lo indica
(Kyriazopoulou, 2015).
Si bien el desarrollo de aplicaciones inteligentes para el área de transporte
inteligente es variado, pocas han sido orientadas al área de servicio usando SaaS
como su eje principal. La importancia de estas aplicaciones radica no solo en la
interaccione entre los usuarios y servicios sino en la disminución de una brecha
digital existente.
El propósito de este artículo es discutir el uso de una arquitectura, que, una vez
establecido sus parámetros de servicios, pueden generar la construcción de un modelo
preliminar y pertinente para el desarrollo de una SC de una manera confiable y
funcional siguiendo al mismo tiempo las plataformas de SaaS. La sección 2 presenta
el estado del arto de la investigación, dando a conocer los resultados recientes de
diferentes tipos de investigaciones. La sección 3 incluirá la metodología encargada
de generar un modelo inicial sobre el cual se realizará la transición a SC y con el cual
se desarrollará la aplicación. La sección 4 contara con resultados del método
generado. Por último, la sección 5 mostrara las conclusiones y resultados encontrados
y sugerencias del trabajo de investigación a futuro.
2 Estado del arte
En (Faria, Brito, Baras, & Silva, 2017), los autores realizaron un trabajo en
Madeira Interactive Technologies Institute el cual indica la importancia sobre la
implementación de Smart Cities, y a su vez el uso de Smart Mobility, dirigido hacia
el diverso uso del transporte, optimizándolo y provocando un transporte inteligente
que pueda resolver las necesidad de la población así como problemas que van desde
la innovación tráfico y el desarrollo de una infraestructura para el trasporte.
La investigación indica diversos proyectos factibles para la solución de diversos
problemas de transporte tales como en la ciudad de Berlin/Wolfsburg, en donde la
ciudad se ha instalado una red WLAN que sirve para rastrear las unidades de
transporte publica si como estaciones de bicicletas en tiempo real. Así mismo se
indica el desarrollo de una aplicación para el rastreo de ciclistas, a través de una
aplicación desarrollada en la plataforma Android con la finalidad de obtener
localización, velocidad y dirección vía GPS. Los teléfonos se sincronizaron a su vez
con las luces del semáforo y el objetivo de dicha aplicación es rastrear que ciclistas
cruzan estos semáforos.
Así mismo como indica (Vakula & Raviteja, 2017), indica que así como han
crecido el número de vehículos para servicio de la sociedad, el transporte público es
el dominante y sugiere aplicaciones inteligentes para la solución en el área de
transporte de una ciudad tales como:
➢ Billetes inteligentes y cobro automático de tarifas
➢ Autobuses y paradas inteligentes basados en GPS
➢ Sistemas de autobuses de transito rápido.
Siendo en este sentido de gran relevancia para la investigación actual, ya que,
según el autor, son áreas que requieren de una mayor atención y sobre todo de
soluciones que deben ser implementadas puntualmente.
De igual manera y no menos importante, (Wieclaw et al., 2017) nos indica que los
proyectos con soluciones complejas requieren estrategias aplicadas desde un enfoque
destinado a Cloud Computing y así mismo se debe considerar como una plataforma
para ofrecer y desplegar los servicios de SC. Así mismo nos indica los diferentes
niveles que interactúan, siendo SaaS el nivel más importante pues es el punto más
alto donde el usuario consume los servicios prestados por el proveedor.
En el uso de Cloud Computing y su interacción con sistemas de transporte
inteligente, como lo precisa la investigación (Marrero-Almonte, Marin-Tordera,
Masip-Bruin, & Sanchez-Lopez, 2015) con el fin de ofrecer funciones de cloud
computing más adaptables y eficientes a los sistemas de transporte inteligente, se
propuso una arquitectura que facilita el suministro de aplicaciones y servicios de
contenido a los usuarios de transportes así como la personalización del mismo.
Cloud computing puede proporcionar varios beneficios como escalabilidad,
confiabilidad, elasticidad y recursos compartidos. Sin embargo, menciona que las
ciudades deben mejorar su infraestructura existente e invertir en el desarrollo de
métodos innovadores para ampliar las posibilidades de acceso a los contenidos
pertinentes y a una amplia variedad de aplicaciones o servicios existentes, así como
a nuevos a través de tecnología emergente.
Como se puede ver con los diferente autores e investigaciones mencionadas el
crecimiento y mejora en el área de transporte inteligente va en incremento de manera
relevante.
3 Metodología utilizada
3.1 Modelación de factores para transición a Smart City.
En esta sección una versión preliminar del modelado de transporte inteligente será
descrito. Según (Wieclaw et al., 2017) Smart Cities debe contemplar tres niveles de
su arquitectura para generar esta transición y estas según el autor son las siguientes:
➢ Nivel 1. En este nivel se enfoca en las diferentes recursos y servicios que
ofrece la ciudad y que pueden ser gestionados a través de dispositivos como
sensores de celulares o dispositivos especiales.
➢ Nivel 2. Este nivel es el intermediario de procesar la información de manera
analítica con técnicas de Cloud Computing por mencionar algunas y de
igual manera se encarga de la gestión y actualización de información. Es la
capa más importante, necesaria e innovadora para la transición a Smart
Cities.
➢ Nivel 3. Portales de información que contienen y desplieguen la
presentación de los datos, conteniendo interfaces e interacción con la
implementación de los servicios digitalizados.
Para el correcto funcionamiento de esta primera versión del modelo, los siguientes
puntos son considerados. La Fig. 1 detalla la construcción del modelado.
Fig 1. Factores para la transicion a Transporte Inteligente.
Se identificaron los tres factores principales para la generación una transición
hacia un Transporte Publico Inteligente. El primer factor es la optimización de
servicio el cual permite un mejor entendimiento del comportamiento del usuario
Accesibilidad
Disponibilidad de datos
Optimización de rutas
Generar cambios
según demanda
Clase social
Facilidad de uso
Optimización de Servicio
Personalización de Servicio
Aceptación Social
dentro del sistema de transporte urbano. El segundo factor es la personalización de
servicio en la cual el usuario podrá monitorear la infraestructura y la entrega del
servicio. Y por último el factor de aceptación social y la necesidad de adaptación de
la plataforma tecnológica de servicio y la facilidad en su uso. En la Fig. 1 se puede
apreciar el modelado de transición propuesto.
3.2 Modelación de los niveles implementando Cloud Computing.
Como se observa en la Fig.2 los elementos que se toman en cuenta para la
transición de a Smart Cities desde un enfoque dirigido a servicio y según el autor
(Wieclaw et al., 2017) son los siguientes:
Fig 2. Elementos de SaaS para Smart Cities.
Los elementos mostrados anteriormente sobre SaaS se interrelacionan con los
niveles de arquitectura ya expuestos generando un enfoque dirigido a servicios.
Como se observa en la Fig. 3 los diferentes niveles logran relacionarse con los
elementos de SaaS. El nivel de optimización de servicio se relaciona con
directamente a la mejora del servicio de transporte mediante la ubicación y
posicionamiento de los autobuses. El segundo nivel, personalización de servicio se
relaciona con la visualización de SaaS, los servicios online reflejados al usuario y la
manera como pueden interactuar con ellos a partir de la plataforma dedicada para ese
fin. Por último, el nivel de Aceptación social, relacionada con el elemento de
informes de SaaS, los cuales llevaran registro de parte del usuario sobre la facilidad
de uso de la herramienta, así como su confiabilidad en la misma en la cuestión de que
se reciba información puntual.
Fig 3. Modelación de los niveles de servicio.
Como se aprecia estos elementos, una vez relacionados con la parte de Cloud
Computing y SaaS en específico, se puede plantear a partir de estos modelos, un
modelo general para realizar la transición a un sistema de transporte urbano
inteligente el cual se definirá en la siguiente sección de resultados.
4 Resultados
En esta sección el desempeño de la modelación inicial propuesto y sus diferentes
entradas son probadas, en este caso los servicios que debe cumplirse para generar un
trasporte público inteligente. Diferentes escenarios son considerados como se puede
apreciar en la Fig. 4. donde se expone claramente el modelo sobre el cual se
implementará el uso de un transporte inteligente.
Es importante primeramente definir cuáles son los servicios que ofrece un
transporte inteligente y como estos son proporcionados. Como se observa y además
de la capa de servicios y los factores de transición hacia un transporte inteligente que
la componen, se pueden identificar cuatro tipos de áreas o clientes para el transporte
urbano inteligente y estos son: seguimiento, aseguramiento de calidad de datos,
estandarización y accesibilidad de datos. Con estos elementos podemos identificar
cuales servicios de transporte urbano inteligente se proporcionan a la capa de
servicios. El primero es seguimiento el cual es dirigido al usuario y gestores de
servicio para llevar un control de una correcta distribución de los servicios. La
segunda es aseguramiento de calidad de datos, generada para poder ser capaz de
realizar cambios dependiendo de la demanda y otorgando calidad en los mismos. El
tercero es estandarización, el cual establece los protocolos de intercambio de
información y facilita el intercambio de esta. La cuarta es accesibilidad de los datos,
el cual hace referencia al acceso de información de las diferentes rutas a través de la
aplicación.
Fig 4. Modelo de uso de las TIC’s para el mejoramiento de y monitoreo de Sistemas de
Transporte Urbano Inteligente (Elaboración del autor).
Estos servicios a su vez son procesados por la parte de Cloud Computing, como
se observa y estos en conjunto realizan la virtualización, parte fundamental para la
transición requerida en Smart Cities. En primer lugar, se encuentra SaaS, que es el
nivel en el que se enfoca al software que proporcionara el servicio a los usuarios. En
según lugar DaaS es la virtualización a un nivel de arquitectura de los servicios. En
tercer lugar, se encuentra PaaS la cual permitirá el funcionamiento de la aplicación a
implementar y que los servicios se encuentren disponibles en internet. Por último,
IaaS otorgara una infraestructura con acceso directo a la nube, virtualizando la parte
de hardware. Estos elementos de Cloud Computing están presentes durante todo el
modelo y su construcción, y en constante mejora continua del mismo. No se deben
de aislar ningún elemento de Cloud Computing del modelo.
Transporte
Urbano
Inteligente
Optimización de
Servicio
Personalización
del Servicio
Aceptación
Social
Seguimiento
Aseguramiento
de calidad de
datos
Accesibilidad en
los datos
Mejora Continua
SaaS
DaaS
PaaS
IaaS
Estandarización
Cloud Computing
Servicios
basados en
Cloud para S.C.
Servicios
5 Conclusiones y pautas para futura investigación
En este artículo propusimos un modelo inicial para la construcción de una Smart City utilizando los elementos claves tales como la arquitectura y su plataforma SaaS de Cloud Computing. Este articulo logra otorgar un enfoque a la arquitectura del modelo para la generación de transporte urbano inteligente así mismo ilustrando su importancia y soluciones ofrecidas una vez se apliquen al desarrollo de una aplicación al área informática. El trabajo destinado para un futuro es llevar a un grado de madurez más sólido al modelo y desarrollando en conjunto una aplicación que siga la métrica establecido por el mismo modelo ya mencionado. Como una fase inicial, el modelo es claro y ayuda a entender la unión de los servicios hacia la conversión inteligente de los mencionados. Agradecimientos. Agradecemos a los evaluadores por sus pertinentes observaciones, así como CONACYT y a la Universidad Autónoma de Aguascalientes por el financiamiento hacia esta investigación.
Referencias
Faria, R., Brito, L., Baras, K., & Silva, J. (2017, 10-13 July 2017). Smart mobility: A survey.
Paper presented at the 2017 International Conference on Internet of Things for the
Global Community (IoTGC).
Kyriazopoulou, C. (2015, 20-22 May 2015). Smart city technologies and architectures: A
literature review. Paper presented at the 2015 International Conference on Smart
Cities and Green ICT Systems (SMARTGREENS).
Marrero-Almonte, R., Marin-Tordera, E., Masip-Bruin, X., & Sanchez-Lopez, S. (2015, 17-
18 June 2015). Conceptual approach of a hierarchical cloud architecture for
intelligent transport systems. Paper presented at the 2015 14th Annual
Mediterranean Ad Hoc Networking Workshop (MED-HOC-NET).
Strasser, M., & Albayrak, S. (2016, 13-15 Sept. 2016). A pattern based feasibility study of
cloud computing for Smart Mobility solutions. Paper presented at the 2016 8th
International Workshop on Resilient Networks Design and Modeling (RNDM).
Vakula, D., & Raviteja, B. (2017, 7-8 Dec. 2017). Smart public transport for smart cities.
Paper presented at the 2017 International Conference on Intelligent Sustainable
Systems (ICISS).
Wieclaw, L., Pasichnyk, V., Kunanets, N., Duda, O., Matsiuk, O., & Falat, P. (2017, 21-23
Sept. 2017). Cloud computing technologies in “smart city” projects. Paper presented
at the 2017 9th IEEE International Conference on Intelligent Data Acquisition and
Advanced Computing Systems: Technology and Applications (IDAACS).
ANEXO F – Articulo Modelo para la implementación de Transporte Público Inteligente basado en la arquitectura Smart City y utilizando las herramientas de Cloud Computing aceptado en congreso ANIEI 2018.
ANEXO G – Constancia de participación en congreso ANIEI 2018 con el articulo Modelo para la implementación de Transporte Público Inteligente basado en la arquitectura Smart City y utilizando las herramientas de Cloud Computing.
ANEXO H – Publicación del articulo Modelo para la implementación de Transporte Público Inteligente basado en la arquitectura Smart City y utilizando las herramientas de Cloud Computing en libro electrónico de memorias CNCIIC2018 del congreso ANIEI 2018.
Enlace de consulta de libro de memorias: http://www.aniei.org.mx/Archivos/Memorias/L_Electronico_CNCIIC2018.pdf
ANEXO I – Articulo: Mapping of the transport system of the city of Aguascalientes using GTFS Data for the generation of Intelligent Transport based on the Smart Cities paradigm.
Mapping of the transport system of the city of Aguascalientes using GTFS Data for the generation of
Intelligent Transport based on the Smart Cities paradigm
Raul Alejandro Velasquez Ortiz 1, Francisco Javier Álvarez Rodríguez 2, Miguel Vargas Martin3 y Julio Cesar Ponce Gallegos 4
1, 2, 4 Universidad Autónoma de Aguascalientes, Departamento de Ciencias de la Computación. Av.
Universidad, Ciudad Universitaria, C.P: 20131, Aguascalientes, Aguascalientes. México. 1 [email protected], 2 [email protected], 4
3 Ontoario Tech University, Faculty of Business and Information Technology. 2000 Simcoe Street North, Oshawa, Ontario L1G 0C5 Canada.
Abstract. The cities through the time have generated a great amount of services that in turn have facilitated the lifestyle of the population. These services have been able to connect through various electronic media, resulting in easier delivery of them and a massive consumption. That same growth of the cities technologically towards its services, generates an intelligent city. But the growth of the population, causes an even greater demand for service that causes new problems and challenges to offer them with the highest quality. The growth of the city of Aguascalientes has increased over time, complicating the way in which public transport service is provided, as it is not only used for the capital city but for some municipalities of the entity. Public transport does not have accurate and updated information, causing problems to locate a route in a given time, causing deficiency in the service for users, causing the way to use public transport is asking users for information on where to locate a route depending on where it is required to reach, achieving in the long term is not functional. The main objective of the article is to present a mapping where routes and stops will be established using the GTFS (General Transit Feed Specification) format defined in [1]. Generating finally an intelligent transport by means of applications and giving origin to a Smart City precise in [2] and consequently, generating an intelligent mobility system. Keywords: GTFS, GTFS-RT, Smart Mobility, Mapping, Smart City.
1 Introduction
Across several cities around the world, public transport has been of vital importance in providing a service to society for better mobility over long distances and support for those who do not have a vehicle of their own. However, cities such as Portland in the United States suffered from little information on the management and location of public transport, so in 2002, under the premise of locating this information through the Internet suggested by the computer manager of geographic information systems of the city mentioned above, Bibiana McHugh, and in collaboration with Google, developed a tool capable of managing traffic data. Google adapted it and called it GTFS (General Transit Feed Specification) which, from that moment, began to be implemented through various cities around the world as indicated in [3].
The large number of API's has facilitated the use and manipulation of GTFS generating a large increase in possibilities for the creation of applications for tracking public transport, whether buses, trains, etc., without the need to have a large amount of knowledge to make the programming of these tools.
The GTFS format is generated from a collection of 13 tables that allow the recording of information about bus units, being the most important tables agency, routes, trips, calendar, stop times and stops respectively. Each one of the tables requires attributes, for example, in the stops table the stop ID, stop name, stop latitude and stop longitude are required. These attributes allow programmers to identify the location of stops on Google Maps and tag them by ID and name and simplify the work of developing transportation planning applications as indicated in [1].
We will define the problems that the city of Aguascalientes suffers in the area of public transport, as well as the definition and use of the GTFS model that will be used for the mapping and subsequent update in Google Maps.
As the city of Aguascalientes does not have a stable and well-defined mobility model, it lacks a quality service in public transport, which has repercussions on the acceptance of users and consumers. The GTFS model to be implemented to transform public transport into an intelligent system will therefore be defined.
The city has a transportation system that has GPS technology but is not used for tracking units to inform users. It has an application that gives static information about the waiting times of a bus, but these times are variable because there is no control of departure and arrivals of the trips made by buses, generating that users do not have the real information of the journeys and therefore do not know the exact time of the trip of the unit.
Likewise, the schedules established in the public transport units are not carried out, causing problems of collection time at bus stops and therefore, waiting times ranging from 30 to 45 minutes of waiting per unit.
The purpose of this article is to define and build a Smart City in Aguascalientes starting with its public transport, transforming it into intelligent transport, which although the city's transit system is semi-formal or informal due to the scarce relationship that transport units
have with technology, is a more challenging work but possible to achieve. Section 2 will cover the state of the art and will focus on how in various cities with the same situation as the city of Aguascalientes and in even more complicated situations, it has been possible to generate applications from the inclusion of the GTFS to its transport database. It will also analyze the work done in Mexico City, being the first city in Mexico to implement GTFS to its transport systems. Section 3, methodology, it will indicate the different methods and techniques, as well as standards for the resolution of the problem detailed above. Section 4 will cover the results obtained and it will be possible to visualize the mapping by means of Google Maps from the GFTS files. To conclude, section 5 will give the relevant conclusions about the work, and the approach that will be taken for the future work, focused mainly on the construction of the application based on the GTFS files and the progressive transformation of the city of Aguascalientes to a Smart City.
2 State of art
In [4], the authors mention the importance of the GTFS format and its use with the various transport agencies or concessionaires as an option to offer interoperability is their transport system. The use of the model established by GTFS is simple to understand and, therefore, achievable in a short time. The ease of implementation, as well as the use of map technology such as Google Maps for the integration of GTFS tables, has facilitated the development of different databases around the world to record open data on public transport information in general, providing information on arrival time, location of routes, and optimal routes depending on the location of the user, facilitating the mobility of users.
Once GTFS was implemented in Portland, USA, a register of different transport agencies from different countries of the world was started to obtain a more intelligent and optimal transport. Countries such as Beijing, Paris, Bogota, Cleveland, to mention a few, transformed their transportation systems to the same format, radically changing the use of these as shown in [3]. This study succeeded in innovating, since previously it was very complicated to achieve a system that could plan public transportation trips through applications, and it was not until the creation of the standard already mentioned that a significant change was achieved. However, being a methodology of recent creation, at the time lacked tools for the development of applications.
Similarly, in 2016, Mexico City decided to implement the GTFS format to control and facilitate the use of public transport of its different transport companies. A work team was integrated in which academics, governments and society were dedicated to record the information they requested since the concessionaires had nothing digitized and the information was not very precise.
Based on the technology and the use of crowdsourcing methodology, they developed an application called Mapaton, with which the bus stops of the users would be registered, in a massive way, with the purpose of generating a reliable database to obtain this information.
After a week, the information was collected and could be recorded in such a way that they were able to make various applications for the management of public transport, whether buses, trains, or metro, to name a few. However, no proposal was made for the analysis of the data, because many users recorded erroneous locations, repeated or non-existent, generated a large amount of time in the analysis and validation of real data, which left the project with difficulties for implementation.
Mexico City when performing the Mapaton project achieved the registration of GFTS data and due to the size of the metropolis, this did not achieve the expected impact, due to the lack and little literature contained on the same subject. The project was completed, but more documentation is required to support it, as it could not be completed in its entirety, making the lack of information on GTFS implementation and its use noticeable. Its work would have been greatly simplified, using applications in charge of facilitating the verification of information capture, which in this sense, was carried out by users. Despite this, the proposal was interesting and managed to make a change that the other states of the Mexican Republic still do not make in their public transport.
Currently there are 1069 registered concessionaires that have implemented the GTFS model and 584 locations around the world that use it to manage their public transport, being from this, Mexico City, the only city within the Mexican Republic, which integrates and uses its public transport services from the GTFS format [5], generating at the same time intelligent mobility in their means of transport, which in turn enables the city as a Smart City as indicated in [6].
All the cities that have managed to implement transport services and transformed them have generated an intelligent mobility based on technology for the optimization of this one, in such a way that, as it was mentioned, they have managed to establish an intelligent city, particularly in the area of transport, which causes great changes that speed up and improve the quality of the services.
3 Methodology
This section will define the techniques and standards that will be used to solve the problem that the city of Aguascalientes suffers in the area of public transport, as well as the definition and use of the GTFS model that will be used for mapping and subsequent updating in Google Maps. As the city of Aguascalientes does not have a stable and well-defined mobility model, it lacks a quality service in public transport, which has repercussions on the acceptance of users and consumers. The GTFS model to be implemented to transform public transport into an intelligent system will therefore be defined.
The steps to consider are the implementation of the GTFS standard that is essential for the generation of schedules and position buses in order to generate a feed that can be used in the future in the development of applications, either own or third-party with free distribution. Also, the validation part, which is supported, is required to be displayed on Google Maps, which is a fundamental part of the solution.
Similarly, it requires the use of GTFS-RT that will define and execute GTFS data already implemented on maps with functions in real time, and this is a crucial point because it is necessary to achieve the objective of problem solving.
3.1 GTFS Static Model
The general model of GTFS contemplates 13 files or tables that conform the total of the format for its use, being 6 files necessary for its correct operation and 7 optional GTFS files. The official files of the GTFS format are: agency.txt, stops.txt, routes.txt, trips.txt, stop_times.txt, calendar.txt, calendar_dates.txt, fare_attributes.txt, fare_rules.txt, shapes.txt, frequencies.txt, transfers.txt y feed_into.txt. As shown in, the GTFS model required is the one that will be used to begin with the development of the mapping of the city of Aguascalientes (See Fig.1), as indicated in [7].
Fig. 1. Basic structure of the GTFS table model.
The consumption of the GTFS files are necessary for the real time validation of the route movements as well as the establishment of the stops. The city of Aguascalientes for the moment reflects the minimum use of GTFS files because it requires a digitization of services as soon as possible and that is available to everyone, in this case, being published to Google maps as it establishes [9].
The defined structure suggests how the different files communicate with each other, by means of established IDs, this to reflect the proper communication between files and at the time of performing the relevant validation.
3.2 GTFS RT
An extension of the GTFS format is the specification called GTFS-RT (General Transit Feed Specification Real Time), which once implemented the GTFS files to Google Maps servers or mobile application, can be processed to obtain information in real time, converting the GTFS static files already implemented into dynamic files that provide detailed information on the location of buses, service alerts in case of any congestion and vehicle positions which provides information on transport units.
The format for the interaction of data with GTFS files established is made from protocol buffers, and define the data within the file gtfs-realtime.proto, in order to generate the code and perform the transmission of data [9]. 4 Results
4.1 Displaying GTFS data in QGIS
In this section the GTFS files will be reflected in specialized geographic software, to show an image before the update that will be obtained once the state of Aguascalientes is placed and updated with the GTFS files previously generated.
The visualization of GTFS data requires a partnership with the mobility agency of the city and in this case, in order to perform a management of validation and correction of the data, it is required to previously perform tests with some software. Certainly there are a series of useful tools for this purpose, we used the QGIS software, a geographic software that allows to preview the GTFS files using Google Maps and have an exact preview of the stops and routes that will be displayed once the GTFS database is uploaded to Google Maps servers.
As can be seen in Fig.2, once the Stops.csv file is completed, these are automatically captured on the map, obtaining its exact location.
Fig. 2. City mapping using GTFS format.
The points indicated in the map show the stops that have been registered in the GTFS files, specifically stops.txt, these in turn, will be placed with the coordinates already registered in the Google maps map. The tool that provides this support is QGIS and tells us in real time how it will be displayed once uploaded to Google Maps.
QGIS is a tool with many geographic capabilities, which is useful because you can view, edit and visualize the information of the stops in this case, because before uploading the information to Google, it is necessary a filtering and analysis of GTFS data [8].
The advantage of using the standard GTFS is clear, to have a more solid control of the transport units, being specific, the urban transport. Currently Mexico City as well as the city of Leon, Guanajuato, are the only cities to implement the methodology established by Google, for the creation of intelligent mobility. Most states do not yet have the implementation of GTFS and much less GTFS-RT, because the issue is unknown, there are bus units with GPS technology for tracking units but is still scarce due to the lack of information they can provide and is not accurate information such as the standard mentioned. The city of Aguascalientes, Mexico contemplates to be the third city of the republic in generating intelligent mobility when giving these results.
4.2 OneBusAway as a development tool
Once the main GTFS files have been completed, further development of the application is considered. For this step there is a lot of information and open source tools for the manufacture of applications. There are a lot of products for the consumption of GTFS. The
applications can be generated through transit agencies or through third parties or external companies, as indicated in [8].
The amount of applications of free distribution or open source are very varied, from the use of Google as manager of the GTFS files, to applications such as Moovit, Challo App, Citymapper, Transit App, OneBusAway, to mention a few. The ease of use of these free applications implies a production of applications in a very short period if you had to develop from scratch as mentioned in [3].
OneBusAway (OBA) is a free distribution project which since 2010 has managed to generate impact due to the great simplicity of modification in addition to having a large community that supports users of various mobility agencies that require to develop their own without the need to start a project from scratch. Currently, OBA's development team extends not only to the government but also to academia with the support of the universities of Washington, South Florida, City College of New York, just to mention a few, as well as different mobility agencies that contribute to the development of the application and its growth, with a variety of them between the United States and Canada [11].
Although OBA is a nonprofit organization and which has its application available on various platforms, a few cities have chosen to customize the OBA system to suit their needs, generating new brands totally independent of the original application, finally offering more application options.
Therefore, it is decided to make the decision to generate an application, which in order to speed up the process, gives us the freedom to create an independent brand and with the ease of using the GTFS and GTFS-RT files [10].
4.3 Discussion of results
Preliminary results indicate that although the data capture of the mobility agency, focused only on one means of urban transport, in this case, buses, has been agile thanks to the fact that the information is digitalized. Making a comparison with the Mapatón project in Mexico City you can see that although they managed to capture a large amount of information, due to the amount of population that resides in that city, were only GTFS static data, validated to be displayed on Google Maps [12], which our advantage is that not only remains in the register of the standard GTFS, but goes beyond, the implementation of GTFS-RT and more than that, to a practical use, an application that manages this data and helps to communicate the population with the means of transport, since in the way it was done in Mexico City, and although it is a significant advance due to the size of the city, maintaining only static data, does not offer a long-term solution, in addition to the constant maintenance that must be offered because a change of that nature must be gradual, by taking the various types of transport one by one, managing and monitoring them. Currently the project is inactive and the application of Mapaton is out of service which is a retrocession in the progress made towards the transformation of an intelligent transport.
The Mapatón advantage is undoubtedly the support of many people for the collaboration of GTFS data capture, but without proper monitoring, the project is abandoned and can no longer be funded. The Mapatón advantage is undoubtedly the support of many people for collaboration in capturing GTFS data, but without proper monitoring, the project is abandoned and can no longer be funded.
The advantages of this project, goes beyond simple capture, goes towards a real practical use, ending in an app, which can be configured and edited for city purposes, that's why OneBusAway was decided as the basis of the application. Both projects have defenses, but it is necessary to use the GTFS data in a real time application like in this project.
5 Conclusions and direction for future research
The greatest contribution is that the beginning of the development of an application is given using free distribution tools, in order to implement the GTFS standard to a public transport agency without the need to have any cost and with the possibility of generating comparatives in the transit data of both the application and Google Maps, as it serves as a reference for both the calculation of time as well as a second option for the user in the use of consumer applications transit data.
In this article is contemplated the mapping of routes and stops of the bus concessioned by the city of Aguascalientes using the GTFS standard to achieve it. It is possible to obtain an approach of the magnitude of the problem and it can be observed how it is possible to have a management not only of the reflected bus stations but a possible adaptation of the GTFS generated towards some application.
The work provided for the future is the conclusion of the GTFS base files, as well as the development of an application based on the GTFS generated, thus the city of Aguascalientes would be the third city, apart from Mexico City and the city of Leon that implements the geolocation of public transport by means of applications based on Google Transit technology and with the use of the standard already mentioned, and thus transforming the city to a Smart City.
Acknowledgements. We thank the evaluators for their pertinent observations, as well as
CONACYT and the Autonomous University of Aguascalientes for funding this research. Likewise, the University of Ontario Institute of Technology for the advice provided in this research and to the General Coordination of Mobility (CMOV) of the state of Aguascalientes for their support with information on the city's transportation system.
References
1. T. Zhang, M. Chen, and C. Lawson, "General Transit Feed Specification data visualization," in 2014 22nd International Conference on Geoinformatics, 25-27 June 2014 2014, pp. 1-6, doi: 10.1109/GEOINFORMATICS.2014.6950839.
2. M. Strasser and S. Albayrak, "A pattern based feasibility study of cloud computing for Smart Mobility solutions," in 2016 8th International Workshop on Resilient Networks De-sign and Modeling (RNDM), 13-15 Sept. 2016 2016, pp. 295-301, doi: 10.1109/RNDM.2016.7608301.
3. H. Krambeck. "Introduction to the General Transit Feed Specification (GTFS) and Informal Transit System Mapping (Self-Paced)." World Bank Group. https://olc.worldbank.org/content/introduction-general-transit-feed-specification-gtfs-and-informal-transit-system-mapping (accessed 27/12/18, 2019).
4. M. Friedrich, F. Leurent, I. Jackiva, V. Fini, and S. Raveau, "From Transit Systems to Models: Purpose of Modelling," in Modelling Public Transport Passenger Flows in the Era of Intelligent Transport Systems: COST Action TU1004 (TransITS), G. Gentile and K. Noekel Eds. Cham: Springer International Publishing, 2016, pp. 131-234.
5. OpenMobilityData. "OpenMobilityData." https://transitfeeds.com/feeds (accessed 24/03/19, 2019).
6. R. Faria, L. Brito, K. Baras, and J. Silva, "Smart mobility: A survey," in 2017 International Conference on Internet of Things for the Global Community (IoTGC), 10-13 July 2017 2017, pp. 1-8.
7. M. Braga, M. Y. Santos, and A. Moreira, "Integrating Public Transportation Data: Creation and Editing of GTFS Data," in New Perspectives in Information Systems and Technologies, Volume 2, Cham, Á. Rocha, A. M. Correia, F. B. Tan, and K. A. Stroetmann, Eds., 2014// 2014: Springer International Publishing, pp. 53-62.
8. Girish, M. (2019). Better Bus Implementing Bus Tracking App with GTFS data. In G. Mai-yah (Ed.), (pp. 137). Retrieved from https://www.amazon.com/BetterBus-Implementing-Tracking-GTFS-data ebook/dp/B07QDCWHTP/ref=sr_1_1?keywords=betterbus&qid=1556889659&s=gateway&sr=8-1
9. Google. (2016). Programa de partners de Google Transit. Retrieved from http://maps.google.com/help/maps/mapcontent/transit/
10. Ferris, B., Watkins, K., & Borning, A. (2010). OneBusAway: results from providing real-time arrival information for public transit. Paper presented at the Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, Atlanta, Georgia, USA.
11. OneBusAway. (2010). The Open Source platform for Real Time Transit Info. Retrieved from https://onebusaway.org/
12. Téllez, R. (2016). A Case from Mexico City: Laboratorio para la Ciudad’s Mapatón CDMX. Retrieved from http://legiblepolicy.info/a-case-from-mexico-city-laboratorio-para-la-ciudads-mapaton-cdmx/
ANEXO J – Articulo Mapping of the transport system of the city of Aguascalientes using GTFS Data for the generation of Intelligent Transport based on the Smart Cities paradigm aceptado en congreso ICAETT 2019.
ANEXO K – Constancia de participación en congreso ICAETT 2019 con el articulo Mapping of the transport system of the city of Aguascalientes using GTFS Data for the generation of Intelligent Transport based on the Smart Cities paradigm.
ANEXO L – Publicación del articulo Mapping of the transport system of the city of Aguascalientes using GTFS Data for the generation of Intelligent Transport based on the Smart Cities paradigm en libro electrónico de memorias Springer a través de su serie Advances in Intelligent Systems and Computing, e indexadas en ISI Proceedings, EI-Compendex, DBLP, SCOPUS, Google Scholar y Springerlink.
Enlace de consulta de libro de memorias: Acceso al libro: https://link.springer.com/book/10.1007/978-3-030-32022-5
Acceso al capítulo: https://link.springer.com/chapter/10.1007/978-3-030-32022-5_17
Enlace de consulta del artículo publicado: DOI : https://doi.org/10.1007/978-3-030-32022-5_17
CROSSMARK: http://crossmark.crossref.org/dialog/?doi=10.1007/978-3-030-32022-
5_17&domain=pdf
ANEXO M – Articulo: Mapeo de Rutas de Transporte Público Concesionado de la Ciudad de Aguascalientes Mediante el uso de GTFS para la Generación de Transporte Inteligente Basado en el Paradigma de Smart Cities.
ANEXO N – Articulo Mapeo de Rutas de Transporte Público Concesionado de la Ciudad de Aguascalientes Mediante el uso de GTFS para la Generación de Transporte Inteligente Basado en el Paradigma de Smart Cities aceptado en congreso CIIP 2019.
ANEXO O: Cartel del Articulo: Mapeo de Rutas de Transporte Público Concesionado de la Ciudad de Aguascalientes Mediante el uso de GTFS para la Generación de Transporte Inteligente Basado en el Paradigma de Smart Cities.
ANEXO P – Constancia de participación en congreso CIIP 2019 con el articulo Mapeo de Rutas de Transporte Público Concesionado de la Ciudad de Aguascalientes Mediante el uso de GTFS para la Generación de Transporte Inteligente Basado en el Paradigma de Smart Cities aceptado en congreso CIIP 2019.
ANEXO Q – Articulo: Diseño de arquitectura TUI para la implementación de Transporte Inteligente y validación mediante series de tiempo.
Diseño de arquitectura TUI para la implementación de
Transporte Inteligente y validación mediante series de
tiempo
Raul Alejandro Velasquez Ortiz 1, Francisco Javier Álvarez Rodríguez 2,
Birzavit Monrreal Salazar 3 y Orlando Pérez Corona 4
1, 2 Universidad Autónoma de Aguascalientes, Departamento de Ciencias de la
Computación. Av. Universidad, Ciudad Universitaria, C.P: 20131,
Aguascalientes. México. 1 [email protected], 2 [email protected]
3 Instituto Tecnológico de Reynosa, Departamento de Ingeniería Industrial.
Lomas Real de Jarachina Sur, C.P.88730, Reynosa, Tamaulipas. 3 [email protected]
4 Universidad Tecnológica de Nayarit, Departamento de Ciencias de la Computación.
Carretera Federal 200 Km, C.P.637809, Xalisco, Nayarit. 3 [email protected]
Resumen. El transporte público es uno de los aspectos más importantes con
respecto a los servicios que ofrecen las ciudades, según el trabajo de [1], las civilizaciones humanas modernas se enfrentan al problema del urbanismo en masa, lo que complica la entrega de los servicios. Este paper presenta la arquitectura de Transporte Urbano Inteligente (TUI), desde los antecedentes de las ciudades inteligentes, y las aplicaciones con implementación de Cloud Computing, con el fin de optimizar los tiempos de llegada y salida de cada unidad de transporte el cual tiene las variables tiempo y la demanda requerida del transporte. Los principales resultados de este trabajo se centran en la capacidad del estadístico para encontrar soluciones eficientes de tiempo y demanda, mediante la experimentación de campo en un problema detectado para posteriormente realizar la validación de los tiempos de transporte mediante el estadístico de series de tiempo.
Abstract. Public transport is one of the most important aspects with respect to
the services offered by cities, according to the work of [1], modern human civilizations face the problem of urbanism in mass, which complicates the delivery of services. This paper presents the architecture of Intelligent Urban Transport (TUI), from the antecedents of intelligent cities, and applications with Cloud Computing implementation, in order to optimize the arrival and departure times of each transport unit which has the variable time and demand required for transport. The main results of this work focus on the capacity of the statistician to find efficient solutions of time and demand, by means of field experimentation in a detected problem to later carry out the validation of the times of transport by means of the statistic of time series.
Palabras clave: Transporte Urbano Inteligente, Series de Tiempo, Arquitectura,
Smart Cities, Smart Mobility.
1 Introducción
Hoy en día, uno de los problemas más críticos que enfrenta el transporte urbano es el
constante incremento en la demanda y el congestionamiento esto debido la urbanización
a escala.
Como menciona [2], debido al incremento del urbanismo, la aparición de riesgos,
problema y preocupaciones en ofrecer los servicios a una población lleva a las
autoridades a la búsqueda de soluciones óptimas, que según los investigadores solo se
pueden encontrar dentro de las estructuras inteligentes, es decir la estructura Smart Cities
que implementan el uso de las Tecnologías de Información y Comunicación (TIC).
La propuesta de la nueva estructura de Transporte Urbano Inteligente, la anteriormente
llamada arquitectura TUI, la cual permitirá ser utilizada en diferentes ciudades para el
mejoramiento de uno de los aspectos presentados bajo el esquema Smart Cities, la
movilidad inteligente.
La población busca diferentes opciones de transporte que se acoplen a sus necesidades,
lo que ha dado origen a una diversidad de opciones como taxis, o servicios de terceros
tales como Uber.
La arquitectura TUI propone una estructura de movilidad inteligente mediante del
estándar GTFS (General Transit Feed Specification), que contendrá la información de
las rutas y horarios de todas las unidades para mostrarse en una interfaz que facilite al
usuario la comprensión de sus consultas.
Los modelos de tiempo de series por su parte han sido muy utilizados en áreas de
optimización y predicción en diferentes ramificaciones de diversos campos de trabajo
tales como la meteorología, hidrología y áreas comunes como la mejora o
experimentación de cálculos en tiempos y el uso estadístico tales como procesamiento
de imágenes, solo por mencionar algunos.
Para dar solución al problema de optimización del transporte urbano en esta
investigación se utilizará la serie de tiempos [3]. En este caso se realizará la toma de
datos de una ruta de la ciudad de Aguascalientes. La población inicial está compuesta
por el tiempo que genera el viaje de la ruta, así como la demanda de usuarios que solicita
el servicio.
El objetivo del paper es aplicar la arquitectura TUI en las ciudades para la generación
de transporte inteligente, siendo la ciudad de Aguascalientes donde se realizarán la
experimentación y toma de datos para el soporte de funcionalidad de la arquitectura y el
modelo de series de tiempo.
Definiendo las secciones a presentar, la sección 2 mostrara una serie de anteceden-tes
de la problemática que se presenta, así como soluciones relacionadas con el proyecto del
paper. La sección 3 determina el uso de la arquitectura TUI desarrollada, así como el uso
de la serie de tiempo y su correlación para la optimización del transporte urbano,
demostrando la validación entre el algoritmo y la arquitectura planteada. La sección 4
mostrara los diversos resultados derivados de la experimentación y discusiones
pertinentes al trabajo desarrollado. Por último, la sección 5 presentara las conclusiones
y trabajo a desarrollar en el futuro.
2 Estado del arte
La movilidad ha experimentado diferentes cambios a lo largo de los años, según el
autor [4] debido a la aparición de diversas opciones de viaje, la población dio origen a
3 tipos de movilidad en ciudades, Walking Cities con la implementación de calles
estrechas, que unen una densidad de población significativa con el uso de la tierra para
el movimiento a pie, Transit Cities un plan de Transporte Urbano desarrollado en
Toronto, Ontario, Canadá, el cual consistió en el uso de rutas de ferrocarril y tranvías
para comunicar y optimizar la movilidad en grandes ciudades, Automobile City nacida
desde el desarrollo tecnológico y la necesidad de ofrecer al ciudadano la libertad de
movimiento y decisión de destino, ha provocado una sobrepoblación en el movimiento
urbano.
Algunos de los países han desarrollado los servicios tecnológicos de movilidad
urbana, con el objetivo de minimizar la ocurrencia de accidentes de tráfico debido a
causas relacionadas con deficiencias en la gestión de tráfico debido a causas relacionadas
con deficiencias en la gestión del tráfico [5]. Según datos estadísticos de las ciudades de
Colombia, aunque la mayoría de las grandes ciudades tienen tasas de mortalidad cercanas
o inferiores a la tasa nacional, las ciudades intermedias superan con creces la tasa
nacional. La ciudad de Popayán (capital del departamento del Cauca, ciudad intermedia
colombiana de aproximadamente 400.000 habitantes) no es ajena a esta situación, tiene
una de las tasas de mortalidad por accidentes más altas del país, de 18,28 en 2011 a 21,26
en 2015.Estos servicios se han desarrollado dentro del marco de los sistemas de
transporte inteligente.
Las principales causas identificadas de accidentes de tráfico son: la desobediencia a
las regulaciones de tránsito y el exceso de velocidad. Los ITS son una opción importante
para la movilidad sostenible, estos sistemas aumentan la eficiencia del transporte
público, pero para la implementación de estos se necesitan arquitecturas que
proporcionan una referencia sobre servicios de movilidad, las prioridades existen-tes,
procesos y funciones que deben implementarse.
En 2006, el Departamento de los Estados Unidos presento una propuesta para
desarrollar, usar y mantener una arquitectura regional del ITS [6]. Los autores
establecieron 6 pasos para realizar las actividades de desarrollo, uso y mantenimiento de
la arquitectura de ITS. La aplicación de la propuesta se limita exclusivamente a la
arquitectura estadunidenses, excluyendo la posibilidad de incorporar otros aspectos
relevantes de otras arquitecturas.
El crecimiento de la población y la rápida urbanización creo enormes desafíos para las
ciudades indias debido al crecimiento de la población en el 3% anual, debido al
crecimiento de las ciudades el tema de movilidad se convirtió en un problema, por lo que
se optó por la implementación del transporte inteligente dirigido a la opción de transporte
más utilizada los autobuses. Las soluciones inteligentes para el transporte en las ciudades
incluyeron: Smart Ticketing y Automated Fare Collection, Bus Rapid Transit Systems y
Smart GPS buses and bus-stops [7].
3 Metodología
Para esta investigación se utilizará la arquitectura TUI para la optimización de las
redes de transporte urbano de la ciudad de Aguascalientes, con el objetivo de que esta
pueda ser implementada en otras ciudades.
Además de la comprobación de los tiempos de llegada y salida, así como la demanda
obtenida de la experimentación con el uso de la serie de tiempos y su relación con la
estructura TUI.
3.1 Metodología TUI
La arquitectura TUI se basó en las actuales arquitecturas de ciudades inteligentes y los
tres factores que determinan un transporte inteligente; la optimización del servicio,
personalización del servicio, y la aceptación social.
Fig. 1. Principales factores hacia la transición de Transporte Público Inteligente.
La optimización del servicio se logrará con el uso de la tecnología móvil y el registro de
datos bajo el estándar GTFS, la personalización del servicio se realiza por me-dio de un
servicio en la nube que ofrecerá la información que el usuario solicite y la aceptación
social una vez que el proyecto es implementado se busca la adaptación de este con la
sociedad y mejora para el fácil uso de la sociedad.
Por lo tanto, se buscó crear una arquitectura que facilite la creación del transporte urbano
inteligente que abarque y se acople a la perfección con los factores del transporte urbano
inteligente.
Esta arquitectura se origina a partir de las siguientes arquitecturas Framework de
Smart Cities y Framework de Cloud Computing. Esta arquitectura es la base la para todo
transporte inteligente que esté basado en el estándar GTFS y se muestra a continuación.
Fig. 2. Arquitectura TUI.
Una vez realizada la fusión de las arquitecturas mencionadas se puede apreciar el
comportamiento que se divide en dos grupos, el primer grupo de características. En
seguida hay un segundo nivel que encaja al desarrollo de la arquitectura de OBA los
cuales son servicio de alertas y estimaciones, Servidor OBA, GTFS y Servidor de la
agencia de movilidad.
Para la interacción entre cada uno de ellos debe generar los resultados en específico
para el origen del transporte urbano inteligente.
El primer módulo, seguimiento y servicios de alertar y notificaciones, estos dos
interactúan de tal manera que las diferentes alertas de la aplicación se reflejen en el
sistema.
El segundo módulo, aseguramiento de la calidad y servidor OBA para la peticiones y
respuestas dadas entre la aplicación y el servidor deben sincronizarse de tal manera que
se puedan resolver la comunicación con el usuario.
El tercer módulo es la estandarización que propone la arquitectura es el módulo GTFS,
un modelo para el nacimiento de un sistema urbano inteligente y que logra satisfacer la
demanda que solicitada por parte del usuario.
El cuarto modulo es la accesibilidad de datos el cuan se conjuga con la agencia o
concesionaria, los datos GTFS, así como información del sistema de transporte.
3.2 Series de tiempo (Time series)
Para validar el primer módulo de la arquitectura TUI, referente al servicio de alertas y
estimaciones, se decidió por utilizar el esquema estadístico de series de tiempo, esto
debido a la facilidad de extracción de información estadística útil, en este caso,
comprobar y justificar un correcto muestreo de los tiempos de cada parada y la
confiabilidad de los datos proporcionados con la finalidad de obtener tiempos precisos
dentro de las alertas que la aplicación ejecuta hacia los usuarios.
4 Experimentación y Resultados
Se trabajo en la ciudad de Aguascalientes, dicha ciudad cuenta con un sistema de
transporte que almacena un total de 47 rutas de transporte urbano, específicamente se
realizó la experimentación en la ruta 1 de este servicio el cual cuenta con una longitud
total de 46.83 km. Esta ruta tiene un total de viajes diarios de 184 los cuales inician de
5:50 a 21:34 de lunes a sábados con horario especial los domingos. Para este caso, se
experimentó en un horario de 12:00 a 15:00 horas, debido a la demanda de este y a la
cantidad de usuarios aproximada que es de 105. Como se muestra la figura, la ruta y su
recorrido.
Fig. 3. Mapa de ruta y terminales de la ruta 1 de la ciudad de Aguascalientes.
Como se indica en el recuadro siguiente (Ver Tabla 1) se muestra información
fundamental de la ruta 1, así como su recorrido diario y distancia aproximada por
recorrer. Estos parámetros son útiles debido a que se da un punto de referencia para la
justificación de los resultados obtenidos posteriormente y la comparativa de los tiempos
para las notificaciones.
Ruta Longitud Tiempo viaje Flota Intervalo
Ruta 1 N – S 22.97 km 1:10 hrs 14 10 min
Ruta 1 S - N 23.86 km 1:40 hrs 14 10 min
Tabla 1. Datos generales de la ruta 1.
Con los datos presentados, se realizó el experimento con el soporte del software Minitab
el cual nos permitió realizar los cálculos de serie de tiempo. Los datos con los que se
realizó el experimento fueron capturados durante 7 días consecutivos según lo marcan
en algunas investigaciones [8].
Los resultados que se obtuvieron, como se puede mostrar en la figura, son los
siguientes. Cabe aclarar que estos resultados son una previsualización de precisa sobre
los tiempos que requiere la unidad para llegar a cada parada y puede variar según la
demanda del servicio que se requiera en el momento de la experimentación.
Fig. 3. Comparación de tiempo entre paradas.
La prueba realizada fue de sentido norte a sur de la ruta 1, como se aprecia, fueron analizados con datos GPS así como toma manual de los tiempo, logrando vislumbrar una correlación cercana de tiempo, que si bien existe una diferencia mínima, esta se debe principalmente a la cantidad de usuarios que hacen uso del servicio, pues si bien la experimentación se realizó en horarios similares, factores como la retardo en la salida del autobús o velocidad del manejo, provocaron discrepancias mínimas en los resultados, aunque en ocasiones como lo expresa la gráfica, los tiempos de llegada de la unidad pueden elevarse en consideración a factores externos como el tráfico. Los resultados por lo tanto ofrecen una gran correlación de exactitud con lo cual la demanda de usuarios debe mantenerse o disminuir basado de igual manera en los tiempos oficiales que maneja el gobierno del estado, junto a la coordinación de movilidad.
5 Conclusiones y dirección para futuro trabajo de investigación
En este artículo se propuso la implementación y adaptación de la arquitectura TUI, con la finalidad de poder crear un entorno de movilidad inteligente, enfocándonos en el área de transporte urbano, siendo una necesidad el poder crear un servicio que no solo mejore la manera de trasladarse de la sociedad, sino que haga crecer a la ciudad misma. Si bien parte de la arquitectura en un primer módulo ha sido justificada, el trabajo a futuro pretende realizar una abstracción a fondo de esta y de sus diferentes módulos. Así mismo en la construcción de métodos de optimización de tiempos, logrando un enfoque que proporcione alertas aún más precisas para los usuarios dentro del uso de la aplicación a desarrollar. Con un primer módulo definido, se logra visualizar un entendimiento claro del uso de la arquitectura y su necesidad de implantación. Agradecimientos. Agradecemos a los evaluadores por sus observaciones pertinentes, así como al CONACYT y a la Universidad Autónoma de Aguascalientes por financiar esta investigación. Asimismo, al Instituto Tecnológico de Reynosa, a la Universidad Tecnológica de Nayarit y al Ontario Tech University por el asesoramiento brindado en esta investigación y a la Coordinación General de Movilidad (CMOV) del estado de Aguascalientes por su apoyo con información sobre el sistema de transporte de la ciudad.
Referencias
[1] Makarova, I., Shubenkova, K., Mavrin, V., Boyko, A., & Katunin, A. (2017, 11-13 Sept. 2017).
Development of sustainable transport in smart cities. Paper presented at the 2017 IEEE 3rd
International Forum on Research and Technologies for Society and Industry (RTSI).
[2] Arroub, A., Zahi, B., Sabir, E., & Sadik, M. (2016, 26-29 Oct. 2016). A literature review on
Smart Cities: Paradigms, opportunities and open problems. Paper presented at the 2016
International Conference on Wireless Networks and Mobile Communications (WINCOM).
[3] Makridakis, Spyros. (1976). A Survey of Time Series. International Statistical Review. 44.
10.2307/1402964.
[4] Faria, R., Brito, L., Baras, K., & Silva, J. (2017, 10-13 July 2017). Smart mobility: A survey.
Paper presented at the 2017 International Conference on Internet of Things for the Global
Community (IoTGC).
[5] Salazar-Cabrera, R., & Pachón, Á. (2019). Methodology for Design of an Intelligent Transport
System (ITS) Architecture for Intermediate Colombian City. Ingeniería y competitividad, 21,
49-62.
[6] Department of Transportation, O. o. O. (2006). Regional ITS Architecture Guidance
Document. In U. S. D. o. Transportation (Ed.), (pp. 261). Retrieved from
https://ops.fhwa.dot.gov/publications/regitsarchguide/raguide.pdf
[7] Vakula, D., & Raviteja, B. (2017, 7-8 Dec. 2017). Smart public transport for smart cities. Paper
presented at the 2017 International Conference on Intelligent Sustainable Systems (ICISS).
[8] Ruano-Daza, E., Cobos, C., Torres-Jimenez, J., Mendoza, M., & Paz, A. (2018). A
multiobjective bilevel approach based on global-best harmony search for defining optimal
routes and frequencies for bus rapid transit systems. Applied Soft Computing, 67, 567-583.
doi:https://doi.org/10.1016/j.asoc.2018.03.026
ANEXO R – Articulo: Diseño de arquitectura TUI para la implementación de Transporte Inteligente y validación mediante series de tiempo aceptado en congreso ANIEI 2019.
ANEXO S – Constancia de participación en congreso ANIEI 2019 con el articulo Diseño de arquitectura TUI para la implementación de Transporte Inteligente y validación mediante series de tiempo.
ANEXO T – Conferencia impartida en el Tecnológico Universitario Aguascalientes sobre el tema de tesis Diseño de Modelo Arquitectónico para la Implementación de Transporte Urbano bajo las Arquitecturas de Movilidad Inteligente de Smart Cities y el uso de Cloud Computing.
ANEXO U – Carta de invitación de movilidad de investigación de la University of Ontario Institute of Technology.
ANEXO V – Carta de liberación de movilidad de investigación de la University of Ontario Institute of Technology.
ANEXO W – Convenio de colaboración entre la Universidad Autónoma de Aguascalientes y la Coordinación General de Movilidad del estado de Aguascalientes para trabajo de tesis y movilidad de la ciudad.
ANEXO X – Certificado de obra ante INDAUTOR denominado Modelo Transporte Inteligente.
![DIVISION DE CIENCIAS BÁSICAS E INGENIERÍA · 2019. 5. 8. · DIVISION DE CIENCIAS BÁSICAS E INGENIERÍA [2015] Dr. José Luis Hernández Pozos Jefe del Departamento de Física](https://img.pdfslide.net/doc/110x75/60719696f1ba4160c553dfc1/division-de-ciencias-bsicas-e-ingeniera-2019-5-8-division-de-ciencias-bsicas.jpg)
