ALTERNATIVA DE SOLUCIÓN PARA VISUALIZACIÓN DE LAS...
46
ALTERNATIVA DE SOLUCIÓN PARA VISUALIZACIÓN DE LAS RUTAS Y UBICACIÓN GEOGRÁFICA EN TIEMPO REAL PARA EL SISTEMA DE TRANSPORTE PÚBLICO AUTORES: JUAN MANUEL SALAMANCA VERA LUCIANO ALEJANDRO CAMACHO JAIMES Tesis de Ingeniería en Telecomunicaciones UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA PROYECTO CURRICULAR DE INGENIERIA EN TELECOMUNICACIONES Bogotá D.C., Colombia 2017
Transcript of ALTERNATIVA DE SOLUCIÓN PARA VISUALIZACIÓN DE LAS...
ALTERNATIVA DE SOLUCIÓN PARA VISUALIZACIÓN DE LAS
RUTAS Y UBICACIÓN GEOGRÁFICA EN TIEMPO REAL PARA EL
SISTEMA DE TRANSPORTE PÚBLICO
AUTORES:
JUAN MANUEL SALAMANCA VERA
LUCIANO ALEJANDRO CAMACHO JAIMES
Tesis de Ingeniería en Telecomunicaciones
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD TECNOLÓGICA
PROYECTO CURRICULAR DE INGENIERIA EN TELECOMUNICACIONES
Bogotá D.C., Colombia
2017
JUAN MANUEL SALAMANCA VERA
LUCIANO ALEJANDRO CAMACHO JAIMES
ALTERNATIVA DE SOLUCIÓN PARA VISUALIZACIÓN DE LAS
RUTAS Y UBICACIÓN GEOGRÁFICA EN TIEMPO REAL PARA EL
SISTEMA DE TRANSPORTE PÚBLICO
Tesis presentada al Programa de Ingeniería en Telecomunicaciones de la
Universidad Distrital “Francisco José de Caldas” Facultad Tecnológica, para
obtener el título de Ingeniero en Telecomunicaciones
Programa:
Ingeniería en Telecomunicaciones
Director:
Ing. Giovani Mancilla Gaona
Bogotá, Febrero de 2017
Resumen
La movilidad de la población en grandes ciudades, es uno de los temas principales
a cubrir dentro de las políticas ciudadanas, para esto, se desarrollan constantes
estrategias que proporcionen alternativas de transporte, que cubran estas
necesidades. A medida que crecen las ciudades, de igual manera se incrementa
los medios de transporte ofrecidos a las personas de una ciudad, esto ha
generado diferentes problemas para encontrar rutas disponibles y rápidas,
incrementando los tiempos de llegada desde una ubicación a otra. El uso de la
tecnología utilizada para este proyecto, representa una alternativa eficiente para la
ubicación de los medios de transportes disponibles dentro de una ciudad, a esto
se le suma el poder obtener con precisión la ubicación de los vehículos
disponibles y su recorrido de viaje.
Para el desarrollo de este proyecto se explotó las características internas de
hardware y software de los dispositivos Android, como el uso de los módulos GPS,
GSM, acelerómetros, brújulas, entre otros, que permiten desarrollar una alternativa
eficiente para la ubicación geográfica de vehículos de transporte público. Mediante
una aplicación desarrollada para Android e instalada en una Tablet o Smartphone
y asignado a un conductor, ruta y un vehículo de transporte público se puede
obtener en tiempo real información como; recorrido, ubicación del vehículo,
número de paraderos, entre otros. Todos estos datos se visualizaran en una
aplicación para Android con función de usuario, la cual tomara los datos de las
posiciones geográficas que la aplicación conductor ha enviado a un servidor Web
centralizado.
Palabras clave: gps, android, transporte, vehículos, aplicación, node.js.
Abstract
Mobility of the population in large cities is one of the main topics to be covered
within the citizen's policies. To this end, constant strategies are developed to
provide transportation alternatives that cover these needs. As cities grow, so does
the means of transportation offered to the people of a city, this has created
different problems in finding available and fast routes, increasing arrival times from
one location to another. The use of the technology used for this project represents
an efficient alternative for the location of the means of transport available within a
city, to this is added the ability to accurately obtain the location of the available
vehicles and their travel.
The development of this project exploited the internal hardware and software
features of Android devices, such as the use of GPS modules, GSM,
accelerometers, compasses, among others, to develop an efficient alternative for
the geographical location of public transport vehicles. Using an application
developed for Android and installed on a Tablet or Smartphone and assigned to a
driver, route and a public transport vehicle can be obtained in real time information
such as; Travel, vehicle location, number of stops, among others. All this data will
be displayed in an Android application with user function, which will take the data
of the geographical positions that the driver application has sent to a centralized
Web server.
Keywords: gps, android, transport, vehicles, application, node.js
Contenido
Resumen ................................................................................................................. 3
Abstract ................................................................................................................... 4
Lista de Términos .................................................................................................... 6
Glosario ................................................................................................................... 7
1. INTRODUCCIÓN ............................................................................................. 8
2. JUSTIFICACIÓN .............................................................................................. 8
3. DESCRIPCIÓN DEL PROYECTO ................................................................... 9
3.1. PLANTEAMIENTO DEL PROBLEMA ........................................................ 9
4. OBJETIVOS ..................................................................................................... 9
4.1.1. OBJETIVO GENERAL ......................................................................... 9
4.1.2. OBJETIVOS ESPECÍFICOS ............................................................. 10
5. MARCO TEÓRICO CONCEPTUAL ............................................................... 11
5.1.1. ANDROID .......................................................................................... 11
5.1.2. GOOGLE MAPS ................................................................................ 11
5.1.3. NODE.JS ........................................................................................... 13
5.1.4. SERVIDOR WEB ............................................................................... 13
5.1.5. BASES DE DATOS ........................................................................... 18
5.1.6. SISTEMA DE POSICIONAMIENTO GLOBAL - GPS ........................ 20
5.1.7. LA TRANSMISIÓN DE DATOS EN LA TELEFONÍA MÓVIL ............. 20
6. DESARROLLO DEL PROYECTO .................................................................. 24
6.1. DESARROLLO DE PLATAFORMA WEB ................................................ 25
6.1.1. SERVIDOR PARA TRANSACCIÓN DE DATOS ............................... 26
6.1.2. PÁGINA WEB DE ADMINISTRACIÓN .............................................. 28
6.2. APLICACIÓN NO. 1 – CONDUCTOR ...................................................... 32
6.3. APLICACIÓN NO. 2 – USUARIO ............................................................. 37
6.4. SERVIDOR DE BASE DE DATOS ........................................................... 39
7. PRUEBAS TÉCNICAS ................................................................................... 41
8. CONCLUSIONES .......................................................................................... 43
9. BIBLIOGRAFÍA .............................................................................................. 45
Lista de Términos
AJAX: Asynchronous JavaScript And XML
App: Aplicación Informática (del inglés application)
CSS: Cascading Style Sheets
DBA: Data Base Administrator
SQL: Structured Query Language
AWS: Amazon Web Services
VPS: Virtual Private Server
HTTP: Hypertext Transfer Protocol
GPRS: General Packet Radio Service
EDGE: Enhanced Data rates for GSM Evolution
UMTS: Universal Mobile Telecommunications System
WCDMA: Wideband Code Division Multiple Access
CDMA: Code Division Multiple Access
HSDPA: High Speed Downlink Packet Access
LTE: Long Term Evolution
SOAP: Simple Object Access Protocol
XML: Extensible Markup Language
REST: Representational State Transfer
RPC: Remote Procedure Calls
WSDL: Web Services Description Language
JSON: JavaScript Object Notation
FDD: Frequency Division Duplexing
TDD: Time Division Duplexing
MIMO: Multiple Input Multiple Output
Glosario 2G: Segunda generación de telefonía móvil.
3G: Abreviatura de tercera generación de transmisión de voz y datos a través de
la telefonía móvil.
4G: Abreviatura de la cuarta generación de tecnologías de telefonía móvil.
API: (Application Programming Interface), interfaz de programación de
aplicaciones.
Google Maps: Servidor de aplicaciones de mapas en la web, pertenece a la
empresa Google.
GPS: (Global Position System) Sistema de posicionamiento global que permite
determinar la posición de un objeto (persona, un vehículo etc.).
HTML: Lenguaje de marcas de hipertexto para la elaboración de páginas web.
HTTP: (Hypertext Transfer Protocol) usado para la transacción de la World Wide
Web.
JavaScript: Lenguaje de programación de uso principalmente para desarrollo de
páginas web dinámicas.
MySQL: Gestor de bases de datos relacional, multihilo y multiusuario.
Node.JS: Intérprete Javascript del lado del servidor
SOAP: Es un protocolo estándar que define cómo dos objetos en diferentes
procesos pueden comunicarse por medio de intercambio de datos XML.
WSDL: Es un formato del Extensible Markup Language (XML) que se utiliza para
describir servicios web (WS).
XML: Es un meta-lenguaje que permite definir lenguajes de marcas, utilizado para
almacenar datos en forma legible.
<div>: de división - Sirve para crear secciones o agrupar contenidos en el código
HTML.
Tiempo real: Un sistema de tiempo real es un sistema informático que
interacciona con su entorno físico y responde a los estímulos del entorno dentro
de un plazo de tiempo determinado. No basta con que las acciones del sistema
sean correctas, sino que, además, tienen que ejecutarse dentro de un intervalo de
tiempo determinado.
1. INTRODUCCIÓN
Los sistemas de ubicación geográfica en tiempo real para los sistemas de
transporte, presentan grandes prestaciones a la sociedad, permitiendo obtener la
información necesaria de las rutas dentro de una ciudad. A esto se le adicionan
detalles específicos como el recorrido ofrecido por los distintos vehículos de
transporte público, número de paraderos e inclusive conocer el tiempo de llegada
a cada estación, entre muchos servicios más.
El uso de dispositivos móviles como Android, han simplificado la forma de cómo
accedemos a servicios por medio de las aplicaciones, mejorando la productividad,
tanto para ofrecer mecanismos de información y obtención de estos de forma
simple y económica.
Con la llegada de múltiples servicios en la nube y la rápida difusión de Internet
para dispositivos móviles, se ha incrementado la demanda de servicios de acceso
en tiempo real, es por esta razón que en la actualidad, tener conocimiento del
tiempo de llegada del transporte urbano a cada punto o paradero, genera una
necesidad de ahorrar tiempos al momento de esperar una determinada ruta,
mejorando así la forma en que la población de una ciudad se desplaza de un
punto a otro.
2. JUSTIFICACIÓN
La solución plasmada en esta tesis, quiere mostrar una alternativa de solución
para la ubicación en rutas de los sistemas de transporte públicos. El conocer y
encontrar rutas acordes a las necesidades de la población de grandes ciudades es
uno de los objetivos principales a tratar dentro de las urbes modernas. Mediante el
uso de la tecnología, como dispositivos móviles Android, el uso de las
telecomunicaciones (GPS, Red celular, WIFI) y la implementación de sistemas de
información (bases de datos, servidores web), permiten que la información este
centralizada y accesible desde cualquier lugar, tan sólo con una conexión a
Internet.
3. DESCRIPCIÓN DEL PROYECTO
3.1. PLANTEAMIENTO DEL PROBLEMA
En la ciudad de Bogotá un sistema organizado de transporte público es
fundamental para el desarrollo de la misma ya que con el aumento de la población
y el crecimiento de la ciudad hacia la periferia, los habitantes necesitan recorrer
distancias más largas para llegar a su destino. Con la llegada sistemas como
Transmilenio y SITP se ha organizado de una forma más eficiente la forma en que
los ciudadanos se transportan, aun así, no se puede determinar con precisión la
llegada de los buses a los diferentes paraderos.
Existen aplicaciones para dispositivos móviles que hacen más fácil tomar un bus,
ya que indican la ruta y las paradas que este hace, algunas aplicaciones indican
un tiempo estimado de llegada del bus al paradero, pero ese tiempo estimado no
está ligado a una ubicación geográfica en tiempo real, por esta razón es necesaria
la creación de una herramienta tecnológica que permita al usuario de transporte
publico conocer la ubicación del bus que está esperando y de esta manera permitir
que este conozca el trayecto y posición del bus a esperar y así ahorrar varios
minutos e incluso horas esperando un bus que aún se encuentra lejos del
paradero.
4. OBJETIVOS
4.1.1. OBJETIVO GENERAL
Desarrollar una plataforma para la visualización de las rutas de transporte público
y su ubicación geográfica en tiempo real, mediante el uso de dispositivos móviles
Android.
4.1.2. OBJETIVOS ESPECÍFICOS
Crear una primera aplicación en Android con función Conductor e interfaz
de autenticación ante servidor web, que permita la visualización del
trayecto a recorrer y envío de los cambios en su ubicación geográfica al
servidor.
Implementar de una segunda aplicación en Android, basada en la
primera, con función de usuario final (pasajero) para la visualización de
las diferentes rutas de transporte y ubicación de los buses y paraderos.
Desarrollar una plataforma bajo Node.js e interfaz Web para la
administración de rutas, usuarios y vehículos, con almacenamiento
sobre una base de datos.
Establecer un servidor de base de datos implementado en MySQL, que
almacene la información de la plataforma web y los datos enviados por
los dispositivos móviles.
5. MARCO TEÓRICO CONCEPTUAL
5.1.1. ANDROID
Android es el sistema operativo más reciente para dispositivos móviles, adquirido
por Google y en unión con fabricantes de Hardware y Software se conforma la
Open Handset Alliance, quienes de forma colaborativa desarrollaron de forma
abierta el sistema operativo para fomentar la innovación de dispositivos móviles y
ofrecer altas experiencias de usuario, mayor a la de otros dispositivos móviles[1].
Android fue construido desde cero para permitir a los desarrolladores crear
aplicaciones móviles atractivas que aprovechen al máximo todo lo que un teléfono
tiene para ofrecer. Fue construido para ser verdaderamente abierto. Por ejemplo,
una aplicación puede llamar a cualquiera de las funciones principales del teléfono,
como hacer llamadas, enviar mensajes de texto o utilizar la cámara, lo que permite
a los desarrolladores crear experiencias más complejas y más coherentes para los
usuarios.
Android se basa en el kernel Linux abierto. Además, utiliza una máquina virtual
personalizada diseñada para optimizar recursos de memoria y hardware en un
entorno móvil. Android es de código abierto; Puede ampliarse ampliamente para
incorporar nuevas tecnologías de vanguardia a medida que surjan. La plataforma
seguirá evolucionando a medida que la comunidad de desarrolladores trabaje
juntos para crear aplicaciones móviles innovadoras [2].
5.1.2. GOOGLE MAPS
Google Maps fue desarrollado originalmente por dos hermanos Daneses, Lars y
Jens Rasmussen, co-fundadores de Where 2 Technologies una empresa dedicada
a la creación de soluciones de mapeo.
La empresa fue adquirida por Google en octubre de 2004, y los dos hermanos
luego crearon Google Maps (también son los que están detrás de Google Wave).
¿Cómo funciona Google Maps?
Es sólo HTML, CSS y JavaScript trabajando junto. Los mapas son solo imágenes
que se cargan en el fondo a través de peticiones ejecutadas por la tecnología de
AJAX, y se insertan en etiquetas <div> dentro de la página HTML. Mientras se
navega en el mapa, el API envía información acerca de las nuevas coordenadas y
los niveles de “zoom” del mapa a través de AJAX y esto retorna nuevas
imágenes.
El API consiste de archivos JavaScript que contienen las clases, métodos y
propiedades que se usan para el comportamiento de los mapas.
Google Maps ha dispuesto su libre utilización, ofreciendo grandes características
a cualquier persona con conocimientos avanzados o no.
Coordenadas
Las coordenadas son usadas para expresar las ubicaciones en el mundo. Google
Maps usa el sistema de coordenadas Word Geodetic System 84 (WGS 84), el cual
es el mismo usado por el sistema de posicionamiento global (GPS). Las
coordenadas se expresan usando Latitud y Longitud. (ver figura 1)
La latitud se mide desde el Sur al Norte y la longitud se mide desde el Oeste al
Este.
Figura 1: El centro del mundo, latitud 0 y longitud 0
El sistema de coordenadas usadas, están expresadas usando números decimales
separados por coma. La latitud siempre precede la longitud.
La latitud es positiva si va después del punto mostrado en el mapa y negativo si va
antes. La longitud es positiva si va arriba del punto y negativa si va debajo. [3]
5.1.3. NODE.JS
Node es un intérprete Javascript del lado del servidor que cambia la noción de
cómo debería trabajar un servidor. Su meta es permitir a un programador construir
aplicaciones altamente escalables y escribir código que maneje decenas de miles
de conexiones simultáneas en una máquina física.
Node.js proporciona una manera fácil para construir programas de red escalables
y en comparación con otras aplicaciones de servidor como Java™ y PHP, donde
cada conexión genera un nuevo hilo que potencialmente viene acompañado de
2MB de memoria. En un sistema que tiene 8 GB de RAM, esto da un número
máximo teórico de conexiones concurrentes de cerca de 4.000 usuarios. A mayor
cantidad de clientes se necesitará más servidores, lo que aumenta los costos de
despliegue de infraestructura aumentando los costos para el despliegue de alguna
solución.
Node.js resuelve el problema cambiando la forma en que se realiza una conexión
con el servidor. En lugar de generar un nuevo hilo de OS para cada conexión (y de
asignarle la memoria acompañante), cada conexión dispara una ejecución de
evento dentro del proceso del motor de Node.js. Node también afirma que nunca
se quedará en punto muerto, porque no se permiten bloqueos y porque no se
bloquea directamente para llamados E/S. Node afirma que un servidor que lo
ejecute puede soportar decenas de miles de conexiones concurrentes [4].
5.1.4. SERVIDOR WEB
Los servidores web son los encargados de recibir las peticiones referidas a
páginas o elementos de la web a través del protocolo http o https y de devolver el
resultado de la petición, que suele ser un recurso alojado en el servidor.
Normalmente es el navegador el que pide al servidor el recurso que desea el
usuario, para finalmente recibir dicho recurso (si fue válida la petición) y traducirle
si es necesario a su forma legible por el usuario (es decir la traducción de HTML la
hace el navegador). [5]
5.1.4.1. SERVICIOS WEB
El consorcio W3C define los Servicios Web como sistemas software diseñado para
soportar una interacción interoperable máquina a máquina sobre una red. Los
Servicios Web suelen ser APIs Web que pueden ser accedidas dentro de una red
(principalmente Internet) y son ejecutados en el sistema que los aloja.
La definición de Servicios Web propuesta alberga muchos tipos diferentes de
sistemas, pero el caso común de uso de refiere a clientes y servidores que se
comunican mediante mensajes XML que siguen el estándar SOAP.
En los últimos años se ha popularizado un estilo de arquitectura Software
conocido como REST (Representational State Transfer). Este nuevo estilo ha
supuesto una nueva opción de estilo de uso de los Servicios Web. A continuación
se listan los tres estilos de usos más comunes:
Remote Procedure Calls (RPC, Llamadas a Procedimientos Remotos):
Los Servicios Web basados en RPC presentan una interfaz de llamada a
procedimientos y funciones distribuidas, lo cual es familiar a muchos
desarrolladores. Típicamente, la unidad básica de este tipo de servicios
es la operación WSDL (WSDL es un descriptor del Servicio Web, es
decir, el homólogo del IDL para COM).
Las primeras herramientas para Servicios Web estaban centradas en
esta visión. Algunos lo llaman la primera generación de Servicios Web.
Esta es la razón por la que este estilo está muy extendido. Sin embargo,
ha sido algunas veces criticado por no ser débilmente acoplado, ya que
suele ser implementado por medio del mapeo de servicios directamente
a funciones específicas del lenguaje o llamadas a métodos. Muchos
especialistas creen que este estilo debe desaparecer.
Arquitectura Orientada a Servicios (Service-oriented Architecture, SOA).
Los Servicios Web pueden también ser implementados siguiendo los
conceptos de la arquitectura SOA, donde la unidad básica de
comunicación es el mensaje, más que la operación. Esto es típicamente
referenciado como servicios orientados a mensajes.
Los Servicios Web basados en SOA son soportados por la mayor parte
de desarrolladores de software y analistas. Al contrario que los Servicios
Web basados en RPC, este estilo es débilmente acoplado, lo cual es
preferible ya que se centra en el “contrato” proporcionado por el
documento WSDL, más que en los detalles de implementación
subyacentes.
REST (REpresentation State Transfer). Los Servicios Web basados en
REST intentan emular al protocolo HTTP o protocolos similares mediante
la restricción de establecer la interfaz a un conjunto conocido de
operaciones estándar (por ejemplo GET, PUT,...). Por tanto, este estilo
se centra más en interactuar con recursos con estado, que con mensajes
y operaciones.
5.1.4.2. SERVICIOS REST
REST (Representational State Transfer) es un estilo de arquitectura de software
para sistemas hipermedias distribuidos tales como la Web. El término fue
introducido en la tesis doctoral de Roy Fielding en 2000, quien es uno de los
principales autores de la especificación de HTTP.
En realidad, REST se refiere estrictamente a una colección de principios para el
diseño de arquitecturas en red. Estos principios resumen como los recursos son
definidos y diseccionados. El término frecuentemente es utilizado en el sentido de
describir a cualquier interfaz que transmite datos específicos de un domino sobre
HTTP sin una capa adicional, como hace SOAP. Estos dos significados pueden
chocar o incluso solaparse. Es posible diseñar un sistema software de gran
tamaño de acuerdo con la arquitectura propuesta por Fielding sin utilizar HTTP o
sin interactuar con la Web. Así como también es posible diseñar una simple
interfaz XML+HTTP que no sigue los principios REST, y en cambio seguir un
modelo RPC. Cabe destacar que REST no es un estándar, ya que es tan solo un
estilo de arquitectura. [6]
5.1.4.3. INTERCAMBIO DE DATOS POR JSON
JSON es un formato ligero de intercambio de datos. Leerlo y escribirlo es simple para humanos, mientras que para las máquinas es simple interpretarlo y generarlo. Está basado en un subconjunto del Lenguaje de Programación JavaScript, Standard ECMA-262 3rd Edition - Diciembre 1999. JSON es un formato de texto que es completamente independiente del lenguaje pero utiliza convenciones que son ampliamente conocidos por los programadores de la familia de lenguajes C, incluyendo C, C++, C#, Java, JavaScript, Perl, Python, y muchos otros. Estas propiedades hacen que JSON sea un lenguaje ideal para el intercambio de datos.
JSON está constituído por dos estructuras:
- Una colección de pares de nombre/valor. En varios lenguajes esto se conoce como un objeto, registro, estructura, diccionario, tabla hash, lista de claves o un arreglo asociativo.
- Una lista ordenada de valores. En la mayoría de los lenguajes, esto se implementa como arreglos, vectores, listas o sequencias.
Estas son estructuras universales; virtualmente todos los lenguajes de programación las soportan de una forma u otra. Es razonable que un formato de intercambio de datos que es independiente del lenguaje de programación se base en estas estructuras.
En JSON, se presentan de estas formas:
Un objeto es un conjunto desordenado de pares nombre/valor. Un objeto comienza con “{“ (llave de apertura) y termine con “}” (llave de cierre). Cada nombre es seguido por “:” (dos puntos) y los pares nombre/valor están separados por “,” (coma).
Figura 2. Representación de un objeto - JSON
Un arreglo es una colección de valores. Un arreglo comienza con [ (corchete izquierdo) y termina con ] (corchete derecho). Los valores se separan por , (coma).
Figura 3. Representación de un arreglo - JSON
Un valor puede ser una cadena de caracteres con comillas dobles, o un número, o true o false o null, o un objeto o un arreglo. Estas estructuras pueden anidarse.
Figura 4. Representación de un valor - JSON
Una cadena de caracteres es una colección de cero o más caracteres Unicode, encerrados entre comillas dobles, usando barras divisorias invertidas como escape. Un carácter está representado por una cadena de caracteres de un único carácter. Una cadena de carateres es parecida a una cadena de caracteres C o Java.
Figura 5. Representación de una cadena string - JSON
Un número es similar a un número C o Java, excepto que no se usan los formatos octales y hexadecimales.
Figura 6. Representación de una cadena número - JSON
Los espacios en blanco pueden insertarse entre cualquier par de símbolos. [7]
5.1.5. BASES DE DATOS
Un sistema de bases de datos sirve para integrar los datos, organizar campos,
registros y archivos. Lo componen los siguientes elementos:
- Hardware. Máquinas en las que se almacenan las bases de datos.
Incorporan unidades de almacenamiento masivo para este fin.
- Software. Es el sistema gestor de bases de datos. El encargado de
administrar las bases de datos.
- Datos. Incluyen los datos que se necesitan almacenar y los metadatos que
son datos que sirven para describir lo que se almacena en la base de datos.
- Usuarios. Personas que manipulan los datos del sistema. Hay tres
categorías. [8]
5.1.5.1. TIPOS DE BASES DE DATOS
Las bases de datos se pueden clasificar de varias maneras, según el contexto que
se esté manejando o su utilidad.
- Bases de datos dinámicas
Estas son bases de datos donde la información almacenada se modifica con el
tiempo, permitiendo operaciones como actualización, borrado y adición de datos,
además de las operaciones fundamentales de consulta.
De acuerdo a su modelo de administración de datos:
- Bases de datos Jerárquicas
En este modelo los datos se organizan en una forma similar a un árbol (visto al
revés), en donde un nodo padre de información puede tener varios hijos. El nodo
que no tiene padres es llamado raíz, y a los nodos que no tienen hijos se los
conoce como hojas. Son especialmente útiles en el caso de aplicaciones que
manejan un gran volumen de información y datos muy compartidos permitiendo
crear estructuras estables y de gran rendimiento.
- Bases de datos de red
Éste es un modelo ligeramente distinto del jerárquico; la diferencia fundamental es
la modificación del concepto de nodo: se permite que un mismo nodo tenga varios
padres (posibilidad no permitida en el modelo jerárquico). Mejora la redundancia
de datos sin embargo la administración es más compleja y limita el uso del usuario
final.
- Bases de datos transaccionales
Son bases de datos cuyo único fin es el envío y recepción de datos a grandes
velocidades, estas bases son muy poco comunes y están dirigidas por lo general
al entorno de análisis de calidad, datos de producción e industrial.
- Bases de datos relacionales
Éste es el modelo utilizado en la actualidad para modelar problemas reales y
administrar datos dinámicamente. En este modelo, el lugar y la forma en que se
almacenen los datos no tienen relevancia (a diferencia de otros modelos como el
jerárquico y el de red). Esto tiene la considerable ventaja de que es más fácil de
entender y de utilizar para un usuario esporádico de la base de datos.
La información puede ser recuperada o almacenada mediante "consultas" que
ofrecen una amplia flexibilidad y poder para administrar la información. [9]
5.1.6. SISTEMA DE POSICIONAMIENTO GLOBAL - GPS
El sistema de posicionamiento global (GPS) es un sistema que permite determinar
en toda la Tierra la posición de un objeto (una persona, un vehículo) con una
precisión de hasta centímetros (si se utiliza GPS diferencial), aunque lo habitual
son unos pocos metros de precisión. El sistema fue desarrollado, instalado y
empleado por el Departamento de Defensa de los Estados Unidos. Para
determinar las posiciones en el globo, el sistema GPS se sirve de 24 satélites y
utiliza la trilateración.
El GPS funciona mediante una red de 24 satélites en órbita sobre el planeta
Tierra, a 20 200 km de altura, con trayectorias sincronizadas para cubrir toda la
superficie de la Tierra. Cuando se desea determinar la posición, el receptor que se
utiliza para ello localiza automáticamente como mínimo tres satélites de la red, de
los que recibe unas señales indicando la identificación y la hora del reloj de cada
uno de ellos. Con base en estas señales, el aparato sincroniza el reloj del GPS y
calcula el tiempo que tardan en llegar las señales al equipo, y de tal modo mide la
distancia al satélite mediante el método de trilateración inversa, el cual se basa en
determinar la distancia de cada satélite al punto de medición. Conocidas las
distancias, se determina fácilmente la propia posición relativa respecto a los
satélites. Conociendo además las coordenadas o posición de cada uno de ellos
por la señal que emiten, se obtiene la posición absoluta o coordenada real del
punto de medición. También se consigue una exactitud extrema en el reloj del
GPS, similar a la de los relojes atómicos que lleva a bordo cada uno de los
satélites [10].
5.1.7. LA TRANSMISIÓN DE DATOS EN LA TELEFONÍA MÓVIL
Para reflejar la evolución de las tecnologías utilizadas en la telefonía móvil se utiliza el concepto de “generación”, de forma que cada generación engloba un
conjunto de estándares de transmisión de datos (y de voz) que ofrecen unas determinadas prestaciones y calidad de servicio. 1G – Fue la primera generación de telefonía móvil y utilizaba tecnología analógica para la transmisión de información. Se utilizó en los años 80. 2G – Es la segunda generación de telefonía móvil que utiliza fundamentalmente GSM (Global System for Mobile Communications, sistema global para las comunicaciones móviles) como estándar de transmisión de telefonía digital. Permite la transmisión tanto de voz como de datos (por ejemplo, mensajes cortos de texto o SMS). Utiliza varias bandas de frecuencia dependiendo de la región o país. 3G – La 3G es tipificada por la convergencia de la voz y datos con acceso inalámbrico a Internet, aplicaciones multimedia y altas transmisiones de datos. Los protocolos empleados en los sistemas 3G soportan más altas velocidades de información enfocados para aplicaciones más allá de la voz tales como audio (MP3), video en movimiento, video conferencia y acceso rápido a Internet, sólo por nombrar algunos. [11]
5.1.7.1. Transmisión de datos en 3G Estándar 3G: EDGE EDGE (Enhanced Data rates for GSM of Evolution o Tasas de Datos Mejoradas
para la evolución de GSM) también conocida como EGPRS (Enhanced GPRS) es
el siguiente estándar que aparece en la telefonía móvil para la transmisión de
datos. Esta tecnología funciona con redes GSM que tengan implementado GPRS
y las actualizaciones necesarias propias de EDGE, por lo que es relativamente
sencilla su implementación por parte de los operadores.
Debido a su compatibilidad con GSM hay autores que la consideran una
tecnología puente entre 2G y 3G, es decir, 2.5G. Sin embargo, EDGE puede
alcanzar una velocidad de transmisión teórica de 384 Kbps, con lo cual cumple los
requisitos de la ITU para una red 3G, también ha sido aceptado por la ITU como
parte de IMT-2000, de la familia de estándares 3G.
EDGE utiliza modulación GMSK (Gaussian Minimum-Shift Keying) y modulación 8-
PSK (8 Phase Shift Keying) para algunos de los esquemas de modulación y
codificación de datos aumentando así su eficacia.
S
UMTS (Universal Mobile Telecommunications System o Servicio Universal de
Telecomunicaciones Móviles) es el nombre con el que se engloban todas las
tecnologías incluidas en 3G desligadas de las redes GSM. Precisamente el hecho
de que los operadores hayan necesitado una gran inversión para implantar las
redes UMTS ha ocasionado un gran retraso en su implementación. Este retraso ha
sido cubierto en muchos casos con las tecnologías intermedias 2.5G. La
tecnología de transmisión utilizada en UMTS es WCDMA.
WCDMA es una tecnología móvil inalámbrica de tercera generación que aumenta
las tasas de transmisión de datos de los sistemas GSM. Utiliza como técnica de 36
multiplexación CDMA (multiplexación por división de código). Soporta de manera
satisfactoria una tasa transferencia de datos que va de 144 hasta 512 Kbps para
áreas de cobertura amplias aunque en el estándar se especifican velocidades de
hasta 2 Mbps. El estándar de WCDMA fue desarrollado como el proyecto de la
sociedad 3GPP, que es el acrónimo de 3rd Generation Partnership Project. Esta
organización realiza la supervisión del proceso de elaboración de estándares
relacionados con 3G.
El despliegue de redes UMTS facilita la aparición del servicio conocido como
Internet móvil ya que las velocidades que se pueden alcanzar con esta tecnología
permiten hacer uso de una gran parte de los servicios ofrecidos en Internet,
típicamente la navegación web. De esta forma aparecen en el mercado tanto
teléfonos móviles que soportan la tecnología 3G como módems 3G utilizados para
proporcionar conectividad a ordenadores. Normalmente la conexión de estos
dispositivos al ordenador es mediante un puerto USB. [12]
5.1.7.2. Red Móvil LTE – 4G
Long Term Evolution, conocido por sus siglas como LTE, es una tecnología de
radio, de alta capacidad, estandarizada por la 3GPP.
LTE es una tecnología de radio acceso de 4ta generación, o 4G, desarrollada en
respuesta a la creciente demanda de alta capacidad de ancho de banda en redes
móviles. LTE se introdujo a partir del Release 8 de la 3GPP, como una evolución a
las redes HSPA (rel.6) e I-HSPA (rel.7) [13].
Las soluciones para redes LTE están basadas en una arquitectura plana, de baja
latencia, y con una tecnología de radio de alta capacidad. LTE es una tecnología
de radio acceso con canales o portadoras de ancho de banda en un rango de
1.4MHz hasta 20MHz. Las bandas de frecuencia estándares en que se
implementa esta tecnología, incluyen las bandas 700MHz, 850MHz, 1700MHz,
1800MHz, 1900MHz, 2100MHz, 2600MHz.
La interfaz de aire comprende tecnologías FDD (Frequency División Duplexing) y
TDD (Time Division Duplexing).
Dependiendo de la tecnología y el ancho de banda de la portadora LTE, el sistema
permite tasas de transferencias de 150Mbps en descarga y de 50Mbps en subida.
El término downlink (bajada) en redes móviles se conoce a la comunicación
en sentido radiobase hacia terminal móvil, mientras que el uplink (subida) se
refiere a la comunicación del terminal móvil hacia la radiobase. [14]
5.1.7.3. VELOCIDAD DE LOS ESTÁNDARES DE LA TELEFONÍA MÓVIL
Tabla con la comparación de la velocidad de transmisión de subida y bajada, que permiten los distintos estándares funcionando actualmente en la telefonía celular. Tabla 1: Comparación de la velocidad de los estándares de la telefonía móvil. [15]
Tecnología Velocidad
promedio de bajada
Velocidad promedio
de subida
GSM (2G) 1.8 kB/s 1.8 kB/s
GPRS (2.5G) 7.2 kB/s 3.6 kB/s
CDMA2000 1×RTT 18 kB/s 18 kB/s
EDGE (2.75G) 29.6 kB/s 29.6 kB/s
UMTS 3G 48 kB/s 48 kB/s
EDGE (type 2 MS) 59.2 kB/s 59.2 kB/s
EDGE Evolution (type 1 MS) 148 kB/s 59 kB/s
EDGE Evolution (type 2 MS) 237 kB/s 118 kB/s
HSPA (3.5G) 1,706 kB/s 720 kB/s
HSPA+ 5.25 MB/s 1.437 MB/s
LTE (2×2 MIMO) 21.625 MB/s 7.25 MB/s
LTE (4×4 MIMO) 40.750 MB/s 10.750 MB/s
6. DESARROLLO DEL PROYECTO
Para el desarrollo del proyecto se parte del punto inicial de lograr obtener la
ubicación en tiempo real de los vehículos (Buses) en el punto de la ruta en donde
se encuentran y visualizarse en una aplicación de usuario.
Mediante el desarrollo de una App con rol de Conductor y utilizando el GPS de los
dispositivos Android, se obtiene las coordenadas de geolocalización, las cuales
serán enviadas de forma periódica a un servidor de Internet y almacenadas sobre
una base de datos. Las coordenadas almacenadas permiten ser consultadas por
la App de Usuario y a su vez visualizarse sobre un mapa de la API de google
maps, mostrando la ubicación del vehículo sobre una ruta previamente creada.
Se implementó un Servicio Web bajo una plataforma desarrollada en Node.JS,
que a su vez funciona como servidor HTTP, donde se integra una página Web que
se encarga de administrar las rutas, buses y conductores. La información recibida
por el servidor Web se envía a la base de datos para ser almacenada y así
organizar los datos de las rutas, buses, conductores y coordenadas enviados por
la aplicación de Android de Conductor. Ver Imagen 1.
Imagen 1. Diagrama de Bloques de la plataforma.
6.1. DESARROLLO DE PLATAFORMA WEB
La plataforma Web se divide en dos partes, el Servicio Aplicación Web para la
transacción de datos de las aplicaciones con rol de Conductor y Usuario y la otra
parte aloja la página web Administradora de los diferentes objetos del sistema;
rutas, buses y conductores y se almacenan sobre la base de datos MySQL
Para soportar la plataforma Web se hizo uso de un VPS (Virtual Private Server) de
Amazon Web Services, el cual proporciona las características necesarias para la
implementación de aplicaciones en la nube.
El servidor de AWS consta de una instancia EC2 con un modelo de servidor
T2.Micro (ver tabla 2), que para fines de etapas de pruebas resulta una opción
bastante eficiente. El sistema operativo está basado en la distribución de Linux
Red Hat.
Tabla 2: Características Instancia EC2 – AWS [16]
Modelo CPU virtual Procesador
físico
Velocidad del
reloj (GHz)
Memoria
(GiB) Almacenamiento
t2.micro 1 Familia Intel
Xeon Hasta 3.3 1 Solo EBS
6.1.1. SERVIDOR PARA TRANSACCIÓN DE DATOS
Con el objetivo de obtener un alto rendimiento al momento de la recepción y envió
de datos, se hizo uso de Node.JS, el cual permite ejecutar aplicaciones del lado
del servidor además permite la recepción de solicitudes HTTP y manejo de
paquetes TCP.
El servidor web consta de múltiples servicios API REST, estos se pueden traducir
como puntos de acceso al servidor los cuales cumplen diferentes funciones a
través del protocolo HTTP, dentro de estas funciones están: GET, POST, PUT y
DELETE, que se encargaran de leer, modificar, eliminar y crear campos en la base
de datos (ver imagen 2).
Imagen 2: Transacciones entre Apps y Servidor Web.
El servidor Web recibe diferentes paquetes de datos en formato JSON que
contienen la información necesaria para realizar las diferentes acciones sobre la
Base de Datos, estos datos provenientes de las aplicaciones de Conductor y
Usuario, transportan información importante como; los datos de autenticación de
usuarios registrados, las coordenadas de los vehículos, la solicitud de las rutas y
las respuestas para actualización de las aplicaciones. Todos estos datos se
almacenan en la Base de Datos de MySQL de forma constante y así permitir su
consulta de forma inmediata.
Código báse del servidor en Node.JS
Servidor HTTP y Servicios REST var express = require('express');
var router = express.Router();
var myParser = require("body-parser");
var db = require('./app_modules/DataBase/Db');
var transactionManger =
require('./app_modules/Manager/TransactionManager');
var FireBase = require('./app_modules/FireBase/FireBase');
var configuration = require('./app_modules/Configuration');
var Login = require('./app_modules/Manager/Login');
var app = express();
app.use(myParser.json({extended: true}));
app.use(myParser.urlencoded({extended: true}));
app.use(router);
app.use(express.static(__dirname + '/public'));
var http = require('http');
/*Inciacion del servidor */
app.listen(8080, function () {
var test = new db.MySqlConnection(db.connection);
setTimeout(function () {
test.testConnection();
}, 1000);
});
/* Captura de errores en el servidor */
process.on('uncaughtException', function (err) {
console.log('Caught exception: ' + err);
});
/* Servcios REST*/
app.post("/Transaction", function (request, response) {
console.log('Transaction');
transactionManger.manageTransaction(request, response);
});
app.post("/Login", function (request, response) {
console.log('Login');
Login.Login(request, response);
});
app.post("/get_routes", function (request, response) {
console.log('get_routes');
transactionManger.getRoutes(request, response);
})
6.1.2. PÁGINA WEB DE ADMINISTRACIÓN
La página de Administración Web, es la plataforma de gestión de rutas, vehículos
y conductores, su función principal se centra en la creación, actualización y
eliminación de estos elementos (ver imagen 3).
El desarrollo se realizó en HTML5, CSS y JavaScript, permitiendo obtener una
interfaz ligera y dinámica en el cambio de los parámetros.
La interfaz principal cuenta con tres módulos de administración, Conductores,
Vehículos y Rutas, los cuales cumplen las funciones principales para la
modificación de los objetos en la base de datos.
6.1.2.1. MÓDULO RUTAS
Este módulo está diseñado para administrar todo el sistema de rutas de los vehículos, su interfaz principal presenta un módulo de creación y otro módulo de listado, edición y eliminación.
Imagen 3: Pantalla Administración de rutas.
Para la creación de las rutas se utilizó JavaScript y las API de Google Maps, estas herramientas permiten seleccionar un mapa, en el que proporcionando las coordenadas se delimita la zona a visualizar.
Para dibujar las rutas, se selecciona un punto origen en el mapa y un punto final, la API de Google Maps se encargará de generar una línea entre estos dos puntos, se marcan tantos puntos como se requiera para dibujar el trayecto completo de una ruta (ver imagen 4).
Para determinar las direcciones físicas en formato catastral de los paraderos se utiliza la API Geocoding de Google Maps, la cual retorna el valor de la dirección según las coordenadas de Latitud y Longitud. [18]
Imagen 4: Pantalla para trazado de rutas y creación de los paraderos.
El mapa resultante con el trazado de la ruta será enviado a las aplicaciones de
Conductor y Usuario según la solicitud realizada por estas (ver imagen 5).
Imagen 5: Tabla de direcciones de los paraderos según Latitud y Longitud.
6.1.2.2. MÓDULO DE VEHÍCULOS
Este módulo permite la creación de los vehículos del sistema, para fines de
pruebas se utilizó la placa como único valor de identificación del vehículo.
La interfaz de este módulo muestra un listado con la cantidad de vehículos
creados y la última posición geográfica reportada desde la App de Conductor.
Tras la creación de los vehículos y después de salvar los cambios, se envía la
información a una tabla de vehículos dentro de la base de datos (ver imagen 6).
Imagen 6: Pantalla de Administración de vehículos.
6.1.2.3. MÓDULO DE CONDUCTORES
Este módulo es el encargado de la administración de los conductores que utilizaran el sistema, así como serán los usuarios que se les permitirá autenticarse desde la aplicación de Android de Conductor (ver imagen 7).
Imagen 7: Pantalla de Administración de usuarios / conductores.
Para la creación de usuarios se diseñó un formulario con algunos campos básicos,
los cuales permiten guardar la información de cada conductor del sistema.
Los campos de “Nombre” y “Documento” se utilizaron como los datos de
autenticación desde la App de Conductor, para poder ingresar al sistema.
Con los datos creados de “Vehículo” y “Ruta” se puede realizar la asignación al
nuevo usuario creado o para fines de modificar usuarios existentes, previamente
creados. Estos datos se almacenan en la base de datos y se asociaran la las
tablas de rutas y vehículos (ver imagen 8).
Imagen 8: Formulario para la creación de usuarios.
6.2. APLICACIÓN NO. 1 – CONDUCTOR
Para determinar la ubicación de los buses de transporte se desarrolló una
aplicación con rol de Conductor, que se encargara de reportar su posición
mediante el uso de las coordenadas geográficas obtenidas a través del GPS del
dispositivo y empaquetarse para enviarse al servidor Web, haciendo uso de la
conexión 3G / LTE del dispositivo.
La aplicación de Conductor se desarrolló teniendo en cuenta algunos aspectos
importantes en su desarrollo:
- Se utilizó el SDK Android Studio, para el desarrollo de la aplicación de
conductor
- Para hacer uso de los servicios de Google se requirió una cuenta de
desarrollador, la cual provee las claves para utilizarse con los servicios de
Google Play Services (Google Maps). [18]
- Uso de los sensores Acelerometro y Magnetometro del dispositivo para
determinar la dirección a la cual está apuntando.
- Uso del sensor GPS interno del dispositivo.
Para la construcción de la aplicación se implementó una pantalla de ingreso de
credenciales de usuario para permitir el acceso sólo a usuarios autorizados en la
plataforma de Administración de Rutas (ver imagen 9), al momento de ingreso se
obtiene del servidor la información de las ruta y vehiculo asociada a la cuenta,
previamente asignada en la plataforma de Administración.
Imagen 9: Pantalla de inicio de sesión – App Conductor.
Tras ingresar con las credenciales de usuario al sistema, se obtiene en la pantalla
la ruta dibujada sobre un mapa de la API de Google Maps (ver imagen 10).
Imagen 10: Pantalla mapa de la ruta– App Conductor.
Sobre la parte Izquierda de la pantalla se puede obtener la información detallada
del conductor y el vehículo (ver imagen 11).
Imagen 11: Pantalla información conductor y vehículo– App Conductor.
Autenticación: Para realizar la autenticación ante el servidor, se
requiere de la información de usuario y contraseña, estas se
empaquetan en un archivo JSON, que será enviado a la API REST -
Login del servidor Web.
JSON Package – Datos de Autenticación {
"URL": "http:\/\/54.213.81.66:8080\/Login",
"DATA": {
"user": "NombreUsuario",
"document": "Contraseña"
}
}
Respuesta del Servidor: El servidor Web después del ingreso
satisfactorio del usuario, retornara a la App de Conductor la información
del trazado de la ruta a seguir, los datos del vehículo y la información del
usuario, esto se entrega en una paquete JSON.
JSON Package – Respuesta con los datos del usuario, vehículo y
ruta {
"id": 6,
"creationUTCTime": 1483806307417,
"lastModificationUTCTime": 1485299948549,
"locked": 0,
"name": "Usuario",
"document": "20111222333",
"phone": "123456789",
"address": "Tv Univerisdad Distrital",
"email": "[email protected]",
"driverLicense": "222333111",
"vehicleId": 4,
"routeId": 21,
"token": null,
"vehicle": {
"id": 4,
"creationUTCTime": 1475866291563,
"lastModificationUTCTime": 1485295062790,
"locked": 1,
"plate": "nueva",
"latitude": 4.67204,
"longitude": -74.0754956,
"driverId": 0
},
"route": {
"id": 21,
"creationUTCTime": 1485299931626,
"lastModificationUTCTime": 1485299931626,
"locked": 0,
"name": "rutaprueba",
"path": [
{
"id": 243,
"routeId": 21,
"position": 0,
"latitude": 4.641103123968215,
"longitude": -74.07857894897461
},
{
"id": 245,
"routeId": 21,
"position": 1,
"latitude": 4.624506373159518,
"longitude": -74.08201217651367
},
{
"id": 244,
"routeId": 21,
"position": 2,
"latitude": 4.6116735672168065,
"longitude": -74.09265518188477
}
],
"stops": [
{
"id": 179,
"routeId": 21,
"position": 0,
"latitude": 4.641103123968215,
"longitude": -74.08029556274414,
"description": "Cdad. Universitaria",
"address": "Ak 30"
},
{
"id": 178,
"routeId": 21,
"position": 1,
"latitude": 4.625704089861983,
"longitude": -74.08355712890625,
"description": "Gran América",
"address": "Av. Cdad. de Quito"
},
{
"id": 177,
"routeId": 21,
"position": 2,
"latitude": 4.613384621418812,
"longitude": -74.09385681152344,
"description": "Av. Nqs - Cl 12",
"address": "Cra. 31 #12-2"
}
]
}
}
Geolocalización: Para determinar la ubicación del vehículo, se hace uso
de la red celular y el sensor GPS del dispositivo, de esta manera se
obtiene su ubicación de forma más precisa. Los datos obtenidos están
delimitados por la Latitud y Longitud terrestre, estos serán enviados al
servidor Web junto con el número de identificación del vehículo en un
paquete JSON, así se puede conocer que vehículo está cambiando de
posición y poder almacenar las coordenadas en la base de datos, para
posteriormente poder ser visualizadas sobre la App de Usuario.
JSON Package – Coordenadas GPS y ID Vehiculo {
"URL": "http:\/\/54.213.81.66:8080\/Transaction",
"DATA": {
"service": "save-entity",
"data":
"{\"clazz\":\"Vehicle\",\"obj\":{\"latitude\":4.67204,\"longitude
\":-74.0754956,\"id\":16}}"
}
}
6.3. APLICACIÓN NO. 2 – USUARIO
La aplicación de Usuario permite obtener un listado de las rutas almacenadas en
la Base de Datos del servidor Web, para ser mostrarse sobre un mapa de la API
de Google Maps. Al seleccionar una ruta, esta mostrará la ubicación de todos los
vehículos asociados a esa ruta y esta se actualizará a medida que los buses se
desplacen por su recorrido.
La aplicación de Usuario se desarrolló teniendo en cuenta algunos aspectos
importantes en su desarrollo:
- Se utilizó el SDK Android Studio, para el desarrollo de la aplicación de
usuario.
- Para hacer uso de los servicios de Google se requirió una cuenta de
desarrollador, la cual provee las claves para utilizarse con los servicios de
Google Play Services (Google Maps). [18]
- Uso de los sensores Acelerometro y Magnetometro del dispositivo para
determinar la dirección a la cual está apuntando.
- Uso del sensor GPS interno del dispositivo
El desarrollo de esta aplicación se centra exclusivamente en visualizar las rutas
disponibles, en el cual se incluye el listado de paraderos de la ruta y su respectiva
visualización con la ubicación en tiempo real de los vehículos asociados a la ruta
(ver imagen 12).
Imagen 12: Pantalla listado de rutas y paraderos de la ruta – App Usuario.
Para la visualización en tiempo real de los vehículos, se agregó dos botones, uno
con función de INICIO y otro con función de DETENER, estos botones iniciaran o
detendrán respectivamente el movimiento de los buses sobre el Mapa (ver imagen
13).
Imagen 13: Pantalla ubicación de los buses de la ruta – App Usuario.
Durante el inicio de la aplicación se hará comprobación del acceso a la red, para
determinar si se actualizan las rutas almacenadas en la DBA del servidor o se
hace uso de las que están almacenadas en la memoria del dispositivo.
Las rutas almacenadas en el dispositivo se guardan en un motor de base de datos
SQLite
6.4. SERVIDOR DE BASE DE DATOS
El servidor de base de datos principal esta implementado bajo MySQL bajo un
modelo relacional, se encarga de almacenar toda la información de la plataforma
Web y aplicaciones móviles.
Imagen 14: Asociación de las diferentes tablas a los usuarios conductores.
6.4.1.1. TABLAS CREADAS EN EL SISTEMA
La distribución de tablas se creó con el fin de optimizar las consultas y su almacenamiento a través de las solicitudes realizadas por las App Conductor y Usuario
Imagen 15: Tablas y atributos de la base de datos.
7. PRUEBAS TÉCNICAS
Para la verificación de la carga del sistema, se emplearon algunas pruebas de
estrés, con las cuales se logra obtener un valor aproximado de la respuesta del
servidor a múltiples solicitudes, en este caso múltiples App de conductor enviando
su posición al servidor y múltiples App de usuario haciendo peticiones de revisión
de estas ubicaciones.
Las mediciones se hicieron utilizando un proveedor de estrés en línea.
URL: http://loadimpact.com
Imagen 16: Prueba de carga con 25 conexiones concurrentes
La respuesta se interpreta por los VUs Actives (Usuarios Virtuales Activos), para
esta prueba es de 25 VUs (ver imagen 16). El VU load time, es el tiempo que le
toma a cada usuario virtual hacer una petición, para este caso el tiempo de carga
con pocos usuarios o muchos usuarios es de aproximadamente 1.5 segundos.
Esto teniendo en cuenta las características del servidor de AWS (ver tabla 2).
Diagrama Final de la “Alternativa de solución para visualización de las rutas y
ubicación geográfica en tiempo real para el sistema de transporte público”
Imagen 16: Diagrama lógico de la plataforma.
8. CONCLUSIONES
Se logra desarrollar la plataforma de manera eficiente para la ubicación de las
rutas y vehículos empleando un dispositivo con Android para el envió de su
ubicación y cambios respectivos de posición y otro dispositivo con Android
para la visualización de estas coordenadas.
La integración de un sistema de autenticación para la aplicación de conductor,
además de agregar seguridad para el acceso, permite identificar el usuario de
un vehículo con el recorrido a realizar según la ruta preestablecida y
adicionalmente se puede obtener las coordenadas mediante el ID único de
usuario.
Con el desarrollo de la aplicación de usuario para la visualización de las rutas
se logró integrar un método para la actualización en tiempo real de los nuevos
recorridos creados en el servidor sin necesidad de hacer actualizaciones
constantes de la App.
Mediante el uso de Node.JS se pueden construir aplicaciones del lado del
servidor, integrado sistemas de fácil escalabilidad según los requerimientos de
las aplicaciones creadas, como por ejemplo número de conexiones
concurrentes a un servicio Web, facilidad para la interconexión de aplicaciones
móviles que requieren un servicio específico sin necesidad de largos códigos
de programación.
El uso de sistemas cliente – servidor en la nube, ahorran tiempo y recursos al
momento de despliegue de infraestructura centralizada, permitiendo obtener
múltiples resultados de desempeño en fases de prueba, para posteriormente
pensar en un posible crecimiento y escalabilidad.
El desarrollo de aplicaciones con sistemas de geolocalización para ubicación
de rutas, representa un gran aporte para la solución de los tiempos de espera
de un bus por parte de los usuarios.
Los dispositivos móviles hoy en día son una buena opción para la solución de
problemas cotidianos, la gran cantidad de sensores y el nivel de
procesamiento que se encuentra dentro de los dispositivos hace de los
dispositivos móviles una muy buena herramienta para desarrollar aplicaciones.
Mediante el desarrollo de App’s para dispositivos móviles y el uso centralizado
de servicios ubicados en Internet, se puede obtener soluciones robustas para
la prestación de servicios a la comunidad y a la industria.
El uso de paquetes de datos en formato JSON hace que sea muy eficiente el
envió de datos a través de la red ya que se puede agregar suficiente
información manteniendo tamaños de paquete muy pequeños, ideales para la
transmisión sobre la red celular.
Mediante el uso de las App en teléfonos de ciertas marcas de fabricantes, se
observan algunos problemas en la ubicación GPS, donde se refleja inexactitud
de la posición o intermitencia del envió de coordenadas debido a defectos de
fabricación de los dispositivos. Google Maps Help Forum: ------
https://productforums.google.com/forum/#!topic/maps/SdncC4XdxTo. GPS is -
- not working: https://forum.xda-developers.com/mate-8/help/gps-t3414443
9. BIBLIOGRAFÍA
[1] Web Site: http://www.malavida.com, “La Historia de Android.” [Online].
Available: http://www.malavida.com/es/post/la-historia-de-android,. [Accessed: 05-
Oct-2016].
[2] Web Site: www.openhandsetalliance.com, “android_overview.” [Online].
Available: http://www.openhandsetalliance.com/android_overview.html. [Accessed:
05-Oct-2016].
[3] G. Svennerberg, Beginning Google Maps API 3, ch. 1: A Brief History, pp. 2-
4, United States, Ed. Apress, 2010.
[4] M. Abernethy, “os-nodejs.” [Online]. Available:
https://www.ibm.com/developerworks/ssa/opensource/library/os-nodejs.
[Accessed: 05-Nov-2016].
[5] J. S. Asenjo, Implantación de Aplicaciones Web 2º ASIR, Servidores de
Aplicaciones Web, Creative-Commons, España, 2011.
[6] R. N. Marset. Modelado, Diseño e Implementación de Servicios Web, ELP,
Departamento de Sistemas Informaticos y Computacion, Universidad Politecnica
de Valencia, 2006 – 2007.
[7] Json.org, Introducción a JSON, [Online]. Available: http://www.json.org/json-
es.html , [Accessed: 9-Feb-2017].
[8] Jorge Sánchez, “Diseño Conceptual de Bases de Datos.” 2004.
[9] “Tipos De Bases De Datos,” El blog de base de datos. [Online]. Available:
http://basededatos.over-blog.net/article-tipos-de-bases-de-datos-68319538.html.
[Accessed: 15-Dic-2016].
[10] “Sistema_de_posicionamiento_global.” [Online]. Available:
https://es.wikipedia.org/wiki/Sistema_de_posicionamiento_global. [Accessed: 05-
Nov-2016].
[11] A. Fernández López, D. González López, A. Rubio Lara, Telefonía Móvil,
Transmisión y Redes de Datos, U.H.U., 2002.
[12] ms.gonzalez, “La transmisión de datos en la telefonía móvil | Redes
Telemáticas.”, [Online]. Available: http://redestelematicas.com/la-transmision-de-
datos-en-la-telefonia-movil/
[13] Nokia Academy, “LTE End to End System Part 1”, Nokia Academy, 2014
[14] Antti Toskala, “LTE Release 8/9 course”, Nokia Academy, 2015
[15] “Las redes de transmisión de datos usadas en los teléfonos celulares,”
NorfiPC. [Online]. Available: http://norfipc.com/celulares/redes-transmision-datos-
usadas-telefonos-celulares.php. [Accessed: 07-Dic-2016].
[16] “Tipos de instancias de Amazon EC2”, [Online]. Available:
https://aws.amazon.com/es/ec2/instance-types
[17] “Google Maps Geocoding API”, [Online]. Available:
https://developers.google.com/maps/documentation/geocoding/intro
[18] “Google Maps Android API”, [Online]. Available:
https://developers.google.com/maps/documentation/android-api/start?hl=es-419
