Dep. de Ingeniería Electrónica Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2016 Proyecto Fin de Carrera Ingeniería de Telecomunicación Sistema de Optimización de Rutas de Transporte Público
Dep. de Ingeniería Electrónica
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2016
Proyecto Fin de Carrera
Ingeniería de Telecomunicación
Sistema de Optimización de Rutas de Transporte
Público
Proyecto Fin de Carrera
Ingeniería de Telecomunicación
Sistema de Optimización de Rutas de
Transporte Público
Autor:
Jesús Otal Cotán
Tutor:
Juan Antonio Sanchez Segura
Profesor titular
Dep. de Ingeniería Electrónica
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2016
Proyecto Fin de Carrera: Sistema de Optimización de Rutas de Transporte Público
Autor: Jesús Otal Cotán
Tutor: Juan Antonio Sanchez Segura
El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes
miembros:
Presidente:
Vocales:
Secretario:
Acuerdan otorgarle la calificación de:
Sevilla, 2016
El Secretario del Tribunal
i
AGRADECIMIENTOS
Muchas son las personas que me han acompañado durante esta etapa de mi vida. Ha sido un
largo y duro camino que sin el apoyo de estas personas no hubiera logrado completar, por ello y
ahora que me acerco al final quisiera dejarles estas palabras de agradecimientos.
En primer lugar, agradecer a mis padres y hermanos, ellos son los que han vivido todos mis
buenos y malos momentos, tenerlos cerca siempre me ha dado fuerzas para seguir adelante.
Agradecer a mi tutor, Juan Antonio Sanchez, no sólo por enseñarme y guiarme durante este
proyecto, si no por todas las mañanas que hemos estado juntos hablando de nuestros proyectos y
nuestras cosas. Poco a poco ha dejado de ser un profesor más, para convertirse en un amigo.
Agradecer también a mis compañeros de carrera, sin sus apuntes y tardes de estudios esto no
hubiera sido posible. Hacer mención especial a David, Isa, Migue y Paco, ellos han hecho más
llevadero todos estos años. Juntos hemos crecido y juntos nos hemos apoyado.
Agradecer a todos mis amigos, tanto los que me han apoyado en la cercanía cómo los que lo
han hecho en la distancia. Mayte, Edith, Piedad, Carlos, Sergio, y muchos nombres más que me
han acompañado en las distintas etapas del camino.
Y por último y no por ello menos importante, quisiera agradecer a la persona culpable de que
eligiera este y no otro proyecto, simplemente, gracias por todo Sara.
Gracias a todos.
Jesús Otal Cotán
Sevilla, 2016
iii
RESUMEN
El objetivo de este proyecto es intentar dar una solución a la problemática que presenta el
transporte público en muchas de sus rutas. Los vehículos realizan diferentes desvíos durante su
trayecto para obtener el mayor número de usuarios. Muchos de estos desvíos son innecesarios al
no encontrar clientes en las paradas, y por ello se pierde mucho tiempo y se realiza kilómetros
extras del que se realizaría con una ruta más directa.
Para dar solución a este problema se realizará un sistema de comunicaciones donde
interactúan varios tipos de clientes con un servidor. Un tipo de cliente se encontrará en los
vehículos, proporcionará información al servidor sobre su posición global y recibirá de él las
solicitudes de los usuarios que se han pedido a través del cliente que se encuentra en las paradas,
o vía aplicación web. El otro tipo de clientes, los que se encuentra en las paradas, se
encargarán por tanto de enviar las solicitudes de petición de parada al servidor y obtener de éste
la información del medio de transporte más cercano. Por último, el servidor se encargará de la
obtención de todos los datos y almacenarlos en una base de datos, y calcular la respuesta
peticionada por ambos clientes. Además almacenará la aplicación web, que servirá para visionar
la posición de los vehículos del sistema en tiempo real, y solicitar de una forma alternativa las
peticiones de parada.
Con dicho sistema, los medios de transportes tomarían las rutas más directas, sólo
realizando los desvíos cuando haya usuarios en las paradas.
v
ÍNDICE
AGRADECIMIENTOS ............................................................................................................ i
RESUMEN.............................................................................................................................. iii
ÍNDICE .................................................................................................................................... v
ÍNDICE DE FIGURAS ........................................................................................................... ix
ÍNDICE DE TABLAS ............................................................................................................ xi
1. Introducción ......................................................................................................................... 1
1.1 Motivación ..................................................................................................................... 1
1.2 ¿En qué consiste el Sistema? .......................................................................................... 2
1.3 Estado del Arte ............................................................................................................... 3
1.3.1 MOVILOC .............................................................................................................. 3
1.3.2 Comparativa ............................................................................................................ 5
1.4 Alcance........................................................................................................................... 5
2. Diseño del Sistema ............................................................................................................... 7
2.1 Introducción ................................................................................................................... 7
2.2 Introducción al estándar GSM ....................................................................................... 7
2.2.1 El concepto de red celular ....................................................................................... 8
2.2.2 Arquitectura de la red GSM .................................................................................... 8
2.3 Introducción al estándar GPRS .................................................................................... 10
2.3.1 Arquitectura de la red GPRS ................................................................................. 10
2.3.2 Calidad de servicio ................................................................................................ 11
2.4 GPS .............................................................................................................................. 11
2.4.1 Protocolo NMEA .................................................................................................. 12
3. Elección de componentes ................................................................................................... 15
3.1 Introducción ................................................................................................................. 15
3.2 Elección de la plataforma de desarrollo ....................................................................... 15
3.2.1 Análisis de alternativas ......................................................................................... 15
3.2.2 Decisión final ........................................................................................................ 19
3.3 Elección de modem GSM/GPRS ................................................................................. 21
3.3.1 Análisis de alternativas ......................................................................................... 21
3.3.2 Decisión final ........................................................................................................ 23
3.4 Elección del módulo GPS ............................................................................................ 24
3.3.1 Análisis de alternativas ......................................................................................... 24
3.3.2 Decisión final ........................................................................................................ 25
4. Servidor y aplicación web .................................................................................................. 27
vi
4.1 Introducción ................................................................................................................. 27
4.2 Conceptos básicos ........................................................................................................ 27
4.2.1 Servidor Web o HTTP .......................................................................................... 27
4.2.2 Cliente Web ........................................................................................................... 27
4.2.3 Base de datos ......................................................................................................... 28
4.2.4 Funcionamiento Cliente-Servidor Web ................................................................. 28
4.2.5 Otras herramientas ................................................................................................ 31
4.3 Diseño y programación del Servidor ............................................................................ 34
4.3.1 Base de datos ......................................................................................................... 34
4.3.2 Scripts Php/JS ....................................................................................................... 37
5. Alojamiento web ................................................................................................................ 43
5.1 Introducción ................................................................................................................. 43
5.2 Tipos de alojamientos .................................................................................................. 43
5.1.1 Alojamiento propio ............................................................................................... 43
5.1.2 Alojamiento gratuito ............................................................................................. 43
5.1.3 Alojamiento compartido........................................................................................ 44
5.1.4 Alojamiento dedicado ........................................................................................... 44
5.1.5 Alojamiento en la nube ......................................................................................... 44
5.3 Decisión final ............................................................................................................... 45
5.4 Xampp .......................................................................................................................... 45
5.4.1 DNS Dinámico ...................................................................................................... 46
5.5 Hostinger ...................................................................................................................... 48
6. Clientes............................................................................................................................... 51
6.1 Introducción ................................................................................................................. 51
6.2 Comandos AT .............................................................................................................. 51
6.2.1 Comandos Generales ............................................................................................. 51
6.2.2 Comandos para el GPS.......................................................................................... 52
6.2.3 Comandos para aplicaciones HTTP ...................................................................... 53
6.3 Diseño y programación del Cliente-Vehículo .............................................................. 55
6.4 Diseño y programación del Cliente-Parada .................................................................. 58
6.5 Interfaz Clientes ........................................................................................................... 60
7. Presupuesto ........................................................................................................................ 63
8. Conclusiones y posibles mejoras ....................................................................................... 65
8.1 Introducción ................................................................................................................. 65
8.2 Adaptación a todas las rutas ......................................................................................... 65
8.3 Aplicación móvil .......................................................................................................... 65
vii
8.4 Adaptación a todos los medios de transportes ............................................................. 65
8.5 Sistema de alimentación de las plataformas de desarrollo ........................................... 65
8.6 Seguridad ..................................................................................................................... 66
8.7 Sistema de pago por el servicio .................................................................................... 66
8.8 Gestor de estadísticas ................................................................................................... 66
REFERENCIAS ..................................................................................................................... 67
GLOSARIO ........................................................................................................................... 69
ESQUEMÁTICO SIM908 ..................................................................................................... 71
ix
ÍNDICE DE FIGURAS
Ilustración 1: Ruta de autobús línea Albaida-Sevilla ............................................................... 1
Ilustración 2: Esquema de Comunicaciones del Sistema ......................................................... 2
Ilustración 3: Sistema MOVILOC ........................................................................................... 3
Ilustración 4: Aplicación Móvil TUSSAM .............................................................................. 5
Ilustración 5: Logo GSM ......................................................................................................... 7
Ilustración 6: Disposición de celdas de estaciones bases ......................................................... 8
Ilustración 7: Arquitectura de la red GSM ............................................................................... 9
Ilustración 8: Órbitas de satélites GPS ................................................................................... 12
Ilustración 9: Logo Arduino ................................................................................................... 15
Ilustración 10: Logo Raspberry Pi ......................................................................................... 16
Ilustración 11: MSP430 Launchpad ....................................................................................... 18
Ilustración 12: Intel Galileo ................................................................................................... 18
Ilustración 13: Pinguino ......................................................................................................... 18
Ilustración 14: Banana Pi ....................................................................................................... 19
Ilustración 15: Arduino Mega 2560 R3 ................................................................................. 21
Ilustración 16: Arduino Uno R3 ............................................................................................. 21
Ilustración 17: Shield GSM/GPRS SIM900 .......................................................................... 22
Ilustración 18: Shield GSM/GPRS M10 ................................................................................ 22
Ilustración 19: Modem TC65 Siemens .................................................................................. 23
Ilustración 20: Shield GSM/GPRS SIM900 Arduino ............................................................ 24
Ilustración 21: Módulo GPS NEO 6M ................................................................................... 25
Ilustración 22: Shield GSM/GPRS/GPS SIM908 .................................................................. 26
Ilustración 23: Logo Apache .................................................................................................. 27
Ilustración 24: Logo MySQL ................................................................................................. 28
Ilustración 25: Logo HTML, JavaScript y CSS ..................................................................... 30
Ilustración 26: Logo Ajax ...................................................................................................... 30
Ilustración 27: Logo PHP ....................................................................................................... 30
Ilustración 28: Relación entre lenguajes de programación lado Cliente y lado Servidor ...... 31
Ilustración 29: Interfaz PhpMyAdmin ................................................................................... 32
Ilustración 30: Tabla geolocalización de la base de datos...................................................... 34
Ilustración 31: Tabla solicitud de la base de datos. ................................................................ 35
Ilustración 32: Tabla paradas de la base de datos. ................................................................. 35
Ilustración 33: Tabla distancias de la base de datos. .............................................................. 36
Ilustración 34: Diagrama de flujo clientevehiculo.php .......................................................... 38
Ilustración 35: Diagrama de flujo clienteparada.php ............................................................. 40
Ilustración 36: Diagrama de flujo index.php .......................................................................... 41
Ilustración 37: Diagrama de flujo funciones.js ...................................................................... 41
Ilustración 38: Interfaz web ................................................................................................... 42
Ilustración 39: Panel de control XAMPP ............................................................................... 46
Ilustración 40: DNS Dinámico NO-IP ................................................................................... 47
Ilustración 41: Configuración router HUAWEI ..................................................................... 47
Ilustración 42: Diagrama de estados Cliente-Vehículo .......................................................... 57
Ilustración 43: Diagrama de estado Cliente-Parada ............................................................... 59
Ilustración 44: Interfaz física Clientes ................................................................................... 60
xi
ÍNDICE DE TABLAS
Tabla 1: Rendimiento según esquemas de codificación GPRS .............................................. 11
Tabla 2: Características modelos de placas Arduino ............................................................. 16
Tabla 3: Características modelo de placas Raspberry Pi ........................................................ 17
Tabla 4: Precios de placas de desarrollo ................................................................................ 20
Tabla 5: Precios modem GSM/GPRS .................................................................................... 23
Tabla 6: Precios módulos GPS ............................................................................................... 25
Tabla 7: Precios API de Google ............................................................................................. 33
Tabla 8: Limitaciones de Hostinger ....................................................................................... 48
Tabla 9: Características soportadas por Hostinger ................................................................. 49
Tabla 10: Información de los servidores de Hostinger .......................................................... 49
Tabla 11: Herramientas del panel de control de Hostinger .................................................... 49
Tabla 12: Pines LCD Nokia 5110 .......................................................................................... 61
Tabla 13: Costes de Materiales .............................................................................................. 63
Tabla 14: Costes de Mano de Obra ........................................................................................ 64
Tabla 15: Importe Total del Proyecto .................................................................................... 64
1. Introducción Proyecto Fin de Carrera
1
1. Introducción
1.1 Motivación
Durante mis años de estudios de Ingeniería de Telecomunicación siempre he viajado en
transporte público. Para desplazarme por la ciudad, para acudir a la Escuela, para visitar otras
ciudades… A lo largo de todos esos años he ido adquiriendo información como usuario habitual
de las virtudes e inconvenientes de usar transporte público. Sobre todo de los problemas
surgidos por los autobuses en los trayectos entre pueblos y la ciudad.
Uno de los problemas que he detectado es la falta de comunicación existente entre los
usuarios que esperan en las paradas de autobuses y los propios autobuses. Esta falta de
comunicación hace la espera una incertidumbre, sin saber si has llegado a tiempo para cogerlo o
ya ha pasado el autobús por tu parada. Aunque si es cierto que en algunas ciudades, como
Sevilla capital, existen aplicaciones móviles que te permiten conocer dicha información, no
sucede así en trayectos entre pueblos.
Otro de los problemas que he observado es que el autobús realiza diversos desvíos de la
carretera principal, sin tener conocimientos de si en dichos desvíos hay usuarios esperando o no.
Teniendo que acudir al lugar y encontrarse la mayoría de las veces que no se encontraba nadie.
Conociendo dichos problemas, surge este proyecto. Este proyecto consiste en diseñar un
sistema de comunicación entre las paradas de transporte público y los medios de transporte para
que el conductor no tenga que dar desvíos innecesarios, reduciendo así, el tiempo entre trayectos
y en combustible. Esta disminución de combustible se resume en un ahorro considerable de
costes para la empresa de transportes, y en menor contaminación para el medio ambiente.
Además, dicho sistema intenta apaliar la falta de información de los usuarios sobre el estado de
los medios de transporte.
A lo largo del proyecto, para facilitar la compresión del mismo, se tomará como ejemplo la
ruta tomada por el autobús de línea Albaida-Sevilla, ya que es la ruta de la cual más información
contengo, y ejemplifica mejor todos los problemas anteriormente mencionados.
Ilustración 1: Ruta de autobús línea Albaida-Sevilla
1. Introducción Proyecto Fin de Carrera
2
1.2 ¿En qué consiste el Sistema?
Para solventar los problemas anteriormente descritos se propone realizar un sistema que
conste de 3 elementos principales.
El primer elemento debe encontrarse en los vehículos / medio de transportes. Debe ser capaz
de obtener la localización en tiempo real de los mismos, así como de recibir las notificaciones
de que hay usuarios en la parada.
El segundo elemento debe encontrarse en las paradas / estaciones. Debe recoger las
solicitudes de los usuarios que desean usar el medio de transporte y proporcionar información
de su estado.
El tercer elemento debe gestionar toda la información llegada por la flota de vehículos y las
solicitudes de los usuarios, de forma que:
-Notifique a los vehículos correspondientes que se ha recibido una solicitud de parada.
-Informe sobre el estado de los vehículos a todas las paradas.
Cómo es obvio, las comunicaciones entre los elementos se deben hacer de forma inalámbrica
ya que los vehículos estarán en continuo movimiento.
Con el sistema propuesto los vehículos circularán por las rutas más directas hacia su destino,
sólo desviándose cuando sea necesario. Y el usuario tendrá en todo momento información de la
localización de los vehículos y el tiempo de espera en la parada.
En la siguiente imagen se muestra el esquema de las comunicaciones. Al primer elemento se
le llamará “Cliente-Vehículo”, al segundo elemento se le llamará “Cliente-Parada”, y al tercer
elemento “Servidor”.
Ilustración 2: Esquema de Comunicaciones del Sistema
1. Introducción Proyecto Fin de Carrera
3
1.3 Estado del Arte
Una vez expuesto el planteamiento del sistema propuesto para solventar los problemas, el
siguiente paso a realizar es un estudio sobre la tecnología ya existente que intenta solucionar la
problemática anteriormente descrita.
Actualmente es fácil encontrar numerosos localizadores GPS que dan la posición global de
cualquier vehículo en tiempo real. Tener un seguimiento del transporte público de cara al
usuario permite solventar uno de los problemas, ya que cualquier usuario que tenga acceso a
dicha información le permite calcular los tiempos aproximados de la llegada del medio de
transporte a las paradas, y tener por tanto mayor control de su tiempo. Sin embargo no se logra
encontrar información sobre la solvencia del segundo gran problema, no existe ningún sistema
donde el usuario interaccione con el medio de transporte, y evitar así los desvíos innecesarios.
Algunos sistemas ofrecen servicios de control de flota de vehículos, debido a su parecido se
estudiará uno de ellos y comparará con el sistema propuesto.
1.3.1 MOVILOC
MOVILOC es un sistema diseñado completamente por el grupo empresarial GMV, dicho
sistema da una solución avanzada de localización y gestión de vehículos que ofrece un amplio
abanico de funcionalidades para que los usuarios tengan un control exhaustivo del trabajo
llevado a cabo por cada uno de los conductores. Conocer los trayectos y kilómetros realizados,
saber si se han cumplido las rutas en tiempo y forma, y controlar que se han cumplido las visitas
diarias establecidas, son algunos de los servicios que MOVILOC proporciona para poder
gestionar su flota de vehículos más eficientemente. MOVILOC utiliza tecnologías GIS, GPS,
GPRS y aplicaciones WEB para obtener toda la información en tiempo real y ofrecer sus
servicios. [1]
Servicios que ofrece MOVILOC:
Localización y Seguimiento en tiempo real
En todo momento se puede saber la localización de cada uno de los vehículos.
Consulta de recorridos realizados
Ilustración 3: Sistema MOVILOC
1. Introducción Proyecto Fin de Carrera
4
Se puede consultar sobre la cartografía o en modo tabla los recorridos realizados por cada
uno de los vehículos.
Gestión de puntos de parada
Puede conocer las paradas que los vehículos han realizado a lo largo de una jornada, el lugar
y el tiempo que duró cada una de ellas.
Control de tiempos de estancia en puntos predefinidos
Posibilidad de crear puntos de interés, que son los lugares de parada habituales de los
vehículos (clientes, oficinas, lugares habituales, etc.). Los informes de visitas a puntos
singulares facilitan a los jefes de flota la consulta de cualquier evento relacionado con los
mismos. De manera rápida y sencilla se puede saber qué trabajador ha visitado a un cliente
determinado, cuándo y cuánto tiempo duró la visita.
Consulta del vehículo más cercano a un lugar (y tiempo estimado de llegada)
Esta funcionalidad es muy útil ya que desde la central se puede consultar que vehículo está
más cercano al lugar donde se ha de realizar un trabajo.
Consulta del estado de las carreteras
Conocer en tiempo real si los vehículos se encuentran atrapados en una carretera por
retenciones
Gestión de alarmas
En tiempo real, el jefe de flota estará informado de las incidencias y situaciones anómalas
que se produzcan en su flota (aviso de entrada/salida o no paso por puntos señalados a horas
programadas, aviso para el mantenimiento de los vehículos, etc.). Estas incidencias son
notificadas de manera inmediata y quedan registradas en la aplicación para futuras consultas
en caso de necesidad.
Gestión de funciones de usuario
Se puede definir diferentes perfiles de usuario, con accesos limitados a la información que
ofrece la aplicación en función de las necesidades.
Gestión de rutas desde el centro de control y envío al vehículo (navegador)
El gestor de flota puede enviar desde el centro de control la ruta que el vehículo debe
realizar para llegar a un punto de trabajo
Mensajería
A través de la consola de mensajes instalada en los vehículos, permite la comunicación
bidireccional entre conductores y centro de control de manera sencilla y económica.
Además todas las comunicaciones mantenidas con los chóferes quedan registradas.
Este sistema está actualmente implementado en la empresa TUSSAM, encargada de
gestionar el servicio de autobuses y tranvías urbanos de Sevilla.
1. Introducción Proyecto Fin de Carrera
5
TUSSAM aprovecha este sistema para ofrecer a los usuarios una aplicación para dispositivos
móviles que permite visualizar, entre otras cosas, los tiempos de llegada de sus vehículos a las
paradas.
A pesar de que MOVILOC ofrece numerosos servicios necesarios para gestionar una flota de
vehículos, ningún servicio sirve para interactuar con el usuario final.
1.3.2 Comparativa
Como se ha estudiado MOVILOC es un sistema muy completo para la gestión/control de
flotas de vehículos, pero carece de funcionalidades donde obtenga información del usuario final.
En cambio, el sistema que se ha propuesto si se enfoca en la información que pueda
proporcionar el usuario para optimizar las rutas/ trayectos de los medios de transportes públicos.
Aun así, ambos sistemas ofrecen información sobre el estado de los vehículos a los usuarios,
y saber de esta forma los tiempos de llegadas de cada medio de transporte.
En definitiva el sistema que se desea realizar podría servir como un servicio complementario
al sistema MOVILOC, o un sistema alternativo que realiza servicios similares a éste.
1.4 Alcance
El objetivo final de este proyecto es el diseño y programación de los 3 elementos del sistema
que se han descrito anteriormente. Para ello la solución buscada optimizará la relación
calidad/costes dentro de las distintas posibilidades.
También se realizará una aplicación web, dónde los usuarios puedan interactuar con el
sistema y visualizar información sobre el mismo.
Puesto que el ámbito de transportes públicos es muy amplio, se escalará el proyecto
centrándonos en la ruta tomada por el autobús de línea Albaida-Sevilla.
Ilustración 4: Aplicación
Móvil TUSSAM
2. Diseño del Sistema Proyecto Fin de Carrera
7
2. Diseño del Sistema
2.1 Introducción
Como se ha descrito anteriormente, el sistema propuesto consta de tres elementos que se
comunican entre sí. Es precisamente en estas comunicaciones donde se debe fijar el eje central
del diseño.
Crear un sistema de comunicaciones desde cero es una tarea bastante compleja y costosa, y
más si estas comunicaciones son inalámbricas y de largo alcance. Habría que fijar frecuencias,
diseñar la arquitectura de red de comunicaciones, protocolos, etc... Afortunadamente existen
tecnologías ya existentes que facilitan la tarea.
En este proyecto se usará la tecnología GSM/GPRS, ya que cumple perfectamente con los
requisitos, comunicaciones inalámbricas; alcance de larga distancia; y arquitectura de red ya
implementada. Además es la tecnología utilizada por el sistema MOVILOC.
En cuanto a la obtención de la localización en tiempo real se usará la tecnología GPS.
2.2 Introducción al estándar GSM
Sistema global para las comunicaciones móviles (del inglés Global System for Mobile
communications, GSM, y originariamente del francés Groupe Spécial Mobile) es un sistema
estándar de telefonía móvil digital. Se denomina estándar "de segunda generación" (2G) porque,
a diferencia de la primera generación de teléfonos portátiles, las comunicaciones se producen de
un modo completamente digital. [2]
Hoy en día, es el sistema digital de comunicaciones que más se usa, permite un rendimiento
máximo de 9,6 kbps, que permite transmisiones de voz y de datos digitales de volumen bajo.
Para ello digitaliza la información y realiza la transmisión asignándole a cada llamada una
ranura de tiempo (TDMA), lo que permite que múltiples llamadas compartan un mismo canal
simultáneamente sin interferir con las demás. Este sistema opera en las bandas 900MHZ y
1800MHZ en Europa, África y Asia y en las bandas 850MHZ y 1900MHZ en Estados Unidos.
La banda 850MHZ también se utiliza para GSM y 3GSM en Canadá, Australia y en varios
países de Latinoamérica.
GSM es el estándar de telecomunicaciones móviles más
extendido en el mundo. La ubicuidad del estándar GSM ha
sido una ventaja tanto para consumidores (beneficiados por
la capacidad de itinerancia y la facilidad de cambio de
operador sin cambiar de terminal, simplemente cambiando la
tarjeta SIM) como para los operadores de red (que pueden
elegir entre múltiples proveedores de sistemas GSM, al ser
un estándar abierto que no necesita pago de licencias).
Además en GSM se implementó por primera vez el servicio de mensajes cortos de texto
(SMS), que posteriormente fue extendido a otros estándares.
Ilustración 5: Logo GSM
2. Diseño del Sistema Proyecto Fin de Carrera
8
2.2.1 El concepto de red celular
Las redes de telefonía móvil se basan en el concepto de celdas, es decir zonas circulares que
se superponen para cubrir un área geográfica.
Ilustración 6: Disposición de celdas de estaciones bases
Las redes celulares se basan en el uso de un transmisor-receptor central en cada celda,
denominado "estación base" (o Estación base transceptora, BTS).
Cuanto menor sea el radio de una celda, mayor será el ancho de banda disponible. Por lo
tanto, en zonas urbanas muy pobladas, hay celdas con un radio de unos cientos de metros
mientras que en zonas rurales hay celdas enormes de hasta 30 kilómetros que proporcionan
cobertura.
En una red celular, cada celda está rodeada por 6 celdas contiguas (por esto las celdas
generalmente se dibujan como un hexágono). Para evitar interferencia, las celdas adyacentes no
pueden usar la misma frecuencia. En la práctica, dos celdas que usan el mismo rango de
frecuencia deben estar separadas por una distancia equivalente a dos o tres veces el diámetro de
la celda.
2.2.2 Arquitectura de la red GSM
En una red GSM, la terminal del usuario se llama estación móvil (MS). Una estación móvil
está constituida por una tarjeta SIM (Módulo de identificación de abonado), que permite
identificar de manera única al usuario y a la terminal móvil, o sea, al dispositivo del usuario
(normalmente un teléfono portátil).
Las terminales (dispositivos) se identifican por medio de un número único de identificación
de 15 dígitos denominado IMEI (Identificador internacional de equipos móviles). Cada tarjeta
SIM posee un número de identificación único (y secreto) denominado IMSI (Identificador
internacional de abonados móviles). Este código se puede proteger con una clave de 4 dígitos
llamada código PIN.
Por lo tanto, la tarjeta SIM permite identificar a cada usuario independientemente de la
terminal utilizada durante la comunicación con la estación base. Las comunicaciones entre una
estación móvil y una estación base se producen a través de un vínculo de radio, por lo general
denominado interfaz de aire (o en raras ocasiones, interfaz Um).
2. Diseño del Sistema Proyecto Fin de Carrera
9
Ilustración 7: Arquitectura de la red GSM
Todas las estaciones base de una red celular están conectadas a un controlador de
estaciones base (o BSC), que administra la distribución de los recursos. El sistema compuesto
del controlador de estaciones base y sus estaciones base conectadas es el Subsistema de
estaciones base (o BSS).
Por último, los controladores de estaciones base están físicamente conectados al Centro de
conmutación móvil (MSC) que los conecta con la red de telefonía pública y con Internet; lo
administra el operador de la red telefónica. El MSC pertenece a un Subsistema de conmutación
de red (NSS) que gestiona las identidades de los usuarios, su ubicación y el establecimiento de
comunicaciones con otros usuarios.
Generalmente, el MSC se conecta a bases de datos que proporcionan funciones adicionales:
El Registro de ubicación de origen (HLR): es una base de datos que contiene información
(posición geográfica, información administrativa, etc.) de los abonados registrados dentro de la
zona del conmutador (MSC).
El Registro de ubicación de visitante (VLR): es una base de datos que contiene información
de usuarios que no son abonados locales. El VLR recupera los datos de un usuario nuevo del
HLR de la zona de abonado del usuario. Los datos se conservan mientras el usuario está dentro
de la zona y se eliminan en cuanto abandona la zona o después de un período de inactividad
prolongado (terminal apagada).
El Registro de identificación del equipo (EIR): es una base de datos que contiene la lista de
terminales móviles.
El Centro de autenticación (AUC): verifica las identidades de los usuarios.
2. Diseño del Sistema Proyecto Fin de Carrera
10
El sistema GSM también comunica con otras redes como la red telefónica conmutada
pública (PSTN), la red digital de servicios integrados (ISDN), la red de datos pública de
conmutación de circuitos (CSPDN) y la red de datos pública de conmutación de paquetes
(PSPDN).
La red celular compuesta de esta manera está diseñada para admitir movilidad a través de la
gestión de traspasos (movimientos que se realizan de una celda a otra).
Finalmente, las redes GSM admiten el concepto de roaming: el movimiento desde la red de
un operador a otra.
2.3 Introducción al estándar GPRS
El estándar GPRS (General Packet Radio Service) es una evolución del estándar GSM y es
por eso que en algunos casos se denomina GSM++ (o GMS 2+). Dado que es un estándar de
telefonía de segunda generación que permite una transición hacia la tercera generación (3G), el
estándar GPRS por lo general se clasifica como 2.5G.[3][4]
GPRS extiende la arquitectura del estándar GSM para permitir la transferencia de datos del
paquete con una tasa de datos teóricos de alrededor de 171,2 Kbits/s (hasta 114 Kbits/s en la
práctica). Gracias a su modo de transferencia en paquetes, las transmisiones de datos sólo usan
la red cuando es necesario. Por lo tanto, el estándar GPRS permite que el usuario reciba facturas
por volumen de datos en lugar de la duración de la conexión, lo que significa especialmente que
el usuario puede permanecer conectado sin costo adicional.
Para el transporte de voz, el estándar GPRS emplea la arquitectura de red GSM y provee
acceso a la red de datos (especialmente Internet) por medio del protocolo IP o del protocolo
X.25.
GPRS admite características nuevas que no están disponibles en el estándar GSM y que se
pueden clasificar en los siguientes tipos de servicios:
Servicio de punto a punto (PTP): es la capacidad de conectarse en modo cliente-
servidor a un equipo en una red IP.
Servicio de punto a multipunto (PTMP): constituye la capacidad de enviar paquetes a
un grupo de destinatarios (Multidifusión).
Servicio de mensajes cortos (SMS).
2.3.1 Arquitectura de la red GPRS
La integración de GPRS a una arquitectura GSM requiere que se añadan nuevos nodos de
red denominados GSN (nodos de soporte GPRS) ubicados en una red de transporte:
El router SGSN (Nodo de soporte de servicio GPRS) gestiona las direcciones de las
terminales de la celda y proporciona la transferencia de la interfaz de paquetes con la
pasarela GGSN.
La pasarela GGSN (Nodo de soporte de pasarela GPRS) se conecta con otras redes de
datos (Internet). En particular, GGSN debe proporcionar una dirección IP a las
terminales móviles durante toda la conexión.
2. Diseño del Sistema Proyecto Fin de Carrera
11
2.3.2 Calidad de servicio
GPRS integra el concepto de calidad de servicio (abreviado QoS), que representa la
capacidad de adaptar el servicio a las necesidades de una aplicación. Los criterios de calidad de
servicio son los siguientes:
Prioridad
Confiabilidad GPRS define dos clases de confiabilidad:
Demora
Rendimiento
El estándar GPRS especifica 4 esquemas de codificación, llamados CS-1, CS-2, CS-3 y CS-
4. Cada uno define el nivel de protección de los paquetes contra interferencias para poder
degradar la señal según la distancia entre las terminales móviles y las estaciones base. Cuanto
mayor sea la protección, menor será el rendimiento:
Esquema de
codificación Rendimiento Protección
CS-1 9,05 Kbit/s Normal (señalización)
CS-2 13,4 Kbit/s Ligeramente menor
CS-3 15,6 Kbit/s Reducida
CS-4 21,4 Kbit/s Sin error de conexión
Tabla 1: Rendimiento según esquemas de codificación GPRS
2.4 GPS
El sistema de posicionamiento global (GPS) es un sistema que permite determinar en todo el
mundo 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. [5]
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.
Los satélites son alimentados por energía solar, y tienen baterías de repuesto para usarlas en
el caso de un eclipse solar. Pequeños cohetes en cada satélite los mantiene con precisión en sus
órbitas. Cada satélite pesa entre 3.000-4.000 libras, y tiene una vida útil proyectada de 10 años.
Constantemente se construyen y lanzan a órbita satélites de reemplazo.
Cada uno de estos 24 satélites circunda la Tierra dos veces al día en una órbita muy precisa,
a aproximadamente 7.000 millas por hora. Orbitan a aproximadamente 12.000 millas sobre la
Tierra, y la constelación de satélites está situada de modo que hay al menos cuatro satélites
visibles en el cielo en un momento dado.
2. Diseño del Sistema Proyecto Fin de Carrera
12
Los satélites GPS transmiten dos señales de
radio de baja potencia, una para uso civil y otra
para uso militar. La señal civil se emite en 1575.42
MHz en la banda UHF. Al igual que todas las
señales de radio, las señales GPS viajan en línea
recta y no pasan a través de objetos sólidos
gruesos.
Cuando se desea determinar la posición, el
receptor que se utiliza para ello localiza
automáticamente como mínimo cuatro 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, la cual se basa en
determinar la distancia de cada satélite respecto 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 coordenadas reales 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 llevan a bordo cada uno de
los satélites.
2.4.1 Protocolo NMEA
NMEA son las siglas de “National Marine Electronics Association”, dicha asociación se
fundó con la intención de ayudar a crear un sistema estándar de comunicaciones entre distintos
fabricantes de aparatos electrónicos para barcos. La idea era desarrollar unas especificaciones
comunes tanto a nivel de protocolos de comunicaciones como a nivel de conexiones. [6]
Actualmente dicho protocolo está muy extendido en todo el mundo, siendo los sistemas GPS
los que más lo utilizan.
El estándar NMEA tiene dos protocolos fuertemente diferenciados: NMEA 0183 y NMEA
2000. Este último es un sistema mucho más novedoso. Dentro de cada uno de estos grupos
también hay versiones específicas que mejoran el rendimiento o aumentan las opciones.
NMEA 2000: Este protocolo es una versión más moderna. Es totalmente diferente a su
predecesor y en lugar de trabajar con puertos serie utiliza como base de trabajo el sistema
CANBUS, muy extendido en la industria y sobre todo en el campo de los automóviles.
NMEA 0183: Es un lenguaje electrónico estándar que permite a diversos equipos de distintos
fabricantes interactuar unos con otros. El formato de mensaje que se emite para este protocolo
consiste en una cabecera y una relación de datos. Para los GPS receptores la cabecera está
formada por las letras “$GP” junto a las 3 letras que nombran la sentencia.
A continuación se analizarán las sentencias más utilizadas por los GPS receptores.
Ilustración 8: Órbitas de satélites GPS
2. Diseño del Sistema Proyecto Fin de Carrera
13
2.4.1.1 $GPGGA
Las sentencias $GPGGA proporciona el posicionamiento global de datos fijos del sistema.
La manera de interpretarla es la siguiente, teniendo en cuenta que la numeración, es la posición
de la trama separada por comas:
$GPGGA,1,2,3,4,5,6,7,8,9,10,11,12,13,14*15
1. Hora UTC (Tiempo Universal Coordinado) en formato: hhmmss.
2. Latitud en formato: gggmm.ssss.
3. Orientación en latitud: N (Norte) o S (Sur).
4. Longitud en formato:gggmm.ssss.
5. Orientación en longitud: E (Este) o W (Oeste).
6. Indicación de calidad GPS: 0=nula; 1= precisión GPS.
7. Número de satélites visibles por el receptor: nn.
8. Dilución horizontal de posición: xx.x.
9. Altitud de la antena por encima / por debajo del nivel del mar (geoidal): xxxxx.x.
10. Unidades de altitud: M (metros).
11. Separación geoidal: xxx.x.
12. Unidades de separación: M (metros).
13. Tiempo en segundos desde la última actualización:xx.
14. ID de referencia de la estación.
15. Checksum.
2.4.1.2 $GPSGLL
La sentencia $GPSGLL proporciona la posición geográfica, latitud / longitud. La manera de
interpretarla es la siguiente, teniendo en cuenta que la numeración, es la posición de la trama
separada por comas:
$GPGLL,1,2,3,4,5,6,*7
1. Latitud en formato: gggmm.ssss.
2. Orientación en latitud: N (Norte) o S (Sur).
3. Longitud en formato: gggmm.ssss.
4. Orientación en longitud: E (Este) o W (Oeste).
5. Hora UTC (Tiempo Universal Coordinado) en formato: hhmmss.
6. A (Datos Activo) o V (Vacío)
7. Checksum.
2. Diseño del Sistema Proyecto Fin de Carrera
14
2.4.1.3 $GPGSA
La sentencia $GPSGSA proporciona la calidad de la señal GPS y satélites activos. La
manera de interpretarla es la siguiente, teniendo en cuenta que la numeración, es la posición de
la trama separada por comas:
$GPGSA,1,2,3,,,,,,,,,,,,4,5,6*7
1. A (Selección automática 2D o 3D) o M (Manual).
2. Precisión 3D: 1= ninguna, 2= precisión 2D, 3= precisión 3D
3. Números PRN de los satélites utilizados para la fijación (espacio para 12).
4. Dilución de precisión de posición (PDOP).
5. Dilución de precisión horizontal (HDOP).
6. Dilución de precisión vertical (VDOP).
7. Checksum
2.4.1.4 $GPGSV
La sentencia $GPSGSV proporciona Información de cada satélite. La manera de interpretarla
es la siguiente, teniendo en cuenta que la numeración, es la posición de la trama separada por
comas:
$GPGSV,1,2,3,4,5,6,7,,,,,,,,,,,,*8
1. Número de sentencias por completo de datos.
2. Sentencia a la cual se está refiriendo.
3. Número de satélites a la vista.
4. Número PNR del satélite.
5. Elevación en formato: gg
6. Acimutal en formato: gg
7. Relación señal a ruido (SNR).
Se repiten los datos hasta 4 satélites por sentencias.
8. Checksum.
Notas: g = grados, m= minutos, s= segundos, h= horas. El número de letras indica las cifras
que contiene ese campo, y el punto indica la coma decimal.
3. Elección de componentes Proyecto Fin de Carrera
15
3. Elección de componentes
3.1 Introducción
En el mercado existen numerosos modem que permiten comunicaciones GSM/GPRS. Estos
modem suelen tener un puerto serie desde el cual poder ser controlados mediante comandos AT
por un microcontrolador externo o un ordenador. Igualmente sucede con los módulos GPS, por
ello la primera elección que se debe realizar es la/s plataforma/s de desarrollo que se va a
encargar de gestionar las aplicaciones de cada uno de los elementos del sistema propuesto. Y
posteriormente elegir el modem GSM/GPRS o módulo GPS que mejor se adapte a este.
3.2 Elección de la plataforma de desarrollo
Para la elección del que será el cerebro del sistema también surgen numerosas alternativas
posibles. Por ello es conveniente realizar un análisis de algunas de ellas y finalmente elegir la
mejor alternativa para cada uno de los tres elementos.
3.2.1 Análisis de alternativas
Una de las alternativas es el diseño/creación de una plataforma de desarrollo propia eligiendo
un microcontrolador y adaptarlo a cualquiera de los modem GSM/GPRS que se encuentre en el
mercado. Pero esta alternativa requiere de mucha complejidad, de mayor tiempo y esfuerzo que
otras alternativas. Aunque si da total flexibilidad para diseñar el hardware del sistema, sin estar
sujeto a ningún tipo de restricción.
Otra alternativa es acudir a plataformas de hardware libre existentes en el mercado, para ello
se analizarán las más conocidas, ya que facilitan mucho la posterior programación, y la
detección de posibles fallos en el sistema debido a la gran información que hay hoy en día sobre
estas plataformas. Entre las distintas plataformas de desarrollo que se pueden encontrar, las más
conocidas son Arduino y Raspberry Pi.
3.2.1.1 Arduino
Arduino es una plataforma de hardware libre,
basada en una placa con un microcontrolador y un
entorno de desarrollo, diseñada para facilitar el uso
de la electrónica en proyectos multidisciplinares. [7]
El hardware consiste en una placa con un
microcontrolador Atmel AVR y puertos de
entrada/salida. Los microcontroladores más usados
son el Atmega168, Atmega328, Atmega1280, y
Atmega8 por su sencillez y bajo coste que permiten
el desarrollo de múltiples diseños. Por otro lado el
software consiste en un entorno de desarrollo que
implementa el lenguaje de programación
Processing/Wiring y el cargador de arranque que es
ejecutado en la placa. Se programa en el ordenador para que la placa controle los componentes
electrónicos.
Ilustración 9: Logo Arduino
3. Elección de componentes Proyecto Fin de Carrera
16
Arduino puede tomar información del entorno a través de sus entradas analógicas y digitales,
puede controlar luces, motores y otros actuadores. El microcontrolador en la placa Arduino se
programa mediante el lenguaje de programación Arduino (basado en Wiring) y el entorno de
desarrollo Arduino (basado en Processing). Los proyectos hechos con Arduino pueden
ejecutarse sin necesidad de conectar a un ordenador. [8]
Las especificaciones de los modelos de placas Arduino más conocidos se resumen en la
siguiente tabla:
Modelo Microcontrolador Frecuencia
de Reloj
Digital
I/O
Entradas
Analógicas PWM UART
Memoria
Flash
Arduino
Due AT91SAM3X8E 84MHz 54 12 12 4 512Kb
Arduino
Leonardo ATmega32U4 16MHz 20 12 7 1 32Kb
Arduino
Uno R3 ATmega328 16MHz 14 6 6 1 32Kb
Arduino
Mega 2560
R3
ATmega2560 16MHz 54 16 14 4 256Kb
Tabla 2: Características modelos de placas Arduino
3.2.1.2 Raspberry Pi
Raspberry Pi es una placa computadora
(SBC) de bajo costo desarrollada en Reino
Unido por la Fundación Raspberry Pi, con el
objetivo de estimular la enseñanza de ciencias
de la computación en las escuelas. [9]
En realidad, se trata de una diminuta placa
base de 85 x 54 milímetros en el que se aloja
un chip Broadcom BCM2835 con procesador
ARM hasta a 1 GHz de velocidad (modo
Turbo haciendo overclock), GPU VideoCore
IV y 512 Mbytes de memoria RAM (Las primeras placas contaban con sólo 256MB de RAM).
Para que funcione, se necesita un medio de almacenamiento (Raspberry Pi utiliza tarjetas de
memoria SD o microSD), conectarlo a la corriente utilizando cualquier cargador microUSB de
al menos 1000mah para las placas antiguas y de al menos 2000mah para las modernas.
En función del modelo que se escoja, se dispondrá de más o menos opciones de conexión,
aunque siempre tendrá al menos un puerto de salida de video HDMI y otro de tipo RCA,
minijack de audio y un puerto USB 2.0 (modelos A y A+, B dispone de dos USB y B+ y
Raspberry Pi 2 disponen de 4 USB) al que conectar un teclado y ratón.
En cuanto a la conexión de red, se dispone de un puerto Ethernet (los modelos A y A+ no
disponen de puerto Ethernet) para enchufar un cable RJ-45 directamente al router o se puede
recurrir a utilizar cualquier adaptador inalámbrico WiFi compatible.
Ilustración 10: Logo Raspberry Pi
3. Elección de componentes Proyecto Fin de Carrera
17
Con respecto al software, se le pueden instalar diversos sistemas operativos, siendo su
sistema operativo oficial una versión adaptada de Desbian, denominada Raspbian. [10]
Las especificaciones de las diferentes placas de Raspberry Pi se muestran en la siguiente
tabla:
Características Raspberry Pi
Model A+
Raspberry Pi
Model B+
Raspberry Pi 2
Model B
SoC BCM2835 BCM2835 BCM2836
Fabricante Broadcom Broadcom Broadcom
CPU ARM1176JZF-S ARM1176JZF-S ARM Cortex-A7
Instrucciones ARMv6 ARMv6 ARMv7
Cores Single-core Single-core Quad-core
Velocidad 700MHz 700MHz 900MHz
RAM 256MB 512MB 1024MB
Almacenamiento MicroSD slot MicroSD slot MicroSD slot
GPU 250MHz Broadcom
VideoCore IV
250MHz Broadcom
VideoCore IV
250MHz Broadcom
VideoCore IV
Conexiones
-HDMI
-1x USB2 port
-40 GPIO pins
-MIPI camera
connector
-MIPI display DSI
-Vídeo compuesto
(PAL y NTSC) vía
3.5 mm TRRS jack
compartido con
audio estéreo
-HDMI
-4x USB2 ports
-10/100 Ethernet
-40 GPIO pins
-MIPI camera
connector
-MIPI display DSI
-Vídeo compuesto
(PAL y NTSC) vía 3.5
mm TRRS jack
compartido con audio
estéreo
-HDMI
-4x USB2 ports
-10/100 Ethernet
-40 GPIO pins
-MIPI camera
connector
-MIPI display DSI
-Vídeo compuesto
(PAL y NTSC) vía 3.5
mm TRRS jack
compartido con audio
estéreo
Alimentación 5 V a 2A micro USB 5 V a 2A micro USB 5 V a 2A micro USB Tabla 3: Características modelo de placas Raspberry Pi
3.2.1.3 Otras plataformas
Existen numerosas plataformas de hardware libre aparte de las ya mencionadas, Arduino y
Raspberry Pi. Y aunque sean menos conocidas resulta interesante conocer un poco de ellas. .
3.2.1.3.1 MSP430 Launchpad
La tarjeta MSP430 Launchpad es una herramienta de desarrollo y de evaluación para los
dispositivos MSP-430 de Texas Instruments. [11]
3. Elección de componentes Proyecto Fin de Carrera
18
La tarjeta dispone de un socket de 20 pines que puede albergar uno de los dos
microcontroladores de 16 bits de la familia MSP430 que vienen con el kit, dispone además de
una conexión USB que permite descargar y depurar programas directamente en el hardware.
La tarjeta MSP-EXP430G2 viene con 2
microcontroladores MSP430, con 16KB de Flash, 512B
RAM, 16Mhz de velocidad e integrado con periféricos
como conversor AD de 10bits, timers, comunicación serial
(UART, I2C y SPI).
3.2.1.3.2 Intel Galileo
La Intel Galileo es una placa de desarrollo Open Hardware basado en el procesador Quark
SoC X1000 de 32bits de Intel con una velocidad de 400MHz. Está diseñada para ser compatible
con el IDE de Arduino y con las Arduino Shields. Su hardware incluye los mismos pins que un
Arduino Uno Rev 3, además de un conector Ethernet, un zócalo para tarjetas microSD, USB
Host, puerto serie RS-232, un puerto mini PCI Express (mPCIE) y 8 MByte NOR Flash. [12]
La diferencia entre la Galileo y una
placa Arduino normal la marca el hecho de
poder combinar la estructura de hardware y
software del Arduino con el sistema
operativo Linux. Gracias a esto, se puede
controlar hardware como sensores o
motores con otros lenguajes de
programación cómo Python o Node.js,
conectarlos a Internet, crear un servidor o
tener acceso a fecha y tiempo real entre
otras muchas posibilidades de computación
comunes en una plataforma x86.
3.2.1.3.3 Pinguino
Pinguino es una plataforma de hardware y
software "open source" para la experimentación
con microcontroladores, similar a Arduino pero
basada en un microcontrolador PIC18F2550 y
cuenta con su propio Entorno de Desarrollo
Integrado de uso y apariencia similar al de
Arduino. A diferencia de la placa Arduino, el
Pinguino no necesita una Interfaz UART a USB
adicional para comunicarse con la PC, debido a
que el microcontrolador PIC18F2550 tiene un
Ilustración 12: Intel Galileo
Ilustración 13: Pinguino
Ilustración 11: MSP430 Launchpad
3. Elección de componentes Proyecto Fin de Carrera
19
módulo USB integrado, lo cual le permite comunicarse directamente con la PC y reduce el costo
del hardware, dejando además libre el puerto UART del microcontrolador para las aplicaciones.
[13]
Algunas características de esta placa son:
-Este trabaja con un cristal de 20 MHz y es compatible con USB 2.0.
-18 entradas/salidas digitales con 5 entradas analógicas compartidas.
-UART para comunicaciones seriales.
-2 salidas PWM rápidas (3000 Hz).
-5 entradas analógicas.
3.2.1.3.4 Banana Pi
Banana Pi es un miniordenador muy similar al concepto de la Rapsberry Pi. El
funcionamiento de este miniordenador es muy similar al de otros miniordenadores. Su sistema
operativo se instala en una tarjeta SD y desde ella se ejecuta el sistema operativo preferido por
los usuarios. Se puede instalar varios sistemas operativos de manera que una única tarjeta puede
tener Debian y Android. El conector Sata ayuda a conectar un disco duro fácilmente, por
ejemplo, para utilizar Banana Pi como un servidor de almacenamiento. [14]
En cuanto a las características hardware que ofrece Banana Pi son:
-Procesador ARM7 Dual Core 1Ghz
-1GB de RAM DDR3
-GPU ARM MALI400
-Gibabit Ethernet
-Conexión infraroja
-Micrófono
-Conector SATA para disco duro
3.2.2 Decisión final
El único criterio fijado hasta ahora para la elección de la plataforma de desarrollo es que al
menos tenga un puerto serie para la comunicación del modem GSM/GPRS mediante comandos
AT. Todas las alternativas anteriormente cumplen con este requisito, por ello, hay que acudir a
otros criterios de selección.
Uno de los criterios que se debería tener en cuenta es el precio. Por tanto, para la decisión
final se tendrá en cuenta optimizar la relación calidad/precio que ofrecen las diferentes
plataformas.
A continuación se muestra una tabla con los precios aproximados de las diferentes
alternativas estudiadas anteriormente.
Ilustración 14: Banana Pi
3. Elección de componentes Proyecto Fin de Carrera
20
Arduino
Modelo Precio
Arduino Due 12-15 €
Arduino Leonardo 5-8 €
Arduino Uno R3 5-8 €
Arduino Mega 2560 R3 8-12 €
Raspberry Pi
Modelo Precio
Raspberry Pi Model A+ 20-25 €
Raspberry Pi Model B+ 30-35 €
Raspberry Pi 2 Model B 40-45 €
Otras Plataformas
Modelo Precio
MSP430 Launchpad 9-10 €
Intel Galileo 60-65 €
Pingüino 5€
Banana Pi 40-45 € Tabla 4: Precios de placas de desarrollo
Como se observa los precios más caros son los modelos de la Raspberry Pi y las plataformas
Intel Galileo y Banana Pi, esto es así porque realmente no son una plataforma de desarrollo
basadas en microcontroladores, sino que son ordenadores con dimensiones reducidas. Las
plataformas basadas en microcontroladores, Arduino, MSP430 Launchpad y Pinguino, aportan
mayor facilidad para conectarse con diferentes elementos, en cambio, los ordenadores aportan
mayor potencia de cálculo. Son productos diferentes que pueden abordar un mismo problema e
incluso complementarse.
Para el proyecto que se desea realizar, solo el Servidor requiere de una potencia de cálculo
elevada, por ello se optará por plataformas de desarrollo basadas en microcontroladores tanto en
los Clientes-Vehículos como en los Clientes-Paradas y así aprovechar su facilidad para
conectarse con los modem GSM/GPRS y GPS. Para el Servidor se utilizará un servicio de
alojamiento dedicado o un ordenador cualquiera, pudiendo ser alguno de los ordenadores
anteriormente mencionados.
De entre las plataformas basadas en microcontroladores la que ofrece mayor versatilidad,
facilidad de uso y mayor información de uso es Arduino. Por ello, finalmente se optará por esta
opción.
Para los Clientes-Vehículos, se usará el modelo Arduino Mega 2560 R3 puesto que contiene
4 puertos series. De esta forma podrá comunicarse con el módulo GPS y el modem GSM/GPRS
por canales de comunicación serie independientes.
3. Elección de componentes Proyecto Fin de Carrera
21
Para los Clientes-Paradas, a diferencia de los Clientes-Vehículos, no necesita comunicación
con un módulo GPS, puesto que son elementos fijos en las paradas/estaciones de medios de
transporte. Por tanto, un único puerto serie será necesario para comunicación con el modem
GSM/GPRS. Por ello la elección final será el modelo Arduino Uno R3.
3.3 Elección de modem GSM/GPRS
Una vez decidida las plataformas de desarrollos que se van a utilizar para cada uno de los
elementos del sistema, toca elegir cual modem GSM/GPRS se adapta mejor a dichas
plataformas.
3.3.1 Análisis de alternativas
Existen múltiples opciones que ofrece el mercado para la elección de los modem
GSM/GPRS. Dentro de las alternativas posibles, se pueden diferenciar entre las que pueden ir
acopladas directamente a las plataformas de desarrollo ya elegidas y las que necesitan cableado
para la conexión entre la plataforma y el modem. Se analizaran las alternativas más conocidas
del mercado.
3.3.1.1 Shield GSM/GPRS SIM900
En el mercado existen múltiples modelos de shields (escudos) para Arduino y/o Raspberry
Pi que contienen el modem cuatribanda basado en el chip SIM900, que funciona en la
frecuencias EGSM 900MHz/DCS 1800MHz y GSM850 MHz/PCS 1900MHz. Dichos escudos
se pueden conectar directamente en la parte superior de la placa Arduino o Raspberry Pi. [15]
Como ya se ha comentado anteriormente la comunicación del Arduino o Raspberry Pi con
el modem se realiza mediante los pines de TX, RX y GND del puerto serie.
Ilustración 15: Arduino Mega 2560 R3
Ilustración 16: Arduino Uno R3
3. Elección de componentes Proyecto Fin de Carrera
22
Dentro del hardware de los diferentes shields, se suelen encontrar los siguientes dispositivos:
Modem GSM/GPRS basado en el chip SIM900
Conectores de entrada y salida de audio (para realizar o recibir llamadas)
Reloj RTC, con batería de respaldo
Varios pines de GPIO libres controlables mediante comandos AT
Opción para conexión RS232 vía hardware o software
3.3.1.2 Shield GSM/GPRS M10
Es el shield GSM/GPRS oficial de Arduino y está
basado en el chip M10. Al igual que las Shield
GSM/GPRS SIM900 se conecta directamente a la placa
de Arduino. Tiene soporte oficial de Arduino y por tanto
librerías oficiales. Carece de dispositivos adicionales en
la propia shield pero si existe la posibilidad de
conectarlos.
3.3.1.3 Siemens TC65
El módem Siemens TC65 es un terminal para la comunicación machine-to-machine. Con
características como la plataforma de desarrollo Java y varias interfaces industriales estándar.
Las interfaces que dispone son:
Conector Antena SMA 50 ohmios
9x Conectores D-sub para comunicaciones series
Conector Micro-N-lok 24 pines
- I2C bus
- SPI bus
- Múltiples GPIO
- 2x Entradas analógicas (ADC)
Ilustración 17: Shield GSM/GPRS SIM900
Ilustración 18: Shield GSM/GPRS M10
3. Elección de componentes Proyecto Fin de Carrera
23
A diferencia de los shields, este módem no
puede ser acoplado directamente a las
plataformas de desarrollo elegidas. Habría que
cablear desde uno de los puertos series del
modem hasta el puerto serie del Arduino.
3.3.2 Decisión final
De entre las alternativas estudiadas, tanto los shields GSM/GPRS SIM900 como los M10
son los que mejor se adaptan al sistema, ya que se acoplan directamente a nuestras plataformas
de desarrollo. Aun así, es necesario analizar los costes de todas las alternativas para ver cual
resulta la idónea.
En la siguiente tabla se muestran los precios aproximados de cada una de las alternativas:
Modelo Precio
Shield GSM/GPRS SIM900 20-35 €
Shield GSM/GPRS M10 65-70 €
TC65 Siemens 230 € Tabla 5: Precios modem GSM/GPRS
Como se observa el modem TC65 de Siemens, aparte de que no se acopla a nuestra
plataforma de desarrollo sale bastante caro para lo necesario en este proyecto. En cuanto a los
shields, el basado en el chip M10 a pesar de ser el oficial, y tener soporte de Arduino, es menos
usado que el basado en el chip SIM900. Por ello es más fácil encontrar información sobre éste
último. Además los shields SIM900 se pueden encontrar a precios mucho más económicos y
ofreciendo dispositivos hardware adicionales acoplados al shield, como por ejemplo los
conectores de entrada y salida de audio y el RTC.
Por ello para los Clientes-Paradas se usará el shield GSM/GPRS basado en SIM900.
A continuación se muestra la placa escogida junto a los elementos que contiene.
Ilustración 19: Modem TC65 Siemens
3. Elección de componentes Proyecto Fin de Carrera
24
3.4 Elección del módulo GPS
Al igual que los modem GSM/GPRS se analizará que alternativa se adapta mejor a nuestras
plataformas de desarrollo.
3.3.1 Análisis de alternativas
En el mercado existen numerosos módulos GPS, que pueden comunicarse a través de un
puerto serie con las plataformas de desarrollo elegidas. Una de las opciones existente es un
shield que además de contener las funcionalidades de GSM/GPRS, tiene incorporado un GPS.
Las otras opciones requieren de comunicaciones independientes entre el modem GSM/GPRS, el
módulo GPS y la plataforma de desarrollo. A continuación se analizará cada una de estas
opciones, y saber así cual es la opción que presenta mayores ventajas.
3.3.1.1 Shield GSM/GPRS/GPS SIM908
El shield GPS/GPRS/GSM contiene el modem cuatribanda basado en el chip SIM908,que al
igual que el SIM900, funciona en la frecuencias EGSM 900MHz/DCS 1800MHz y GSM850
MHz/PCS 1900MHz. De hecho este chip es muy similar al SIM900 salvo que también
incorpora un receptor GPS para recuperar datos de posicionamiento. [16]
El shield también se controla con comandos AT mediante un puerto serie e incluye dos
antenas: una antena GPS y una antena GSM de alta ganancia.
3.3.1.2 Módulos GPS
Dentro de los diferentes módulos receptores GPS, existen módulos de tamaños muy
reducidos y fáciles de portar. La comunicación se hace por puerto serie, y gracias a ese reducido
tamaño, fácil de acoplar con nuestras plataformas de desarrollo elegidos. Uno de los más
conocidos es el módulo NEO 6M de Ublox. [17]
Ilustración 20: Shield GSM/GPRS SIM900 Arduino
3. Elección de componentes Proyecto Fin de Carrera
25
Características:
- Ultra sensibilidad: -165dBm
- Soporta estándares WAAS/EGNOS/MSAS/GAGAN
- Frecuencia de actualización 5Hz
- Protocolo NMEA (a 9600bps)
- 1x puerto serial
- Antena incorporada de 18.2 x 18.2 x 4.0 mm
3.3.2 Decisión final
Todas las alternativas mencionadas anteriormente son válidas para nuestras plataformas de
desarrollo. Por ello es necesario a analizar sus precios para ver cual resulta más interesante.
En la siguiente tabla se muestran los precios aproximados de cada una de las alternativas:
Modelo Precio
Shield GSM/GPRS/GPS SIM908 50-60 €
NEO 6M 15-20€ Tabla 6: Precios módulos GPS
Como se observa el shield GSM/GPRS/GPS SIM908 es más caro que los módulo GPS NEO
6M, pero esta shield ya incorpora las funcionalidades GSM/GPRS. Puesto que los Clientes-
Vehículos necesitan de todas esas funcionalidades, la comparación real de los precios debe
realizarse con el conjunto módulo GPS NEO 6M y shield GSM/GPRS SIM900, ya que el
módulo GPS por sí solo no aporta funcionalidades GSM/GPRS. Si se suma los precios de dicho
conjunto, el precio final es aproximado al shield GSM/GPRS/GPS SIM908, teniendo la
desventaja de que tanto las comunicaciones del modem GSM/GPRS, como las comunicaciones
del módulo GPS con la plataforma de desarrollo se deben hacer de manera independientes.
Por ello para los Clientes-Vehículos se usará finalmente el shield GSM/GPRS/GPS basado
en el chip SIM908.
A continuación se muestra la placa escogida junto a los elementos que contiene.
1. Conector jack para auriculares: Canal de salida de voz analógica.
2. Conector para antena GSM de interfaz SMA.
3. Conector de Arduino : Para poder acoplar con una placa Arduino.
4. Conector para antena GSM.
5. Interfaz de control SIM908.
6. Conector para antena GPS.
7. Interfaz USB a UART.
8. Altavoz original de Nokia: Canal de salida de voz analógica.
9. Botón de reset Arduino.
10. SIM908.
11. Indicador de red SIM908: Parpadea lentamente cuando se ha registrado la red.
12. Indicador de encendido.
13. Micrófono: Canal de entrada de voz analógica.
Ilustración 21: Módulo GPS
NEO 6M
3. Elección de componentes Proyecto Fin de Carrera
26
14. Tarjeta SIM.
15. CP2102.
16. Indicador UART Tx/Rx.
17. Interruptor de encendido.
18. Conector jack de alimentación DC 6V~9V.
19. Motor vibrador.
20. 74HC125.
21. NCP2890 amplificador de canal analógico.
22. MIC29302.
23. Jumper SIM908 salida analógica positiva.
24. Jumper SIM908 salida analógica negativa.
25. Jumper habilita NCP2890.
Ilustración 22: Shield GSM/GPRS/GPS SIM908
4. Servidor y aplicación web Proyecto Fin de Carrera
27
4. Servidor y aplicación web
4.1 Introducción
Como ya se introdujo anteriormente el Servidor debe ser capaz de gestionar toda la
información procedente de los Clientes-Vehículos, así como la de los Clientes-Paradas. Una vez
procesada dicha información, debe notificar a los Clientes-Vehículos si se ha producido una
solicitud de parada y a los Clientes-Parada información relativa del estado de los vehículos.
Para realizar estas tareas, se configurará un servidor web o HTTP, que es el más adecuado
para el sistema propuesto, ya que se puede acceder a él vía GPRS. Además se diseñará una
aplicación web que se conecte al Servidor y así poder interactuar los usuarios con el sistema
mediante un navegador web.
Antes de ello, es importante tener claro los conceptos de servidor web o HTTP, cliente web, y
base de datos. Así como los lenguajes de programación que usarán y las relaciones existentes
entre ellos. Una vez realizado dicho estudio, se programará tanto la aplicación del servidor
como la aplicación web.
4.2 Conceptos básicos
4.2.1 Servidor Web o HTTP
Un servidor web o servidor HTTP es un programa informático que procesa una aplicación
del lado del servidor, realizando conexiones bidireccionales y/o unidireccionales y síncronas o
asíncronas con el cliente. El servidor genera o cede una respuesta en cualquier lenguaje o
aplicación del lado del cliente. El código recibido por el cliente suele ser compilado y ejecutado
por un navegador web. Para la transmisión de todos estos datos suele utilizarse algún protocolo.
Generalmente se usa el protocolo HTTP para estas comunicaciones, perteneciente a la capa de
aplicación del modelo OSI. A dicho protocolo se le asigna habitualmente el puerto TCP 80.
4.2.1.1 Apache
El servidor HTTP Apache es un servidor web HTTP de
código abierto, para plataformas Unix (BSD, GNU/Linux,
etc.), Microsoft Windows, Macintosh y otras, que
implementa el protocolo HTTP/1.1 y la noción de sitio
virtual. Es el servidor HTTP más utilizado en la
actualidad, presenta entre otras características altamente
configurables, bases de datos de autenticación y negociado
de contenido, aunque carece de una interfaz gráfica que
ayude en su configuración.
4.2.2 Cliente Web
Un cliente es una aplicación informática o dispositivo que consume un servicio remoto en
otro ordenador conocido como servidor, normalmente a través de una red de
telecomunicaciones. El ordenador y el navegador web de un usuario serían considerados un
cliente web. En el proyecto que se desea realizar tanto los Clientes-Vehículos como los
Clientes-Paradas, actuarían de cliente web, y obtendría los servicios del servidor a través de la
red GSM/GPRS.
Ilustración 23: Logo Apache
4. Servidor y aplicación web Proyecto Fin de Carrera
28
4.2.2.1 Peticiones Web
Un cliente web puede realizar peticiones al servidor mediante HTTP de dos formas diferente:
- El método de petición GET, en el que el recurso se solicita a través de la url al servidor
Web.
- El método de petición POST, los datos a enviar al servidor se incluyen en el cuerpo de la
misma petición con las cabeceras HTTP asignadas correspondientemente respecto al tipo de
petición. Generalmente se asocia con los formularios web en los que los datos suelen ser
cifrados para enviarlos de manera segura al servidor.
4.2.3 Base de datos
Una base de datos o banco de datos es un conjunto de datos pertenecientes a un mismo
contexto y almacenados sistemáticamente para su posterior uso. En este sentido; una biblioteca
puede considerarse una base de datos compuesta en su mayoría por documentos y textos
impresos en papel e indexados para su consulta. Actualmente, y debido al desarrollo tecnológico
de campos como la informática y la electrónica, la mayoría de las bases de datos están en
formato digital, siendo este un componente electrónico, por tanto se ha desarrollado y se ofrece
un amplio rango de soluciones al problema del almacenamiento de datos.
Existen programas denominados sistemas gestores de bases de datos, abreviado SGBD (del
inglés Database Management System o DBMS), que permiten almacenar y posteriormente
acceder a los datos de forma rápida y estructurada.
4.2.3.1 MySQL
MySQL es un sistema de gestión de bases de datos
relacional, multihilo y multiusuario de licencia GPL. Como
tal base de datos relacional, desde un punto de vista lógico
usa tablas para guardar los datos. Internamente un
mecanismo de almacenamiento (storage engine) será el
encargado de guardar en último término los datos de las
tablas en dispositivos físicos, para que éstos tengan
durabilidad. Su popularidad como aplicación web está muy
ligada a PHP, que a menudo aparece en combinación con MySQL.
Existen varias interfaces de programación de aplicaciones que permiten, a aplicaciones
escritas en diversos lenguajes de programación, acceder a las bases de datos MySQL,
incluyendo C, C++, C#, Pascal, Java,PHP, Python, Ruby.
4.2.4 Funcionamiento Cliente-Servidor Web
El Servidor web se ejecuta en un ordenador manteniéndose a la espera de peticiones por
parte de un cliente (un navegador web) y que responde a estas peticiones adecuadamente,
mediante una página web que se exhibirá en el navegador o mostrando el respectivo mensaje si
se detectó algún error.
Además de la transferencia de código HTML, los Servidores web pueden entregar
aplicaciones web. Éstas son porciones de código que se ejecutan cuando se realizan ciertas
peticiones o respuestas HTTP. Hay que distinguir entre:
Ilustración 24: Logo MySQL
4. Servidor y aplicación web Proyecto Fin de Carrera
29
Aplicaciones en el lado del cliente: el cliente web es el encargado de ejecutarlas en la
máquina del usuario. El servidor proporciona el código de las aplicaciones al cliente y éste,
mediante el navegador, las ejecuta. Es necesario, por tanto, que el cliente disponga de un
navegador con capacidad para ejecutar aplicaciones (también llamadas scripts). Comúnmente,
los navegadores permiten ejecutar aplicaciones escritas en lenguaje javascript y java, aunque
pueden añadirse más lenguajes mediante el uso de plugins.
Aplicaciones en el lado del servidor: el servidor web ejecuta la aplicación, ésta, una vez
ejecutada, genera cierto código HTML, el servidor toma este código recién creado y lo envía al
cliente por medio del protocolo HTTP.
4.2.4.1 Lenguajes del lado cliente
A continuación se presentará los lenguajes del lado cliente que se usarán, aunque existen otros
múltiples lenguajes. [18]
4.2.4.1.1 HTML
El lenguaje llamado HTML indica al navegador donde colocar cada texto, cada imagen o
cada video y la forma que tendrán estos al ser colocados en la página.
El lenguaje consta de etiquetas que tienen esta forma <B> o <P>. Cada etiqueta significa una
cosa, por ejemplo <B> significa que se escriba en negrita (bold) o <P> significa un párrafo,
<A> es un enlace, etc. Casi todas las etiquetas tienen su correspondiente etiqueta de cierre, que
indica que a partir de ese punto no debe de afectar la etiqueta. Por ejemplo </B> se utiliza para
indicar que se deje de escribir en negrita. Así que el HTML no es más que una serie de etiquetas
que se utilizan para definir la forma o estilo que queremos aplicar al documento.
4.2.4.1.2 CSS
CSS son las siglas de Cascading Style Sheets, en español Hojas de estilo en Cascada. Es una
tecnología que permite crear páginas web de una manera más exacta. Gracias a las CSS se es
mucho más dueño de los resultados finales de la página, pudiendo hacer muchas cosas que no se
podía hacer utilizando solamente HTML, como incluir márgenes, tipos de letra, fondos,
colores... Incluso se pueden definir estilos propios en un archivo externo a nuestras páginas; así,
si en algún momento se quiere cambiar alguno de ellos, automáticamente se actualizarán todas
las páginas vinculadas al sitio.
4.2.4.1.3 Javascript
Javascript es un lenguaje de programación utilizado para crear pequeños programitas
encargados de realizar acciones dentro del ámbito de una página web. Se trata de un lenguaje de
programación del lado del cliente, porque es el navegador el que soporta la carga de
procesamiento. Su uso se basa fundamentalmente en la creación de efectos especiales en las
páginas y la definición de interactividades con el usuario. Las sentencias escritas en javascript
se encapsulan entre las etiquetas <script> y </script>.
4. Servidor y aplicación web Proyecto Fin de Carrera
30
4.2.4.1.4 Ajax
AJAX, acrónimo de Asynchronous JavaScript And XML,
no es un lenguaje de programación en sí, más bien es una
técnica de desarrollo web para crear aplicaciones
interactivas. Estas aplicaciones se ejecutan en el cliente, es
decir, en el navegador de los usuarios mientras se mantiene
la comunicación asíncrona con el servidor en segundo plano.
De esta forma es posible realizar cambios sobre las páginas
sin necesidad de recargarlas, mejorando la interactividad, velocidad y usabilidad en las
aplicaciones.
JavaScript es el lenguaje interpretado (scripting language) en el que normalmente se efectúan
las funciones de llamada de Ajax mientras que el acceso a los datos se realiza mediante
XMLHttpRequest, objeto disponible en los navegadores actuales. En cualquier caso, no es
necesario que el contenido asíncrono esté formateado en XML.
4.2.4.2 Lenguajes del lado servidor
Al igual que los lenguajes del lado cliente, a continuación se presentará los lenguajes del
lado servidor que se usarán, aunque existen otros lenguajes. [19]
4.2.4.2.1 PHP
PHP es el acrónimo de Hipertext Preprocesor. Es un
lenguaje de programación del lado del servidor gratuito e
independiente de plataforma, rápido, con una gran librería
de funciones y mucha documentación. Por ello lo convierte
en el lenguaje de programación web más empleado del lado
servidor.
4.2.4.2.2 SQL
SQL, por sus siglas en inglés Structured Query Language, es un lenguaje declarativo de
acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones en
ellas. Una de sus características es el manejo del álgebra y el cálculo relacional que permiten
efectuar consultas con el fin de recuperar, de forma sencilla, información de bases de datos, así
como hacer cambios en ellas.
Ilustración 27: Logo PHP
Ilustración 25: Logo HTML, JavaScript y CSS
Ilustración 26: Logo Ajax
4. Servidor y aplicación web Proyecto Fin de Carrera
31
4.2.4.3 Relación entre lenguajes de programación lado Cliente y lado Servidor
A continuación se muestra un esquemático que ayuda a entender mejor la relación entre los
diferentes lenguajes que se usarán. [20][21]
1. El navegador web efectúa la petición de la página web.
2. El servidor llama al interprete PHP si es necesario.
3. PHP interpreta los scripts interactuando con la base de datos si es preciso y devuelve al
servidor el documento generado.
4. El servidor envía el documento resultante en formato HTML.
5. El documento es interpretado por el navegador ejecutando los script del lado del cliente y
se presenta el resultado en la pantalla.
6. Ajax mantiene la comunicación asíncrona con el servidor en segundo plano.
4.2.5 Otras herramientas
Existen algunas herramientas que son de utilidad para la programación del Servidor y la
aplicación web. A continuación se resumen aquellas que serán usadas en el sistema.
Ilustración 28: Relación entre lenguajes de programación lado Cliente y lado Servidor
4. Servidor y aplicación web Proyecto Fin de Carrera
32
4.2.5.1 PhpMyAdmin
PhpMyAdmin es una herramienta escrita en PHP con la intención de manejar la
administración de MySQL a través de páginas web, utilizando Internet. Actualmente puede
crear y eliminar Bases de Datos, crear, eliminar y alterar tablas, borrar, editar y añadir campos,
ejecutar cualquier sentencia SQL, administrar claves en campos, administrar privilegios,
exportar datos en varios formatos y está disponible en 72 idiomas. Y además se encuentra
disponible bajo la licencia GPL.
4.2.5.2 Google Maps API
Google Maps es un servidor de aplicaciones de mapas en la web. Ofrece imágenes de mapas
desplazables, así como fotografías por satélite del mundo e incluso la ruta entre diferentes
ubicaciones o imágenes a pie de calle con Google Street View. [22]
Google Maps está desarrollado casi por entero con JavaScript y XML. Con la API de Google
Maps un usuario puede modificar oficialmente casi cualquier aspecto de la interfaz original.
Con una contraseña oficial de desarrollador, la API es libre de uso para cualquier sitio web.
En cuanto a los precios de la API de Google se rigen en dos planes, Plan Estándar y Plan
Premium.
Con el Plan Estándar de las API de Google Maps, pagas cuando superas los límites de uso
gratuito de cada API de Maps. Este plan se puede utilizar para las implementaciones gratuitas,
externas y disponibles de forma pública. El servicio que prestes debe ser gratuito y público para
los usuarios finales.
Las API de Google Maps Premium ofrecen funciones mejoradas y un mayor nivel de
asistencia para organizaciones que añadan mapas a sitios web o aplicaciones móviles de pago,
sitios web internos o aplicaciones de seguimiento de elementos.
A continuación se muestra la tabla de precios de ambos planes para las API que serán usadas
en nuestra aplicación web.
Ilustración 29: Interfaz PhpMyAdmin
4. Servidor y aplicación web Proyecto Fin de Carrera
33
Web
ESTÁNDAR PREMIUM
- API de JavaScript de
Google Maps
- API de Google Static Maps
- API de imágenes de Google
Street View
- Gratuito hasta que se
superen las 25.000 cargas de
mapas al día durante 90 días
consecutivos.
- 0,50 USD por cada 1000
cargas de mapas adicionales
por encima de las 25.000
diarias, una vez que se
alcance el límite de uso de
25.000 cargas de mapas en 90
días (hasta un máximo de
1.000.000 al día)
- Precios según volumen
requerido
- Funciones mejoradas del
Plan Premium:
- Sin anuncios (garantizado)
- Tamaño de imagen de hasta
2048 x 2048 píxeles
- API de inserción de Google
Maps
- Uso ilimitado gratuito -
Servicios web
ESTÁNDAR PREMIUM
- API de indicaciones de
Google Maps
- API del servicio de matriz
de distancia de Google Maps
- API de elevación de Google
Maps
- API de codificación
geográfica de Google Maps
- API de ubicación geográfica
de Google Maps
- API de carreteras de Google
Maps
- API de zona horaria de
Google Maps
- Gratuito hasta 2500
solicitudes diarias
- 0,50 USD por cada 1000
solicitudes adicionales, hasta
un máximo de 100.000 al día
- Precios según volumen
requerido
- Funciones mejoradas del
Plan Premium:
- Aumentos en las cuotas de
consultas por segundo
- Funciones mejoradas de la
API de matriz de distancia y
de la API de carreteras
- Servicio web de API de
Google Places
- 150.000 solicitudes gratis al
día (tras una validación de la
tarjeta de crédito )
- Precios según volumen
requerido
Tabla 7: Precios API de Google
4. Servidor y aplicación web Proyecto Fin de Carrera
34
4.3 Diseño y programación del Servidor
4.3.1 Base de datos
Una vez explicado los conceptos básicos sobre el Servidor y antes de proceder con la
explicación del código del Servidor, se ha de conocer la estructura que tendrá la base de datos.
Ya que en ella se insertarán las solicitudes de paradas procedentes de los Clientes-Parada, así
como las coordenadas procedentes de los Clientes-Vehículos. Además servirá para guardar
datos auxiliares necesarios para calcular las distancias y tiempos de duración aproximados entre
los dos tipos de Clientes y obtener así el Cliente-Vehículo más cercano a cada Cliente-Parada.
Con dicha información el Servidor podrá generar las respuestas a las peticiones de los Clientes.
gelocalización.sql
Ilustración 30: Tabla geolocalización de la base de datos.
En esta tabla se guardará las coordenadas procedentes de los Clientes-Vehículos. Los
campos que constituyen dicha tabla son los siguientes:
-ID: Es un valor entero que se autoincrementa automáticamente, indica el número de filas
insertadas hasta ese instante.
-IDbus: Es una cadena de caracteres que indica el identificador del Cliente-Vehículo.
-Trayecto: Es una cadena de caracteres que indica en qué dirección va el Cliente-Vehículo.
-Latitud: Es un valor float que indica la latitud del Cliente-Vehículo.
-Longitud: Es un valor float que indica la longitud del Cliente-Vehículo.
-Tiempo: Es un valor timestamp que indica la fecha y hora a la que se insertan los datos.
4. Servidor y aplicación web Proyecto Fin de Carrera
35
solicitud.sql
Ilustración 31: Tabla solicitud de la base de datos.
En esta tabla se guardará las solicitudes de paradas procedentes de los Clientes-Parada. Los
campos que constituyen dicha tabla son los siguientes:
-ID: Es un valor entero que se autoincrementa automáticamente, indica el número de filas
insertadas hasta ese instante.
-IDparada: Es una cadena de caracteres que indica el identificador del Cliente-Parada.
-Trayecto: Es una cadena de caracteres que indica en qué dirección va el Cliente-Vehículo
del que se desea realizar una solicitud de parada.
-Estado: Es una cadena de carácter que indica el estado de solicitud de la parada.
-Tiempo: Es un valor timestamp que indica la fecha y hora a la que se insertan los datos.
paradas.sql
Ilustración 32: Tabla paradas de la base de datos.
En esta tabla se guardará las coordenadas procedentes de los Clientes-Parada, y las distancias
con respecto al origen y destino de la ruta. Estas distancias sirven de referencia para el cálculo
4. Servidor y aplicación web Proyecto Fin de Carrera
36
del Cliente-Vehículo más cercano a cada Cliente-Parada. Los campos que constituyen dicha
tabla son los siguientes.
-ID: Es un valor entero que se autoincrementa automáticamente, indica el número de filas
insertadas hasta ese instante.
-Nombre: Es una cadena de caracteres que indica el identificador del Cliente-Parada.
-Latitud: Es un valor float que indica la latitud del Cliente-Parada.
-Longitud: Es un valor float que indica la longitud del Cliente-Parada.
-Origen: Es un valor entero que indica la distancia en metros del Cliente-Parada con respecto
al origen de la ruta.
-Destino: Es un valor entero que indica la distancia en metros del Cliente-Parada con
respecto al destino de la ruta.
distancias.sql
Ilustración 33: Tabla distancias de la base de datos.
En esta tabla se guardará las distancias y tiempo de llegada calculado entre los Clientes-
Vehículos y los Clientes-Parada. También se guardará la distancia entre los Clientes-Vehículos,
y la referencia. Dicha referencia será el Origen o Destino de la ruta según la dirección que
marque el campo Trayecto. Si el campo Trayecto marca una dirección de “Ida” la referencia
será el Origen, en caso contrario, si la dirección marca una dirección de “Vuelta” la referencia
será el Destino, comparando este campo de Referencia con el de la distancia calculada entre el
Cliente-Parada y el Origen o Destino de la ruta, será fácil calcular el Cliente-Vehículo de la ruta
que se encuentras más cercano a cada Cliente-Parada. Los campos que constituyen dicha tabla
son los siguientes:
-ID: Es un valor entero que se autoincrementa automáticamente, indica el número de filas
insertadas hasta ese instante.
-IDbus: Es una cadena de caracteres que indica el identificador del Cliente-Vehículo.
-IDparada: Es una cadena de caracteres que indica el identificador del Cliente-Parada.
-Trayecto: Es una cadena de caracteres que indica en qué dirección va el Cliente-Vehículo.
4. Servidor y aplicación web Proyecto Fin de Carrera
37
-Distancia: Es un valor entero que indica la distancia en metros entre el Cliente-Vehículo y el
Cliente-Parada.
-Duración: Es un valor entero que indica la duración de llegada en segundos del Cliente-
Vehículo al Cliente-Parada.
-Referencia: Es un valor entero que indica la distancia ente el Cliente-Vehículo y la
referencia.
4.3.2 Scripts Php/JS
El Servidor está constituido por varios scripts Php y JavaScript que se relacionan ente ellos
usando la técnica de desarrollo web Ajax anteriormente descrita y con la base de datos cuya
estructura se acaba de exponer. A continuación se explicará con diagramas de flujo cada uno de
ellos para facilitar mejor su comprensión.
clientevehiculo.php
Este scripts es el encargado de recibir las coordenadas procedentes de los Clientes-Vehículos
y guardarlos en la base de datos. Como respuesta recibe el estado de las solicitudes de paradas
de todos los Clientes-Paradas. Además sirve para reiniciar el estado de la solicitud de parada del
Cliente-Parada más cercano al Cliente-Vehículo que está mandando la información si éste así lo
desea.
1. Para iniciar la conexión con la base de datos se llama a un pequeño script (config.php) que
contiene las credenciales de la misma.
2. Los datos que les llega del Cliente-Vehículo son IDbus, Trayecto, Latitud,Longitud. Y una
bandera llamada Reinicio, que indica como anteriormente se ha explicado si se desea reiniciar el
estado de solicitud de parada del Cliente-Parada más cercano.
3. Los datos se guardan en la tabla geolocalización.sql
4. Es el bucle donde mira el estado de solicitud de todos los Clientes-Parada.
5. Los datos se consultan en la tabla solicitudes.sql y en la tabla paradas.sql
6. Comprueba si la bandera de Reinicio está activa, si no es así ya devuelve el estado de
solicitud de parada del Cliente-Parada. En caso contrario, continua.
7. Las distancias se calculan mediante la API de google.
8. Los datos se guardan en la tabla distancias.sql
9. Si la bandera reinicio está activa se continua, en caso contrario se finaliza el script
10. Los datos se consultan en la tabla distancias.sql
11. Se guardan en la tabla solicitudes.sql el estado “OFF” con los datos del Cliente-Parada
más cercano.
4. Servidor y aplicación web Proyecto Fin de Carrera
38
Ilustración 34: Diagrama de flujo clientevehiculo.php
4. Servidor y aplicación web Proyecto Fin de Carrera
39
clienteparada.php
Este scripts es el encargado de recibir las solicitudes de paradas procedentes de los Clientes-
Paradas y guardarlos en la base de datos. Como respuesta recibe la distancia y tiempo
aproximado del Cliente-Vehículo más cercano.
1. Para iniciar la conexión con la base de datos se llama a un pequeño script (config.php) que
contiene las credenciales de la misma.
2. Los datos que les llega del Cliente-Parada son IDparada, Trayecto, Estado.
3. Los datos se guardan en la tabla solicitudes.sql
4. Los datos se consultan en la tabla paradas.sql
5. Es el bucle donde mira las coordenadas todos los Clientes-Vehículos.
6. Los datos se consultan en la tabla geolocalizacion.sql
7. Las distancias se calculan mediante la API de google.
8. Los datos se guardan en la tabla distancias.sql
9. Se consulta en la tabla paradas.sql y en la tabla distancias.sql para calcular el vehículo
más cercano que está en la ruta.
10. Se devuelve la distancia y tiempo aproximado calculado del Cliente-Vehículo más
cercano.
4. Servidor y aplicación web Proyecto Fin de Carrera
40
Ilustración 35: Diagrama de flujo clienteparada.php
4. Servidor y aplicación web Proyecto Fin de Carrera
41
index.php
Este script es el encargado de generar el código html que da forma a la página web. Toma
las hojas de estilo CSS para definir y crear la presentación del documento. Y carga los script
Javascript que serán ejecutados en el navegador.
Ilustración 36: Diagrama de flujo index.php
funciones.js
Este script es el que llama a la API de google para dibujar el mapa. Se encarga de dibujar los
marcadores dentro del mapa que representan a los Clientes-Paradas y Clientes-Vehículos
implantados en el sistema.
Ilustración 37: Diagrama de flujo funciones.js
Los marcadores de los Clientes-Paradas se dibujan al iniciar la página web y los marcadores
de los Clientes-Vehículos se van actualizando cada segundo.
Para la actualización de los marcadores de los Clientes-Vehículos se utiliza Ajax, que llama
a un script php, consultacoordenadas.php, que le devuelve las coordenadas del Cliente-Vehículo
a representar en el mapa.
4. Servidor y aplicación web Proyecto Fin de Carrera
42
Ilustración 38: Interfaz web
En los marcadores de los Clientes-Paradas también se puede solicitar las paradas, para ello
llama a un script php, solicitudesweb.php, muy similar a clienteparada.php. Este script al igual
que clienteparada.php guarda en la base de datos las solicitudes de paradas obtenidas por la web
y devuelve el tiempo de duración aproximado y distancia del vehículo más cercano de forma
que pueda ser representado en el propio marcador.
5. Alojamiento web Proyecto Fin de Carrera
43
5. Alojamiento web
5.1 Introducción
El alojamiento web o web hosting es el servicio que provee a los usuarios de Internet un
sistema para poder almacenar información, imágenes, video o cualquier contenido accesible vía
web. En proyecto propuesto se requiere alojar el Servidor junto a la aplicación web.
Existen distintos tipos de alojamientos con sus ventajas e inconvenientes, por ello es
importante analizarlos antes de elegir una opción.
Por lo general los tipos de alojamientos que se ofrecen son:
Alojamiento propio
Alojamiento gratuito
Alojamiento compartido
Alojamiento dedicado
Alojamiento en la nube
5.2 Tipos de alojamientos
5.1.1 Alojamiento propio
Consiste en crear el servidor Web utilizando nuestra propia infraestructura. Para ello se
requiere de un ordenador que esté permanentemente conectado a Internet.
Una de las ventajas que proporciona el usar un alojamiento propio es que la inversión
realizada se ajusta al alcance del propio proyecto. Pudiéndose escalar a medida que aumenten
los servicios ofrecidos por el proyecto. Además de que es la forma idónea para probar el
proyecto mientras está aún en desarrollo.
Sin embargo la inversión aumenta según la criticidad del proyecto, si se quiere que no se
caiga el servicio hay que invertir en mejores equipos, mejor software, y en una gestión técnica.
5.1.2 Alojamiento gratuito
Es un servicio que brindan algunas empresas para alojar aplicaciones web, cada empresa
tiene sus particularidades en cuanto al tipo de servicio ofrecido y las condiciones del mismo.
Al registrarse en un servicio de "hosting gratis" el usuario normalmente obtiene un panel de
control desde el cual podrá administrar el servicio y una dirección URL desde la cual se podrá
acceder al sitio.
Algunos tipos de alojamiento web gratuito son:
Hosting gratis a cambio de posts
En este tipo de alojamiento el usuario debe participar de manera activa en un
determinado foro o comunidad para poder acceder al servicio de hosting de manera
gratuita.
5. Alojamiento web Proyecto Fin de Carrera
44
Hosting gratis a cambio de publicidad
En este tipo de alojamiento el usuario debe agregar publicidad (suministrada por la
empresa de hosting) en su sitio web para poder acceder al servicio de hosting de manera
gratuita. En algunos casos la publicidad es agregada de manera automática en la parte
inferior o superior del sitio.
Hosting gratis sin nada a cambio
En este tipo de alojamiento no se le solicita nada a cambio al usuario, el mismo no
necesita poner publicidad en su sitio ni participar en foros o comunidades. Algunas de
estas empresas se financian llevando clientes a otras empresas de hosting pago o
vendiendo "upgrades" de las cuentas de hosting gratis.
Las ventajas que tiene este tipo de alojamientos es que se puede alojar de manera totalmente
gratuita el servidor, y sin costes de infraestructura adicional. Además te proporciona una mayor
seguridad en cuanto a las caídas del servicio.
En cuanto a los inconvenientes, te pueden proporcionar publicidad no deseada en la
aplicación. Y limitarte en capacidad de almacenamiento o ancho de banda que requiera el
servicio. Además al compartir dirección IP con otros usuarios, las malas acciones de estos
pueden acarrear problemas como por ejemplo aparecer en listas negras de Internet e
imposibilitarte usar el correo electrónico.
5.1.3 Alojamiento compartido
Consiste en alojar varias aplicaciones web en un mismo Servidor Web, de modo que los
recursos de dicho servidor se comparten entre todas las aplicaciones web alojadas en el mismo.
Los costes del Servidor Web se reparten entre todos los usuarios que tienen alojados su
aplicación web en él. Reduciendo así los costes comparado a un alojamiento dedicado.
La ventaja es que no se tiene tantas limitaciones como en un alojamiento gratuito, y carece
de publicidad no deseada.
En cambio sigue teniendo el mismo inconveniente que los alojamientos gratuito, por
compartir la dirección IP con otros usuarios.
5.1.4 Alojamiento dedicado
En este tipo de alojamiento el servidor es exclusivamente para el usuario que lo contrata,
todos los recursos están disponibles para el uso que quiera darse. Pero todos los costes del
mismo lo asume un único usuario.
5.1.5 Alojamiento en la nube
En este tipo de Alojamiento Web, los recursos de multitud de Servidores Web se combinan
de modo que actúan como si fuese un único Servidor en el que se puede alojar nuestra página
web. La principal ventaja de este tipo de hosting es su gran flexibilidad, pues permite ajustar de
forma dinámica y en tiempo real los recursos utilizados por nuestra aplicación web en función
de la demanda real de recursos que la aplicación necesita en cada momento.
Del mismo modo, se trata de una solución muy fiable, si uno de los Servidores Web que se
están combinando para alojar nuestra aplicación web dejase de funcionar, al momento otro
5. Alojamiento web Proyecto Fin de Carrera
45
Servidor Web lo sustituiría para que nuestra aplicación web siga funcionando correctamente en
todo momento.
Este tipo de alojamiento Web también tiene la ventaja de que se puede pagar por los recursos
que realmente se han utilizado, en lugar de tener que pagar una cuota fija.
5.3 Decisión final
Puesto que el alcance de este proyecto es realizar un prototipo del sistema, y por tanto los
recursos requeridos por dicho prototipo no son muchos, se ha decido optar por un alojamiento
propio mientras se realizaba el desarrollo del proyecto. Y posteriormente usar un alojamiento
gratuito para las pruebas del mismo.
Para la creación del servidor web, se usado es una distribución de Apache completamente
gratuita y fácil de instalar llamada Xampp, que además contiene un servidor MySQL, y un
intérprete PHP y Perl. Es compatible con cualquier ordenador, incluso las plataformas
Raspberry Pi, Banana Pi, e Intel Galileo anteriormente estudiadas.
En cuanto al alojamiento gratuito, se ha optado por Hostinger, puesto que es uno de los más
utilizados, te proporciona unas limitaciones aptas para el Servidor y panel de control sencillo de
usar.
5.4 Xampp
XAMPP es un servidor independiente de plataforma, software libre, que consiste
principalmente en el sistema de gestión de bases de datos MySQL, el servidor web Apache y los
intérpretes para lenguajes de script: PHP y Perl. El nombre proviene del acrónimo de X (para
cualquiera de los diferentes sistemas operativos), Apache, MySQL, PHP, Perl. [23]
El programa está liberado bajo la licencia GNU y actúa como un servidor web libre, fácil de
usar y capaz de interpretar páginas dinámicas. Actualmente XAMPP está disponible para
Microsoft Windows, GNU/Linux, Solaris y Mac OS X.
XAMPP solamente requiere descargar y ejecutar un archivo ZIP, tar , exe o fkl, con unas
pequeñas configuraciones en alguno de sus componentes que el servidor Web necesitará.
XAMPP se actualiza regularmente para incorporar las últimas versiones de
Apache/MySQL/PHP y Perl. También incluye otros módulos como OpenSSL y phpMyAdmin.
Para su instalación hay que conceder los permisos al firewall en caso de que haya alguno
instalado en el sistema.
A continuación se muestra el panel de control de XAMPP, desde donde se puede iniciar
todos los servicios necesarios para la ejecución del servidor.
Con los botones de “Start” o “Stop” se inicia o se paran los servicios.
5. Alojamiento web Proyecto Fin de Carrera
46
Los dos archivos principales de configuración son los archivos httpd.conf (Apache) y php.ini
(PHP). Para editarlos hay que hacer clic en el botón "Config" correspondiente a Apache y hacer
clic en el archivo que se quiere editar. En dichos archivos se pueden configurar entre otras cosas
los puertos que usaran los servicios, la ruta de directorios que tiene el contenido web, el límite
total de procesos del servidor o clientes conectados simultáneamente, etc.
Una vez configurado todo, para comprobar el funcionamiento del servidor basta con poner
en un navegador web la dirección http://localhost o darle al botón “Admin” del panel de control
de XAMPP.
5.4.1 DNS Dinámico
Para que se pueda acceder al Servidor es necesario tener una dirección IP fija, en caso de no
tenerse, se puede contratar servicios de DNS dinámico.
Los servicios DNS dinámico es una forma de asociar un nombre de dominio a un servidor
que tiene IP dinámica. Para ello se ha de instalar un pequeño programa en el servidor y que
informe sobre la IP que tiene. Entonces, cada vez que se inicia el servidor, o cuando se desee,
envía la dirección IP actual a la empresa que proporciona el DNS dinámico, para que el
subdominio elegido se dirija a la IP que se tiene en cada momento.
Existen numerosas empresas que ofrecen servicio de DNS dinámico, o Dynamic DNS en
inglés, algunas de ellas gratuitamente. Una de las empresas que ofrecen este servicio es NO-IP,
siendo su servicio gratuito para los usuarios registrados.
Ilustración 39: Panel de control XAMPP
5. Alojamiento web Proyecto Fin de Carrera
47
Si el servidor que se pretende acceder a través de DNS dinámico está en una red local y la
conexión a Internet se gestiona a través de un router, se debe configurar el router para que las
conexiones se dirijan al servidor.
Para ello hay que abrir el puerto del router asociado al servicio que se quiere ofrecer. Por
ejemplo, el puerto 21 para las conexiones FTP o el puerto 80 para las conexiones web. Habría
que asociar ese puerto con la IP de red local que tenga el servidor.
A continuación se muestra la configuración de un router HUAWEI para permitir accesos a
conexiones FTP y HTTP.
Ilustración 41: Configuración router HUAWEI
Ilustración 40: DNS Dinámico NO-IP
5. Alojamiento web Proyecto Fin de Carrera
48
5.5 Hostinger
Como ya se ha comentado Hostinger ofrece
servicios de alojamientos con diferentes
limitaciones según el plan contratado. Existiendo
un plan completamente gratuito que es el que se
usará para alojar el Servidor. Pudiéndose ampliar
en un futuro en el caso de mayor necesidad de
recursos. [24]
A continuación se muestra una tabla comparativa de las limitaciones de los diferentes planes
y las características soportadas.
Limitaciones
0,00€
1,99€ / mes 4,99€ / mes
Gratis
Premium Empresarial
Espacio de disco 2000MB Ilimitado Ilimitado
Tráfico de datos 100GB Ilimitado Ilimitado
Número de sitios 2 Ilimitado Ilimitado
Registro gratuito de
dominio No Sí Sí
Instalador automático 50 Scripts 60 Scripts 60 Scripts
Certificado SSL
privado por un año No No Sí
Copia de seguridad
de datos Limitado Semanalmente Diariamente
Garantía de tiempo
en línea 99% 99,5% 99,9%
Tabla 8: Limitaciones de Hostinger
Características soportadas
Gratis
Premium Empresarial
Soporte PHP 5.2, 5.3,
5.4, 5.4, 5.6, 7.0 Sí Sí Sí
Bases de datos
MySQL 2 Ilimitado Ilimitado
Herramienta
PHPmyAdmin Sí Sí Sí
Acceso FTP Sí Sí Sí
FTP sobre SSL No Sí Sí
Consola web SSH Sí Sí Sí
5. Alojamiento web Proyecto Fin de Carrera
49
Acesso SSH
completo No Sí Sí
Dominios aparcados 2 Ilimitado Ilimitado
Subdominios 2 Ilimitado Ilimitado Tabla 9: Características soportadas por Hostinger
Las características de los servidores de Hostinger también varían según el plan contratado.
Información del servidor
Gratis
Premium Empresarial
Velocidad de la red
del servidor 10 mbps 100 mbps 1000 mbps
RAM del servidor 8 GB 16 GB 16 GB
Procesador del
servidor Xeon E3-1230 Intel Xeon W3680 Intel Xeon W3680
Configuración de
disco duro RAID-1 RAID-10 RAID-10
Sistema operativo Centos CloudLinux CloudLinux Tabla 10: Información de los servidores de Hostinger
Por último se muestra algunas las herramientas que ofrece Hostinger en su panel de control.
Herramientas del panel de control
Gratis
Premium Empresarial
Administrador de
cuentas de correo Sí Sí Sí
Copia de seguridad/
Restaurar base de datos Sí Sí Sí
Copia de seguridad/
Restaurar sitio Sí Sí Sí
Estadísticas del sitio Sí Sí Sí
Administradores de
archivos Sí Sí Sí
Páginas de error
personalizadas Sí Sí Sí
Directorios protegidos
por contraseña Sí Sí Sí
Administrado de
bloqueo de IP Sí Sí Sí
Tabla 11: Herramientas del panel de control de Hostinger
6. Clientes Proyecto Fin de Carrera
51
6. Clientes
6.1 Introducción
Como anteriormente se ha mencionado, los Clientes del proyecto que se desean realizar
constan de una plataforma de desarrollo Arduino junto a un shield GSM/GPRS SIM900 para los
Clientes-Parada y un shield GSM/GPRS/GPS SIM908 para los Clientes-Vehículos. Estos shield
serán los encargados de realizar la comunicación, y para ello hay que mandarle las instrucciones
por un puerto serie mediante comandos AT. Por tanto antes de proceder con la programación de
los Clientes es importante saber que son los comandos AT y cuales existen.
6.2 Comandos AT
Los comandos AT, también conocidos como comandos Hayes (en honor a su desarrollador
Dennis Hayes), son una serie de instrucciones que conforman una interfaz de comunicación
entre el usuario y un modem. Su abreviatura AT por la que son mundialmente conocidos estos
comandos proviene de la palabra ‘attention’. [25]
Aunque la finalidad principal de los comandos AT fue la comunicación con módems, la
telefonía móvil GSM/GPRS también adoptó este lenguaje como estándar de comunicación.
En la actualidad, todos los terminales móviles GSM poseen una serie específica de
comandos AT que permiten configurarlos por medio de estas instrucciones e indicarles una serie
de acciones para que se ejecuten, tales como marcar un número de teléfono, enviar o leer un
SMS, consultar el estado de conexión a la red, comunicarse con un servidor web, etc.
Gracias a que la transmisión de comandos AT no depende del canal de comunicación a
través del cual estos sean enviados (cable, infrarrojos, Bluetooth, etc.), se puede utilizar nuestra
placa Arduino para transmitir dichos comandos al modem GPRS/GSM que sea capaz de
interpretarlos y actuar en consecuencia.
Como son muchos los comandos existentes, únicamente se va a mencionar junto con una
breve descripción, aquellos que puedan resultar de principal interés en el desarrollo del
proyecto.
6.2.1 Comandos Generales
- AT – Con este comando se verifica que el módulo está recibiendo las instrucciones. Si
todo es correcto, tras enviarlo debe responder con un “OK”. En caso contrario no se obtiene
respuesta alguna.
- AT+CPIN? – Este comando sirve para comprobar si la tarjeta SIM está desbloqueada o si
por el contrario, requiere introducir el código PIN para proceder con el desbloqueo de la misma.
Cuando la SIM esté operativa responderá con un “ready”.
- AT+CPIN = ”****” – En el caso de que sea necesario introducir el PIN, éste es el comando
que se debe enviar, escribiendo los 4 dígitos correspondientes al código de desbloqueo en el
lugar de los asteriscos, delimitado entre comillas. Debe responder con un “OK” en caso de que
se haya desbloqueado con éxito.
6. Clientes Proyecto Fin de Carrera
52
- AT+CREG? – Este comando indica el estado de conexión a la red. La respuesta recibida
seguirá la siguiente notación: +CREG: <n>, <stat>, donde:
<stat> = 0 No registrado, no está buscando una conexión de red.
<stat> = 1 Registrado a la red nacional.
<stat> = 2 No registrado, pero buscando la red.
<stat> = 3 Registro denegado.
<stat> = 5 Registro tipo roaming.
6.2.2 Comandos para el GPS
-AT+CGPSPWR=<mode> – Este comando controla el encendido o apagado del GPS
dependiendo del contenido del parámetro <mode>.
<mode> = 0 Apaga el GPS.
<mode> = 1 Enciende el GPS.
-AT+CGPSRST=<mode> – Este comando sirve para resetear el GPS.
<mode> = 0 Resetea el GPS en modo “arranque en frío”.
<mode> = 1 Resetea el GPS en modo autónomo.
-AT+CGPSIPR=<rate> – Con este comando se indica la velocidad de transmisión de los
datos por el puerto serie. La velocidad se configura en baudios por segundos.
<rate> 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800.
-AT+CGPSSTATUS? – Este comando sirve para saber si el GPS ha localizado la posición.
El comando responde con una de las siguientes respuestas:
<mode> = “Location Unknown”.
<mode> = “Location Not Fix”.
<mode> = “Location 2D Fix”.
<mode> = "Location 3D Fix”.
-AT+CGPSINF=<mode> – Este comando es el que proporciona la información del GPS.
Dependiendo del parámetro <mode> da la información de una forma u otra.
<mode> = 2 Responde con una trama NMEA “$GPGGA”.
<mode> = 4 Responde con una trama NMEA “$GPGLL”.
<mode> = 8 Responde con una trama NMEA “$GPGSA”.
<mode> = 16 Responde con una trama NMEA “$GPGSV”.
<mode> = 32 Responde con una trama NMEA “$GPRMC”.
<mode> = 64 Responde con una trama NMEA “$GPVTG”.
<mode> = 128 Responde con una trama NMEA “$GPZDA”.
6. Clientes Proyecto Fin de Carrera
53
<mode> = 0 Responde con una trama del siguiente formato:
<mode>,<longitude>,<latitude>,<altitude>,<UTC time>,<TTFF>,<num>,<speed>,<course>
Dónde:
<mode> es el modo indicado para que proporcione la información.
<longitude> es la longitud dada en grados, minutos y segundos.
<latitude> es la latitud dada en grados, minutos y segundos.
<altitude> es la altitud.
<UTC time> es la fecha y hora actual dado en el siguiente formato: yyyymmddHHMMSS
yyyy es el año escrito en 4 cifras.
mm es el mes escrito en 2 cifras.
dd es el día escrito en 2 cifras.
HH es la hora escrita en 2 cifras.
MM es el minuto escrito en 2 cifras.
SS es el segundo escrito en 2 cifras.
<TTFF> es una medida del tiempo requerido por el GPS receptor para fijar la primera señal
en segundos.
<speed> es la velocidad sobre la tierra.
<course> es el rumbo sobre la tierra.
6.2.3 Comandos para aplicaciones HTTP
-AT+HTTPINIT – Este comando inicializa un servicio HTTP, responde con “OK” si todo
ha ido correcto.
-AT+HTTPTERM – Este comando finaliza un servicio HTTP, responde con “OK” si todo ha
ido correcto.
-AT+HTTPPARA=<HTTPparamTag>,<HTTPparamValue> –Con este comando, entre otras
cosas, se puede indicar la URL del servicio HTTP al que se quiere acceder.
<HTTPparamTag> = URL, si se quiere indicar la URL.
<HTTPparamValue> la URL del servidor HTTP.
- AT+HTTPREAD=<start_adress>,<byte_syze> – Con este comando se lee la respuesta del
servidor HTTP.
<start_adress> el punto de comienzo de los datos de lectura.
<byte_syze> la longitud en byte que se quieren leer.
-AT+HTTPACTION=<Method> – En el caso que se haya mandado al servidor una petición
GET o POST, con este comando se le indica que método se ha usado.
<Method> = 0 GET
6. Clientes Proyecto Fin de Carrera
54
<Method> = 1 POST
<Method> = 2 HEAD
Este comando responde con códigos de estados HTTP, a continuación se muestra la lista de
los más conocidos.
100 - Continue
El navegador puede continuar realizando su petición (se utiliza para indicar que la primera
parte de la petición del navegador se ha recibido correctamente).
101 - Switching Protocols
El servidor acepta el cambio de protocolo propuesto por el navegador (puede ser por ejemplo
un cambio de HTTP 1.0 a HTTP 1.1).
200 - OK
Respuesta estándar para peticiones correctas.
201 - Created
La petición ha sido completada y ha resultado en la creación de un nuevo recurso.
202 - Accepted
La petición ha sido aceptada para procesamiento, pero este no ha sido completado. La
petición eventualmente pudiere no ser satisfecha, ya que podría ser no permitida o prohibida
cuando el procesamiento tenga lugar.
204 - No Content
La petición se ha completado con éxito pero su respuesta no tiene ningún contenido (la
respuesta sí que puede incluir información en sus cabeceras HTTP).
300 - Multiple Choices
Indica opciones múltiples para el URI que el cliente podría seguir. Esto podría ser utilizado,
por ejemplo, para presentar distintas opciones de formato para video, listar archivos con
distintas extensiones.
301 - Moved Permanently
Esta y todas las peticiones futuras deberían ser dirigidas a la URI dada.
302 - Found
Este es el código de redirección más popular, pero también un ejemplo de las prácticas de la
industria contradiciendo el estándar. La especificación HTTP/1.0 (RFC 1945) requería que el
cliente realizara una redirección temporal (la frase descriptiva original fue "Moved
Temporarily"), pero los navegadores populares lo implementaron como 303 See Other. Por
tanto, HTTP/1.1 añadió códigos de estado 303 y 307 para eliminar la ambigüedad entre ambos
comportamientos. Sin embargo, la mayoría de aplicaciones web y bibliotecas de desarrollo aún
utilizan el código de respuesta 302 como si fuera el 303.
303 - See Other (desde HTTP/1.1)
La respuesta a la petición puede ser encontrada bajo otra URI utilizando el método GET.
6. Clientes Proyecto Fin de Carrera
55
400 - Bad Request
La solicitud contiene sintaxis errónea y no debería repetirse.
404 - Not Found
Recurso no encontrado. Se utiliza cuando el servidor web no encuentra la página o recurso
solicitado.
405 - Method Not Allowed
Una petición fue hecha a una URI utilizando un método de solicitud no soportado por dicha
URI; por ejemplo, cuando se utiliza GET en una forma que requiere que los datos sean
presentados vía POST, o utilizando PUT en un recurso de solo lectura.
409 - Conflict
Indica que la solicitud no pudo ser procesada debido a un conflicto con el estado actual del
recurso que esta identifica.
500 - Internal Server Error
Es un código comúnmente emitido por aplicaciones empotradas en servidores web, que
genera contenido dinámicamente, por ejemplo aplicaciones montadas en IIS o Tomcat, cuando
se encuentran con situaciones de error ajenas a la naturaleza del servidor web.
501 - Not Implemented
El servidor no soporta alguna funcionalidad necesaria para responder a la solicitud del
navegador (como por ejemplo el método utilizado para la petición).
6.3 Diseño y programación del Cliente-Vehículo
El sketch de Arduino de los Clientes-Vehículos consta de una gran máquina de estados. A
continuación se presenta el diagrama de estados por el cual está formado. [26]
Clientevehiculos.ino
1. Se inicializa el hardware. Se configuran los pines de entrada o salida, la velocidad del
puerto serie, inicialización de las variables etc…
2. Se comprueba que hay conexión con el modem GSM/GPRS.
3. Se configura las respuestas en modo sin eco.
4. Se introduce el pin de la tarjeta SIM.
5. Se enciende el GPS.
6. Se resetea la configuración del GPS.
7. Se configura la velocidad de transmisión del GPS.
6. Clientes Proyecto Fin de Carrera
56
8. Se espera a que los satélites estén fijados.
9. Se espera a que se conecte a la red GSM.
10. Se abre un contexto tipo GPRS.
11. Se configura la APN.
12. Se introduce el usuario de la APN.
13. Se introduce la contraseña de la APN.
14. Se establece la conexión GPRS.
15. Se obtiene las coordenadas de las tramas NMEA.
16. Se inicia una nueva conexión HTTP.
17. Se establece conexión HTTP.
18. Se manda una petición HTTP mediante una URL.
19. Se indica que es una petición GET.
20. Se lee la respuesta y se representa.
21. Se finaliza la conexión HTTP.
Los errores se producen cuando hay una respuesta negativa un número sucesivo de veces.
6. Clientes Proyecto Fin de Carrera
58
6.4 Diseño y programación del Cliente-Parada
Al igual que los Clientes-Vehículos, el sketch de Arduino de los Clientes-Paradas está
constituido por una máquina de estados. A continuación se presenta su diagrama de estados.
Clienteparada.ino
1. Se inicializa el hardware. Se configuran los pines de entrada o salida, la velocidad del
puerto serie, inicialización de las variables etc…
2. Se comprueba que hay conexión con el modem GSM/GPRS.
3. Se configura las respuestas en modo sin eco.
4. Se introduce el pin de la tarjeta SIM.
5. Se espera a que se conecte a la red GSM.
6. Se abre un contexto tipo GPRS.
7. Se configura la APN.
8. Se introduce el usuario de la APN.
9. Se introduce la contraseña de la APN.
10. Se establece la conexión GPRS.
11. Se espera a que se solicite mediante el pulsador la parada.
12. Se inicia una nueva conexión HTTP.
13. Se establece conexión HTTP.
14. Se manda una petición HTTP mediante una URL.
15. Se indica que es una petición GET.
16. Se lee la respuesta y se representa.
17. Se finaliza la conexión HTTP.
Los errores se producen cuando hay una respuesta negativa un número sucesivo de veces.
6. Clientes Proyecto Fin de Carrera
60
6.5 Interfaz Clientes
Tanto el Cliente-Vehículo, como el Cliente-Parada están constituidos por una misma interfaz
física, que servirá como medio para interactuar con ellos y mostrar la información del sistema.
A continuación se muestra la distribución de esta interfaz, y el cableado necesario para su
conexión a la placa Arduino.
Ilustración 44: Interfaz física Clientes
La interfaz física incluye una pantalla LCD Nokia 5110 que será la encargada de mostrar la
información. Para los Cliente –Vehículo mostrará las paradas que actualmente haya solicitud de
parada. Y para los Cliente-Parada mostrará la información del Cliente-Vehículo más cercano en
caso de que se haya solicitado la parada.
La pantalla Nokia 5110 está formada por 8 pines que son los siguientes:
Número de Pin Nombre de Pin Función de Pin Notas
1 RST Reset
2 CE Chip Selection
(Selección de chip)
3 DC Data/Command
s choice
4 DIN Serial data in
6. Clientes Proyecto Fin de Carrera
61
5 CLK Serial clock
6 VCC
Positive power
supply
(Alimentación
positiva)
2.7V a 3.3V
7 LIGHT LED backlight
supply
Conectar a
VCC para máx
brillo
8 GND Ground (Tierra)
Tabla 12: Pines LCD Nokia 5110
Los 5 primeros pines son las líneas de control SPI de la pantalla. Cuando no se utilizan otros
dispositivos SPI, el pin 2 (CE), de selección de chip se puede conectar a GND, de modo que se
pueden usar solo 4 líneas de control.
La pantalla utiliza el chip controlador PCD8544 de Philips. Este chip está diseñado para
funcionar sólo a 3.3V y tienen niveles de comunicación de 3V, por lo que para los
microcontroladores de 5V se requiere un conversor de nivel lógico o resistencias de limitación
de corriente (de lo contrario podría dañar fácilmente la pantalla).
Para poder interactuar los usuarios con el sistema, la interfaz consta con unos pulsadores.
Dichos pulsadores sirven para solicitar paradas en el caso de los Clientes-Parada. El pulsador 1
servirá para pedir solicitud de parada en los trayectos de Ida, y el pulsador 2 para los trayectos
de Vuelta. También servirá para reiniciar el estado de las solicitudes de paradas en el caso de
los Clientes-Vehículos, indistintamente que pulsador se pulse se reiniciará la solicitud de la
parada más cercana.
Estos pulsadores van conectados a los pines de interrupción de Arduino. De esta forma se
puede interactuar de forma asíncrona con el sistema.
Por último, la interfaz consta de un conjunto de interruptores DIP, que servirá al usuario
para configurar algunos parámetros. En el caso de los Clientes-Vehículos se puede configurar
con uno de los interruptores si está realizando un trayecto de Ida o de Vuelta.
El resto de interruptores se dejan reservados para futuros parámetros de configuración.
7. Presupuesto Proyecto Fin de Carrera
63
7. Presupuesto
Los costes referentes a los materiales utilizados se reflejan en la siguiente tabla:
Concepto
Unidades Precio (€/ud.) Subtotal (€)
Arduino Uno R3
1 5,08 € 5,08 €
Arduino Mega 2560 R3
1 9,12 € 9,12 €
Shield GSM/GPRS SIM900
1 51,00 € 51,00 €
Shield GSM/GPRS/GPS
SIM908
1 23,99 € 23,99 €
Protoboard
1 1,27 € 1,27 €
LCD Nokia 5110
1 2,37 € 2,37 €
Pack 40 Cables Arduino
1 1,43 € 1,43 €
Pulsador Boton Arduino
2 0,20 € 0,40 €
LEDs - Through Hole
2 0,10 € 0,20 €
Pack 10 Resistencias-
Through Hole
1 0,35 € 0,35 €
DIP Switches
2 0,10 € 0,20 €
Ordenador portátil Lenovo
G500
1 599,99 € 599,99 €
TOTAL COSTE DE MATERIALES
695,40 €
Tabla 13: Costes de Materiales
7. Presupuesto Proyecto Fin de Carrera
64
En cuanto a los costes de la mano de obra del proyecto se refleja en la siguiente tabla:
Concepto
Horas Precio (€/h) Subtotal (€)
Ingeniero Superior de
Telecomunicación
300 20,00 € 6000,00 €
TOTAL COSTE DE MANO DE OBRA
6000,00 €
Tabla 14: Costes de Mano de Obra
Por último el importe total del proyecto se refleja en la siguiente tabla:
Concepto
Importe (€)
Total Coste de Materiales
695,40 €
Total Coste de Mano de Obra
6000,00 €
TOTAL
6695,40 €
Beneficio Industrial (20%)
1339,08 €
TOTAL (SIN IVA)
8034,48 €
TOTAL (21% IVA)
9721,73 €
Tabla 15: Importe Total del Proyecto
8. Conclusiones y posibles mejoras Proyecto Fin de Carrera
65
8. Conclusiones y posibles mejoras
8.1 Introducción
A lo largo de este proyecto, se ha diseñado un prototipo inicial de un sistema para optimizar
las rutas del transporte público, y aprovechar el mismo para ofrecer información del estado de
los medios de transporte a los usuarios. Este prototipo inicial ha servido para comprobar la
viabilidad del sistema propuesto, aun así se han simplificado muchos detalles a tener en cuenta
si se quiere que el sistema sea un producto comercial. Por tanto, este proyecto aún tiene un
amplio margen de mejoras. A continuación se expondrá algunas de ellas que se han considerado
importantes.
8.2 Adaptación a todas las rutas
En este proyecto, se ha tenido en cuenta una única ruta, para facilitar el prototipo inicial. El
incorporar mayor número de rutas puede suponer incorporar nuevas variables y problemas no
tenidos en cuenta hasta ahora. Habría que escalar el Servidor, de forma que analice los datos
provenientes de todos los medios de transportes de todas las rutas y así tomar las decisiones
acorde a dicha información.
8.3 Aplicación móvil
En el sistema propuesto una aplicación web es la encargada de poder interactuar con el
sistema, o a través del pulsador instalado en las propias paradas. Aunque la aplicación web se
pueda ver a través de cualquier teléfono móvil con acceso a internet, resultaría más intuitivo y
de mayor facilidad de uso una aplicación dónde mostrara toda la información de los vehículos
similar a la de TUSSAM anteriormente mencionada, y que además se pueda solicitar las paradas
desde ella.
8.4 Adaptación a todos los medios de transportes
Aunque en dicho proyecto se ha centrado en aquellos medios de transportes que tienen una
ruta prefijada, también podría ser útil para aquellos medios de transportes que no la tienen,
como pueden ser los taxis. El Servidor podría analizar todos los datos provenientes de los taxis
de una ciudad y mostrarlo en la aplicación web, y modificar el sistema de solicitud de paradas,
para poder así solicitar la presencia de un taxi en las coordenadas que se le indique. Y en el caso
de tener ya una aplicación en el teléfono móvil adaptada al sistema, ésta misma poder indicar
gracias al GPS del móvil las coordenadas a los taxistas.
8.5 Sistema de alimentación de las plataformas de desarrollo
Hasta ahora no se ha tenido en cuenta como alimentar las plataformas de desarrollos del
sistema, usándose para el prototipo inicial baterías, o la propia red eléctrica de una vivienda.
Pero si las plataformas de desarrollos deben estar en las paradas y en los medios de transportes,
habría que analizar cómo alimentarlas. Los Clientes Vehículos no supondrían gran problema
puesto que todos los vehículos tienen una batería, sin embargo en los Clientes Paradas, la
alimentación se debe hacer mediante baterías. Habría que diseñar un sistema de recarga de
dichas baterías, pudiendo ser perfectamente unas placas solares, ya que el consumo del sistema
no es muy grande.
8. Conclusiones y posibles mejoras Proyecto Fin de Carrera
66
8.6 Seguridad
Si el sistema se quiere hacer comercial, habría que proporcionarle cierto nivel de seguridad,
para que el mal uso de los usuarios no interfiera en el correcto desarrollo de la aplicación. Para
ello los datos podrían ir encriptado, y el servidor usar el protocolo HTTPS, donde se crea un
canal cifrado entre el navegador web y el propio servidor. De esta forma aunque algún atacante
consiga interceptar la transferencia de datos de la conexión, ya que lo único que obtendrá será
un flujo de datos cifrados que le resultará imposible de descifrar.
8.7 Sistema de pago por el servicio
Hasta ahora si el sistema se implementase el servicio es totalmente gratuito para aquellos
usuarios que lo deseen usar, pero de esta forma habría que confiar en el buen juicio de las
personas para su correcto uso. Aun así habrá usuarios que soliciten la parada, obliguen por ello
a desviarse el medio de transporte y después no hacer uso del mísmo, para evitar estos casos, se
podría implementar un sistema en las paradas y en la aplicación web dónde se pague ya el
importe del trayecto cuando se solicite la parada. De esta forma se evitaría en gran medida el
mal uso por parte de los usuarios, y en el caso de hacerlo se les penaliza con el coste del
trayecto.
8.8 Gestor de estadísticas
También se podría implementar en el sistema un gestor de estadísticas para estudiar la
cantidad de usuarios que solicitan las paradas, cuáles son las horas de mayor utilización de las
paradas o cualquier otra información relevante. Con dichos estudios se podrían hacer rutas más
óptimas y mejorar en definitiva el transporte público.
67
REFERENCIAS
[1] http://www.moviloc.com/index.php/es/moviloc
[2] http://universocelular.com/2007/12/07/gsm-y-gprs-conceptos-generales/
[3] http://www.gsmspain.com/glosario/?palabra=GPRS
[4] http://www.gsma.com/aboutus/gsm-technology/gprs
[5] http://www.gps.gov/spanish.php
[6] http://www.gpsinformation.org/dale/nmea.htm
[7] https://www.arduino.cc/
[8] http://sabetecnologia.blogspot.com.es/2013/03/tabla-comparativa-de-arduinos.html
[9] https://www.raspberrypi.org/
[10] https://raspberryparatorpes.net/
[11] http://www.ti.com/ww/en/launchpad/launchpads-msp.html
[12] https://www.arduino.cc/en/ArduinoCertified/IntelGalileo
[13] http://wiki.pinguino.cc/index.php/PIC18F45K50_Pinguino/es
[14] http://www.banana-pi.org
[15] http://www.seeedstudio.com/wiki/GPRS_Shield_V1.0
[16] http://www.waveshare.net/wiki/GSM-GPRS-GPS-Shield-UserManual
[17] https://www.u-blox.com/en/product/neo-6-series
[18] http://www.tutorialesya.com.ar
[19] https://secure.php.net/manual/es/index.php
[20] http://www.adelat.org/media/docum/lenguajes_del_lado_servidor_o_cliente.html
[21] https://openclassrooms.com/question-a-propos-de-html-php-javascript-et-ajax-48567
[22] https://console.developers.google.com/apis/
[23] http://computerhoy.com/crea-tu-propio-servidor-local-desarrollo-web-xampp-6009
[24] http://www.hostinger.es/
[25] http://m2msupport.net/m2msupport/software-and-at-commands-for-m2m-modules/
[26] https://www.cooking-hacks.com/documentation/tutorials/geolocation-tracker-gprs-gps-
geoposition-sim908-arduino-raspberry-pi/
69
GLOSARIO
AJAX JavaScript Asíncrono y XML
API Interfaz de Programación de Aplicaciones
APN Nombre del Punto de Acceso
DNS Sistema de Nombres de Dominio
FTP Protocolo de Transferencia de Archivos
GIS Sistema de Información Geográfica
GPRS Servicio General de Paquetes vía Radio
GPS Sistema de Posicionamiento Global
HTML Lenguaje de Marcas de Hipertexto
NMEA Asociación Nacional de Electrónica Marina
PHP Pre-procesador de Hipertexto
RTC Reloj en Tiempo Real
SIM Módulo de Identificación de Abonado
SMS Servicio de Mensajes Simples
SPI Interfaz de Periféricos Serie
SQL Lenguaje de Consulta Estructurado
SSH Órdenes Seguro
SSL Capa de Puertos Seguros
TDMA Acceso Múltiple por División de Tiempo
UART Transmisor-Receptor Asíncrono Universal
USB Universal Serial Bus