sistema de optimización de rutas de transporte...

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.2 Decisión final ........................................................................................................ 23

3.4 Elección del módulo GPS ............................................................................................ 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


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


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


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.


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


6

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


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).


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.


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.


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.


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


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.


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


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


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]


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


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


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.


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.


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


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


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.


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


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.


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


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


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


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


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


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>.


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


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


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


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


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 )


requerido

Tabla 7: Precios API de Google


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.


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:



-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


36

del Cliente-Vehículo más cercano a cada Cliente-Parada. Los campos que constituyen dicha

tabla son los siguientes.



-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:



-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.


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.


38

Ilustración 34: Diagrama de flujo clientevehiculo.php


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.


40

Ilustración 35: Diagrama de flujo clienteparada.php


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.


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.


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


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.


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


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


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í


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


50

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.


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”.


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


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.


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.


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.


57

Ilustración 42: Diagrama de estados Cliente-Vehículo


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.


59

Ilustración 43: Diagrama de estado Cliente-Parada


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


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.


62

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

71

ANEXO: ESQUEMÁTICO SIM908

72

ANEXO: ESQUEMÁTICO SIM900

sistema de optimización de rutas de transporte...

Documents