InstitutoPolitécnicoNacional EscuelaSuperiordeCómputo ESCOM

Instituto Politécnico NacionalEscuela Superior de Cómputo

ESCOM

Trabajo Terminal

Çonjunto de Bibliotecas para el desarrollo de Sistemas AVL"

2015-2-014

Presentan:Guevara Castillo Jorge

Mendoza Reboyo Marco Antonio

Directores

————————————————- ————————————————-M. en C. Hermes Francisco Montes Casiano M. en C. Ulises Vélez Saldaña

Julio 2015

1

Instituto Politécnico NacionalEscuela Superior de Cómputo

No. de Registro: 2015-2-014 Serie: Amarilla Julio 2015

Documento Técnico

Conjunto de Bibliotecas para el desarrollo de Sistemas AVL

Presentan:Guevara Castillo Jorge[1]

Mendoza Reboyo Marco Antonio[2]

RESUMENPara mejorar el control de su parque vehicular es común que las organizaciones opten por el

desarrollo y uso de sistemas AVL (Localización Vehicular Automatizada, por sus siglas en inglés)que se adecuen a sus necesidades. En la actualidad los sistemas AVL se desarrollan a la medida ydebido a su complejidad a menudo se opta por el uso de soluciones comerciales. A continuación sepropone la construcción de un conjunto de Bibliotecas que permita desarrollar sistemas AVL parareducir tiempos y costos de desarrollo de este tipo de sistemas.

Palabras clave: AVL, Biblioteca de software, Sistema web.

Directores

————————————————- ————————————————-M. en C. Montes Casiano Hermes Francisco M. en C. Vélez Saldaña Ulises

[1] [email protected][2] [email protected]

2

Advertencia

“Este documento contiene información desarrollada por la Escuela Superior de Cómputodel Instituto Politécnico Nacional, a partir de datos y documentos con derecho depropiedad y por lo tanto, su uso quedará restringido a las aplicaciones que explicitamentese convengan.”

La aplicación no convenida exime a la escuela su responsabilidad técnica y da lugar alas consecuencias legales que para tal efecto se determinen.

Información adicional sobre este reporte técnico podrá obtenerse en:

La Subdirección Académica de la Escuela Superior de Cómputo del Instituto PolitécnicoNacional, situada en Av. Juan de Dios Bátiz s/n Teléfono: 57296000, extensión 52000.

4

Índice general

1. Introducción 81.1. Presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2. Sistemas AVL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3. Organización del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2. Estado del Arte 112.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2. Geolocalización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1. GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.2. A-GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.3. Sistemas de Referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.4. Sistema de Coordenadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3. Visualización de Mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.1. Servidor de Mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.2. Bases de Datos Geográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.3. OpenLayers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4. Vehículos y Variables de Sensado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5. Sistema AVL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5.1. Arquitectura de un AVL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.5.2. Tipos de Sistemas AVL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.5.3. Sistemas AVL en la Actualidad . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.6. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.7. API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.8. Propuestas de Solución Similares . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.8.1. OpenGTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.8.2. Traccar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.9. Patrones de Diseño de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.9.1. Patrones Creacionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.9.2. Patrones de Comportamiento . . . . . . . . . . . . . . . . . . . . . . . . . . 342.9.3. Patrones Estructurales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3. Análisis del Problema 363.1. Problemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1.1. Complejidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5

3.1.2. Integración de Tecnologías . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1.3. Diseño Complejo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.4. Curva de Aprendizaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2. Objetivo del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.1. Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3. Planteamiento de la Solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3.1. Requerimientos del Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3.2. Requerimientos del Desarrollador del AVL . . . . . . . . . . . . . . . . . . . 413.3.3. Requerimientos no Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.4. Propuesta de Solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.5. Metodología y plan de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4. Diseño e implementación 474.1. Diseño de LibAVL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.1.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.1.2. Modelo de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.3. Conjunto de Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5. Pruebas y resultados 645.1. Pruebas de concepto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.1.1. Visualización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.1.2. Rutas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.1.3. Geocercas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.1.4. AVLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.2. Pruebas de integración y usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.2.1. Prueba 1: Ejecución del tutorial Hola mundo. . . . . . . . . . . . . . . . . . 695.2.2. Prueba 2: Ejecución del tutorial Seguimiento. . . . . . . . . . . . . . . . . . 705.2.3. Prueba 3: Ejecución del tutorial Rutas. . . . . . . . . . . . . . . . . . . . . . 705.2.4. Prueba 4: Ejecución del tutorial Geocercas. . . . . . . . . . . . . . . . . . . . 715.2.5. Resultados generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6. Conclusiones 74

7. Trabajo Futuro 757.1. Alertas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.2. Generación y Control de Reportes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.3. Compatibilidad con otros sistemas gestores de base de datos . . . . . . . . . . . . . 767.4. Aplicación móvil para teléfonos inteligentes . . . . . . . . . . . . . . . . . . . . . . . 767.5. Añadir capas de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Anexos 76

A. JavaDoc 77A.1. JavaDoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6

B. Tutorial 79B.1. Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

B.1.1. ¿Qué es LibAVL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79B.1.2. Hola mundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81B.1.3. Visualización de mapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88B.1.4. Seguimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89B.1.5. Rutas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92B.1.6. Geocercas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95B.1.7. Alarmas SOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97B.1.8. Consultas, bajas, modificaciones vehiculares y de AVLDs . . . . . . . . . . . 99B.1.9. Estilos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100B.1.10.Haciendo crecer a LibAVL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

C. Pruebas realizadas a individuos 106

7

Capítulo 1

Introducción

1.1. PresentaciónEl presente documento es el reporte técnico de avances de desarrollo del trabajo terminal Con-

junto de Bibliotecas para el desarrollo de sistemas AVL que presenta los avances que comprendenla investigación, descripción de la problemática, estado del arte, desarrollo y pruebas realizadas.Dicho trabajo terminal tiene el número de registro 2015-2-014 y fue elaborado por los alumnosGuevara Castillo Jorge y Mendoza Reboyo Marco Antonio.

1.2. Sistemas AVLHoy en día los vehículos son vitales para la movilidad del ser humano, economía, derivado de

ello es importante gestionar y monitorear los vehículos ya que son activos importantes.

Los Dispositivos de Localización Automática de Vehículos (Automatic Vehicle Location De-vice, AVLD por sus siglas en inglés) son dispositivos que se colocan en los vehículos y permitenmonitorear su estatus:

Ubicación.

Combustible.

Nivel de Gasolina.

Velocidad.

Generalmente las grandes organizaciones adquieren sistemas AVL que son soluciones complejasque incluyen hardware y software que les permiten realizar tareas, tales como visualizar la posiciónde uno o más vehículos en un mapa, ver las rutas recorridas por dichos vehículos, ver el historialde cada uno de sus vehículos, ver variables sensadas con el dispositivo, reportes de los vehículos.

Este trabajo terminal está centrado en la problemática de desarrollar un sistema AVL. Es-tos desarrollos en particular son complicados porque incluyen una gran cantidad de solucionesindependientes con el fin de resolver problemas específicos como:

8

Configurar el dispositivo de localización a utilizar.

Configurar la comunicación del dispositivo con un servidor.

Desplegar la información del servidor en un mapa.

Por lo tanto se tiene como objetivo construir herramientas que faciliten esta tarea al progra-mador, orientadas inicialmente a un conjunto específico de soluciones a integrar. Soluciones talescomo archivos de configuración tanto para el dispositivo de localización como para desarrollar elsistema, bibliotecas y un dispositivo de localización con características específicas, con miras a queestas posteriormente se extiendan, se convierten en un conjunto de herramientas denominado API.

1.3. Organización del documentoÉste reporte se ha organizado en siete capítulos y un apartado de anexos, de cada uno se expone

una breve descripción de su contenido a continuación:

Capítulo 2. Estado del arteEn el capítulo 2 se abordan algunas de las definiciones, referencias y conceptos referentes al desa-rrollo de sistemas AVL, teniendo como objeto describir el contexto general del trabajo terminal yel contenido del presente reporte de avance. Se abarcan temas y definiciones partiendo desde loque es un sistema AVL y sus principales componentes hasta lo que es una API, y conceptos comoGSM, GPS, servidor de mapas, entre otros.

También se expone la situación actual y los avances alusivos a la temática que rodea al temaprincipal del trabajo terminal. Se aborda información acerca del desarrollo de sistemas AVL comer-ciales, además se incluye información relacionada al estado del desarrollo actual de los frameworksAVL y sus componentes, con el fin de dar paso al análisis del problema.

Capítulo 3. Análisis del problemaEn el capítulo 3 se explora el problema y se muestra el análisis del mismo, iniciando con el estudiodel contexto, seguido de una exposición de la problemática, mostrar el objetivo del trabajo ter-minal, el análisis de la solución y terminando con la propuesta de solución elegida para afrontardicha problemática.

Capítulo 4. Diseño e ImplementaciónEn el capítulo 4 se presenta el desarrollo del presente trabajo terminal, así como pruebas de con-cepto que permiten validar la arquitectura del AVL y definir los aspectos técnicos que deberáncontener el conjunto de Bibliotecas.

Capítulo 5. Pruebas y resultadosEn el capítulo 5 se muestran las pruebas de concepto y las realizadas a individuos con la finalidadde dar mayor sustento a las conclusiones del presente trabajo terminal.

9

Capítulo 6. ConclusionesEn el capítulo 6 se exponen las conclusiones referentes al trabajo desarrollado en el trabajo termi-nal, incluyendo argumentos ante las dificultades enfrentadas, las soluciones dadas y los resultadosobtenidos.

Capítulo 7. Trabajo futuroEn el capítulo 7 se plantean los módulos que podrían añadir valor al presente trabajo terminal yque podrían desarrollarse a futuro ya que quedan fuera del presente trabajo terminal.

AnexosAl final del documento se presenta un apartado de anexos 7.5, conteniendo toda la informacióncomplementaria mencionada dentro del presente reporte.

10

Capítulo 2

Estado del Arte

En éste capítulo se abordan definiciones, referencias y conceptos referentes a la temática delConjunto de Bibliotecas para el desarrollo de sistemas AVL. El objetivo es comprender el contextogeneral del trabajo terminal y el contenido del presente reporte.

También se aborda información acerca del desarrollo de sistemas AVL comerciales, se incluyeinformación relacionada al estado del desarrollo actual de un conjunto de Bibliotecas y sus com-ponentes.

Los temas y definiciones son los siguientes:

Sistema AVL, sus principales componentes y el mercado.

Geolocalización.

Visualización de Mapas.

Vehículos y variables de sensado.

Sistema AVL.

Framework.

API.

Propuestas de solución similares.

Patrones de Diseño de Software.

2.1. ContextoUn sistema de localización vehicular se ha convertido en un servicio de importancia para or-

ganizaciones que tienen vehículos como herramientas de trabajo, o que tienen a su disposición eluso de vehículos para el transporte personal. Sectores como el transportista o de valores se hanbeneficiado del uso de sistemas de localización en sus flotillas supliendo algunas de sus necesidades,

11

ya que permiten hacer varias tareas, como por ejemplo: obtener la ubicación de sus vehículos encaso de robo, el monitoreo de los mismos, mejora en la confiabilidad del servicio y provisión deinformación a bajo costo para ser utilizada con propósitos de planificación.

Sin embargo, las partes que componen un sistema AVL no son pocas. Integran elementos dehardware y software los cuales llamaremos: dispositivo de localización( o AVL), medio de comu-nicación, sistema central, medio de almacenamiento y mecanismo de visualización; los cuales sepueden ver en la figura 2.1 y se detallaran en este capitulo.

Además, las necesidades que suplen son variadas y no están orientadas a un tipo de usuario enespecial (sea una organización o para uso personal). Estas necesidades se explicaran más adelanteen el capitulo 3 y 4. Sumado a esto, las organizaciones que ofertan sistemas AVL muchas vecestienen contratos con proveedores de software y hardware que limitan a los desarrolladores al uso dealguna tecnología en especial. Otra opción es que los desarrolladores estén inclinados por alguna,realizando de manera más sencilla, más rápida y con mayor entendimiento su trabajo.

Las organizaciones que desarrollan un sistema AVL, incorporan las tecnologías de informaciónpara favorecer la comunicación entre los dispositivos y los usuarios finales, favoreciendo de estaforma los procesos logísticos al interior de estas.

En los siguientes temas se comenzarán a describir los conceptos de las tecnologías que empleaun sistema AVL, para obtener un mejor entendimiento de su funcionamiento.

2.2. GeolocalizaciónLa geolocalización implica el posicionamiento que define la localización de un objeto en un

sistema de coordenadas determinado. Este proceso es generalmente empleado por los sistemas deinformación geográfica, diseñados especialmente para capturar, almacenar, manipular y analizaren todas sus posibles formas la información geográfica referenciada, con la clara misión de resol-ver problemas de gestión y planificación. Existen varias alternativas para conocer esta ubicación,aunque claro, son los dispositivos móviles los que por su portabilidad con nosotros mismos nospermitirán más fácilmente conocer nuestra ubicación y actualizarla a medida que nos vamos mo-viendo y por tanto, cambiando de ubicación geográfica. Entre ese amplio abanico de opciones quenos permiten descubrir la geolocalización se destacan los receptores GPS, de los cuales entraremosmás a detalle a continuación, los cuales y gracias a la red de satélites que rodea al planeta podránubicarnos en cualquier parte del globo terráqueo en el cual nos encontremos.

2.2.1. GPSUna de las tecnologías más usadas por los dispositivos de localización es el Sistema de Po-

sicionamiento Global (Global Position System, GPS por sus siglas en inglés), la cual se basa entecnología satelital[6].

Las principales redes de satélites GPS en órbita alrededor del planeta son:

12

Programa de Tecnología de Navegación Satelital (NAVSTAR GPS por sus siglas en inglés):creado por los Estados Unidos. La red satelital más usada y famosa que cuenta con 24satélites en órbita a una altitud de 20,200 km y con un periodo aproximado de 12 horas[7].Mayormente utilizada con fines militares aunque cuenta con dos tipos de señales, una parauso militar y otra para uso civil.

Galileo: Proyecto de navegación satelital de la Unión Europea pensado para ser completamen-te libre. Actualmente no completamente funcional por retrasos en el desarrollo del proyectopero con el que ya se han hecho pruebas. Permite la localización de receptores GPS en tierrapero que también fue diseñado para la navegación en el espacio[8].

GLONASS: Sistema global de navegación por satélite (Global Navigation Satellite System,GLONASS por sus siglas en inglés) ruso que está divida en 2 constelaciones una exclusivade navegación con 28 satélites y una de GPS con 30 en su constelación 24 en operación, 3 derepuesto y 1 en fase de pruebas [9].

Compass (Beidou-2). Sistema de navegación satelital chino que es la segunda generación delproyecto Beidou que no provee un servicio global sino solamente local para China y algunosvecinos[10].

Funcionamiento

El sistema de posicionamiento global está dividido en 3 partes o segmentos como se observa enla figura 2.1 y se describen a continuación:

1. Segmento satelital.

2. Segmento de control.

3. Segmento de usuario.

Figura 2.1: Segmentos GPS

13

Segmento Satelital

Es la red de satélites en órbita: 24 satélites en órbita con una inclinación de 55 grados conrespecto al ecuador distribuidos en 6 planos con 4 satélites cada uno, a una altitud de 20,200 kmy con una periodo aproximado de 12 horas. Dicha precisión en su inclinación, altitud y periodo,permite obtener una ubicación fiable por parte del dispositivo de localización sin importar suposición en el globo terrestre, un motivo de peso para ser una tecnología tan utilizada.Un satélite consta de 3 partes principales:

1. Computadora: controla todas las funciones del satélite, la más importante, el vuelo en laórbita.

2. Reloj atómico: reloj con una exactitud de hasta 3 nanosegundos.

3. Radiotransmisor: envía y recibe las señales de la tierra.

Los satélites GPS manejan 2 tipos de señales:

C/A-code: Código de adquisición común (Coarse Acquisition Code, C/A-code por sus siglasen inglés) que es enviado por la banda L1 a una frecuencia de 1575.42 MHz. que es de usocivil. La señal C/A broadcast es conocida como Servicio de Posición Estandard (StandardPosition Service, SPS por sus siglas en inglés).

P-code: Código de Precisión (Precision code, P-code por sus siglas en inglés) que es deuso militar con mayor precisión y cifrado para evitar en lo posible la visualización de lainformación por cualquier usuario. La señal es transportada por la banda L2 a una frecuenciade 1227.6 MHz.La señal P-code broadcast es conocida como Servicio Preciso de Posición (Precise PositionService, PPS por sus siglas en inglés).

Las frecuencias de broadcast son utilizadas para iniciar el proceso de comunicación por parte deldispositivo de localización con el satélite.

Segmento de Control

Son estaciones que supervisan los satélites, existen 5 alrededor de la tierra que envían su in-formación al centro de operaciones en la base de la fuerza aérea Schriever en Colorado donde seprocesa toda la información de los satélites como sus efemérides y sus errores.

Las efemérides son una lista de posiciones de los cuerpos celestes como la luna, que permitenuna mejor orientación espacial, junto con los datos de las posiciones de los satélites alrededor dela tierra.

Los datos recopilados de todas las efemérides son enviados una vez al día con ayuda de antenasen tierra, lo que permite tener una sincronización adecuada de cada satélite con la constelaciónsatelital y manipular su dirección o velocidad, si fuera necesario, desde tierra.

14

El control de los satélites desde tierra es sumamente importante, ya que permite monitorear suposición y observar a través de sus efemérides si su posición con respecto a otros satélites y a loscuerpos celestes es la adecuada para realizar su función.

Segmento de Usuario

Se refiere a todos los receptores GPS o dispositivos de localización, que pueden recibir las se-ñales GPS e interpretarlas para determinar su localización.

Dichos receptores o antenas GPS reciben 2 tipos de información:

1. Datos de almanaque (Almanac Data por su traducción al inglés), que se refiere a la posiciónde los satélites y que son recibidos constantemente y almacenados en la memoria del receptorGPS.

2. Efemérides, que permiten obtener la ubicación del satélite, el tiempo de su reloj, entre otros.

Para obtener su ubicación, el receptor GPS hace uso de fórmulas matemáticas y de los datosque ya posee de los satélites. Primero el receptor hace uso de la señal de broadcast para ubicarcuáles satélites están cerca de él y se sincronizan por medio de un código pseudo aleatorio queambos conocen. Una vez que los satélites le envían sus datos (descritos en secciones previas), sepuede determinar la distancia del satélite al receptor calculando la diferencia de tiempo que tardóla señal en llegar del satélite al receptor (ya que la velocidad de la luz es constante).

El receptor GPS necesita de por lo menos 3 satélites para conocer su ubicación aproximada,ya que utiliza algoritmos definidos para realizar una triangulación de su posición con respecto alos satélites. Para conocer su latitud, longitud y elevación, son necesarios 4 satélites, ya que elcuarto intersecta la triangulación hecha previamente, de ahí que la precisión de un GPS varíe deaproximadamente 15 metros (en el 95% del tiempo) hasta los 3 metros[12].

2.2.2. A-GPSEl sistema GPS Asistido (Assisted GPS, A-GPS por sus siglas en inglés) es un sistema creado

principalmente para mejorar el tiempo de cálculo y la exactitud de la posición donde la señal GPSno es captada adecuadamente.

La mayoría de los receptores GPS no son capaces de descargar completamente la informacióndel satélite como las efemérides o el almanaque en la primera petición (primer posicionamiento oposicionamiento inicial), lo que hace que sea largo y en ocasiones devuelva información errónea;dicho problema es solucionado con el sistema A-GPS[13].

Los sistemas asistidos GPS son utilizados comúnmente en la tecnología móvil, aunque no limita-dos a ella, y utiliza información preconocida por las redes de telefonía guardada en sus servidores[14]sobre la constelación GPS para dispositivos que se encuentran en lugares con interferencias o den-tro de edificios, lo que para un GPS normal sería imposible resolver.

15

El inconveniente de éste sistema se encuentra en la necesidad de tener siempre actualizada lainformación regularmente vía internet, del o los servidores lo que se ve reflejado en el costo.

GPS vs A-GPS

Podemos resumir que cada tecnología tiene sus ventajas y sus desventajas. Mientras el GPS nonecesita de alguna otra red para obtener la posición, es de muy buena precisión en lugares abiertospero es un tanto lento, el A-GPS es más rápido pero dependiente de la conexión a la red del móvily un tanto menos preciso en interiores. La decisión de su uso dependerá su aplicación.

2.2.3. Sistemas de ReferenciaEn la actualidad, la utilización de los GPS es común para la realización de sistemas AVL donde

la precisión es fundamental. Debido a ello, se ha presentado una dificultad si queremos utilizar elGPS en cualquier parte del mundo y que nos presente en un mapa las coordenadas que correspondeal Sistema local de ese país. Es por eso que hacemos uso de un Sistema de Referencia, el cual serefiere al conjunto de coordenadas espacio-tiempo que se requieren para poder determinar la posi-ción de un punto en el espacio usadas por un observador, el cual es capaz de realizar medicionesde magnitudes físicas.

Las trayectorias medidas y el valor numérico de muchas magnitudes son relativas al sistemade referencia que se considere. Sin embargo, aunque los valores numéricos de las magnitudes pue-den diferir de un sistema a otro, siempre están relacionados por relaciones matemáticas tales quepermiten a un observador predecir los valores obtenidos por otro observador. Teniendo en cuentaesto, hablaremos a detalle del WGS84.

WGS84

El Sistema Geodésico Mundial 1984 (World Geodetic System 84, WGS84 por sus siglas eninglés), es un sistema de coordenadas geográficas mundial que permite localizar cualquier punto dela Tierra por medio de tres unidades dadas. Es representado por un código del Grupo de Estudiode Petróleo Europeo (European Petroleum Survey Group, EPSG por sus siglas en inglés) el cuales EPSG:4326 que describe las coordenadas geográficas WGS84.

El Sistema Geodésico Mundial es un estándar para su uso en la cartografía, geodesia y navega-ción. Cuenta con un estándar de coordenadas de la Tierra, un estándar de referencia de la superficieesférica (el dato o elipsoide de referencia) para los datos de altitud, y una superficie equipotencialgravitacional (el geoide) que define el nivel del mar nominal. El origen de coordenadas de WGS84está destinado a ser ubicado en el centro de la masa de la Tierra, estimándose un error de cálculomenor a 2 cm. por lo que es en la que se basa el GPS.

Está definido por los siguientes parámetros:

1. Origen: Centro de masa de la Tierra.

16

2. Sistemas de ejes coordenados:Eje Z: dirección del polo de referencia del IERS-The International Earth Rotation ServiceEje X: intersección del meridiano origen definido en 1984 por el BIH pasando por el

origen, perpendicular al eje Z.Eje Y: eje perpendicular a los dos anteriores y coincidentes en el origen.

3. Elipsoide WGS84Semieje mayor (a)= 6,378,137 mSemieje menor (b)= 6,356,752.3142 m

4. Constante de Gravitación Terrestre: 3,986004418 x 1014 m3/s2.

5. Velocidad Angular: 7,292115 x 10−5 rad/s

6. Coeficiente de forma dinámica: -484,166 85 x 10−6.

2.2.4. Sistema de CoordenadasLa localización es contextualmente simple e intuitiva para la mayoría de la gente. Por ejemplo,

la gente puede relacionarse en donde están sobre un mapa, seguir direcciones a un lugar, agarrarfácilmente el contexto espacial de su entorno local, y así sucesivamente. En cambio, ubicarnospor medio de coordenadas resulta difícil para la gente, sin embargo para que las computadorasintercambien datos geoespaciales, se requiere de una definición clara de la ubicación y el Sistemade referencia espacial.

Básicamente la localización geográfica de un punto se puede realizar detallando uno de estosdos parámetros:

Coordenadas geográficas en formato Longitud-Latitud.

Coordenadas (x,y) Universal Transversal de Mercator (Universal Transverse Mercator, UTMpor sus siglas en inglés).

Para representar un punto en la Tierra se pueden usar dos tipos de coordenadas: las angulares(que usan los grados, minutos y segundos como medidas de referencia) y las rectangulares (queusan el metro y el Sistema decimal). Al hablar de coordenada nos referimos a la secuencia de Nnúmeros designando la posición de un punto en N-espacios dimensionales. Además, son siempreexpresadas usando algún Sistema de coordenadas de referencia, los cuales han hecho referencia alplaneta Tierra.

Ya entendido lo que es una coordenada, a continuación se expondrán los dos sistemas de pro-yección antes mencionados con sus características principales.

17

Geográficas

Aunque para la mayoría de los usuarios de un sistema AVL no sea tan importante la ubicaciónpor medio de coordenadas, es un hecho que lo que se obtiene de un dispositivo de localización soncoordenadas, ya que éstas son utilizadas para obtener la posición del vehículo en un mapa.

Un Sistema de Coordenadas Geográficas (Geographic Coordinate System, GCS por sus siglasen inglés) es un sistema que referencia cualquier punto de la superficie terrestre, un GCS incluyeuna unidad angular de medida, un meridiano base y un datum (conjunto de datos de coordenadasbasado en un esferoide)[20].

Para referirnos a un punto en el mapa con un sistema de coordenadas, utilizamos valores delatitud y longitud que son ángulos medidos desde el centro de la Tierra hasta un punto de lasuperficie y se miden en grados o grados centesimales. Todo mapa está referido por lo menos aun sistema de coordenadas, para obtener el detalle de su ubicación geográfica. A continuación semuestra los valores que miden la latitud y la longitud:

La latitud mide el ángulo entre cualquier punto y el ecuador. Las líneas de latitud se deno-minan paralelos. La latitud es el ángulo que existe entre un punto cualquiera y el Ecuador.

La longitud mide el ángulo a lo largo del ecuador desde cualquier punto de la Tierra. Laslíneas de longitud son círculos máximos que pasan por los polos y se llaman meridianos.

El ecuador es un elemento importante de este Sistema de coordenadas; representa el cero delos ángulos de latitud y el punto medio entre los polos.

Además, podemos hablar de posición al ubicarnos en un mapa, las cuales existen dos:

Posición absoluta: se determina a través de las coordenadas geográficas (latitud y longitud).

Posición relativa: permite localizar distintos espacios territoriales a partir de tomar otroespacio territorial como referencia.

UTM

El Sistema de Coordenadas Universal Transversal de Mercator (Universal Transverse Mercator,UTM por sus siglas en inglés) es un sistema de coordenadas basado en la proyección cartográficatransversa de Mercator, que se construye como la proyección de Mercator normal, pero en vezde hacerla tangente al ecuador, se la hace tangente a un meridiano. A diferencia del sistema decoordenadas geográficas, expresadas en longitud y latitud, las magnitudes en el Sistema UTM seexpresan en metros únicamente al nivel del mar, que es la base de la proyección del elipsoide dereferencia.

Proyección Mercator: La UTM es una proyección cilíndrica conforme. El factor de escala enla dirección del paralelo y en la dirección del meridiano son iguales (h = k). Las líneas loxo-drómicas se representan como líneas rectas sobre el mapa. Los meridianos se proyectan sobre

18

el plano con una separación proporcional a la del modelo, así hay equidistancia entre ellos.Sin embargo los paralelos se van separando a medida que nos alejamos del ecuador, por loque al llegar al polo las deformaciones serán infinitas. Además es una proyección compuesta;la esfera se representa en trozos, no entera. Para ello se divide la Tierra en husos de 6o delongitud cada uno. La proyección UTM tiene la ventaja de que ningún punto está demasiadoalejado del meridiano central de su zona, por lo que las distorsiones son pequeñas. Pero estose consigue al coste de la discontinuidad: un punto en el límite de la zona se proyecta encoordenadas distintas propias de cada huso.

Para evitar estas discontinuidades, a veces se extienden las zonas, para que el meridiano tangentesea el mismo. Esto permite mapas continuos casi compatibles con el estándar. Sin embargo, en loslímites de esas zonas, las distorsiones son mayores que en las zonas estándar.

2.3. Visualización de MapasEn la interfaz de usuario de un sistema AVL, una parte muy importante es la visualización de

la ubicación del o los vehículos en un mapa geográfico, ya que es más comprensible que leer unacoordenada obtenida por un dispositivo de localización GPS.

Un mapa es una representación selectiva de una parte mayor o menor de la totalidad de lasuperficie terrestre sobre un plano horizontal y visual, materializados en longitudes y latitudes,las cuales configuran la extensión del área mapeada bajo una visión panorámica.[18]. Un mapageográfico está formado por satélites y mediciones diversas preferentemente basado en límitesfísicos más que políticos[19]. Los sistemas AVL no se limitan al uso cierto tipo de mapas, sino quetoman lo mejor de cada uno para enriquecer la visualización vehicular.

2.3.1. Servidor de MapasUn servidor de mapas es un motor que permite la visualización de mapas (por lo general en

una página web)[21], de ahí la función tan importante que desempeña en un sistema AVL. Losmapas alojados en estos servidores son generados a partir de datos que ellos mismos recolectan,algunos de ellos son de código abierto, otros comerciales o gratuitos.

Una forma de dividir los tipos de servidores de mapas es por su tipo licencia, como se mencionóanteriormente pero también se dividen por el tipo de desarrollo que permiten:

Interno: donde se permite la creación y modificación de datos de mapas del servidor, funcio-namiento y visualización.

Externo: donde se permite la creación y modificación de la visualización de los mapas servidosdel lado del cliente.

19

Los principales servidores de mapas que no son de código abierto son:

Google Maps.

Yahoo Maps.

Bing Maps.

ArcGis.

Los principales servidores de mapas de código abierto son:

OpenStreetMap.

GeoServer.

UMN MapServer.

Mapguide.

Degree.

2.3.2. Bases de Datos GeográficasComo se dijo anteriormente, un servidor de mapas aloja datos sobre los mapas con un formato

estandarizado organizado de tal manera que sirvan para los Sistemas de Información Geográfica(Geographic Information System, GIS por sus siglas en inglés) dichos datos son guardados en basesde datos llamadas geográficas o geoespaciales (BDG).

Una BDG es una colección de datos orientada a sistemas de información geográfica que permi-tan un almacenamiento estructurado, de acuerdo a criterios espaciales, tipos de consultas y gestiónde información geográfica[22]. Estas bases de datos asocian dos tipos de datos (también llamadosobjetos), los espaciales y los no espaciales.

Los datos o atributos espaciales son las características geográficas de los objetos descritos(ubicación, dimensión, forma) y los no espaciales son las características cuantitativas asociadas alobjeto que se desea describir, es decir, datos descriptivos.

2.3.3. OpenLayersOpenLayers es una biblioteca de JavaScript puro que permite la visualización de datos sobre

mapas para diversos navegadores web sin depender de un servidor en particular. Es una de lasbibliotecas más utilizadas para la visualización de mapas e implementa una API JavaScript parala construcción de aplicaciones geográficas web enriquecidas, similar a la API de Google Maps conla diferencia de que OpenLayers es Software Libre desarrollado por y para la comunidad OpenSource[45].

20

2.4. Vehículos y Variables de SensadoUna de las características que puede tener el dispositivo de localización es la posibilidad de

adaptarse a diferentes tipos de vehículos y de obtener diferentes variables de sensado. En la actua-lidad existe una gran cantidad de vehículos los cuales según el paso de los años se les incorporandiferentes características las cuales benefician tanto al conductor como a los usuarios de estosvehículos, existen vehículos personales, vehículos de pasajeros y vehículos de carga, los cualescuentan con distintas características pero mismas variables que permiten el control y supervi-sión de dicho vehículo, los sensores más comunes para medir las variables más comunes en dichosvehículos son:

Sensor de posición del cigüeñal. Usualmente se encuentra en la tapa de distribución decombustible o en el monoblock, su función es proporcionar al pcm la posición del cigüeñal ylas rpm.

Sensor de temperatura de refrigerante del motor. Se encuentra en la caja del ter-mostato conocida como toma de agua, su función es informar al pcm la temperatura delrefrigerante del motor para que este a su vez calcule la entrega de combustible, la sincroni-zación del tiempo y el control de la válvula egr, así como la activación y la desactivación delventilador del radiador.

Sensor de temperatura del aire de admisión. Se encuentra en el ducto de plástico dela admisión del aire, su función es determinar la densidad del aire y medir la temperaturadel aire.

Sensor de velocidad del vehículo. Se encuentra en la transmisión o atrás del tablerode instrumentos, su función es proporcionar la velocidad a la que se desplaza el vehículo enmovimiento.

Sensor de masa de aire. Se encuentra entre el filtro de aire y el cuerpo de aceleración, seusa como dispositivo de medición térmica evitando el ahogamiento del motor.[17]

El contar con este tipo de sensores y poder sensar sus valores a lo largo del día permite poderllevar un control adecuado de dicho vehículo y beneficiar al usuario al mantenerlo informado sobreel estado de éste, de esta manera es muy recomendable que un dispositivo pueda obtener la infor-mación y enviarla hacia un servidor para así incorporarse a un sistema AVL.

Se hablará de sistemas AVL, donde se detallará su definición, así como la arquitectura queconlleva, para hablar de los tipos de sistemas que existen y finalmente los sistemas AVL comercialesque existen en la actualidad aquí en México.

2.5. Sistema AVLLos Sistemas de Localización Vehicular Automatizada (Automatic Vehicle Location, AVL por

sus siglas en inglés), son sistemas cuya principal función radica en monitorear la posición en la que

21

se encuentran los vehículos a través de un GPS o un sistema de radiofrecuencia, el cual se encargade obtener la localización del vehículo cada determinado tiempo. Existe una gran diversidad desistemas AVL, algunos de los cuales además de que se encargan de obtener la posición del vehículo,también se encargan de sensar los componentes principales del vehículo[1]. (Como pueden ser:velocidad, aceleración, nivel de gasolina).

2.5.1. Arquitectura de un AVLLa mayoría de los sistemas AVL poseen una arquitectura común compuesta de 3 partes prin-

cipales, como lo podemos observar en el cuadro 2.2, y continuación se describen:

Figura 2.2: Arquitectura AVL

Dispositivo de localización: El dispositivo de localización, (dispositivo de rastreo GPS) secoloca por lo general dentro del vehículo y obtiene la ubicación en conjunto con informacióndel propio vehículo y la almacena o la envía a un servidor según sea el tipo de Sistemaimplementado. La información obtenida por el dispositivo además de su ubicación puede sernivel de gasolina, temperatura del motor, altitud, estado de las puertas (abiertas/cerradas),presión de las llantas, estado de la batería, entre otros y puede tener el control de cortar lagasolina, encender el motor, encendido de luces tanto delanteras como traseras, entre otras.La capacidad de estos dispositivos define en gran medida la capacidad final de todo el sistemaAVL.

Servidor de localización: Éste servidor tiene que cumplir con tres tareas: recibir los datosobtenidos del dispositivo de localización o rastreo, almacenar los datos recibidos de dicho

22

dispositivo y por último brindar la información demandada por el usuario de acuerdo a losdatos almacenados.

Interfaz de usuario: La interfaz de usuario determina como se podrá visualizar y accesar ala información dentro del servidor cumpliendo con los requerimientos del sistema en cuestión(como podría ser ver la información del vehículo de forma detallada en una tabla)[2].

Componentes del Dispositivo de Localización

Los dispositivos de localización están compuestos por cuatro módulos principales:1. Módulo de localización. Encargado de obtener la posición del vehículo en coordenadas me-

diante un dispositivo especializado. Tales dispositivos pueden utilizar alguna de las siguientestecnologías:

GPS: se encarga de brindar longitud, latitud y altitud en la que se encuentra el vehículo.Es muy utilizado en la actualidad gracias a que recibe una comunicación satelital ypuede ubicarse tanto en carretera o dentro de edificios, aunque los tiempos de retardoaumentan para la obtención de las coordenadas debido a la interferencia con la cual sepueda encontrar.GLONASS: es otro sistema tecnológico que permite la localización del vehículo quepuede ser comparable con el GPS ya que es un sistema de navegación satelital trabajadopor la Defensa Aeroespacial Rusa y es una buena alternativa como cobertura global,cuenta con una gran precisión y trabaja de una manera muy similar al GPS, es por esoque los celulares actuales de gama alta lo traen integrado[3].RF: Otra opción importante es la localización por radiofrecuencia, esta tiene la ventajade una respuesta rápida en caso de encontrarse dentro de un área de cobertura. Escomúnmente utilizada dentro de las zonas urbanas, pero tiene la desventaja que nopuede ser utilizada en zonas rurales o zonas con poca cobertura, no cuenta con unaprecisión similar al GPS[4].

2. Módulo de comunicación. Para transferir información entre el vehículo y el servidor ge-neralmente se utiliza otro componente: un módem GSM/GPRS/UMTS que permita transfe-rencia de datos (en general para enviar o recibir mensajes de texto, e-mails, o peticiones http).

3. Módulo de sensado. Es aquel encargado de la obtención de datos del vehículo el cualpuede implementar una gama de sensores propios o puede adquirir datos de los sensores quevienen por defecto instalados en el vehículo, esto es a través de comunicación directa con elvehículo (a través de una interfaz elegida por el fabricante), de esta forma se pueden adquirirdatos útiles como el nivel de gasolina, la velocidad del vehículo, que se pueden incorporar alsistema y hacerlo tan complejo como se requiera.

4. Unidad procesadora de datos. Encargada de coordinar a todos los demás componentes yalmacenar o enviar los datos recopilados de acuerdo a la configuración dictada por el servidorde localización.

23

Componentes del Servidor de Localización

El servidor de localización es el encargado principal de coordinar la interacción entre los dis-positivos de localización y la interfaz de usuario. Este servidor cuenta con algunos componentesindispensables para cubrir su función:

Un componente de comunicación a la espera de datos y/o peticiones por parte de los dispositi-vos de localización para desencadenar una acción específica (como puede ser el guardado de datos,una notificación del cambio del estado de una variable de sensado dentro del vehículo, entre otros).

Otro de los componentes importantes del servidor de localización es el de almacén de datosgeneralmente representado por una base de datos, donde se recopila toda la información concer-niente a los dispositivos de localización y la especifica requerida por el propio sistema AVL.

El servidor de localización además posee un componente capaz de tomar configuración propor-cionada por él o los usuarios del sistema AVL y organizar peticiones al dispositivo de localizacióno hacia la interfaz de usuario.

Componentes de la Interfaz de Usuario

Para promover una correcta interfaz de usuario, lo principal en un sistema AVL es colocar lainformación recabada por el dispositivo de localización, procesada por el servidor de localizaciónen un mapa configurable (en cuanto tamaño, posición, zoom).

Además de diferentes marcadores, anotaciones, indicaciones, líneas guía, iconos, etc. Que sepueden colocar sobre el mapa en cuestión.

2.5.2. Tipos de Sistemas AVLA pesar de que existe una gran cantidad de organizaciones que se encargan de proveer este

tipo de sistemas, cuyas características son distintas en variedad y complejidad, es posible catalo-gar los sistemas AVL en dos tipos básicos, pasivos y activos, cuyas características se detallan acontinuación:

Sistema AVL ActivoUn sistema activo se refiere a que cada determinado tiempo se solicita la obtención de laposición del vehículo y transmitirla junto con los demás datos obtenidos del vehículo paraser procesados y almacenados en un servidor utilizando radiofrecuencias o tecnología GS-M/GPRS por ejemplo. De esta forma se puede hacer cualquier tipo de consulta de la infor-mación recabada a cualquier hora deseada, esta información por lo regular se ve desplegadaen una página web a través de un mapa para conocer la ruta registrada por el Sistema.

Sistema AVL Pasivo

24

Los sistemas AVL pasivos permiten la obtención de la posición del vehículo de forma diferida,es decir, los datos son almacenados internamente para un evío posterior programado o paraser extraidos manualmente[5].

2.5.3. Sistemas AVL en la ActualidadEn el mercado nacional e internacional existen organizaciones que desarrollan y ofertan sistemas

AVL, con características tales como: sistema de alertas, geocercas, sistema de reportes y aplicaciónmóvil. Para describir mejor sus características y hacer un comparativo entre ellas, se han elegi-do a GP NETWORK SYSTEM[32], Lo Jack[33], Black Jack[34], CoSoAVL[35], Encontrack[36] yProsegur[37].

Las organizaciones antes mencionadas cuentan con años de experiencia, una consolidación enel mercado nacional y, como es el caso de Prosegur, no solo una presencia nacional sino interna-cional, además de una considerable gama de opciones y paquetes de servicios los cuáles pueden serobservados con mayor detenimiento en las referencias antes citadas para cada organización.

En los cuadros 2.1 y 2.2 se muestran características generales de los sistemas que ofertan,como la tecnología empleada para la localización o la cobertura que ofrecen, y en el cuadro 2.3características específicas, como botones de pánico o control de variables del vehículo. El propósitoes hacer un comparativo entre los sistemas que han desarrollado algunas de las más importantesorganizaciones que desarrollan sistemas AVL.

25

Características GeneralesTecnología deLocalización

Tipo deSistema

Alertas

Sistema GPS Radio-frecuencia

Activo Pasivo Llamadastelefónicas

SMS AppAn-droid

AppiOS

AppBlack-berry

GP NET-WORKSYSTEM

Lo Jack

Black Jack

CoSoAVLBásico[38]

CoSoAVLPremium[39]

CoSoAVLNextGeneration[40]

Encontrack

Prosegur

Cuadro 2.1: Tabla de Características Generales1

26

Características GeneralesAlertas Monitoreo y consultas Cobertura

Sistema E-mail Pagina web Nacional

GP NETWORK SYSTEM

Lo Jack

Black Jack

CoSoAVL Básico

CoSoAVL Premium

CoSoAVL Next Generation

Encontrack

Prosegur

Cuadro 2.2: Tabla de Características Generales 2

La característica general más importante en un sistema AVL, es la tecnología empleada parala obtención de la ubicación vehicular, como se puede apreciar existen dos: GPS y radiofrecuencia.La elección de la tecnología por parte de la organización dependerá del tipo de clientes a quiénesté orientado y su área de servicio.

Es de observar que existen mayormente dos áreas de oferta de servicios AVL: los orientados ala recuperación de vehículos (AVL pasivos), como LoJack, BlackJack y Encontrack, y los de mo-nitoreo y control (AVL activos), como Prosegur y CosoAVL. Existen también ofertas de serviciospara uso personal con características limitadas, e intentos de ofrecer servicios de un AVL pasivo yactivo a la vez, pero con altas limitaciones.

Como características generales resaltan también:

Sistema de alertas. Los sistemas antes descritos ofrecen alertas configurables, que puedenser activadas por eventos significativos: sea por un botón de pánico activado por el conductor delvehículo, por variables sensadas del vehículo y por geocercas. Dichas alertas pueden ser enviadaspor e-mail, sms, o por llamadas telefónicas.

Aplicación móvil. Ésta es una utilidad que ofrece una doble utilidad ya que permite no solover los reportes de seguimiento vehicular, sino también como un dispositivo de localización quepuede ser configurado para enviar y recibir información al sistema. Cabe señalar las diversas op-ciones desarrolladas para diferentes plataformas móviles como Android, iOS y Blackberry, lo quepermite mayor comodidad al usuario.

27

Características EspecíficasSistema Localización

en bodegasControlde varia-bles delvehículo

Geocercas Reportesprogra-mables

Botónde páni-co

Sensoresde carga

GP NET-WORKSYSTEM

Lo Jack

Black Jack

CoSoAVLBásico

CoSoAVLPremium

CoSoAVLNext Ge-neration

Encontrack

Prosegur

Cuadro 2.3: Tabla de Características Específicas

Como características específicas podemos resaltar las siguientes:

Geocercas. Las geocercas permiten el acotamiento de una ruta que puede seguir un vehículo,lo que permite un mayor control del mismo. Puede añadirse una geocerca diferente a cada vehículoo a un grupo en especial. En algunas ocasiones se configuran geocercas naturales, si por ejemplo,una empresa solo opera en un país o estado en particular.

Sistema de reportes. Dichos sistemas son configurados por periodo de tiempo o por cantidadde peticiones al dispositivo receptor GPS. La empresa Prosegur, por ejemplo, ofrece un sistemade reportes por cada 24 horas que puede ser consultado en cualquier momento desde su página deinternet accediendo con un nombre de usuario y contraseña.

28

Control de variables del vehículo. Es una de las cualidades con mayor valor para el usuario,sobre todo si lo que desea es una localización constante. Permite no solo sensar ciertas variablesdel vehículo sino a partir de dicho sensado ejercer un control sobre el mismo a voluntad del usuario.

Del lado del servidor, en una arquitectura de un sistema AVL, existe una gran cantidad decódigo que es común y cumple las mismas funciones. Generalmente esto se puede suplir medianteun Framework o una API. En breve se explicarán los 2 conceptos.

2.6. FrameworkEs una estructura de software compuesta por distintos componentes personalizables e inter-

cambiables que facilitan el desarrollo de una aplicación entre ellos (aunque no obligatorios): unentorno de desarrollo, el compilador, un conjunto de bibliotecas y archivos de configuración, entreotros.[26] Esto con la finalidad de proveer una funcionalidad genérica y puede ser sobrescrita o es-pecializada para poder realizar una función particular. En otras palabras, un Framework se puedeconsiderar como una aplicación genérica incompleta y configurable a la que podemos añadirle lasúltimas piezas para construir una aplicación concreta[23].

Entre otras las más importantes características que trata de cubrir un Framework son[23]:

Acelerar y facilitar el proceso de desarrollo.

Reutilizar código ya existente.

Promover buenas prácticas de desarrollo como el uso de patrones de diseño

2.7. APIUna Interfaz de Programación de Aplicaciones (Application Program Interface, API por sus

siglas en inglés) constituye un conjunto de rutinas, procedimientos, protocolos, funciones y he-rramientas que una determinada biblioteca pone a disposición para que sean utilizados por otrosoftware como una capa de abstracción para poder desarrollar una aplicación. En otras palabras,es una interfaz que permite la comunicación entre distintos componentes software. Esto representaun método para alcanzar abstracción a la hora de programar, particularmente en el momento derelacionar los niveles superiores e inferiores del software[28].

De esta forma, podemos decir que una de las tareas centrales de una API es la de ofrecer ungrupo de funciones generales que faciliten el uso o configuración de un entorno de programación yno precisamente una estructura con, por ejemplo, archivos de configuración.

Las API brindan diferentes funcionalidades hacia el proveedor para obtener o actualizar infor-mación, entre lo más destacado se encuentra:

29

Acceso a bases de datos.

Comunicación cliente/servidor.

Comunicación peer-to-peer.

Event-driven (orientada a eventos).

Store and forward (almacenamiento y reenvío).

Procesamiento de transacciones.

Para el desarrollo de este trabajo terminal se consideró únicamente el desarrollo de un conjuntode bibliotecas que permitiera un desarrollo más estructurado de sistemas AVL, por lo tanto, ladefinición más cercana es la de API.

2.8. Propuestas de Solución SimilaresAhora se presentarán algunos de los proyectos existentes que se acercan a la definición de API,

debido a sus componentes y al enfoque para el cual fueron concebidos. Estos proyectos se exponena continuación.

2.8.1. OpenGTSOpenGTS es un proyecto de código abierto diseñado especialmente para proveer servicios web

en la parte de rastreo GPS para flotillas o vehículos.

Características

OpenGTS no solo recolecta datos y almacena la información de localización GPS y datos deTelemetría de dispositivos remotos, también cuenta con las siguientes características:

Autenticación Web: Cada cuenta soporta múltiples usuarios, y cada usuario tiene su propiacontraseña de acceso y controla las secciones correspondientes a su cuenta.

Independiente al dispositivo de localización GPS: Dispositivos de distintos fabrican-tes pueden ser rastreados simultáneamente. OpenGTS incluye soporte para los siguientesdispositivos:

• La mayoría de los dispositivos TK102/TK103 (que utilizan los protocolos TK102/TK103)• Dispositivos AT240, AT110, AT210 de Astra Telematics.• “CelltracGTS” para teléfonos con Sistema Operativo Android.• Otros dispositivos se pueden incorporar al utilizar la "plantilla"de comunicación con el

servidor proporcionada.

30

Atributos Web Personalizables: La vista sobre el sitio web de localización puede serpersonalizable para ajustarse al usuario.

Servidor de Mapas Personalizable: OpenGTS incluye soporte para OpenLayers/OpenS-treetMap, Google Maps, Microsoft Virtual Earth y Mapstraction (provee soporte para Mul-tiMap, Map24, MapQuest y más). OpenGTS permite integrar otros servidores de mapas.

Reportes Personalizables: A través de un XML, se pueden personalizar los reportes de-tallados y el historial de un vehículo en específico o de una flotilla.

Geocercas Personalizables: Las geocercas (geozonas) pueden ser configuradas para repor-tar eventos de llegada/salida del vehículo. Cada geozona puede ser llamada para brindar una"dirección"personalizada la cual es mostrada en los reportes cuando el vehículo se encuentredentro de la geozona.

Independiente al Sistema Operativo: OpenGTS fue escrito completamente en Java, uti-liza teconologías como Apache Tomcat para servidor web y MySQL para almacenamiento dedatos. Siendo así, OpenGTS podrá funcionar en cualquier sistema que soporte estas tecno-logías (incluyendo Linux, Mac OS X, FreeBSD, OpenBSD, Solaris, Windows XP, WindowsVista, Windows 20XX, y más).[41]

2.8.2. TraccarEs un sistema AVL de código abierto para diversos dispositivos de localización GPS desarro-

llado en Java, que hasta el momento soporta más de 30 conjunto de mensajes diferentes. Dichosistema cuenta también con un cliente para dispositivos móviles con Android y un paquete deinstalación para GNU/Linux, Mac OS X, y Windows.

En la página oficial de Traccar[42] podemos descargar la versión más actual (2.8 hasta abril de2014), realizar los siguientes pasos para comenzar su uso:

Descargar e instalar.

Reiniciar la máquina y acceder a http://localhost:8082.

Ingresar al sistema con el usuario admin y el password admin.

Registrar un nuevo dispositivo GPS y configurarlo.

Traccar está dividido en tres partes principales:

1. Servidor. El servidor está construido con diversas herramientas de código abierto que pos-teriormente se describen.

Para la construcción de la red y uso de protocolos Netty: es un Framework NIO(entrada ysalida no bloqueante) cliente-servidor, que permite una ágil realización de aplicaciones en redporque simplifica la creación de sockets y el uso de diferentes protocolos.

31

Para la parte web Jetty: un contenedor de servlets java, como servidor web; también Log4j,una biblioteca (library) para login hecho en java por Apache Software Foundation, para laparte del acceso al servidor.

Para la parte de la base de datos H2: un motor para base de datos de código abierto hechoen java, el conector MySQL/JDBC Driver.

2. Cliente Android. Es una aplicación para Android que puede descargarse de Google Play odirectamente de la página de Traccar, la cual sirve también como dispositivo receptor GPS,simplemente hay que ingresar el IMEI (Identidad Intenacional de Equipo Móvil, por sussiglas en inglés) del dispositivo, la dirección del servidor y el puerto, así como la frecuenciade solicitud de ubicación.

3. Lista de dispositivos. Aunque el sistema no está compuesto por dispositivos, es decir, noofrece un paquete que contenga un dispositivo para instalarse sino que el usuario lo compra,lo instala y lo configura, si ofrece una lista de dispositivos compatibles ya probados. Estosson algunos de ellos: TK101-106, TK201, GPS103, GPS103-A, GL100 y GL200.

Para el registro del dispositivo se tiene un archivo de configuración xml, en el cual, se describeel nombre de la base de datos, el driver, el usuario y la contraseña. Se agrega la frecuenciade refresco de la posición de la base de datos, el id (IMEI por default), la descripción de lastablas donde se almacenará la información del dispositivo y el tipo de dispositivo por numerode serie. Por ejemplo:

<entry key=’gps103.enable’>true</entry><entry key=’gps103.port’>5001</entry>

Cabe resaltar que Traccar puede ser integrado con OpenGTS e incluir todas sus funcionalidadesa través del archivo de configuración xml. Como se puede ver es un sistema muy completo queintegra diversas herramientas, diversos dispositivos e incluso otros sistemas AVL.

Existen módulos o extensiones que se pueden añadir a los gestores de bases de datos para crearbases de datos geográficas o geoespaciales. PostGis es un módulo para PostgeSQL para añadirsoporte de objetos geográficos y es de los más usados.

2.9. Patrones de Diseño de SoftwarePara que una API pueda ser robusta generalmente se utilizan Patrones de Diseño para su

implementación. Al momento de desarrollar una aplicación web nos podemos encontrar con pro-blemas al ir programando, es por eso que los Patrones de Diseño son la solución para este tipo deproblemas. Para que una solución sea considerada un patrón, debe poseer ciertas características.Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en

32

ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentesproblemas de diseño en distintas circunstancias.

Es por eso que aunque nuestra aplicación sea única, tendrá partes comunes con otras aplica-ciones: acceso a datos, creación de objetos, operaciones entre sistemas. En otras palabras, brindanuna solución ya probada y documentada a problemas de desarrollo de software que están sujetosa contextos similares. Debemos tener presente los siguientes elementos de un patrón: su nombre,el problema (cuando aplicar un patrón), la solución (descripción abstracta del problema) y lasconsecuencias (beneficios).

En la actualidad existen varios patrones, los cuales se clasifican en tres tipos, los cuales son:Creacionales, de Comportamiento y Estructurales. [43]

2.9.1. Patrones CreacionalesSon utilizados para instanciar objetos, y así separar la implementación del cliente. Con ellos

intentamos separar la lógica de creación de objetos y encapsularla. Actualmente podemos encontrarlos siguientes Patrones Creacionales:

Fábrica Abstracta (Abstract Factory por su traducción al inglés): Permite trabajar con ob-jetos de distintas familias de manera que las familias no se mezclen entre sí y haciendotransparente el tipo de familia concreta que se esté usando. El problema a solucionar poreste patrón es el de crear diferentes familias de objetos, como por ejemplo la creación deinterfaces gráficas de distintos tipos (ventana, menú, botón, etc.).

Método de Fabricación(Factory Method por su traducción al inglés): Centraliza en una claseconstructora la creación de objetos de un subtipo de un tipo determinado, ocultando alusuario la diversidad de casos particulares que se pueden prever, para elegir el subtipo acrear. Parte del principio de que las subclases determinan la clase a implementar.

Prototipo (Prototype por su traducción al inglés): Crea nuevos objetos clonándolos de unainstancia ya existente.

Instancia única (Singleton por su traducción al inglés): Garantiza la existencia de una únicainstancia para una clase y la creación de un mecanismo de acceso global a dicha instancia.Restringe la instanciación de una clase o valor de un tipo a un solo objeto.

Modelo Vista Controlador (Model View Controller, MVC por sus siglas en inglés): Estepatrón plantea la separación del problema en tres capas: la capa model, que representa larealidad; la capa controller , que conoce los métodos y atributos del modelo, recibe y realizalo que el usuario quiere hacer; y la capa vista, que muestra un aspecto del modelo y esutilizada por la capa anterior para interaccionar con el usuario.

Constructor (Builder por su traducción al inglés): abstrae el proceso de creación de un objetocomplejo, centralizando dicho proceso en un único punto.

33

2.9.2. Patrones de ComportamientoSe utilizan a la hora de definir como las clases y objetos interaccionan entre ellos. Los cuales

son:

Cadena de responsabilidad (Chain of Responsibility por su traducción al inglés): Permiteestablecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada.

Orden (Command por su traducción al inglés): Encapsula una operación en un objeto, per-mitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma.

Intérprete (Interpreter por su traducción al inglés): Dado un lenguaje, define una gramáticapara dicho lenguaje, así como las herramientas necesarias para interpretarlo.

Iterador (Iterator por su traducción al inglés): Permite realizar recorridos sobre objetos com-puestos independientemente de la implementación de estos.

Mediador (Mediator por su traducción al inglés): Define un objeto que coordine la comuni-cación entre objetos de distintas clases, pero que funcionan como un conjunto.

Recuerdo (Memento por su traducción al inglés): Almacena el estado de un objeto y lorestaura posteriormente.

Observador (Observer por su traducción al inglés): Define una dependencia de uno-a-muchosentre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicenautomáticamente todos los objetos que dependen de él.

Estado (State por su traducción al inglés): Permite que un objeto modifique su comporta-miento cada vez que cambie su estado interno.

Estrategia (Strategy por su traducción al inglés): Permite disponer de varios métodos pararesolver un problema y elegir cuál utilizar en tiempo de ejecución.

Método plantilla (Template Method por su traducción al inglés): Define en una operación elesqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite quelas subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.

Visitante (Visitor por su tradución al inglés): Permite definir nuevas operaciones sobre unajerarquía de clases sin modificar las clases sobre las que opera.

2.9.3. Patrones EstructuralesSeparan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan,

para formar estructuras más grandes.

Adaptador (Adapter por su tradución al inglés): Adapta una interfaz para que pueda serutilizada por una clase que de otro modo no podría utilizarla.

34

Puente (Bridge por su tradución al inglés): Desacopla una abstracción de su implementaciónpermitiendo modificarlas independientemente.

Objeto Compuesto (Composite por su tradución al inglés): Utilizado para construir objetoscomplejos a partir de otros más simples, utilizando para ello la composición recursiva y unaestructura de árbol.

Decorador (Decorator por su tradución al inglés): Permite añadir dinámicamente funcio-nalidad a una clase existente, evitando heredar sucesivas clases para incorporar la nuevafuncionalidad.

Fachada (Facade por su tradución al inglés): Provee de una interfaz unificada simple paraacceder a una interfaz o grupo de interfaces de un subsistema.

Peso Ligero (Flyweight por su tradución al inglés): Elimina la redundancia o la reduce cuandose tiene una gran cantidad de objetos con información idéntica.

Apoderado (Proxy por su tradución al inglés): Proporcionar un representante o sustituto deotro objeto para controlar el acceso a éste.

Módulo (Module por su tradución al inglés): Proporcionan encapsulación tanto privada comopúblicoa para las clases. Se utiliza para emular aún más el concepto de clases de tal maneraque se puede incluir ambos métodos públicos / privados y variables en el interior un soloobjeto. [44]

Como podemos observar, en el desarrollo de software sin importar que tan bien esté diseñadauna aplicación, a través del tiempo, puede crecer y cambiar o convertirse en un sistema que sevuelva obsoleto. Es por eso, que es una buena práctica usar Patrones de Diseño en el desarrollo.

Ahora, una vez entendido todo lo que implica el desarrollar este tipo de sistemas, daremos pasoa la problemática y complejidad que se encuentra al momento de desarrollar sistemas AVL.

35

Capítulo 3

Análisis del Problema

En éste capítulo se explora la problemática a la cual se enfrentó en el trabajo terminal, despuésde hacer una introducción al contexto y enunciar el problema, se muestra el análisis del mismo, deesta forma se expone el objetivo del trabajo terminal, el análisis de la solución y terminando conla propuesta de solución elegida para afrontar dicha problemática.

3.1. ProblemáticaActualmente hay diversas organizaciones que se dedican al desarrollo de sistemas AVL (princi-

palmente con fines comerciales) con funciones y fines específicos, pero con características similaresentre sí. Sin embargo, no todos estos sistemas comparten las mismas tecnologías para lalocalización, el procesamiento y la visualización de la información.

A continuación se listan los principales problemas a los que se enfrentan los desarrolladores desistemas AVL.

3.1.1. ComplejidadPrimordialmente, la complejidad radica en definir los alcances del sistema para poder hacer

que toda la implementación gire en torno a estos límites previamente definidos y reflejados en cadaparte de la arquitectura AVL, como se describe enseguida.

Dispositivo de Localización

Para elegir un dispositivo de localización existe la opción de elegir uno existente o desarrollaruno. El problema al utilizar un dispositivo de localización comercial es que muchas veces utilizanprotocolos cerrados específicos a ciertos sistemas AVL, admiten solamente algunos modelos devehículos, y si son genéricos, no admiten añadir nuevas variables de sensados del vehículo. Por otrolado, el problema de utilizar un dispositivo de localización diseñado y desarrollado especialmentepara el sistema AVL en cuestión, implica en la mayoría de las ocasiones un aumento en los recursosnecesarios para llevar el sistema AVL a la implementación.

36

Elección de Plataformas

Para realizar una elección adecuada de plataformas para desarrollar un dispositivo delocalización personalizado, es necesario hacer un estudio adecuado tanto de la plataforma hardwarecomo de del conjunto de mensajes que pueden ser implementados o utilizados para la comunicacióncon el servidor de localización.

Servidor de Localización

Como hemos visto en el capítulo anterior existen muy pocos Sistemas AVL de acceso libre,y de ahí que cada servidor de localización sea diferente, sobre todo los comerciales (que ofrecenel sistema AVL como un servicio). Hay diversas opciones a elegir en este punto, de acuerdo apreferencias tecnológicas, al dispositivo de localización a utilizar y a la tecnología que se utilice enla interfaz de usuario.

Interfaz de Usuario

Este punto puede variar tanto como el servidor de localización, pero aun así el problema prin-cipal radica en la elección correcta de los mapas geográficos o un servidor con bases de datosgeográficas entre otros detalles, un conocimiento avanzado de la API en cuestión para la integra-ción con toda la información requerida por parte del sistema AVL.

Para el desarrollo de la interfaz de visualización es necesario tomar en cuenta característicastales como:

Visualización de vehículos en un mapa.

Elección de mapa base a elegir.

Visualización de rutas recorridas, así como el establecimiento de nuevas rutas.

Generación de reportes de alarmas, estado del vehículo, rutas, geocercas y conductores.

Aunado a éstos problemas de desarrollo, existen algunos otros problemas que añaden complejidada los cuáles el desarrollador de software se le presenta, los cuáles se mencionan abajo.

3.1.2. Integración de TecnologíasComo es posible observar en la arquitectura de un sistema AVL, son diferentes las tecnologías

que se requieren para su desarrollo. Primeramente, la instalación y configuración del dispositivode localización dentro del vehículo, después la implementación de un protocolo para el envío yrecepción de datos.

Para el servidor de localización, se pueden utilizar tecnologías como java o php donde se recibala información del dispositivo de localización y se envíe a la interfaz. Para el envío y recepciónpueden usarse servicios web y hacer uso también de objetos JSON.

37

En cuanto a la visualización de los vehículos y dispositivos en un mapa, ya se han descrito conanterioridad los diferentes servidores de mapas y bibliotecas para la manipulación de los mismos.

Ahora bien, si ya se han realizado las elecciones correspondientes entre las diversas tecnologías,pueden surgir detalles técnicos que no se consderaron, por ejemplo, se tiene un dispositivo listopero el protocolo del servidor no es el adecuado, nos encontramos con un problema que añadecomplejidad.

3.1.3. Diseño ComplejoPor otra parte, desarrollar un sistema AVL implica estructurarlo desde su base, es decir, desde

el dispositivo de localización hasta el funcionamiento del sistema, y debido al trabajo que requieredefinir y organizar cada uno de sus componentes, la complejidad aumenta.

Es necesario también establecer una arquitectura para el desarrollo, tener disponibles bibliotecasy archivos de configuración que realicen las funciones requeridas.

3.1.4. Curva de AprendizajeCada uno de los aspectos antes mencionados consumen para el desarrollador tiempo tanto en

investigación como en desarrollo. Es necesario conocer y seleccionar un dispositivo de localizaciónque tenga la capacidad de almacenar coordenadas geográficas, variables de sensado del vehículo yque contenga puertos de entrada/salida para la lectura de éstas variables, así como su conjuntode mensajes, establecer la estructura del servidor, elegir un gestor de bases de datos y diseñary desarrollar la base de datos, y realizar todas las funcionalidades necesarias para la interfaz devisualización.

Cada parte de la arquitectura de un sistema AVL requiere dedicar tiempo considerable a lainvestigación para siquiera elegir las tecnologías a utilizar, para después pensar en el desarrollo.Por ello se ha diseñado una propuesta de solución con un objetivo en particular y en las seccionessiguientes se hablará de ello.

3.2. Objetivo del ProyectoDiseñar e implementar un conjunto de Bibliotecas de software para desarrollar sistemas AVL,

que permita la visualización de rutas, geocercas, alarmas y monitoreo vehicular; así mismo tendrála finalidad de disminuir la complejidad de la elaboración de sistemas AVL proporcionando unaestructura base para futuros desarrollos.

3.2.1. Objetivos Específicos1. Realizar la documentación tipo Javadoc de los 2 módulos para facilitar la comprensión dela API a los desarrolladores.

38

2. Crear un caso de estudio que compruebe el buen funcionamiento de los módulos desarro-llados.

3. Establecer filtros a los valores de entrada del sistema tales como tipos de caracteres,tamaño de cadenas y estructura de mensajes, con la finalidad de agregar un nivel mínimo deseguridad a la API.

3.3. Planteamiento de la SoluciónEn este contexto, es claro que la existencia de un conjunto de Bibliotecas de software bien

ordenadas y que trabajen en conjunto beneficiaría el desarrollo de sistemas AVL promoviendo lahomologación de conjuntos de mensajes independientemente de las tecnologías utilizadas y acor-tando los tiempos de desarrollo con el propósito de evitar programar todo desde el principio.

La solución que se plantea es la construcción de un conjunto de bibliotecas de funciones queintegren las funciones necesarias para la creación de sistemas AVL específicos, permitiendo a losdesarrolladores minimizar los tiempos. Dichas bibliotecas serán desarrolladas utilizando técnicasque garanticen su reutilización (por ejemplo patrones de diseño).

Tendrá un grado de complejidad considerable debido a las necesidades a cubrir del usuario yal extenso listado de funciones que debe contener, pero al concluir su construcción será una he-rramienta que permitirá la creación de sistemas con mayores características que puedan aportarmayor valor al negocio.

Después de analizar éstos contextos se encontraron coincidencias, es por eso que se presenta ellistado de requerimientos identificados:

3.3.1. Requerimientos del UsuarioId: RU1Nombre: Posición del Vehículo.Descripción: El usuario requiere conocer la posición del vehículo.Prioridad: Alta.

Id: RU2Nombre: Estado del vehículo Posición del vehículo.Descripción: El usuario requiere conocer el estado del vehículo.Prioridad: Alta.

Id: RU3Nombre: Visualización del Vehículo.Descripción: El usuario requiere visualizar el vehículo en un mapa.Prioridad: Alta.

Id: RU4

39

Nombre: Historial de Ubicaciones.Descripción: El usuario requiere un historial que contenga las ubicaciones del vehículo.Prioridad: Media.

Id: RU5Nombre: Gestión de Vehículos.Descripción: El usuario requiere gestionar: registrar, eliminar, consultar y modificar varios

vehículos.Prioridad: Alta

Id: RU6Nombre: Gestión de Geocercas.Descripción: El usuario requiere gestionar las geocercas en un mapa: definir, modificar,

consultar, eliminar, asociar vehículos a una geocerca.Prioridad: Media

Id: RU7Nombre: Iconos para Visualización de Vehículos.Descripción: El usuario requiere identificar con un marcador (o icono) a cada vehículo

dentro del mapa.Prioridad: Alta.

Id: RU8Nombre: Privacidad de Acceso a la Información.Descripción: El usuario requiere definir quien puede accede a la información de los vehícu-

los.Prioridad: Alta.

Id: RU9Nombre: Obtención de la ubicación del vehículo.Descripción: El usuario requiere cambiar la frecuencia con que se obtiene la ubicación del

vehículo.Prioridad: Alta.

Id: RU10Nombre: Apagado de alarmas.Descripción: El usuario requiere notificar de enterado al sistema por una alarma.Prioridad: Alta.

40

3.3.2. Requerimientos del Desarrollador del AVLSe listarán los requerimientos identificados del desarrollador encargados de construir el sistema

AVL centrándonos en las tareas más complejas basadas en los requerimientos del usuario.

Id: RD1Nombre: Configuración de dispositivos.Descripción: El desarrollador requiere un mecanismo que permita configurar los siguientes

parámetros del dispositivo:• Pines de conexión para sensores analógicos y digitales (Activos o No).• Frecuencia de sensado.• Frecuencia de obtención de ubicación.• Frecuencia de Envío de estado del vehículo.• Configuración dirección IP y puerto del servidor.• Estado del dispositivo (Activo, Pasivo).• Configuración de “Botón de pánico” (número de celular al que se enviará la alerta).

Prioridad: Alta.Requerimiento de usuario cubierto: RU10 y RU2

Id: RD2Nombre: Mecanismo de almacenamiento en el dispositivo.Descripción: El desarrollador requiere crear un mecanismo en el dispositivo que permi-

ta almacenar la información obtenida del estado del vehículo y su ubicación, para laoperación de los modos Pasivo o Activo.

Prioridad: AltaRequerimiento de usuario cubierto: RU2

Id: RD3Nombre: Mecanismo de obtención de ubicación.Descripción: El desarrollador requiere crear o configurar un mecanismo para obtener la

ubicación del dispositivo.Prioridad: Media.Requerimiento de usuario cubierto: RU1

Id: RD4Nombre: Mecanismo de visualización de vehículos.Descripción: El desarrollador requiere crear un mecanismo para visualizar la ubicación de

los dispositivos activos en un mapa.Prioridad: Alta.Requerimiento de usuario cubierto: RU3

41

Id: RD5Nombre: Mecanismo de visualización de rutas.Descripción: El desarrollador requiere crear un mecanismo para visualizar la ruta histórica

de los dispositivos activos en un mapa.Prioridad: Media.Requerimiento de usuario cubierto: RU4

Id: RD6Nombre: Mecanismo de comunicación.Descripción: El desarrollador requiere un mecanismo de comunicación entre el dispositivo

y el servidor.Prioridad: Alta.Requerimiento de usuario cubierto: RU8

Id: RD7Nombre: Mecanismo de almacenamiento en el servidor.Descripción: El desarrollador requiere de un mecanismo para almacenar los datos recibidos

del dispositivo en el servidor:• Identificador del dispositivo (IMEI).• Coordenadas geográficas de la ubicación del dispositivo.• Fecha y hora de obtención de coordenadas.• Estado del vehículo (estado de los sensores).

Prioridad: Alta.Requerimiento de usuario cubierto: RU4

Id: RD8Nombre: Mecanismo de gestión de rutas.Descripción: El desarrollador requiere un mecanismo para gestionar rutas a seguir y geo-

cercas.Prioridad: Alta.Requerimiento de usuario cubierto: RU6

Id: RD9Nombre: Mecanismo de gestión de alermas.Descripción: El desarrollador requiere de un mecanismo para gestionar las alarmas: regis-

trar, eliminar, definir acciones, definir vehículos asociados a la alerta del sistema AVLde cualquiera de los siguientes tipos:

• Alarma ocasionada por el botón de pánico.Prioridad: AltaRequerimiento de usuario cubierto: RU6

42

Id: RD10Nombre: Mecanismo de gestión de vehículos.Descripción: El desarrollador requiere un mecanismo para gestionar: registrar, eliminar,

consultar y modificar varios vehículos.Prioridad: Media.Requerimiento de usuario cubierto: RU5

Id: RD11Nombre: Mecanismo de apagado de alarmas.Descripción: El desarrollador requiere de un mecanismo de acción al ser activada una

alarma y de notificación de enterado o apagado de la misma.Prioridad: Media.Requerimiento de usuario cubierto: RU10

El listado dado anteriormente se retomará en el siguiente capítulo para determinar el avance ylos alcances del Conjunto de Bibliotecas.

3.3.3. Requerimientos no FuncionalesId: RNF1Nombre: Mensajes de error.Descripción: El sistema debe mostrar mensajes que describan indicios de error en las si-

guientes situaciones:• Al enviar datos incompatibles al servidor.• Al no poder obtener la ubicación después del periodo de sensado definido por el

usuario.• Al no tener conexión con un servidor de mapas para visualización de rutas, geocercas

y vehículos.Prioridad: Alta.Requerimiento de desarrollador cubierto:

Id: RNF2Nombre: Tamaño de Base de Datos.Descripción: El tamaño de la base estará restringido a las especificaciones de SQLite 3, las

cuáles son:• Tamaño de Base de Datos 2Tb.• Espacio de almacenamiento mínimo 4Kb.• Tamaño de consulta 1MB.

Prioridad: Media.Requerimiento de desarrollador cubierto: RD7.

43

3.4. Propuesta de SoluciónCon respecto a los requerimientos de usuario, del desarrollador, se empleó la siguiente solución:

1. Para la visualización de mapas se utilizará:

OpenStreetMap, por ser de código abierto y de gran compatibilidad con bibliotecas devisualización de mapas en JavaScript, además de contar con constantes actualizacionesde mapas por los usuarios y desarrolladores.Google Maps, por su fácil uso gracias a la documentación de su API versión 3 y elmercado ya ganado entre los usuarios.Openlayers como biblioteca de visualización de mapas del lado del cliente, para im-plementación y configuración de diferentes características sobre mapas en un entornoweb. Elegido también por ser de código abierto, compatibilidad con diferentes formatosde información de mapas como GeoJson y kml, compatibilidad con servidores de ma-pas personalizables como GeoServer y su uso que no se limita a una computadora deescritorio, sino también en un teléfono inteligente.

2. Lenguajes de Programación a implementar:

Java: para la parte del servidor y sus módulos y parte de la visualización.JavaScript: para la construcción de la mayor parte de interfaz de visualización.

3. Se propone que el servidor contenga las siguientes características:

Tomcat con soporte para Java 8.Openlayers versión 2 (debido a una mayor estabilidad que la versión 3).Json-lib y json-simple.Jquery versión 1.6.4. o superior.Sqlite 3.8.9.

4. Para el desarrollo del sistema AVL se propone emplear los siguientes Patrones de Diseño:

Singleton: para promover la integridad de la información que se inserte en la Base deDatos.Facade: para un manejo simple del sistema a través de JSP’s.Bridge: para separar la abstracción (conjunto de mensajes) de su implementación (elconjunto de clases que ejecuta las acciones que se desean por medio del mensaje).

44

3.5. Metodología y plan de trabajoPara el desarrollo de la solución propuesta se analizaron las metodologías ágiles como marco de

trabajo para el desarrollo de la solución, ésto debido a que las metodologías ágiles son aplicablesa equipos pequeños, estan enfocadas a impulsar un desarrollo de software más rápido y pararesponder más rápidamente a los cambios que surgan dentro del proyecto.Tres de las métodologías ágiles más conocidas son XP, Crystal y Scrum. La metodología que sepropone utilizar es Scrum debido a los siguientes aspectos:

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácti-cas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de unproyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio dela manera de trabajar de equipos altamente productivos [58]

Sus principales características se pueden resumir en dos. El desarrollo de software se realizamediante iteraciones, denominadas sprints, con una duración de 30 días. El resultado decada sprint es un incremento ejecutable que se muestra al cliente (en este caso a sinodales,directores y revisor). La segunda característica importante son las reuniones del equipo a lolargo proyecto de desarrollo para coordinación e integración [59].

La metodología Crystal se define con un enfoque principal del trabajo en equipo, su estructuray su comunicación. De hecho la metodología cambia de nombre al cambiar el tamaño del equipode trabajo [60]. Por ese motivo se descartó como metodología a implementar.XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cam-biantes, y donde existe un alto riesgo técnico [61]. Si bien, dentro del desarrollo de la propuestaexiste un riesgo tecnológico alto, los requisitos ya están bien definidos; por este motivo la metodo-logía XP también se descartó.En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficioque aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectosen entornos complejos, donde se necesita obtener resultados pronto, donde la innovación, la com-petitividad, la flexibilidad y la productividad son fundamentales [58].Por lo tanto, se proponen 4 sprints para la realización del conjunto de Bibliotecas y 2 sprintspara la realización de un caso de estudio donde se construya un AVL basado en el conjunto deBibliotecas desarrollado.

1 . Desarrollo de los módulos de gestión de vehículos y alarmas.

2 . Desarrollo de los módulos de gestión de rutas y geocercas.

3 . Desarrollo de los módulos de visualización de mapas y seguimiento vehicular

4 . Desarrollo de los módulos de visualización de rutas y geocercas.

5 . Integración de módulos y desarrollo de aplicación web con las que estará interactuando elusuario.

6 . Pruebas y creación de documentación (Javadoc y tutoriales html).

45

En el cuadro 3.1 se muestra el calendario de trabajo del Trabajo Terminal del alumno GuevaraJorge y el cuadro 3.2 describe el calendario del alumno Mendoza Marco.

Figura 3.1: Diagrama Gantt. Guevara Jorge.

Figura 3.2: Diagrama Gantt. Mendoza Marco.

46

Capítulo 4

Diseño e implementación

En éste capítulo se presenta el trabajo terminado que se ha denominado LibAVL, así comolas pruebas de concepto que permiten validar la arquitectura del AVL y definir los requerimientospara su funcionamiento correcto. También se muestra la arquitectura de LibAVL y su descripcióndetallada.

4.1. Diseño de LibAVL

4.1.1. RequerimientosId: RF1Nombre: Configuración de dispositivos.Descripción: LibAVL proveerá un conjunto de mensajes que permitirá modificar los pará-

metros enunciados en el requerimiento RD1.Prioridad: Alta.Requerimiento de usuario cubierto: RD1

Id: RF2Nombre: Mecanismo de visualización de vehículos.Descripción: LibAVL proveerá un conjunto de bibliotecas que interactúe con OpenLayers

para la carga de layers de visualización de vehículos en un mapa y que a través de Ajaxse comunique con el servidor para obtener sus ubicaciones.Así mismo proveerá de un conjunto de bibliotecas del servidor que responda las peti-ciones Ajax y hagan la consulta a la base de datos para obtener la ubicación.

Prioridad: Alta.Requerimiento de desarrollador cubierto: RD4

47

Id: RF3Nombre: Mecanismo de visualización de rutas.Descripción: LibAVL proveerá un conjunto de bibliotecas que interactúe con OpenLayers

para visualizar las rutas. Así mismo, de un conjunto de funciones para el servidor queenvíe el conjunto de ubicaciones en formato JSON para un mejor manejo con OpenLa-yers.

Prioridad: Media.Requerimiento de desarrollador cubierto: RD5

Id: RF4Nombre: Mecanismo de Comunicación del Dispositivo con el Servidor.Descripción: LibAVL proveerá un conjunto de mensajes de comunicación entre el cliente o

AVLD y el servidor descrito en la sección 4.3.Prioridad: Media.Requerimiento de usuario cubierto: RD6

Id: RF5Nombre: Mecanismo de almacenamiento en el servidor.Descripción: LibAVL proveerá un mecanismo el cual permitirá almacenar la información

recibida del dispositivo dentro del servidor a través de un conjunto de bibliotecas.Prioridad: Media.Requerimiento de usuario cubierto: RD7

Id: RF6Nombre: Mecanismo de gestión de rutas.Descripción: LibAVL proveerá un mecanismo con el cual se podrá crear, eliminar y guardar

tanto geocercas como rutas a seguir a través de un conjunto de bibliotecas.Prioridad: Media.Requerimiento de usuario cubierto: RD8

Id: RF7Nombre: Mecanismo de gestión de alarmas SOSDescripción: LibAVL proveerá un mecanismo con el cual se podrá configurar las alertas

a emitir por el dispositivo y que podrán ser registradas en el servidor a través de unconjunto de bibliotecas.

Prioridad: Media.Requerimiento de usuario cubierto: RD12

Id: RF8Nombre: Mecanismo de gestión de vehículos.Descripción: LibAVL proveerá de un conjunto de bibliotecas para gestionar: registrar, eli-

minar, consultar y modificar varios vehículos.Prioridad: Media.Requerimiento de desarrollador cubierto: RD10

48

4.1.2. Modelo de DesarrolloEn la figura 4.1 se muestra el diagrama relacional de la base de datos conformado por las

siguientes tablas:

Usuario: se almacenarán los datos del administrador del sistema AVL, el cuál podrá realizartodo el monitoreo dentro del sistema.

Vehículo: donde vamos a almacenar las placas del mismo así como el nombre del conductordesignado.

Marca: se almacenará la marca del vehículo, por ejemplo: Ford, Seat, Chevrolet, Nissan,etc.

Submarca: se almacenará la submarca del vehículo, por ejemplo: Focus, Ibiza, Malibú, Sentra,etc.

AVLD: en esta tabla almacenaremos el IMEI del Dispositivo de Localización, así como susvariables de sensado, es decir, 4 sensores digitales y 3 sensores analógicos; el estado en el quese encuentra, es decir, activo o pasivo; número SOS, el cuál va a recibir la alerta del botón depánico;el estado del AVLD, si está activado o desactivado, fecha y hora actual de recolecciónde información.

Alarma: se almacenará el Id de la Alarma SOS a crear, así como la fecha en la que fueactivada, y su estado, es decir, si se encuentra activada o desactivada.

Geocercas: se almacenará el Id de la Geocerca, así como la latitud y longitud para su creacióny representación en el sistema, así como su fecha de creación.

Rutas: se almacenará el Id de la Ruta, así como la latitud y longitud para su creación yrepresentación en el sistema, así como su fecha de creación.

En las figuras 4.2, 4.3, 4.4, 4.5, 4.6, 4.7 se muestra el diagrama de clases que conforman aLibAVL, integrado por los siguientes paquetes:

alarms: permite el encendido y apagado de alarmas SOS generadas por el AVLD.

controller: permite gestionar el acceso a la base de datos en SQLite.

geofences: permite la creación, guardado y obtención de geocercas del servidor.

handlers: permiten gestionar las tablas principales de la base de datos (AVLD, Vehiculo yAlarma). Para promover la integridad de los datos que se insertan, cada una de las clasesque pertenecen al paquete handlers únicamete pueden ser instanciadas a través de métodosestáticos.

routes: ejecuta las sentencias de obtención del historial de rutas así como la inserción de lasposiciones actuales del vehículo.

vehicles: permite altas, bajas, y cambios en AVLDs y vehículos.

49

Figura 4.1: Diseño de la Base de Datos.

50

Para mayor detalle de cada paquete y clase, se ha creado una documentación tipo JavaDocdonde se incluyen los métodos que ejecutan las funciones de LibAVL. Igualmente se ha desarrolladoun conjunto de tutoriales donde se explica paso a paso las configuraciones, métodos y funcionesnecesarias para probar los módulos de LibAVL (visualización y gestión).

Figura 4.2: Diagrama de clases: Alarms.

51

Figura 4.3: Diagrama de clases: Geofences.

Figura 4.4: Diagrama de clases: Handlers.

52

Figura 4.5: Diagrama de clases: ManagerDB.

Figura 4.6: Diagrama de clases: Routes.

53

Figura 4.7: Diagrama de clases: Vehicles.

54

Posteriormente se detallan los diagramas de caso de uso en la figuras 4.8,4.9, 4.10, 4.11.

Figura 4.8: Diagrama de Caso de Uso: Alarma.

Figura 4.9: Diagrama de Caso de Uso: Geocerca.

55

Figura 4.10: Diagrama de Caso de Uso: Ruta.

Figura 4.11: Diagrama de Caso de Uso: Vehiculo.

56

4.2. ArquitecturaDe acuerdo al Insituto de Ingeniería de Software (Software Engineering Institute SEI, por sus

siglas en inglés) la Arquitectura de Software se refiere a las estructuras de un sistema, compuestasde elementos con propiedades visibles de forma externa y las relaciones que existen entre ellos.

La arquitectura es de especial importancia ya que la manera en que se estructura un sistematiene un impacto directo sobre la capacidad de este para satisfacer lo que se conoce como losatributos de calidad del sistema. Por ejemplo el desempeño, que tiene que ver con el tiempo derespuesta del sistema a las peticiones que se le hacen, la usabilidad, que tiene que ver con qué tansencillo les resulta a los usuarios realizar operaciones con el sistema, o bien la modificabilidad, quetiene que ver con qué tan simple resulta introducir cambios en el sistema.

Como se puede apreciar en la figura 4.12, el diagrama de la arquitectura de LibAVL muestranlos dos módulos desarrollados: visualización y gestión y filtrado.

Figura 4.12: Arquitectura de LibAVL.

57

Módulo de visualización

Para interactuar con el conjunto de bibliotecas, desde un JSP se importa el archivo LibAVL.jsel cual implementa el patrón de software constructor (builder) para abstrae el proceso de creacióndel módulo, centralizando dicho proceso en un único punto.Por otra parte, cada uno de los scripts desarrollados en Javascript implementan el patrón módulo(module) para agrupar todas las funcinoes relacionadas y utilizadas globalmente, en una entidadúnica; dichas entidades son LibAVL.Geofence, LibAVL.Track y LibAVLRoute. Cada entidad haceposible la interacción con el módulo de gestión y filtrado.

Módulo de gestión y filtrado

La capa de filtrado recibe todas las peticiones tanto de dispositivos como de clientes web,elimina las que no corresponda, o no cumplan con los requerimientos. En caso de que la peticiónsea adecuada permite el acceso a consultas, almacenamiento y gestión de vehiculos, AVLD, rutas,alertas y geocercas.Todas las peticiones que estén mal formadas siempre se redireccionarán a la página error.jsp oenviarán un mensaje JSON de respuesta con el error.El módulo de filtrado implementa el patrón de diseño fachada (facade) ya que provee de unainterfaz unificada simple para acceder a otras clases dentro del módulo de gestión.Las clases handler implementan el patrón de diseño singleton para promover la integridad de lainformación que se inserte en la Base de Datos.

Arquitectura en capas

Para comprender la interacción con otros módulos y sistemas, se ha incluido un diagrama encapas con la finalidad de describir dichas interacciones.

58

Figura 4.13: Arquitectura a bloques de LibAVL.

Primer nivel

Para hacer uso de LibAVL no es necesario ejecutarla sobre algún Sistema Operativo en parti-cular, sin embargo como se muestra en la 4.13, es la base de todo el funcionamiento de cada partedel sistema.

Segundo nivel

En segundo plano, se encuentra SQLite, el cual será nuestro Sistema Gestor de Base de Datos elcuál permitirá el almacenamiento, la modificación y la extracción de la información en una base dedatos. Los usuarios podrán acceder a la información usando el sistema AVL o a la misma base dedatos. También se encuentra JRE 8, el cual permite la ejecución de los programas en lenguaje Java.

Tercer nivel

En tercer plano, se encuentra Tomcat 8.0.15 el cual implementará las especificaciones que te-nemos en nuestros Servlets y JSPs. que además contendrá las librerías sqlite-jdbc-3.7.2 para laconexión a la Base de Datos.

Json-simple-1.1.1 y Java-json para el formato de los mensajes en JSON, los cuáles estaránconsultando el contenido de la base de datos o la búsqueda de información, para el formato deintercambio de datos del lado del servidor y para parsear los datos recibido.

Y por último el Módulo de Filtrado y de Gestión, los cuáles harán uso del conjunto de Bi-bliotecas LibAVL, en donde el módulo de filtrado corroborará la información que se necesita para

59

consultar a la base de datos de forma correcta o sea almacenada en la misma; el módulo de gestiónguardará toda la información del AVLD, Vehículos, Alarmas, Geocercas y Rutas.

Cuarto nivel

En cuarto plano, se encuentra el Módulo de Visualización, para la creación de mapas, rutas ygeocercas para el seguimiento vehicular. El módulo de visualización interacciona con JQuery parael diseño y con OpenLayers para la creación mapas. Finalmente, se encuentra la Aplicación Webque desarrollará el programador, la cuál hará uso de los módulos descritos anteriormente.

4.3. Conjunto de MensajesPara realizar la conexión entre el AVLD y el servidor, se ha provisto de un conjunto de mensajes

que puede reconocer el módulo de filtrado y gestión de LibAVL para la realización de todas lasfunciones.En la figura 4.14 se muestra el mensaje de almacenamiento de posiciones, su representación enJSON, sus posibles respuestas y la descripción de cada una de ellas.

Figura 4.14: Mensaje 1

60



61



62



Son un total de 7 mensajes que puede recibir el servidor y 8 con los que puede contestar elservidor. Cada uno de ellos están descritos en las figuras 4.15, 4.16, 4.17, 4.18, 4.19 y 4.20.Todos los mensajes están representados como objetos JSON y contienen los datos necesarios pararealizar todas las funciones que permite LibAVL.Los módulos de filtrado y gestión, realizan un parseo de los mensajes obtenidos, obtienen los datosenviados y verifican que sean correctos antes de que interactúen con la base de datos.Por otra parte, el cliente o AVLD, igualmente necesita un conjunto de funciones que lea el mensajeobtenido y decida que acciones realizar de acuerdo a dicho mensaje. Estos mensajes pueden servistos en la consola del desarrollador.

63

Capítulo 5

Pruebas y resultados

El presente capítulo está dividido en dos partes, la primera muestra las pruebas de conceptorealizadas para validar que los módulos realizados funcionen correctamente y para futuras itera-ciones; la segunda parte muestra un conjunto de pruebas realizadas para comprobar la usabilidaddel conjunto de bibliotecas LibAVL.

5.1. Pruebas de conceptoEn ésta sección se muestran los prototipos que se construyeron para validar cada elemento

utilizado para construir el AVL, establecer la comunicación con el servidor, almacenar los datos ypresentar la información en una interfaz de visualización. En cada prueba se enuncian su descrip-ción, funcionalidad, imágenes o capturas de pantalla (si son necesarias) y detalles u observacionespertinentes a cada una de ellas.

5.1.1. VisualizaciónPrueba de Concepto 1: Mostrar plano base.Objetivo: Comprobar la visualización de mapas de Google Maps y OpenStreetMaps utilizando

la biblioteca Openlayers.Desarrollo: A través del uso de la biblioteca OpenLayers, y específicamente, usando el módulo

OpenLayers.Map para mostrar los mapas, se creó un módulo que facilite la visualización de mapas.Se estudió la documentación para poder incluir mapas de GoogleMaps y OpenStreetMap, pararealizar las tareas de movimiento, acercamiento y alejamiento del mapa. En código JavaScript secrearon:

1. Variables privadas y sus métodos de acceso para el manejo de los mapas con que se inicialicenlas fucniones de visualización.

2. Tres funciones de inicialización: defaultInit(), la cuál establece un mapa con dos layers,uno para Google Maps y otro para OpenStreetMap, LibAVL.OSMapsInit(), con un layerde OpenStreetMap y LibAVL.LibAVL.GMapsInit(), que establece un layer de GoogleMaps.

64

Se decidieron utilizar las hojas de estilo que provee OpenLayers para la visualización de los mapas,layers y los accesorios.

Capturas: Resultados descritos en los cuadros 5.1 y 5.2

Figura 5.1: Layer con OpenStretMap

Figura 5.2: Layer con GoogleMaps

65

Prueba de concepto 2: Visualización de un punto en el mapa e información asociada.

Objetivo: Visualizar un punto en un mapa e información asociada utilizando Openlayers.

Desarrollo: Usando el módulo OpenLayers.Layer.Vector y después de leer la documentacióncorrespondiente, se creó en código JavaScript:

1. Una función que permite la creación del marcador, proporcionar un estilo al mismo y seagregarlo al mapa original creado previamente con las funciones de inicialización.

2. Una función donde se dibuja el marcador y la ventana de información.

Capturas: Se muestra en el cuadro 5.3 la visualización del marcador con la ventana de des-cripción.

Figura 5.3: Visualización de la ejecución de la función.

66

5.1.2. RutasPrueba de concepto 3: Visualización de una trayectoria.

Objetivo: Crear el módulo de funciones que permitan la visualización de rutas.

Desarrollo: Haciendo uso de Openlayers se creó en código JavaScript lo siguiente: 2 layers,uno para el trazado de la ruta y otro para añadir los marcadores. Así mismo, una función a laque se le pasarán como parámetros la fecha de inicio y término de la recopilación de datos para elhistorial y la url del servlet a donde se le hará la petición.Cabe resaltar que lo que se espera de parte del servidor es un objeto JavaScript en formato JSONpara ser utilizado por la biblioteca de OpenLayers. En el mapa se visualizará la ruta que fue creada,así como el vehículo en movimiento con su información desplegada en el popup.Capturas: Visualización en el explorador ver cuadro 5.4.

Figura 5.4: Visualización en explorador.+

5.1.3. GeocercasPrueba de concepto 4: Visualización de polígono en un mapa.

Objetivo: Crear el módulo de funciones que permitan la visualización de Geocercas.

Desarrollo: Haciendo uso de Openlayers se creó en código JavaScript lo siguiente: 2 layers,uno para el trazado de la geocerca y otro para añadir los marcadores. Así mismo, una función a laque se le pasarán como parámetros la fecha de inicio y término de la recopilación de datos para el

67

historial y la url del servlet a donde se le hará la petición.Cabe resaltar que lo que se espera de parte del servidor es un objeto JavaScript en formato JSONpara ser utilizado por la biblioteca de OpenLayers.Capturas: Visualización en el explorador ver cuadro 5.5.

Figura 5.5: Visualización en explorador.

5.1.4. AVLDPrueba de concepto 5: Seguimiento de AVLD.

Objetivo: Visualizar el seguimiento de un dispositivo vehicular.

Desarrollo: Haciendo uso de javascript, se desarrolló una función que permite el envío decoordenadas a partir de un evento con el mouse dentro de un mapa creado con Openlayers. Secreó un Servlet que permite la recepción de dichas coordenadas y finalmente, por medio de Ajaxse creó un función que obtuviera la última ubicación de un dispositivo de la base de datos.

5.2. Pruebas de integración y usabilidadPara comprobar la integración y usabilidad del conjunto de Bibliotecas realizadas, se imple-

mentaron un total de cuatro pruebas a 15 alumnos de la ESCOM con el siguiente perfil:

Que hubieran cursado la materia de Tecnologías para la Web.

Que hubieran cursado la materia de Web Application Development.

68

Que hubieran cursado la materia de Sistemas distribuidos.

.Los resultados se muestran en las secciones siguientes (si se desean conocer más detalles de los

datos obtenidos ver el Anexo C.)

5.2.1. Prueba 1: Ejecución del tutorial Hola mundo.Objetivo: Proveer métricas para conocer que tan compleja es la integración de LibAVL para

la creación de un sistema AVL.Desarrollo: La primera prueba consistió en la lectura del tutorial del holamundo, la realización

de cada paso y la visualización del resultado mostrado en dicho tutorial. Durante la prueba se midióel tiempo desde el inicio hasta que el individuo pudiera visualizar el resultado final correctamente.

Resultados: En la figura 5.6 se muestra una gráfica con 3 resultados, el primero es el tiempoque cada individuo tardó en realizar el ejercicio, el segundo es el tiempo máximo esperado y eltercero es el promedio resultante.

Figura 5.6: Gráfica de resultados a prueba 1

Para dicha prueba encontramos los siguientes resultados:

66.66% de los individuos se encontraron por arriba del tiempo máximo esperado.

El 46.66% de los individuos que se encontraron por arriba del tiempo máximo esperado, erande octavo semestre, el 53.34% eran de noveno semestre.

El tiempo promedio fue mayor que el tiempo máximo esperado por 1.22 minutos.

69

5.2.2. Prueba 2: Ejecución del tutorial Seguimiento.Objetivo: Proveer métricas para la usabilidad de LibAVL.Desarrollo: La segunda prueba consistió en la lectura del tutorial de seguimiento, la realización

de cada paso y la visualización del resultado mostrado en dicho tutorial. Durante la prueba se midióel tiempo desde el inicio hasta que el individuo pudiera visualizar el resultado final correctamente.




Solamente el 13.33% de los individuos se encontraron por arriba del tiempo máximo esperado.

Todos los individuos que se encontraron por arriba del tiempo máximo esperado eran deoctavo semestre.

El tiempo promedio fue menor que el tiempo máximo esperado por 3.13 minutos.

5.2.3. Prueba 3: Ejecución del tutorial Rutas.Objetivo: Proveer métricas para la usabilidad de LibAVL.Desarrollo: La tercera prueba consistió en la lectura del tutorial de visualización de rutas,

la realización de cada paso y la visualización del resultado mostrado en dicho tutorial. Durantela prueba se midió el tiempo desde el inicio hasta que el individuo pudiera visualizar el resultadofinal correctamente.

70




Sólo el 20% de los individuos se encontraron por arriba del tiempo máximo esperado.

El 33.33% de los individuos que se encontraron por arriba del tiempo máximo esperado erande octavo semestre, mientras que el 66.67% eran de noveno.


5.2.4. Prueba 4: Ejecución del tutorial Geocercas.Objetivo: Proveer métricas para la usabilidad de LibAVL.Desarrollo: La cuarta prueba consistió en la lectura del tutorial de visualización de geocercas,

la realización de cada paso y la visualización del resultado mostrado en dicho tutorial. Durantela prueba se midió el tiempo desde el inicio hasta que el individuo pudiera visualizar el resultadofinal correctamente.


71



46.66% de los individuos se encontraron por arriba del tiempo máximo esperado.

71.42% de los individuos que se encontraron por arriba del tiempo máximo esperado erande octavo semestre.


5.2.5. Resultados generalesAl terminar de realizar las cuatro pruebas, a cada individuo se le realizaron tres preguntas:

¿Se te complicó la programación de un Sistema AVL?

¿Fue necesario algún conocimiento de Sistemas AVL?

¿Del 0 al 5, cómo calificarías la claridad de la documentación? (siendo 0 nada claro y 5 muyclaro)

En la figura 5.10 se muestra el resultado de las preguntas realizadas con un contundente 100%que describe que ni se le complicó la programación de un AVL ni necesitó algún conocimientoprevio. Con relación a la claridad de los tutoriales se muestra un promedio de calificación de 4.

72

Figura 5.10: Resultados generales

73

Capítulo 6

Conclusiones

Con base en el capítulo anterior se puede concluir que:

Un programador web puede crear por primera vez un Sistema AVL en promedio en 26.22minutos, sin necesidad de tener conocimiento algúno sobre los mismos.

La integración del conjunto de bibliotecas LibAVl se encuentra en un nivel aceptable decomplejidad debido a que para realizar un Sistem AVL por primera vez, el tiempo se ubicósolo con un minuto y medio por encima del tiempo esperado.

El tiempo promedio en realizar un Sistema AVL que cuente con seguimiento vehicular, vi-sualización de rutas y geocercas es de 90.8 minutos, es decir, una hora y media. Las métricasde LibAVL son:

• En el peor de los casos 118.38 minutos.• En el mejor de los casos 66 minutos.

Dichos tiempos comprueban la reducción de la complejidad de la creación de un AVL debidoa que el tiempo del desarrollo del presente trabajo terminal no se compara con el tiempo enque los individuos se han tardado en realizar el total de los tutoriales.

La rúbrica de LibAVL esta relacionada a que el 100% de los encuestados respondió que ni sele complicó la programación de un AVL ni necesitó algún conocimiento previo. Sin embargo,el promedio de claridad de los tutoriales es de 4 (equivalente al 80%), lo que muestra que setardaron más tiempo en comprender los pasos más que en ejecutarlos.Además LibAVL encapsula el conocimiento necesario para realización de un Sistema AVL,debido a las respuestas obtenidas y descritas anteriormente.

La usabilidad de LibAVL siempre se ubicó con un tiempo promedio poco menor al máximoesperado.

74

Capítulo 7

Trabajo Futuro

En el presente capítulo se plantean algunas de las propuestas identificadas con las cuales sepodrán añadir funcionalidades al conjunto de bibliotecas desarrolladas hasta ahora.

7.1. AlertasA lo largo de este trabajo terminal se implementaron alarmas SOS, pero no son los únicos

tipos que se pueden implementar. Las alertas (como se ha decidido llamar para diferenciar de lasalarmas SOS), se pueden generar al enlazar el paquete de clase que maneja las geocercas con otroque se puede denominar alertas, para que al recibir una posición del algún AVLD fuera de dichageocerca, se pueda activar una alerta que se envíe al usuario vía sms o correo electrónico.

7.2. Generación y Control de ReportesGeneración de reportes con estadísticas sobre las siguientes variables:

Kilometraje recorrido por vehículo.

Kilometraje promedio por semana, mes y día.

Rendimiento del vehículo.

Incidencias de salida de geocerca.

Tasa de incidencias.

Velocidad promedio.

Incidencias por cambio de estado del vehículo.

75

7.3. Compatibilidad con otros sistemas gestores de basede datos

Debido a que se ha decidido encapsular lo más posible la implementación de LibAVL, se decidióutilizar SQLite, sin embargo una funcionalidad que podría implementarse es la de agregar unarchivo de configuración .properties donde se especifiquen las configuraciones necesarias para quese pueda trabajar con distintos gestores de base de datos.

7.4. Aplicación móvil para teléfonos inteligentesLa construcción de una aplicación móvil donde se pueda visualizar y controlar todo el sistema

desarrollado con LibAVL sería un aporte importante como trabajo futuro, puesto que permitiríael seguimiento vehicular sin la necesidad de un sistema web tradicional.

7.5. Añadir capas de seguridadSi bien al momento se cuenta con filtros que eliminan peticiones mal formadas, datos incon-

gruentes y un conjunto de mensajes específicos, se podrían añadir capas de seguridad en caso deque algún vehículo sea robado y siga enviando coordenadas al servidor.

76

Anexo A

JavaDoc

A.1. JavaDocDe acuerdo a las características enunciadas de API así como desde el punto de vista de inge-

niería de software, se requiere documentación para programadores y desarrolladores describiendocódigo, funciones y forma de uso de las mismas, para ello actualmente existen diferentes tipos,utilidades y estándares de la misma.

Javadoc es una herramienta de java para generar documentación básica para el programador apartir del código fuente. Se intenta evitar que la documentación que se genera mediante un editorde texto se quede rápidamente obsoleta cuando el programa continúa su desarrollo y no se tieneel tiempo para mantenerla al día. Para ello, se pide a los programadores de Java que escribanla documentación básica (clases, métodos, etc.) en el propio código fuente (en comentarios en elpropio código), con la espera de que esos comentarios se mantengan actualizados cuando se cambiael código. La herramienta Javadoc extrae y genera con ellos documentación en formato html [46].En el cuadro A.1 se presentan las principales etiquetas JavaDoc y su descripción funcional.

Etiqueta Descripción@author Autor del elemento a documentar.@version Versión del elemento.@return Indica los valores de salida o retorno, válido

unicamente para métodos.@exception Indica la excepción que puede generar.@param Describir los parámetros en un método o

constructor.@see Etiqueta de referecias, indica "ver también".

@deprecated Indica que esa parte (método, constructor,etc.) de la API no seguirá usandose por mu-cho tiempo pero aún puede funcionar.

Cuadro A.1: Principales etiquetas JavaDoc

77

Existen actualmente diversas herramientas generadoras de documentación diseñadas en dife-rentes lenguajes y para diferentes lenguajes tales como: PHPdoc, Doxygen o Natural Docs y otrasque integran generadores de documentacion como Visual Studio, NetBeans o Eclipse.

Natural Docs es una herramienta que no solo permite la generación de documentación de códigojava, sino también de código JavaScript, entre otros. Las etiquetas usadas se adecuan a JavaScriptcon un lenguaje natural y es la herramienta utilizada por la biblioteca Openlayers.

78

Anexo B

Tutorial

B.1. TutorialEn breve se presenta un conjunto de tutoriales que pretende introducir a los programadores en

el desarrollo de sistemas AVL, haciendo uso del conjunto de bibliotecas desarrollados en el TrabajoTerminal.

B.1.1. ¿Qué es LibAVL?LibAVL es un conjunto de bibliotecas que permite el desarrollo de sistemas AVL a la medida,

partiendo de una base previamente establecida que conforma las funciones más básicas de unAVL (localización y seguimiento vehicular, alarmas SOS, geocercas y rutas). Los sistemas AVLa desarrollar tienen una arquitectura cliente-servidor y por lo tanto LibAVL esta dividido en dosmódulos diferentes:

1.- Módulo de Visualización: desarrollado en javascript basado en OpenLayers para el lado delcliente.

2.- Módolo de Gestión: desarrollado en Java para el sistema del lado del servidor.

Módulo de Visualización

El módulo de visualización contiene un conjunto de funciones que permiten mostrar mapas,vehículos, historiales/rutas y geocercas al usuario. Cada clase es configurable, permitiendo perso-nalizar el sistema desarrollado.

Las clases que conforman este módulo son:

LibAVL: Contiene las funciones de inicialización de mapas.

LibAVL.Geofence: Permite configurar geocercas.

LibAVL.Route: Permite configurar historiales/rutas.

LibAVL.Track: Permite configurar el seguimiento vehicular.

79

Así mismo, al ser código abierto, el desarrollador puede modificar las funciones para hacerlas crecery adecuarlas a sus necesidades específicas (para información más específica, ver la documentaciónJavaDoc).

Módulo de Gestión

El módulo de gestión está conformado por 6 packages:

Alarms: gestiona las alarmas SOS, contiene las clases AlarFilter y ServletAlarm.

Controller: gestiona los accesos a la base de datos, contiene las clases ManagerDB.

Geofences: gestiona las geocercas creadas por el usuario, contiene las clases ServletGeofence.

Handlers: permite la gestión de las tablas principales de la Base de Datos para realizarinserciones de datos, contiene las clases UpdateAVlD, UpdateAlarm y UpdateVehicle.

Routes: gestiona la recepción y envío de posisciones del AVLD para generar historiales/rutas,contiene las clases ServletRoute.

Vehicles: gestiona las altas, bajas y cambios de vehiculos y AVLDs, contiene las clases Ser-vletVehicle y VehicleFilter.

Cabe mencionar que cada módulo que interacciona con el cliente o con AVLD’s, contiene elementosde filtrado para aumentar la integridad de los datos que se insertan en la base de datos (para infor-mación más específica sobre las clases que componen cada paquete, ver la documentación JavaDoc).

En los tutoriales mostrados se desea proporcionar una descripción de las funcionalidades deLibAVL para facilitar su comprension y el desarrollo de sistemas AVL basados en la LibAVL.

1.- Hola mundo.

2.- Visualización de mapas.

3.- Seguimiento.

4.- Rutas.

5.- Geocercas.

6.- Alarmas SOS.

7.- Consultas vehiculares.

8.- Estilos.

9.- Haciendo crecer a LibAVL.

80

B.1.2. Hola mundoPara comenzar este conjunto de tutoriales, se muestra primeramente como hacer una aplicación

tipo Hola Mundo.

Requerimientos

Es necesario antes de correr cualquier aplicación verificar que se tengan las siguientes bibliotecaspara el lado del cliente:

Openlayers versión 2

LibAVL 1.0

Jquery 1.11.3

Para el lado del servidor:

java-json

json-simple-1.1.1

sqlite-jdbc-3.7.2 (se recomienda igualmente instalar SQLite3 en el sistema operativo dondecorra la aplicación para verificar el comportamiento de la base de datos creada por LibAVL.)

Tomcat 8.0.15 o superior

Salvo Tomcat, las demás bibliotecas están contenidas ya en el presente proyecto.

Creación del proyecto

Una vez seguros de tener las bibliotecas antes mencionadas, creamos un nuevo proyecto weben NetBeans.

81

Figura B.1: Creación de proyecto


82


Al llegar a éste punto, verificamos que elijamos el servidor Tomcat y damos click en finalizar.

Agregar bibliotecas

Es momento de agregar las bibliotecas necesarias mencionadas anteriormente, java-json, json-simple-1.1.1 y sqlite-jdbc-3.7.2 como se describe en la figura B.4. Las cuales realizan funcionesimportantes del lado del servidor.

83

Figura B.4: Agregar bibliotecas

Para agregar las bibliotecas del lado del cliente es necesario crear una carpeta dento de lacarpeta web del proyecto de NetBeans llamada lib donde se agregue OpenLayers2 y LibAVL comose muestra en las figura B.5, y la carpeta db donde se creará de manera automática la base dedatos en SQLite.

84



Es indispensable que las carpetas se llamen lib y db en minúsculas, ya que si no el proyecto nofuncionará ya que las clases toman como referencia el contexto de la aplicación y el nombre de lascarpetas.

Ahora se copia OpenLayers y LibAVL en la carpeta lib.

85


Para finalizar es momento de agregar las carpetas de los estilos que maneja por defecto Open-Layers y LibAVL tal como lo muestra la figura B.8 para la visualización de mapas.


Modificación del archivo index.jsp

En la figura B.9 se muestra una captura de los scritps y estilos necesarios para el funciona-miento del hola mundo.

Figura B.9: Modificación index.jsp

86

La función javascript necesaria para generar el hola mundo descrita en la figura B.10 única-mente contiene 2 líneas de código. Una para la inicialización por defecto, la cual consiste en un parde layers para visualizar mapas en GoogleMaps y OpenStreetMaps. Y otra para la visualizacióndel ícono que representa al vehículo y su información.

La función LibAVL.defaultInit recibe 3 parámetros:

Centro del mapa: longitud y latitud, variable creada con OpenLayers donde se colocará elcentro de todo el mapa.

Zoom: cantidad de zoom para el centro del mapa.

Url: la dirección del servidor al que se realizarán las peticiones.

Figura B.10: Modificación index.jsp

La otra función importante es LibAVL.Track.init y recibe 3 parámetros:

Intervalo de actualización: entero en milisegundos que representa el tiempo de actualizaciónde la información.

Coordenada nueva: variable LonLat de OpenLayers donde se dibujará el marcador del vehícu-lo.

Información: descripción de status del vehículo.

A partir de ahí la función LibAVL.Track realizará peticiones al servidor cada n segundos declara-dos en la función de inicialización.

La última modificación del archivo index.js es la inserción de la etiqueta

1 <div id=" map" class =" smallmap "></div >

que permite la visualización del mapa en la pantalla y llamar a la función javascript creada ante-riormente a través de la siguiente línea de código

1 <body onload =" myfunction ()">

87

Resultado

La figura B.11 presenta la visualización del Hola Mundo con LibAVL.

Figura B.11: Resultado

B.1.3. Visualización de mapasEs posible que lo que se decida es tener un sistema ligero y no demasiadas opciones de visuali-

zación. Para ello, se puede utilizar la función LibAVL.OSMapsInit, que agrega un layer de mapasligero basado en OpenStreetMaps. Contiene las mismas opciones que la función LibAVL.defaultInit.

Centro del mapa: longitud y latitud, variable creada con OpenLayers donde se colocará elcentro de todo el mapa.

Zoom: cantidad de zoom para el centro del mapa.

Url: la dirección del servidor al que se realizarán las peticiones.

O si se prefiere, se puede utilizar el layer con el mapa de GoogleMaps haciendo uso de la funciónLibAVL.GMapsInit.Modo de uso:

1 LibAVL . OSMapsInit (new OpenLayers . LonLat ( -99.14665300000001 , 19.5045687) ,18, "http :// localhost :8084/ HolaMundoAVL /");

2

3 LibAVL . GMapsInit (new OpenLayers . LonLat ( -99.14665300000001 , 19.5045687) ,18, "http :// localhost :8084/ HolaMundoAVL /");

El resultado se muestra en la figura B.12 donde se puede apreciar el layer con la visualización deOpenStreetMaps y en la figura B.13 con GoogleMaps.

88



B.1.4. SeguimientoPara el seguimiento de los vehículos es necesario hacer uso de las clases de la biblioteca Li-

bAVL.jar (los pasos para agregar el jar se muestran en el tutorial Hola mundo), modificar el archivoweb.xml y el index.jsp. A continuación se muestran los pasos necesarios para realizar el seguimientode un nuevo vehículo a través de un AVLD (dispositivo de localización vehicular).

Para el seguimiento vehicular existe la clase ServletRoute que permite la obtención de las po-siciones que ha seguido una vehículo, y así como se pueden obtener un conjunto de coordenadas,se puede obtener una solamente una para dar el efecto de que el vehículo se está moviendo.

Para realizar el seguimiento es necesario realizar los siguientes pasos:

1.- Modificación del web.xml.

89

2.- Registro de un AVLD.

2.- Registro del vehículo.

3.- Asignar el AVLD al vehículo.

4.- Modificar el index.jsp para enviar y recibir datos del seguimiento.

Modificación del web.xml

Debido a que el proyecto creado para la visualización es un proyecto web realizado con la ayudade NetBeans, y en el Hola mundo se describe su creación, lo que hay que hacer es crear el archivoweb.xml en la carpeta WEB-INF (o modificarlo si ya NetBeans lo ha creado por defecto) como semuestra en la figura B.14, y hay que añadir las líneas de código que permitan acceder a los filtros yservlets que permiten el funcionamiento del seguimiento vehicular tal como se muestra en la figuraB.15.

Figura B.14: Modificación web.xml


90

Registro de un AVLD

El paso siguiente es registrar en la base de datos un nuevo AVLD. Dicho registro se puederealizar de forma sencilla haciendo uso del recurso alta_avld.jsp. Dicho recurso (que se puede en-contrar en la carpeta de recursos de LibAVL) se puede agregar al proyecto en la carpeta web pararealizar automáticamente las insersiones de AVLD’s a la base de datos sin la necesidad de realizarninguna configuración extra.

El recurso cuenta con un formulario que permite hacer uso del ServletVehicle (agregado ante-riormente en el web.xml), cuya función principal es la gestión vehicular (altas, bajas y cambios devehículos y AVLD’s).Así mismo, gracias al módulo de filtrado permite conocer cuando existen errores en los datos in-gresados, lo que minimiza el desarrollo por parte de un programador que desee implementar unsistema haciendo uso de éstas bibliotecas.

Registro de un vehículo

A continuación se da de alta un vehículo a través del JSP alta_v.jsp. Dicho recurso (que sepuede encontrar en la carpeta de recursos de LibAVL) se puede agregar al proyecto en la carpetaweb para realizar automáticamente las insersiones de vehículos a la base de datos sin la necesidadde realizar ninguna configuración extra.

El recurso cuenta con un formulario que también hace uso del ServletVehicle y del módulo defiltrado.

Asignar el AVLD al vehículo

Es momento de asignar un AVLD a un vehículo para que se puedan monitorear las variables delvehículo. Para ello está provisto el recurso asigna_avld.jsp con el que se realiza automáticamentela asignación ingresando solamente el IMEI y el número de placas del vehículo a asignar.

Modificar el index.jsp para enviar y recibir datos del seguimiento

Para finalizar, el recurso index.jsp debe modificarse tal como se muestra en la figura B.16,añadiendo dos campos donde se agregue el IMEI y el número de placas y modificando la funciónpara la actualización de datos automatizada.

91

Figura B.16: Modificación index

Resultado

Aunque el resultado aparente, sea solo la aparición de nuevos campos para ingresar datos y unbotón para iniciar el seguimiento y otro para detenerlo, se puede observar ya el seguimiento de unvehículo asignado a un AVLD en la pantalla, como se puede comprobar seleccionando la opciónrun del proyecto en NetBeans (ver figura B.17).

Obviamente si no se encuentra ninguna ubicación en la base de datos o existe algún error enla conexión, se mostrará el error en una ventana y en la consola del navegador.


B.1.5. RutasUna vez que un AVLD ha enviado un número x de posiciones al servidor, es probable que el

usuario desee conocer las ubicaciones que ha seguido el vehículo al cual está asignado el AVLD.

92

Para ello, LibAVL cuenta con un conjunto de mensajes que permiten obtener las ubicaciones ydibujarlas en el mapa, también contiene una biblioteca llamada LibAVL.Track que a parte de per-mitir el seguimiento (como se pudo observar en el tutorial B.1.4)

Los pasos a seguir para poner en marcha la visualización de las rutas recorridas por el vehículoson:





4.- Modificar el index.jsp para recibir datos de rutas.


Debido a que el proyecto creado para la visualización es un proyecto web realizado con la ayudade NetBeans, y en el Hola mundo se describe su creación, lo que hay que hacer es crear el archivoweb.xml en la carpeta WEB-INF (o modificarlo si ya NetBeans lo ha creado por defecto) como semuestra en el tutorial de seguimiento, y hay que añadir las líneas de código que permitan accedera los filtros y servlets que permiten el funcionamiento de las rutas, tal como se muestra en la figuraB.18.

Figura B.18: Geocercas

Registro de un AVLD

Ir a Registro de un AVLD.


Ir a Registro de un vehículo.


Ir a Asignar el AVLD al vehículo.

93

Modificar el index.jsp para recibir datos de geocercas

Para finalizar, el recurso index.jsp debe modificarse tal como se muestra en las figuras B.19 yB.20, añadiendo dos campos donde se agregue el IMEI y el número de placas, y un botón que hagareferencia a la obtención de rutas a través de las funciones de obtención de rutas.

Figura B.19: Rutas

Figura B.20: Rutas

Resultado

Ahora se pueden ver los campos y el botón que permite visualizar las almacenadas en la basede datos para ese AVLD y vehículo (ver figura B.21).

94


B.1.6. GeocercasUna de las funcionalidades importantes del módulo de visualización es la creación de geocercas.

Una geocerca es un polígono que puede ser dibujado y guardado en la base de datos con la finalidadde establecer una área donde un vehículo pueda circular sin problema e identificar cuando dichovehículo comience a enviar posiciones fuera de dicha geocerca.

Los pasos a seguir para poner en marcha las geocercas son:





4.- Modificar el index.jsp para enviar y recibir datos de geocercas.


Debido a que el proyecto creado para la visualización es un proyecto web realizado con la ayudade NetBeans, y en el Hola mundo se describe su creación, lo que hay que hacer es crear el archivoweb.xml en la carpeta WEB-INF (o modificarlo si ya NetBeans lo ha creado por defecto) como semuestra en el tutorial de seguimiento, y hay que añadir las líneas de código que permitan acceder

95

a los filtros y servlets que permiten el funcionamiento de las geocercas, tal como se muestra en lafigura B.22.


Registro de un AVLD

Ir a Registro de un AVLD.


Ir a Registro de un vehículo.


Ir a Asignar el AVLD al vehículo.

Modificar el index.jsp para enviar y recibir datos de geocercas

Para finalizar, el recurso index.jsp debe modificarse tal como se muestra en las figuras B.23 yB.24, añadiendo dos campos donde se agregue el IMEI y el número de placas y añadiendo botonesque hagan referencia a la creación y visualización de geocercas a través de las funciones de creacióny visualización de geocercas.



96

Resultado

Ahora se pueden ver los botones que permiten el dibujar y obtener las geocercas almacenadasen la base de datos para ese AVLD y vehículo (ver figura B.25).


B.1.7. Alarmas SOSUna alarma SOS es un evento generado por el conductor del vehículo que tiene acceso a un

botón de pánico en caso de emergencias, tales como accidentes o intentos de robo.

Al momento de accionar un botón de pánico, regularmente los AVLD envían un sms a unnúmero previamente establecido, a demás de permitir ésta función, se agrega el poder registrardichas alarmas en el sistema web y llevar un seguimiento de dicha alarma.

Para ello se han establecido 2 vías, una web y otra directamente con el mensaje de alarmaSOS (ver conjunto de mensajes permitidos B.15), sin embargo, primeramente se debe modificarel archivo web.xml como se muestra detalladamente en la figura B.26. Ahí se puede observar lasclases y filtros implementados que se necesitan para su correcto funcionamiento.

97

Figura B.26: Alarmas SOS

Alarma vía web

Se puede activar mediante el recurso crea_alarma.jsp, para ello es necesario añadir el recurso enla carpeta web (desde la carpeta de recursos de LibAVL) al proyecto que se ha creado previamente(ver Hola mundo) y volver a seleccionar la opción Run del proyecto en NetBeans y visualizar losresultados, que debe ser una pantalla como la de la figura B.27. En dicha figura se pueden observarlos campos del IMEI y el número de placas con el que se genera la alarma.

En cambio si se desea implementar la alarma SOS desde el AVLD es necesario verificar cuál esel formato que LibAVL reconoce a través de su conjunto de mensajes.


Apagado de alarmas

Cuando una alarma se activa, se genera un ID que es enviado vía sms, con el IMEI y las placasdel vehículo que lo generó. Para poder apagarlas, se ha incluido el recurso apaga_al.jsp, lo únicoque se necesita es el ID de la alarma, el IMEI y las placas del vehículo, e ingresarlas en los camposque éste recurso provee y es todo.

98

Consulta de alarmas

Finalmente para poder visualizar las alarmas generadas, quién las generó, su hora de activacióny apagado, está disponible el recurso consulta_alarma.jsp. En dicho recurso se muestra una tablacon todos los datos necesarios, como se muestra en la figura B.28


B.1.8. Consultas, bajas, modificaciones vehiculares y de AVLDsComo se pudo observar en el tutorial de seguimiento, tanto los AVLD’s como los vehículos

deben registrarse para poder realizarse un seguimiento vehicular, sin embargo, ¿cómo saber quéAVLD’s o vehículos están registrados actualmente?.

Consultas

Para resolver este problema, se integró un recurso llamado consulta_ve.jsp en el cual se mues-tran 2 tablas con el contenido de la base de datos referente a los vehículos y a los AVLD’s.

Dicho recurso hace uso de la clase ManagerDB para realizar todas las consultas necesarias.En la figura B.29 se muestra una captura de cómo se podrían visualizar los datos una vez queestuvieran dados de alta algunos registros en las tablas.

Figura B.29: Consultas

99

Bajas

Para las bajas de los AVLD’s esta provisto el recurso elimina_ve.jsp que permite eliminar tantovehículos como AVLD’s. Se necesita elegir que se desea eliminar y después proceder a ingresar elIMEI o el número de placas, dependiendo el elemento que se desee eliminar.

Modificaciones

Si bien es posible realizar altas de los AVLD’s, para modificar alguna configuración de losdispositivos ya registrados, se ha provisto del recurso modifica_avld.jsp. Dicho jsp requiere que elusuario ingrese el IMEI del AVLD para acceder a sus datos y modificarlos. Al igual que sucede conotros recursos, modifica_avld.jsp primeramente es filtrado para verificar que el IMEI exista y lossiguientes datos ingresados sean congruentes a los datos esperados.Para la modificación de vehículos existe el recurso modifica_ve.jsp, el cual funciona exactamenteigual, necesita el número de placas del vehículo al cual se desea modificar su configuración.

B.1.9. EstilosAunque no forma parte de núcleo de funcionalidades de LibAVL, se ha provisto de un conjunto

de estilos que el desarrollador puede utilizar, si así lo desea, para proporcionar una mejor visuali-zación del sistema.

Requerimientos

Antes de mostrar cómo utilizar las etiquetas de estilos, es necesario agregar las carpetas quecontienen los scripts de estilos con extensión .css.

Es necesario copiar las carpetas bootstrap-3.3.2-dist y css de la carpeta de recursos de LibAVLa la carpeta web de nuestro proyecto y verificar que exista el recurso jquery-1.11.3.min.js en lacarpeta lib donde también se encuentran las bibliotecas de OpenLayers y LibAVL, tal como semuestra en la figura B.30

100

Figura B.30: Estilos

Insertando estilos

Enseguida se muestran un conjunto de etiquetas y sus estilos asociados:

1.- Tag button: se ha provisto para la visualización de botones la clase btn-info y se puede utilizarde la siguiente manera:

1 <button class =" btn btn -info" onclick =" LibAVL . Geofence . saveGeofence ()"> Enviar Geocerca </ button ><br/>

2.- Tag form: para la creación de formularios y enviar información al servidor, por ejemplopara dar de alta un AVLD, se han provisto 2 clases, form-group input-group para texto yform-inline para los campos de texto. A continuación se muestra como utilizar dichas clases.

1 <div class ="form -group input -group">2 <label >IMEI :</label >3 <input class ="form - inline " type =" text" name =" imei "/>4 </div >

3.- Tag ul: dicha etiqueta es utilizada para realizar los menús de funcionalidades, así se podríavisualizar un menú de mapas, AVLD’s, vehículos y alarmas (por ejemplo), modificando elindex.jsp como se muestra a continuación:

1 <div class ="col -sm -2 sidebar ">2 <ul class =" nav nav - sidebar ">3 <li ><a href =" mapas.jsp">Mapa <span class ="sr -only ">( current ) </

span ></a></li >4 <li ><a href =" avld.jsp"> Dispositivo AVL </a></li >5 <li ><a href =" vehiculos .jsp">Vehiculos </a></li >6 <li ><a href =" alarmas .jsp">Alarmas </a></li >

101

7 </ul >8 </div >

Resultado

Para finalizar, modificamos el index.jsp, insertando las siguientes líneas en el head para insertarlos estilos

1 <link rel =" icon" href =" imagenes / icono1 .png">2 <script src =" bootstrap -3.3.2 - dist/js/ bootstrap .js"></script >3 <script src =" bootstrap -3.3.2 - dist/js/ bootstrap .min.js"></script >4 <script src =" bootstrap -3.3.2 - dist/js/jquery -2.1.3. min.js"></script >5 <link rel =" stylesheet " type =" text/css" href =" css/ dashboard .css" media

=" screen " />6 <link rel =" stylesheet " type =" text/css" href =" bootstrap -3.3.2 - dist/css/

bootstrap .css" media =" screen " />7 <link rel =" stylesheet " type =" text/css" href =" bootstrap -3.3.2 - dist/css/

bootstrap -min.css" media =" screen " />

Agregamos el menú explicado anteriormente, y el siguiente div para que dentro de él se insertelo que se desee, formularios, botones etc.

1 <div class ="col -md -7" id=" tgeo">2 <div class =" panel panel - default ">3 <div class =" panel - heading ">4 <h3 class =" panel -title">Index </h3 >5 </div >6 <div class =" panel -body">7 </div >8 </div >9 </div >

Y finalmente el resultado sería el que se muestra en la figura B.31.

Figura B.31: Estilos

102

B.1.10. Haciendo crecer a LibAVLFinalmente, para concluir con este conjunto de tutoriales, se presenta cómo hacer crecer el

conjunto de bibliotecas LibAVL con la finalidad de permitir que el desarrollador cree a partir delas bases ya establecidas, y no limitarlo a utilizar solamente el desarrollo proporcionado.

Para desarrollar módulos y poder agregarlos a LibAVL es necesario seguir los siguientes pasos:

1.- Analizar las funcionalidades del conjunto de clases a desarrollar, para identificar los móduloscon los que se tendrá que interactuar sea de visualización o gestión.

2.- Modificar los archivos de configuración dependiendo si lo que se desea agregar es funcionalidaden la visualización o en gestión.

Análisis de funcionalidades

LibAVL esta dividido en 3 grandes módulos: visualización, gestión y filtrado (aunque al usuarioel módulo de filtrado es transparente). Si lo que se desea es añadir funcionalidades específicas ala visualización, su desarrollo será en OpenLayers (versión 2), por lo tanto el desarrollador deberáidentificar las clases que utilizará y estudiar su funcionamiento en la JavaDoc de OpenLayers. Asímismo debe revisar la JavaDoc de LibAVL para revisar las clases con las que pudiera interactuar.

Por otra parte si el desarrollo es sobre la gestión del sistema, el desarrollo será en Java y sedeberá revisar la JavaDoc de LibAVL.

Para terminar el análisis de funcionalidades, se debe revisar el tipo de interacción que tendrácon el sistema web, ya que para ello se debe establecer un filtrado especial para las clases que sedeseen añadir. Por ejemplo, si se hará uso de la base de datos, se debe añadir un Servlet o Filterpara evaluar los datos antes de añadirlos o antes de realizar consultas, con la finalidad de proveerun nivel de integridad mínimo de seguridad. Por lo tanto se debe añadir funcionalidades de filtradopara cada elemento de visualización o gestión que lo requiera.

Modificación de archivos de configuración

El archivo que se debe modificar para el módulo de visualización es LibAVL.js y para el módulode gestión es el web.xml, los cuales se describen con más detalle:

1.- LibAVL.js. Dicho archivo contiene una variable llamada _library, la cual es una variableprivada que contiene la ubicación (url relativa) donde se ubican los archivos Javascript queconforman LibAVL.

Por lo tanto, una vez desarrollado el conjunto de funciones necesarias, se deben encapsulardentro de un module de Javascript, guardarlo en un archivo con extensión .js y añadirloen la misma ubicación donde se encuentran los otros archivos y especificarlo en la variable_library; para una creación más rápida se puede utilizar el asistente de NetBeans para crearnuevos archivos como se muestra en las figuras B.32, B.33 y B.34.

103

Figura B.32: Modificación LibAVL.js



2.- web.xml. Dicho archivo contiene la descripción de los Servlets y Filters que se crean para

104

añadir funcionalidad de parte del servidor en el módulo de gestión.

Aunque NetBeans agrega las líneas necesarias en archivo web.xml cuando se crean nuevosServlets o Filters, en la figura B.35 se describe cada línea y su funcionalidad. Cabe mencio-nar que no es necesario establecer un Filter por cada Servlet que se cree, ya que se puedeimplementar la etapa de filtrado dentro del mismo Servlet, sin embargo, para una mejorcomprensión del conjunto de bibliotecas se ha desarrollado así.


Por último es necesario añadir las nuevas clases al LibAVL.jar, ubicándonos en la carpeta quecontiene todas los archivos .class de java: WEB-INF de la carpeta web de nuestro proyectode NetBeans con el comando

1 jar cvf LibAVL .jar *

105

Anexo C

Pruebas realizadas a individuos

Figura C.1: Descripción completa de tiempos prueba 1

106



107


108

Bibliografía

[1] Acetrack, About vehicle trakcing [En línea]. Disponible: http://www.acetrack.com.my/tracking.html

[2] Ministry of interior fire safety and resque directorate general, AVL, System for fire bri-gades.[En línea]. Disponible: http://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCoQFjAA&url=http%3A%2F%2Fwww.ctif.fi%2Fresources%2Fuserfiles%2FFile%2FCTIF%2520Fire%2520Prevention%2F2010_Bulgaria_AVL_system.pps&ei=zndRU_C6GqmG8QH9vIGwAQ&usg=AFQjCNGJknS91BwScQiCIcRaJBK9Hd0t_Q&bvm=bv.65058239,d.b2U

[3] Hugo Morales (2012, Mayo 5), GLONASS: ¿Qué es y por qué im-porta? [En línea]. Disponible: http://www.wayerless.com/2012/05/glonass-que-es-y-por-que-se-usa-en-los-moviles-de-ahora/

[4] Localización satelital (2009, Septiembre 10) GPS VS. RADIO FRECUENCIA[En línea]. Disponible: http://localizacionviasatelite.blogspot.mx/2009/09/gps-vs-radio-frecuencia.html

[5] Gisits RASTREO Y MONITOREO VEHICULAR AVL - Automatic Vehicle Location [Enlínea]. Disponible: http://www.gisits.com/avl.html

[6] Guochang Xu, Ïntroducción.en GPS: Theory, Algorithms and Applications. Germany:EditorialSpringer (2003).

[7] Joel McNamara, "GPS fundamentals.en GPS for dummies. Wiley Publishing, Inc (2004).

[8] Revista muy interesante Elena Sanz (2011, octubre 20) Cinco co-sas que deberías saber sobre el sistema de navegación Galileo [En lí-nea]. Disponible: http://www.muyinteresante.es/tecnologia/articulo/cinco-cosas-que-deberias-saber-sobre-el-sistema-de-navegacion-galileo

[9] Página oficial glonass [En línea]. Disponible: http://glonass-iac.ru/en/GLONASS/

[10] Navipedia (2012, septiembre 28) COMPASS General Introduction [En línea]. Disponible:http://www.navipedia.net/index.php/COMPASS_General_Introduction

[11] [Imagen de segmentos GPS] Recuperado de: Artículo Ingeniería Topográfica,blog para seguimiento de información http://velezortarafael.blogspot.mx/p/investigacion-educativa.html

109

http://www.acetrack.com.my/tracking.html

http://www.acetrack.com.my/tracking.html

http://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCoQFjAA&url=http%3A%2F%2Fwww.ctif.fi%2Fresources%2Fuserfiles%2FFile%2FCTIF%2520Fire%2520Prevention%2F2010_Bulgaria_AVL_system.pps&ei=zndRU_C6GqmG8QH9vIGwAQ&usg=AFQjCNGJknS91BwScQiCIcRaJBK9Hd0t_Q&bvm=bv.65058239,d.b2U





http://www.wayerless.com/2012/05/glonass-que-es-y-por-que-se-usa-en-los-moviles-de-ahora/

http://www.wayerless.com/2012/05/glonass-que-es-y-por-que-se-usa-en-los-moviles-de-ahora/

http://localizacionviasatelite.blogspot.mx/2009/09/gps-vs-radio-frecuencia.html

http://localizacionviasatelite.blogspot.mx/2009/09/gps-vs-radio-frecuencia.html

http://www.gisits.com/avl.html

http://www.muyinteresante.es/tecnologia/articulo/cinco-cosas-que-deberias-saber-sobre-el-sistema-de-navegacion-galileo

http://www.muyinteresante.es/tecnologia/articulo/cinco-cosas-que-deberias-saber-sobre-el-sistema-de-navegacion-galileo

http://glonass-iac.ru/en/GLONASS/

http://www.navipedia.net/index.php/COMPASS_General_Introduction

http://velezortarafael.blogspot.mx/p/investigacion-educativa.html

http://velezortarafael.blogspot.mx/p/investigacion-educativa.html

[12] National Coordination Office for Space-Based Positioning, Navigation, and Timing (2014,Marzo 17) GPS Accuracy [En línea]. Disponible: http://www.gps.gov/systems/gps/performance/accuracy/

[13] WayGPS.com A-GPS (GPS asistido) [En línea]. Disponible:http://www.waygps.com/a-gps-asistido.php

[14] GPS World staff (2013, Marzo 1) Showing Smartphones the Way Inside [En línea]. Disponible:http://gpsworld.com/showing-smartphones-the-way-inside/

[15] Clint Smith y Daniel Collins 3G Wireless Networks. USA, Mc Graw Hill Comunications, 2000.

[16] Comer D., y Stevens, D. Internetworking with TCP/IP Volume I: Principles, Protocols, andArchitecture. USA, Pretntice Hall, 2000.

[17] Mitaller, Función de los sensores, ubicación y fallas en el auto [En línea]. Disponible: http://www.mitaller.com/content/funcion-sensores-ubicacion-fallas-auto

[18] J. Ramírez, Universidad Nacional de Colombia, Geografía y Cartografía [En línea]. Disponible:http://www.unalmed.edu.co/~jramirez/libro/cartografiaygeografia.htm

[19] Ibid.

[20] Help Arcgis, ¿Qué son los sistemas de coordenadas geográficas? [En línea]. Disponible: http://help.arcgis.com/es/arcgisdesktop/10.0/help/index.html#//003r00000006000000

[21] Antonio F. Rodríguez, IGN España (2010, Agoso 23), Análisis comparativo de ser-vidores de mapas [En línea]. Disponible: http://blog-idee.blogspot.mx/2010/08/analisis-comparativo-de-servidores-de.html

[22] Ministerio de Fomento Español, Bases de datos geográficas [En línea]. Disponible:http://www.fomento.es/MFOM/LANG_CASTELLANO/DIRECCIONES_GENERALES/INSTITUTO_GEOGRAFICO/CARTOGRAFIA/BBDD/

[23] Javier J. Gutiérrez (Mayo 2006), ¿Qué es un framework web? [En línea]. Disponible: http://www.lsi.us.es/~javierj/investigacion_ficheros/Framework.pdf

[24] Demián Gutierrez (Abril 2010), Frameworks y Componentes [En línea]. Disponible: http://www.codecompiling.net/files/slides/IS_clase_10_frameworks_componentes.pdf

[25] AjaxShake, Framework HTML5 para acelerar su desarrollo [Enlínea]. Disponible: http://www.ajaxshake.com/es/JS/2410671/framework-html5-para-acelerar-su-desarrollo-html5-boilerplate.html

[26] FRAMEWORK, SDK, BIBLIOTECA, API: ¿CUÁLES SON LAS DI-FERENCIAS? [En línea]. Disponible: http://www.4rsoluciones.com/framework-sdk-biblioteca-api-cuales-son-las-diferencias/

110

http://www.gps.gov/systems/gps/performance/accuracy/

http://www.gps.gov/systems/gps/performance/accuracy/

http://www.waygps.com/a-gps-asistido.php

http://www.waygps.com/a-gps-asistido.php

http://gpsworld.com/showing-smartphones-the-way-inside/

http://www.mitaller.com/content/funcion-sensores-ubicacion-fallas-auto

http://www.mitaller.com/content/funcion-sensores-ubicacion-fallas-auto

http://www.unalmed.edu.co/~jramirez/libro/cartografiaygeografia.htm

http://help.arcgis.com/es/arcgisdesktop/10.0/help/index.html#//003r00000006000000

http://help.arcgis.com/es/arcgisdesktop/10.0/help/index.html#//003r00000006000000

http://blog-idee.blogspot.mx/2010/08/analisis-comparativo-de-servidores-de.html

http://blog-idee.blogspot.mx/2010/08/analisis-comparativo-de-servidores-de.html

http://www.fomento.es/MFOM/LANG_CASTELLANO/DIRECCIONES_GENERALES/INSTITUTO_GEOGRAFICO/CARTOGRAFIA/BBDD/

http://www.fomento.es/MFOM/LANG_CASTELLANO/DIRECCIONES_GENERALES/INSTITUTO_GEOGRAFICO/CARTOGRAFIA/BBDD/

http://www.lsi.us.es/~javierj/investigacion_ficheros/Framework.pdf

http://www.lsi.us.es/~javierj/investigacion_ficheros/Framework.pdf

http://www.codecompiling.net/files/slides/IS_clase_10_frameworks_componentes.pdf

http://www.codecompiling.net/files/slides/IS_clase_10_frameworks_componentes.pdf

http://www.ajaxshake.com/es/JS/2410671/framework-html5-para-acelerar-su-desarrollo-html5-boilerplate.html

http://www.ajaxshake.com/es/JS/2410671/framework-html5-para-acelerar-su-desarrollo-html5-boilerplate.html

http://www.4rsoluciones.com/framework-sdk-biblioteca-api-cuales-son-las-diferencias/

http://www.4rsoluciones.com/framework-sdk-biblioteca-api-cuales-son-las-diferencias/

[27] Cornejo,V.E.,Cázarez (Septiembre 2012), La reutilización de software en Grails Framework[En línea]. Disponible: http://www.uaeh.edu.mx/nuestro_alumnado/icbi/articulos/La_reutilizacion_de_software_en_Grails_Framework

[28] El Guru Programador, Que es un API [En línea]. Disponible: http://oldies.elguruprogramador.com.ar/articulos/que-es-una-api.htm

[29] GPS Asintec, Localización de Vehículos [En línea]. Disponible: http://www.asintecgps.com/localizacion-gps/localizacion-de-vehiculos

[30] Rastreo Satelital de Colombia, Rastreo Satelital para Flotas [En línea]. Disponible: http://www.rastreo.com.co/rastreo/rastreo-de-flotas.html

[31] Patrick Campbell (2011, Septiembre 6) Choosing and implementing a successful GPS/AVLsolution [En línea]. Disponible: http://www.onterrasystems.com/storage/fleetsavvy/Fleet%20Managers%20-%20Choosing%20and%20Implementing%20Successful%20GPS-AVL%201.4.pdf

[32] GPNetworks [En línea]. Disponible: http://www.gpnetworks.co.uk/

[33] Lo Jack [En línea]. Disponible: http://www.lojack.com/Home

[34] Black Jack [En línea]. Disponible: http://www.lojack.com.mx/black-jack/

[35] CosoAVL [En línea]. Disponible: http://www.cosoavl.com

[36] Encontrack [En línea]. Disponible: http://www.encontrack.com/enk/index.php

[37] Prosegur [En línea]. Disponible: http://www.prosegur.com.co/

[38] CosoAVL servicio básico [En línea]. Disponible: http://www.cosoavl.com/soluciones_localizacion_automatica_gps_basico.html

[39] CosoAVL servicio premium [En línea]. Disponible: http://www.cosoavl.com/soluciones_localizacion_automatica_gps_premium.html

[40] CosoAVL servicio next generation [En línea]. Disponible: http://www.cosoavl.com/soluciones_localizacion_automatica_gps_next.html

[41] OpenGTS, Open GPS Tracking System [En línea]. Disponible: http://opengts.sourceforge.net/

[42] Traccar http://www.traccar.org/

[43] Patrones de Diseño de Software https://msdn.microsoft.com/es-es/library/bb972240.aspx

[44] Addy Osmani Learning Javascript Design Patterns.

[45] Página oficial de OpenLayers [En línea]. Disponible: http://openlayers.org/

111

http://www.uaeh.edu.mx/nuestro_alumnado/icbi/articulos/La_reutilizacion_de_software_en_Grails_Framework

http://www.uaeh.edu.mx/nuestro_alumnado/icbi/articulos/La_reutilizacion_de_software_en_Grails_Framework

http://oldies.elguruprogramador.com.ar/articulos/que-es-una-api.htm

http://oldies.elguruprogramador.com.ar/articulos/que-es-una-api.htm

http://www.asintecgps.com/localizacion-gps/localizacion-de-vehiculos

http://www.asintecgps.com/localizacion-gps/localizacion-de-vehiculos

http://www.rastreo.com.co/rastreo/rastreo-de-flotas.html

http://www.rastreo.com.co/rastreo/rastreo-de-flotas.html

http://www.onterrasystems.com/storage/fleetsavvy/Fleet%20Managers%20-%20Choosing%20and%20Implementing%20Successful%20GPS-AVL%201.4.pdf



http://www.gpnetworks.co.uk/

http://www.lojack.com/Home

http://www.lojack.com.mx/black-jack/

http://www.cosoavl.com

http://www.encontrack.com/enk/index.php

http://www.prosegur.com.co/

http://www.cosoavl.com/soluciones_localizacion_automatica_gps_basico.html

http://www.cosoavl.com/soluciones_localizacion_automatica_gps_basico.html

http://www.cosoavl.com/soluciones_localizacion_automatica_gps_premium.html

http://www.cosoavl.com/soluciones_localizacion_automatica_gps_premium.html

http://www.cosoavl.com/soluciones_localizacion_automatica_gps_next.html

http://www.cosoavl.com/soluciones_localizacion_automatica_gps_next.html

http://opengts.sourceforge.net/

http://opengts.sourceforge.net/

http://www.traccar.org/

https://msdn.microsoft.com/es-es/library/bb972240.aspx

https://msdn.microsoft.com/es-es/library/bb972240.aspx

http://openlayers.org/

[46] Oracle, Javadoc Tool [En línea]. Disponible: http://www.oracle.com/technetwork/java/javase/documentation/javadoc-137458.html

[47] Petrocad S.A.,[En línea]. Disponible: http://www.petrocad3d.com/linkus.php?link=1264&id=13. [Último acceso: 1 Mayo 2014]

[48] A. G. Rebolledo,Webfecto, 27 Enero 2009. [En línea]. Disponible:http://www.webfecto.com/2011/08/14/rastreo-satelital-de-vehiculos-gps-tracker-gps-trooper/. [Último ac-ceso: 1 Mayo 2014].

[49] GPSNorte, [En línea]. Disponible: http://www.gpsnorte.cl/docs/Explicacion%20GPS%20Tracking.pdf. [Último acceso: 1 Mayo 2014].

[50] Arduino, [En línea]. Disponible: http://www.arduino.cc/es/. [Último acceso: 2 Mayo 2014].

[51] Arduino, [En línea]. Disponible: http://arduino.cc/en/Main/ArduinoBoardUno. [Últimoacceso: 2 Mayo 2014].

[52] beaglebone.org, [En línea]. Disponible: http://beagleboard.org/Products/BeagleBoard-xM. [Último acceso: 2 Mayo 2014].

[53] Raspberry Pi en español, [En línea]. Disponible:http://www.raspberrypi.es/. [Último ac-ceso: 2 Mayo 2014].

[54] Raspberry Pi en español, [En línea]. Disponible: http://www.raspberrypi.es/hardware-raspberry-pi.php. [Último acceso: 2 Mayo 2014].

[55] Raspberry Pi en español, [En línea]. Disponible: http://www.raspberrypi.es/software-raspberry-pi.php. [Último acceso: 2 Mayo 2014].

[56] Raspberry Pi, [En línea]. Disponible: http://www.raspberrypi.org/downloads/. [Últimoacceso: 2 Mayo 2014].

[57] Ken Schwaber, “Agile Project Management With Scrum,” Microsoft Professional, 1st edition,Microsoft Press, United States, 2004.

[58] Xavier Albaladejo, Que es Scrum. [En línea]. Disponible:http://www.proyectosagiles.org/que-es-scrum. [Último acceso: 06 Julio 2015].

[59] Schwaber K., Beedle M., Martin R.C. .Agile Software Development with SCRUM". PrenticeHall. 2001.

[60] Cockbun A., “Agile Software Development”. Addison-Wesley. 2001.

[61] Beck K., “Extreme Programming Explained. Embrace Change”, Pearson Education, 1999.Traducido al español como: “Una explicación de la programación extrema. Aceptar el cambio”,Addison Wesley, 2000.

112

http://www.oracle.com/technetwork/java/javase/documentation/javadoc-137458.html

http://www.oracle.com/technetwork/java/javase/documentation/javadoc-137458.html

http://www.petrocad3d.com/linkus.php?link=1264&id=13

http://www.petrocad3d.com/linkus.php?link=1264&id=13

http://www.webfecto.com/2011/08/14/rastreo-satelital-de-vehiculos-gps-tracker-gps-trooper/

http://www.webfecto.com/2011/08/14/rastreo-satelital-de-vehiculos-gps-tracker-gps-trooper/

http://www.gpsnorte.cl/docs/Explicacion%20GPS%20Tracking.pdf

http://www.gpsnorte.cl/docs/Explicacion%20GPS%20Tracking.pdf

http://www.arduino.cc/es/

http://arduino.cc/en/Main/ArduinoBoardUno

http://beagleboard.org/Products/BeagleBoard-xM

http://beagleboard.org/Products/BeagleBoard-xM

http://www.raspberrypi.es/

http://www.raspberrypi.es/hardware-raspberry-pi.php

http://www.raspberrypi.es/hardware-raspberry-pi.php

http://www.raspberrypi.es/software-raspberry-pi.php

http://www.raspberrypi.es/software-raspberry-pi.php

http://www.raspberrypi.org/downloads/

http://www.proyectosagiles.org/que-es-scrum

http://www.proyectosagiles.org/que-es-scrum

InstitutoPolitécnicoNacional EscuelaSuperiordeCómputo ESCOM

Documents

Transcript of InstitutoPolitécnicoNacional EscuelaSuperiordeCómputo ESCOM