Silo - Tips - Desarrollo de Un Sistema Gestor de Rutas de PDF

)$&8/7$''(,1)250É7,&$
Departamento de Tecnologías de la Información y las Comunicaciones
PROXECTO DE FIN DE CARREIRA DE ENXEÑERÍA TÉCNICA EN
INFORMÁTICA DE XESTIÓN
Desarrollo de un Sistema Gestor de Rutas de
Posicionamiento Global por Satélite
Autor: Miguel Penín Álvarez

Tutor: Antonino Santos del Riego
A Coruña, 24 de Enero de 2002

SISTEMA GESTOR DE RUTAS DE POSICIONAMIENTO GLOBAL POR SATÉLITE
RESUMEN ............................................................................................................. 3
1. INTRODUCCIÓN ...................................................................................... 4
2. DOMINIO DE LA APLICACIÓN. SISTEMAS GPS.............................. 5
2.1. EL SISTEMA NAVSTAR – GPS ............................................................................ 6
2.2. SERVICIOS GPS .................................................................................................... 12
2.3. CARACTERÍSTICAS DE LA SEÑAL DE LOS SATÉLITES GPS ................. 13
2.4. TIPOS DE RECEPTORES GPS ........................................................................... 15
2.5. GARMIN ETREX ................................................................................................... 19
3. ESTADO DEL ARTE............................................................................... 35
4. METODOLOGÍA DE DESARROLLO .................................................. 39
4.1. MODELADO........................................................................................................... 40
4.2. BASE DE DATOS DEL SISTEMA ....................................................................... 59
4.3. LENGUAJES Y HERRAMIENTAS ..................................................................... 64
5. ARQUITECTURA GENERAL DE SISTEMA....................................... 86
6. VALIDACIÓN DEL SISTEMA............................................................... 90
7. CONCLUSIONES .................................................................................... 92
8. GLOSARIO DE TÉRMINOS .................................................................. 93
BIBLIOGRAFÍA.................................................................................................. 94
REFERENCIAS ................................................................................................... 96
ANEXO I - ENTORNO DEL USUARIO............................................................ 97
I
ÍNDICE DE FIGURAS
Figura 1- Segmentos del sistema de satélites ............................................................ 6
Figura 2- Constelación de satélites ........................................................................... 7
Figura 3 - Segmento de control................................................................................. 8
Figura 4- Posicionamiento mediante esferoides ........................................................ 9
Figura 5- Composición de la señal L1 y L2 ............................................................ 15
Figura 6- Funcionamiento DGPS............................................................................ 18
Figura 7- Garmin eTrex.......................................................................................... 19
Figura 8- Conector GPS - PC mediante puerto serie ............................................... 21
Figura 9- Imagen FUGAWI ................................................................................... 36
Figura 10- Imagen OziExplorer.............................................................................. 37
Figura 11- Imagen Trackmaker .............................................................................. 37
Figura 12- Imagen Waypoint +............................................................................... 38
Figura 13- Sistema de servidores DNA................................................................... 39
Figura 14- Actor..................................................................................................... 41
Figura 15- Casos de uso ......................................................................................... 42
Figura 16- Diagrama de clases ............................................................................... 43
Figura 19- Diagrama de secuencia del caso de uso identificarse ............................. 44
Figura 20- Diagrama de secuencia del caso de uso iniciar GPS............................... 45
Figura 21- Diagrama de secuencia del caso de uso parar GPS ................................ 46
Figura 22- Diagrama de secuencia del caso de uso introducir “waypoints” ............. 48
Figura 23- Diagrama de secuencia del caso de uso introducir rutas......................... 50
Figura 24- Diagrama de secuencia del caso de uso ver “waypoints” comunes......... 52
Figura 25- Diagrama de secuencia del caso de uso ver “waypoints” propios........... 53
Figura 26- Diagrama de secuencia del caso de uso ver rutas comunes .................... 55
Figura 27- Diagrama de secuencia del caso de uso ver rutas propias....................... 56
Figura 28- Diagrama de secuencia del caso de modificar “waypoint” ..................... 57
Figura 29- Diagrama de transición de estados del objeto GPS ................................ 59
Figura 30- Representación lógica de la Base de Datos ............................................ 62
Figura 31- Representación física de la Base de Datos ............................................. 63
II
Figura 32- Módulos del sistema.............................................................................. 87

Figura 33- Menú herramientas, opciones de internet............................................... 97
Figura 34- Opciones de internet, Sitios de confianza .............................................. 97
Figura 35- Agregar nuevo web a los “sitios de confianza” ...................................... 98
Figura 36- Página de entrada a la aplicación........................................................... 99
Figura 37- Página de inicio de un usuario registrado............................................. 100
Figura 38- Mensaje con los datos del receptor ...................................................... 100
Figura 39- Pantalla con las rutas recogidas ........................................................... 101
Figura 40- Waypoints almacenados en el receptor GPS ........................................ 102
Figura 41- Modificar el símbolo de un waypoint .................................................. 102
Figura 42- Visualización de un waypoint.............................................................. 103
Figura 43- Visualización de una ruta .................................................................... 103
ÍNDICE DE TABLAS
Tabla 1- Comparación entre NAVSTAR y GLONASS............................................. 7
Tabla 2- Comparación receptores ........................................................................... 20
Tabla 3- Ejemplo protocolo NMEA........................................................................ 23
Tabla 4-Estructura paquete de conexión ................................................................. 25
Tabla 5- Paquetes básicos del protocolo Garmin..................................................... 27
Tabla 6-Protocolo de transmisión de datos ............................................................ 27
Tabla 7- Protocolo de transmisión de comandos ..................................................... 29
Tabla 8- Comandos permitidos............................................................................... 29
Tabla 9- Protocolo de transmisión de “waypoints” ................................................. 30
Tabla 10-Protocolo de transferencia de puntos GPS ............................................... 32
Tabla 11- Protocolo de transferencia de fecha ....................................................... 33
Tabla 12- Protocolo de transmisión de datos en tiempo real.................................... 34
Tabla 13-Objeto Application .................................................................................. 70
Tabla 14- Objeto ASPError .................................................................................... 71
Tabla 15- Objeto Session ....................................................................................... 72
Tabla 16- Objeto Request....................................................................................... 73
Tabla 17- Objeto Request....................................................................................... 75
III
Tabla 18- Objeto server.......................................................................................... 76

Tabla 19- Características de un OCX sobre HTML ................................................ 83
Tabla 20- Propiedades y métodos del OCX gps_garmin ......................................... 88
Tabla 21- Propiedades y métodos del OCX control_FTP........................................ 89
Tabla 22-Propiedades y métodos OCX visor .......................................................... 90
IV
1
D. ANTONINO SANTOS DEL RIEGO, Profesor Titular de la

Universidade da Coruña.
HACE CONSTAR QUE: La memoria titulada “Sistema Gestor de

Rutas de Posicionamiento Global por Satélite” ha sido realizada por
D. MIGUEL PENÍN ÁLVAREZ, bajo mi dirección, en el
departamento de Tecnologías de la Información y las
Comunicaciones de la Universidad de La Coruña, y constituye su
proyecto que presenta para optar al Grado de INGENIERO
TÉCNICO en Informática de la UDC.
A Coruña, 23 de Enero de 2002
Fdo: Prof. D. Antonino Santos Del Riego.
2
RESUMEN
En este proyecto se aborda el diseño y desarrollo de un Sistema Gestor de

Posicionamiento Global por Satélite, en la forma de una aplicación cliente–servidor,
que proporcione acceso al mayor número de usuarios posibles. Además, también se
incluirá la posibilidad de funcionamiento en la forma de aplicación centralizada, sin
un entorno cliente.
En todos los desarrollos o antecedentes analizados en este proyecto, la idea

predominante es la de disponer de una aplicación y únicamente compartir los datos
entre usuarios mediante ficheros, generados con la información de posicionamiento
para su transmisión. Por otro lado, las Bases de Datos (en adelante BD) con puntos o
rutas de posicionamiento global por satélite, en inglés Global Positioning System (en
adelante GPS) consultadas, no permiten una transferencia de la información
directamente desde el receptor GPS. Las herramientas más completas únicamente
permiten la transferencia de ficheros generados a partir de otros programas.
El sistema resultante de este proyecto, desarrollado bajo una interfaz web usando
tecnología Distributed interNet Aplications (en adelante DNA), permite un acceso
directo del receptor GPS a una BD compartida entre todos los usuarios de la
aplicación. La tecnología DNA proporciona en todo momento un servidor virtual de
web, otro de aplicación y un tercero de datos, aun cuando los tres sean el mismo
físicamente o, por ejemplo, el servidor de datos esté distribuido entre varias
máquinas para balancear la carga de trabajo.
Por tanto, el desarrollo del presente proyecto aporta, de una forma conjunta y
consistente, justamente lo carente en el resto de las aplicaciones analizadas, es decir,
el acceso a una BD centralizada de puntos y rutas GPS que permita la comunicación
directa con el receptor y que proporcione un alto grado de integridad, ciertos niveles
de seguridad, y, entre otros, un adecuado entorno de visualización, tanto en 2D como
en 3D.
PALABRAS CLAVE
GPS (Global Positioning System), NAVSTAR (NAVigation SysTem And Ranging),

servicios SPS (Simple Positioning System) y servicios PPS (Precise Positioning
System), UTC (Universal Time Coordinated), DNA (Distributed interNet
Aplications), Com +
3
1. INTRODUCCIÓN
Las técnicas de posicionamiento y navegación por satélite y por GPS, han
evolucionado de manera vertiginosa desde su aparición, traspasando los fines para
los que en un principio fueron diseñadas y llegando a utilizarse en aplicaciones que
ni se imaginaron en el momento de su desarrollo. Los avances en el mundo de las
comunicaciones y de los sistemas electrónicos, los que han permitido que estas
técnicas lleguen a todo tipo de usuarios, traspasando la pequeña comunidad militar o
científica para las que fueron diseñadas. Aunque el posicionamiento global por
satélite nació con fines militares, continuamente se le están encontrando nuevos usos
civiles.
La tecnología GPS puede ser utilizada en cualquier lugar, menos en aquellos en los
cuales es imposible recibir señal, como por ejemplo dentro de edificios, subterráneos
o bajo el agua. En el aire, los GPS son utilizados para la navegación aérea, tanto en
aeronáutica militar como en aviación comercial y general. En el mar, los GPS
también son utilizados por aficionados a la náutica, pescadores y marinos
profesionales. Las aplicaciones terrestres en cambio están más diversificadas. La
comunidad científica, por ejemplo, utiliza la tecnología GPS para obtener datos de
posición y tiempo muy precisos.
Los usos recreativos del GPS son casi tan numerosos como el número de deportes.
Para citar algunos, podemos decir que las unidades GPS son bastante populares entre
los ciclistas, escaladores, cazadores, motociclistas, etc. Cualquiera que precise
mantener un registro o control de su ubicación o posición geográfica, encontrar su
camino quizás en medio de condiciones hostiles o saber la dirección y velocidad en
que se desplaza puede sacar provecho de los beneficios del Sistema de
Posicionamiento Global.
La aplicación presentada abordará el diseño de un sistema para tratar y procesar los
datos proporcionados por los actuales sistemas de posicionamiento global,
mejorando considerablemente las posibilidades de este campo. El desarrollo de este
tipo de sistemas es altamente complejo, al integrar, en un mismo desarrollo,
4
equipamiento hardware (GPS), protocolo de comunicaciones, cableado y el propio

desarrollo software sobre una arquitectura cliente–servidor. Este tipo de entornos
proporcionan acceso a un gran numero de usuarios, y permiten la introducción de la
aplicación en el mundo Internet. En todo momento se pensó en una interfaz acorde a
los posibles usuarios, intentando siempre diseñarla sobre una plataforma web.
Con esto en mente, el presente proyecto se centrará en el estudio e integración de los

distintos sistemas:
• Sistemas de entrada / salida de datos
• Sistemas de almacenamiento centralizado de datos en bases de datos, lo que
proporciona integridad, consistencia y un cierto nivel de seguridad.
• Gestión de puntos GPS
• Desarrollo de un sistema de visualización en 2D de rutas creadas a partir de
los puntos GPS.
• Desarrollo de un sistema de visualización 3D
Además, se abordará el diseño y la construcción de una aplicación en el dominio del
posicionamiento global por satélite. De esta manera, los usuarios podrán disponer de
una avanzada herramienta que les sirva de ayuda a la hora de recolectar o tratar la
información.
2. DOMINIO DE LA APLICACIÓN. SISTEMAS GPS

El GPS es un sistema mundial de localización constituido por una constelación de
satélites, cada uno de ellos dotado con relojes atómicos, computadoras, emisores y
receptores de radio y por estaciones terrestres que monitorizan constantemente a cada
uno de los satélites. Los receptores de GPS utilizan a estos satélites como puntos de
referencia para calcular la latitud, longitud, altitud, velocidad y tiempo exacto.
Para ello, cada satélite transmite a la Tierra su posición y tiempo exacto 1000 veces
por segundo, donde cada milisegundo un receptor computerizado puede calcular la
distancia con el satélite, multiplicando la velocidad de la luz por el tiempo
5
transcurrido en la transmisión de la señal entre el satélite y el receptor GPS. Al

combinar las señales de varios satélites, el receptor puede establecer con “exactitud”
su propia posición.
2.1. EL SISTEMA NAVSTAR – GPS
El sistema NAVSTAR – GPS, al igual que cualquier otro sistema de satélites, está
constituido por tres segmentos:
1. Segmento espacial
2. Segmento de control
3. Segmento de usuario
Figura 1- Segmentos del sistema de satélites
6
El segmento espacial NAVSTAR – GPS está

constituido por una constelación de 24 satélites,
localizados a 20200 Km de la superficie de la
Tierra. Los satélites son la parte fundamental, ya
que se encargan de emitir constantemente las
señales hacia los receptores GPS, cubriendo todo el
globo terrestre. Actualmente los dos sistemas de
satélites más conocidos son el NAVSTAR GPS y el
GLONASS ruso (GLObal NAvigation Satellite
System) con unas características y operatoria muy Figura 2- Constelación de satélites
similares.
Características de las constelaciones NAVSTAR Y GLONASS

Característica NAVSTAR GPS GLONASS
Departamento de Defensa
de los Estados Unidos de
Compañía Impulsora Gobierno Ruso
América por medio de la
NAVSTAR System Ltd
Numero de satélites 24 en 6 planos orbitales 24 en 6 planos orbitales
Media ( 20,200 Km) Media ( 19,200 Km)
Tipo de órbita Inclinación 63º Inclinación 64.8º
Periodo de 12h Periodo de 11h 15min
Banda L Banda L
Frecuencias L1 = 1.57542 GHz L1 = 1.609 GHz
L2 = 1.2276 GHz L2 = 1.251 GHz
CDMA ( Espectro CDMA ( Espectro
Método de acceso
Esparcido) Esparcido)
Vida Útil Aprox. 7,5 años 7,5 años
Tabla 1- Comparación entre NAVSTAR y GLONASS
7
El segmento de control consta de cinco estaciones de monitorización localizadas en

Hawai, Kwajelein, Isla Ascensión, Diego García y Colorado Springs; tres estaciones
terrestres con antenas en Isla Ascensión, Diego García y Kwajelein, y una Estación
Maestra de Control, en inglés Master control Station (MCS), localizada en la base
aérea de Falcon Colorado, la cual mantiene los satélites en posición orbital y su
respectiva regulación. Las estaciones de monitorización rastrean todos los satélites
que se encuentran a la vista, acumulando la información monitorizada. Esta
información se procesa en la MCS para determinar las órbitas de los satélites y para
actualizar cada uno de sus mensaje de navegación.
Figura 3 - Segmento de control
El segmento de usuario está formado por receptores de GPS que proporcionan la

posición, altitud, velocidad y tiempo preciso al usuario desde cualquier parte del
mundo las 24 horas del día.
8
El sistema NAVSTAR GPS se basa en la medida simultánea de la distancia entre el

receptor y al menos 4 satélites. A partir de cada una de las señales, el receptor GPS
puede generar la
ecuación de un
esferoide. La
intersección de los
esferoides generados
por los cuatro satélites
proporciona la posición
“exacta” del receptor
GPS.
Aunque el cálculo de
los retardos temporales
entre 3 de los satélites
y el receptor GPS
proporcionan un punto
Figura 4- Posicionamiento mediante esferoides
en el espacio (Xi, Yi,
Zi), esta situación exigiría una precisión extraordinaria y una gran estabilidad de los
relojes, tanto del satélite como del receptor. Si bien los satélites cumplen estas dos
condiciones, puesto que incorporan un reloj atómico, este no es el caso de la gran
mayoría de los receptores. La solución a este problema introduce una nueva
incógnita en el sistema de ecuaciones debido a la diferencia existente entre el reloj
del satélite y el reloj del usuario, lo que conlleva a la utilización de un cuarto satélite
como mínimo.
La suposición de que el sistema GPS se basa en distancias es ahora falsa , tal y como
se ha visto en el cálculo de la distancia. En realidad no se miden distancias sino
pseudodistancias.
9
Supongamos:
[0] Ri = Distancia (Satélitei, Receptor)
entonces
[1] R i = ∆T • c Donde Ri es la distancia real (sin error en los relojes)
[2] R i’ = ∆Tmedido • c Donde Ri’ es la pseudodistancia
Siendo “ ∆T ” el tiempo transcurrido entre que la señal parte del satélite hasta que
llega al receptor, “ ∆Tmedido ” la diferencia de tiempo entre el reloj atómico del satélite
y el reloj del receptor; y “c” la constante de la velocidad de la luz.
Suponiendo que:
[3] ∆Tmedido = ∆T +
Siendo “ ” el error derivado de la desviación de los relojes.
Entonces a partir de las ecuaciones [2] y [3] se tiene:
[4] R ’i = ( ∆T + ) • c ⇒ R i’ = ( ∆T • c ) + ( • c )
por [1] entonces
[5] R ’i = R i + ( • c )
10
o lo que es lo mismo, la distancia real es:
[6] R i = R i’ - ( • c )
Como las coordenadas de cada satélite son conocidas, se tienen cuatro ecuaciones,
una por satélite, de la forma siguiente:
[7] (X i − U X ) 2 + (Yi − U Y ) 2 + (Z i − U Z ) 2 = (R i’ − c • 2
Siendo i =1 ... 4, (Xi, Yi, Zi) las coordenadas reales del satélite “i” en el momento de
enviar la señal.
Con las cuatro ecuaciones, 1 por cada satélite, se genera un sistema de ecuaciones
con cuatro incógnitas que proporciona una única solución.Si existen mas de cuatro
satélites visibles, se calculan las pseudodistancias respecto a todos ellos, obteniendo
así un sistema con más ecuaciones que incógnitas, simplificando considerablemente
el cálculo de la posición.
Los satélites transmiten señales en dos frecuencias diferentes de la banda L, la señal

denominada “Link 1” (a partir de ahora L1) a 1575.42 MHz y la señal Link 2 (a
partir de ahora L2) a 1227.6 MHz. Las señales se transmiten utilizando la técnica de
espectro ensanchado, empleando dos códigos de señales diferentes, un “código de
adquisición grueso” (código C/A) a 1.023 MHz en la L1 y un “código de precisión”
(código P) tanto en la señal L1 como en la L2.
Tanto el código C/A como el código P pueden ser utilizados para el cálculo de las
pseudodistancias entre el satélite y el usuario; sin embargo, el código P está
normalmente cifrado. Cuando está cifrado, el código P se denomina código Y. Sobre
estos dos códigos, el código C/A y el código P (o Y si está cifrado), se superpone el
11
mensaje de navegación del GPS. Este mensaje proporciona información tal como la
hora del satélite, los datos orbitales precisos de cada satélite (a partir de ahora
efemérides) o los datos relacionados con los parámetros orbitales de toda la
constelación de satélites.
2.2. SERVICIOS GPS

Existen dos niveles proporcionados por el sistema NAVSTAR GPS, el servicio
preciso de localización, “Precise Positioning System” en inglés (PPS) y el servicio
estándar de localización, en inglés “Simple Positioning System” (SPS).
El PPS es un servicio de determinación de la posición y tiempo con alta precisión,

accesible únicamente por usuarios autorizados. El PPS está destinado principalmente
a entornos militares. El uso de dicho servicio está condicionado a la autorización del
Departamento de Defensa de los Estados Unidos. Esta autorización se concede en
función de los requerimientos de defensa interna de los EE.UU. o de los
compromisos de defensa internacional. Los usuarios autorizados a utilizar el sistema
PPS incluye a todos los usuarios militares de EEUU, a los usuarios militares de la
OTAN y otros usuarios militares y civiles como las Fuerzas de Defensa Australianas
o la Agencia de Cartografía de los EEUU. El sistema PPS proporciona una precisión
predecible de 22 metros horizontalmente, 27.7 metros verticalmente y unos 197
nanosegundos en coordenadas UTC (Universal Time Coordinated).
El acceso al servicio PPS está controlado mediante dos sistemas que incorporan
técnicas criptográficas, “Disponibilidad Selectiva”, en inglés Selective Avaliability
(a partir de ahora SA) y técnicas de autenticación de “anti-spoofing”(en adelante A-
S). La técnica SA se usa para reducir la precisión de la posición GPS, la velocidad e
incluso el tiempo a los usuarios no autorizados. El sistema A-S opera introduciendo
un error pseudoaleatorio dentro de la señal del satélite y permanece activo en todos
los satélites con el fin de proteger la señal de una posible intromisión o modificación
en los datos de la misma.
12
Los receptores PPS pueden utilizar tanto el código P como el C/A, o bien los dos a la
vez. El mayor nivel de fiabilidad se alcanza con los códigos P de las dos señales L1 y
L2 conjuntamente. Aun cuando un receptor esté diseñado para soportar el servicio de
posicionamiento preciso, normalmente se utiliza el código C/A para establecer la
comunicación con los satélites.
El SPS es un servicio de posicionamiento global de baja precisión, pero accesible

desde cualquier receptor GPS. En situación internacional normal, el nivel del SA está
controlado para ofrecer un error predecible de 100 metros horizontalmente y 156
metros verticalmente. El sistema de degradación de la señal se puede incrementar o
variar en caso de crisis o guerra.
2.3. CARACTERÍSTICAS DE LA SEÑAL DE LOS SATÉLITES GPS

Para analizar las características de las señales emitidas desde los satélites, se han de
estudiar tres aspectos:
• El código C/A
• El código P(Y)
• Los mensajes de navegación
El código C/A está compuesto por una señal de ruido de 1023 bits pseudoaleatorios
(PRN) con una frecuencia de 1.023 MHz. La longitud corta de la secuencia del
código C/A está diseñada para permitir al receptor una rápida adquisición de la señal
del satélite que incluye la señal con el código P. Cada satélite GPS tiene asignada
una secuencia PRN diferente, seleccionada de entre un grupo de códigos
denominados “Gold codes”. Estos códigos están diseñados para minimizar la
probabilidad de que el receptor GPS confunda un código con otro. El código C/A
sólo es transmitido junto con la señal L1. Este código no está cifrado y está
disponible para todos los receptores GPS.
13
El código P (o bien código Y si está cifrado) es una señal PRN con una frecuencia de
reloj de 10.23 MHz y un periodo de 267 días. Cada uno de los satélites GPS tiene
asociado un único segmento de 7 días, el cual se reinicia cada medianoche del
domingo, asignando secuencias semanales distintas a cada satélite. El código P está
normalmente cifrado con la finalidad de proteger la señal. El código P es transmitido
por cada satélite tanto en la señal L1 como en la L2.
La señal de datos enviada por el satélite, de una frecuencia de 50Hz, está superpuesta
tanto sobre el código P(Y) como sobre el código C/A. El mensaje de navegación
incluye datos únicos del satélite emisor y ciertos datos comunes a todos los satélites.
Los mensajes del satelite contienen la siguiente información:
• Momento en el que fue transmitido el mensaje.

• Ajuste de la transición desde el código C/A al código P(Y).
• Modelo para corregir los errores del reloj.
• Una referencia a la situación de la constelación de satélites.
• Modelo para corregir los errores producidos por la propagación de la señal en
la ionosfera y troposfera.
• Información sobre el estado de funcionamiento del satélite emisor.
• Información sobre el estado de funcionamiento de todos los satélites.
• Parámetros orbitales de todos los satélites.
• Coeficientes para el cálculo de UTC
El mensaje de navegación está formado por 25 tramas de datos, cada una compuesta
de 1500 bits. A su vez, cada una de ellas está formada de 5 subtramas de 300 bits. En
una señal con una frecuencia de 50 Hz, recibir una subtrama le lleva 6 segundos, 30
segundos para recibir la trama entera y 12,5 minutos en recibir todo el mensaje. Las
subtramas uno, dos y tres de cada trama tienen el mismo formato, lo que permite al
receptor GPS recibir la información crítica del satélite emisor cada 30 segundos. La
14
subtrama Nº 1 contiene la información sobre el modelo para corregir los errores del
reloj, así como parámetros sobre la precisión y el funcionamiento del satélite emisor.
La segunda y la tercera subtramas contienen información precisa de la órbita del
satélite emisor, parámetros necesarios para el cálculo de la posición exacta del
satélite, que se utilizan para obtener la pseudodistancia entre el satélite y el receptor.
Las subtramas cuarta y quinta varían en cada uno de las 25 tramas, y contienen la
información común a todos los satélites y los datos menos críticos para el receptor
GPS.
Figura 5- Composición de la señal L1 y L2
2.4. TIPOS DE RECEPTORES GPS

Los receptores GPS se pueden clasificar en los siguientes tipos:
• Continuos
• Secuenciales
• Multiples
• Diferenciales
2.4.1. RECEPTORES CONTINUOS

Un receptor de búsqueda continua tiene al menos cinco o más canales “hardware”,
cuatro para seguir los cuatro satélites simultáneamente y un quinto a mayores para
15
adquirir nuevos satélites. Debido principalmente a su gran complejidad, estos

receptores son los más caros, aunque también los que ofrecen el mejor de los
servicios. Los receptores multicanal utilizan el quinto canal para leer el mensaje de
navegación de un nuevo satélite GPS, cuando el receptor GPS cambia los satélites
seleccionados. Por separado, los canales de seguimiento dedicados permiten a los
receptores mantener la precisión de la localización bajo un movimiento extremo,
proporcionan el mejor sistema anti-interferencias y poseen el tiempo más bajo para
fijar todos los satélites, en inglés “time to fix first” (a partir de ahora TTFF). Este
tipo de receptores GPS está destinado a vehículos de gran velocidad, como puede ser
un avión de combate, vehículos que requieran un TTFF bajo, como son los
submarinos, o bien para aquellos usuarios que necesiten de un sistema anti-
interferencias para recibir la señal.
2.4.2. RECEPTORES SECUENCIALES

Un receptor secuencial fija los satélites mediante uno o dos canales “hardware”. El
sistema fija un satélite detrás de otro y los combina cuando la pseudodistancia a los
cuatro satélites está calculada. Estos receptores GPS son los más económicos. En
contrapartida no son capaces de operar a grandes velocidades y poseen el sistema de
fijación de satélites más lento del mercado.
Dentro de los receptores secuenciales se distinguen dos tipos:
• Receptores monocanal
• Receptores bicanal
Los receptores secuenciales de un canal calculan las pseudodistancias tanto en la

frecuencia L1 como en la L2, con el fin de determinar la posición y compensar el
retardo de la señal en la ionosfera. Para poder obtener un posicionamiento preciso, el
receptor GPS necesita calcular por separado la posición de cada uno de los satélites,
obtener las orbitas exactas y a partir de estos datos, generar un modelo que le permita
calcular la posición de todos los satélites en el mismo momento. Cualquier
movimiento del receptor durante el tiempo en que se reciben los datos de posición de
16
los satélites puede reducir sensiblemente la precisión del posicionamiento. Los

receptores secuenciales monocanales tienen limitado su uso a aquellas funciones en
las que el movimiento sea mínimo.
Los receptores secuenciales bicanal están diseñados para su utilización en vehículos

de velocidad reducida, como pueden ser automóviles o helicópteros. Durante la
conexión inicial con los satélites opera como un receptor secuencial monocanal, pero
en el momento en que los cuatro satélites están fijados, el segundo canal se dedica a
establecer la conexión con todos los satélites, recibiendo la posición de cada uno,
mientras que el otro se dedica a leer el mensaje de navegación de cada uno de los
satélites. Cualquiera de los dos canales está preparado para leer tanto la frecuencia
L1 como la L2 con el fin de compensar el retraso provocado por la ionosfera. Un
receptor GPS bicanal mejora considerablemente el TTFF en comparación con un
receptor monocanal.
2.4.3. RECEPTORES MÚLTIPLES
Un receptor múltiple(o receptores MUX) conmuta de la señal de un satélite a la señal

de otro a una gran frecuencia (habitualmente unas 50 veces por segundo), recogiendo
continuamente datos para mantener de dos a ocho señales procesándose mediante
“software”. Adicionalmente, el receptor lee continuamente el mensaje de navegación
de todos los satélites. En un receptor múltiple de un único canal hardware, es un reloj
el que se encarga de repartir el uso de tiempo del canal. El problema principal de
estos receptores GPS es su sensibilidad ante las interferencias, lo cual hace que los
sistemas de recepción continuos sean idóneos para fines militares. No sucede lo
mismo con los receptores GPS comerciales, ya que al remplazar componentes
“hardware” por procesos “software”, el precio de estos receptores disminuye.
17
2.4.4. RECEPTORES DIFERENCIALES

Con el fin de optimizar la precisión de la medición GPS, se desarrolló una técnica
conocida como”Differential Global Positioning System”(a partir de ahora DGPS). La
precisión en el receptor GPS depende de muchos factores de entre los que destacan el
sistema SA, la desviación de los relojes o el retraso de la señal provocado por la
ionosfera.
La idea principal del sistema DGPS se basa en el hecho de que los satélites están
situados a una gran altura 20200 Km. Ante esta situación, el tiempo que tarda la
señal en llegar a dos puntos cualesquiera situados a una distancia considerable entre
si, por ejemplo 200 Km, debería contener el mismo error de medición.
El sistema DGPS utiliza

estaciones terrestres de
referencia (bases
pertenecientes a la Guardia
Costera de los EEUU y a
agencias internacionales
que establecen sus
estaciones alrededor de
puertos y ríos navegables).
La Estación de referencia
(con coordenadas exactas ya
Figura 6- Funcionamiento DGPS
conocidas) en lugar de
calcular su posición de nuevo, establece el tiempo de travesía (TC) para cada uno de
los satélites que tiene a la vista y los compara con el tiempo proporcionado por cada
satélite (TS). La diferencia entre el TC y el TS se conoce como Error de corrección
(EC). Cuando un receptor GPS con tecnología DGPS fija los satélites, la estación de
referencia transmite el EC con el fin de corregir los errores en las medidas del
receptor.
18
2.5. GARMIN ETREX
Como receptor GPS, se ha seleccionado el modelo eTrex de la empresa Garmin, por

los siguientes motivos:
• Garmin Ltd. es la empresa líder del mercado de receptores GPS de mano,
compitiendo con empresas como Thales Navigation o Holux Technology Inc.
• La empresa Garmin ofrece una extensa documentación sobre los protocolos que
utilizan sus productos.
• El modelo básico de la serie eTrex ofrece la mejor
relación calidad precio del mercado.
• En el momento de iniciar el proyecto era el único
disponible, cedido por el profesor Antonino Santos
del Riego, director del presente proyecto.
El receptor eTrex es un receptor GPS de mano con doce

canales software que incorpora una antena interna y
cinco botones de funciones. Adicionalmente a la
determinación de la posición del usuario, el Garmin
eTrex crea, almacena y etiqueta una localización como
un “waypoint” (punto en la ruta) en su memoria,
permitiendo el posicionamiento en este punto. Cuando
el usuario se empieza a mover, el GPS proporciona,
entre otros datos, la velocidad, la dirección del Figura 7- Garmin eTrex
movimiento, tiempo y distancia al destino. A partir de estos datos básicos, el GPS

eTrex puede determinar su posición exacta, de donde viene, hacia donde se dirige, y
la ruta de regreso a un punto determinado.
19
La Tabla 2 muestra las principales características del receptor GPS de la empresa

“Garmin” eTrex y su comparativa con otros modelos de la misma compañía y de
otras existentes en el mercado.
Característica Blazer 12 Garmin 12 Garmin eTrex
“Waypoints” 100 500 500
Nombres 4 caracteres 6 caracteres 6 caracteres
Batería externa Sí Sí Sí
Baterías 2 4 2
I/0 computadora No Sí Sí
Capacidad DGPS No Sí Sí
Tabla 2- Comparación receptores
2.5.1. INTERFAZ ENTRADA / SALIDA

La interfaz de entrada-salida permite al receptor GPS conectarse con aparatos
externos como pueden ser periféricos de la “Nacional Marine Electronic
Association” (a partir de ahora NMEA), balizas con receptores DGPS (con el fin de
mejorar la señal), una computadora, etc . El GPS Garmin eTrex posee 7 niveles
diferentes de interfaz de entrada-salida:
• Formato Garmin. Formato propietario que permite al usuario intercambiar
“waypoints”, rutas y puntos entre una computadora y el receptor GPS.
• Garmin DGPS. Gestiona la entrada de señales DGPS provenientes de una baliza
con receptor DGPS, utilizando para la comunicación el formato RTCM SC-104.
Si la radiobaliza es de la marca Garmin, el receptor tomará las funciones de
terminal de la radiobaliza.
• Salida NMEA.Este formato soporta el estándar NMEA 0183 versión 2.0.
• Salida de texto. Transmisión de salida en formato ASCII con datos tales como la
localización o la velocidad, pero no permite ningún tipo de entrada.
20
• Entrada RTCM. Soporte para la entrada de datos en formato RTMC SC-104 sin
necesidad del uso de una radiobaliza.
• RTMC/NMEA. Permite la entrada de datos mediante el estándar RTMC SC-104
a la vez que permite una salida de datos en formato NMEA 0183 versión 2.0.
• RTMC/texto. Soporte para la entrada de datos en formato RTMC SC-104 y salida
en formato texto.
2.5.2. CONEXIÓN HARDWARE

La conexión “hardware” para los receptores de la compañía Garmin reúnen los
requerimientos mínimos necesarios para establecer una conexión con un sistema
NMEA. Es también compatible con la mayoría de los puertos serie de computadoras
personales sobre el protocolo RS232. La velocidad de la interfaz se puede ajustar
manualmente, aunque normalmente es el propio receptor el que establece
automáticamente la mejor velocidad de transmisión adaptada a cada tipo de
conexión. La interfaz de conexión solo posee una línea de entrada de datos, una línea
de salida y una toma de conexión a tierra. Además de la línea de conexión de datos,
el GPS aporta una línea de corriente externa con el fin de poder suministrar corriente
al receptor en cualquier circunstancia.
Con el fin de utilizar la conexión “hardware” del GPS Garmin eTrex con cualquiera
de los periféricos anteriormente señalados, es necesario de un cable con los
conectores apropiados. Este cable, en el caso de una conexión entre el receptor GPS
eTrex y un computadora, consta de un conector serie tipo DB9-hembra y un conector
con un formato propietario de la empresa Garmin. La Figura 8 muestra el esquema
de interconexión entre los dos conectores.
Figura 8- Conector GPS - PC mediante puerto serie
21
2.5.3. PROTOCOLO NMEA
La NMEA desarrolló una especificación que defina la interfaz entre varios

equipamientos electrónicos marinos. El estándar permite el envió de información
hacia una computadora u otro componente electrónico. La comunicación de los
sistemas GPS esta definida siguiendo este estándar. La gran mayoría de los
programas de posicionamiento en tiempo real requieren que la información tenga un
formato estándar NMEA. La idea principal del formato NMEA es la de enviar
paquetes de mensajes, llamados sentencias, con toda la información aportada por el
receptor GPS, haciendo independientes unos paquetes de otros.
Todas las sentencias enviadas en formato estándar NMEA tienen dos primera letras
de prefijo las cuales definen el periférico que utilizan esa sentencia (para los
receptores GPS, este prefijo es GP). Estos dos caracteres están seguidos por tres
letras que definen el contenido de la sentencia. Adicionalmente a las existentes, el
estandar NMEA permite a los fabricantes la definición de sentencias propias. Todas
las sentencias nuevas deberán comenzar con el carácter “p” seguido de una letra que
identifique al fabricante. Ademas, todas las sentencias enviadas empiezan con un “$”
y terminan con una secuencia de retorno de carro/fin de línea. El formato NMEA
incluye todos los datos necesarios separados mediante comas en forma ASCII.
Un ejemplo de código NMEA es:
GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*42
La Tabla 3 muestra la interpretación del código NMEA.
GGA Global Positioning System Fix Data

123519 Recogida a las 12:35:19 UTC
4807.038,N Latitud 48º 0.738’ N
22
01131.000,E Longitud 11º 31.000’ E

Calidad de la recogida
• 0 = invalido
1
• 1 = GPS
• 2 = DGPS
08 Números de satélites seguidos
0.9 Error en la medición horizontal
545.4 Altitud en metros sobre el nivel del mar
Corrección de la altura del nivel del mar
46.9
sobre el elipsoide WGS84
Tiempo en segundos desde la ultima
Vacío
corrección DGPS
Vacío Numero de estación DGPS
*42 Suma de control de los datos ( Checksum )
Tabla 3- Ejemplo protocolo NMEA
Cada tipo de dato tiene su propia interpretación en el estándar NMEA. La sentencia

del ejemplo proporciona al receptor la posición actual del usuario. Otras sentencias
pueden proporcionar la misma información pero con datos añadidos. En el estándar
NMEA no existen comandos para hacer que el receptor suministre los datos
requeridos, si un usuario desea recibir un tipo determinado de datos, simplemente
deberá esperar a que el paquete le llegue e ignorar el resto. Aunque varios receptores
de la marca Garmin poseen la capacidad de enviar información al receptor mediante
el sistema NMEA, esta sólo es útil para modificar los valores almacenados en el
receptor (datos de los “waypoints” o rutas), y no para enviar comandos. El sistema
NMEA tampoco implementa la manera de indicar al receptor una lectura incorrecta,
por ejemplo en un error del “checksum”, o que reenvíe determinado paquete.
23
La versión actual del estándar NMEA es la llamada 0182 Versión 2. Este estándar
define que la transmisión se debe hacer a 4800 baudios. Diversas versiones anteriores
del estándar NMEA requieren diferentes velocidades de transmisión, así la versión
0182 requiere 1200 baudios y la 0183 Versión 1.5, solo aceptada por algunos
receptores de la marca Garmin, transmite a una velocidad de 9600 baudios.
Las principales sentencias del estándar NMEA son:

• GPBOD Recorrido de origen a destino
• GPGGA Datos de localización
• GPGLL Datos de latitud / longitud
• GPGSA Datos de los satélites en general
• GPGSV Datos de un satélite detallado
• GPRMC Datos mínimos de posicionamiento, tiempo y velocidad
• GPRTE Datos de una ruta ( datos de entrada-salida )
• GPWPL Datos de un waypoint (datos de entrada-salida)
Adicionalmente los receptores Garmin poseen las siguientes sentencias propietarias:
• PGRME Error estimado

• PGRMM Datos de mapas ( Soportado por Garmin eMap y similares )
• PGRMZ Altitud
• PSLIB Datos de control de las balizas
• HCHDG Datos de salida del compás ( Soportado por Garmin eTrex Summit )
2.5.4. PROTOCOLO GARMIN
El protocolo Garmin está pensado para comunicarse con sistemas de la gama Garmin
GPS. La interfaz con el GPS soporta una transferencia bidireccional de “waypoints”,
rutas, puntos GPS, “waypoints” de proximidad y el estado de la constelación de
24
satélites. A continuación se describe el protocolo de conexión del Garmin eTrex.,

conocido como protocolo de conexión L001
En el protocolo L001, todos los datos están dispuestos en paquetes de bytes. Un

paquete siempre comienza con tres bytes (DLE, ID, tamaño) seguidos de un número
variable de bytes de datos, y finalizando con un grupo de tres bytes (Checksum,
DLE, ETX ). La Tabla 4 muestra la estructura.
Número de byte Descripción del byte Notas

Carácter 16 del
0 Data Link Escape ( DLE )
código ASCII
Identifica el tipo de
1 ID del paquete
paquete
Solo el tamaño del
Tamaño del paquete de
2 paquete de datos , es
datos
decir n-7 bytes
3 hasta n-4 Paquete de datos 0 hasta 255 bytes
Complemento a 2 de
la suma de todos los
n-3 “Checksum”
bytes desde el byte 1
hasta el byte n-4
n-2 Data Link Escape ( DLE )
Carácter 3 del código
n-1 Fin de texto
ASCII
Tabla 4-Estructura paquete de conexión
En el caso de que cualquier byte en el campo tamaño, paquete de datos, o

“checksum” sea igual al DLE, se insertará otro carácter DLE a continuación. Este
carácter no se incluirá ni en el tamaño del paquete, ni en el cálculo del “checksum”.
25
Con este proceso se permite que el carácter DLE se pueda utilizar como delimitador
de los paquetes. A menos que se confirme lo contrario, el dispositivo que recibe un
paquete debe enviar un nuevo paquete de ACK o NAK hacia el dispositivo emisor,
indicando si el paquete fue o no correctamente recibido. Normalmente el dispositivo
transmisor no emite ningún otro paquete hasta que se recibe el paquete ACK o NAK.
El paquete ACK tiene un identificador igual al carácter 6 del código ASCII, mientras
que el paquete NAK tiene por identificador el carácter 21. Cualquiera de los dos
paquetes contiene un entero de 8 bits que determina el paquete de datos al cual
referencian.
Si se recibe un paquete ACK, el paquete de datos enviado previamente habrá sido

recibido correctamente y la comunicación puede continuar. Si se recibe un paquete
NAK, el paquete no se ha recibido correctamente por lo cual debe ser enviado de
nuevo. Los paquetes NAK sólo se utilizan para representar errores a nivel de
conexión, no en los protocolos de alto nivel.
Con la finalidad de que la comunicación no entre en “interbloqueo”, el GPS manda

paquetes NAK con cierta regularidad (entre 2 y 5 segundos), de esta forma, en el
caso de que se pierda un paquete NAK o ACK, el transmisor volvería a enviar el
ultimo paquete, con lo que la comunicación se volvería a establecer.
La Tabla 5 muestra los paquetes básicos definidos en el protocolo Garmin:
Nombre del paquete Carácter Nombre del paquete Carácter

ASCII ASCII
ID_Date_Time 4 ID_Rte_Wpt_Data 30
ID_ACK_Byte 6 ID_Almanac_Data 31
ID_Position_Data 7 ID_Trk_Data 34
26
ID_Command_Data 10 ID_Wpt_Data 35
ID_Xfer_Cmplt 12 ID_Pvt_Data 51
ID_Prx_Wpt_Data 19 ID_Protocol_Array 253
ID_NAK_byte 21 ID_Product_Rqst 254
ID_Records 27 ID_Product_Data 255
ID_Rte_Hdr 29
Tabla 5- Paquetes básicos del protocolo Garmin
2.5.4.1. PROTOCOLO DE APLICACIÓN
Cada uno de los protocolos de aplicación tiene un identificador único que lo

distinguen de otros. El entorno está abierto a la incorporación de nuevos protocolos o
a la mejora de los protocolos ya existentes.
A000 - Protocolo de transmisión de producto
Todos los GPS están diseñados para transmitir los datos relativos al receptor, tales
como el modelo, versión de software instalado, etc.
La Tabla 6 muestra la secuencia de paquetes correspondiente al protocolo de
transmisión:
N Dirección Nombre del paquete Tipo del paquete

0 Host Í GPS Pid_Product_Rqst
1 Host Ì GPS Pid_Product_Data Product_data_type
Tabla 6-Protocolo de transmisión de datos
El paquete 0 (Pid_product_Rqst) es un paquete especial que incluye el identificador

de paquete. El receptor devuelve el paquete 1 con los datos para identificar el
modelo.
27
El paquete de producto (Product_Data_type) consiste en dos enteros de 16 bits

seguidos por una o más cadenas de caracteres terminadas por un carácter nulo
(vbNullChar). El primer entero identifica el tipo de receptor GPS con el identificador
del producto; el segundo identifica la versión multiplicada por 100, por ejemplo la
versión 3.11 se indica como 311. La primera de las cadenas de caracteres contiene la
descripción del modelo de receptor en formato legible para el usuario final.
La definición de la clase “cProduct_Data” es:
Option Explicit
Public Product_ID As Integer
Public Software_Version As Integer
Public Product_Description_1 As String
Public Product_Description_2 As String
A010 - Protocolo de comandos
Esta sección describe la manera de hacerle llegar al receptor GPS las necesidades del
usuario. Todos los GPS admiten como mínimo un protocolo de comandos, sin
embargo, no tienen por que responder a todos. Un comando enviado a un GPS que
no soporta el protocolo por el cual se está comunicando únicamente será ignorado.
La única diferencia entre los distintos protocolos de comandos son los valores del
identificador de operación.
Hay que recordar que cualquiera de los dos lados de la comunicación (GPS o
computadora) pueden hacer una petición de transferencia de datos, por lo que la
aplicación que se esté comunicando con el GPS deberá considerar también las
peticiones del receptor.
28
La secuencia de paquetes correspondiente al protocolo de transmisión de comandos

es:

0 Equipo 1ÍEquipo 2 Pid_command_Data Command_Id_Type
Tabla 7- Protocolo de transmisión de comandos
El paquete 0 contiene los datos necesarios para indicar el comando requerido, esos
datos están codificados en un único entero de 16 bits conforme a la Tabla 8
Operación Valor Comentario

CMD_Reset_Transfer 0 Cancela la transferencia de datos en curso
CMD_Transfer_Alm 1 Transferir del almanaque de los satélites
CMD_Transfer_Posn 2 Transferir la posición
CMD_Transfer_Prx 3 Transferir los “waypoint” próximos al
punto actual
CMD_Transfer_Rte 4 Transferir las rutas almacenadas en el GPS
CMD_Transfer_Time 5 Transferir la hora y el día
CMD_Transfer_Trk 6 Iniciar la transferencia de todos los puntos
almacenados en el receptor
CMD_Transfer_Wpt 7 Transferir “waypoint” almacenados en el
GPS
MD_Turn_Off_Pwr 8 Apagar el receptor GPS
CMD_Start_Pvt_Data 49 Iniciar la transmisión de la posición en
tiempo real
CMD_Stop_Pvt_Data 50 Finalizar la transmisión de la posición en
tiempo real
Tabla 8- Comandos permitidos
29
A100 - Protocolo de transferencia de “Waypoints”
Una vez transmitido el comando de envío de “waypoints” (CMD_Transfer_Wpt), se

pone en funcionamiento el protocolo que envía desde el receptor GPS todos los
“waypoints” almacenados en su BD.

transmisión de “waypoints” es:

0 Equipo 1ÍEquipo 2 Pid_Records Records_type
1 Equipo 1ÍEquipo 2 Pid_Wpt_Data D108_Wayp_Type
2 Equipo 1ÍEquipo 2 Pid_Wpt_Data D108_Wayp_Type
… … … …
n-2 Equipo 1ÍEquipo 2 Pid_Wpt_Data D108_Wayp_Type
n-1 Equipo 1ÍEquipo 2 Pid_Xfer_Cmplt Command_Id_Type
Tabla 9- Protocolo de transmisión de “waypoints”
El primer y el último paquete son los de inicio y fin estándar. El primero de los
paquetes se compone de un único entero de 16 bits que representa el número de
paquetes de datos que se envían a continuación (sin contar con el paquete
Pid_Xfer_Cmplt). El último de los paquetes también contiene un único entero, que se
corresponde con el “código de operación” que se acaba de completar.
El tipo de datos D108_Wayp_Type que se muestra a continuación es el que se

corresponde al modelo eTrex. Cabe destacar que existen 12 versiones a mayores
utilizadas por otros modelos de receptores.
30
Private Type D108_Wpt_Type

Wpt_Class As Byte
Color As Byte
Dspl As Byte
attr As Byte
Smbl As Integer
subclass(17) As Byte
posn As Semicircle_Type
Alt As Single
Dpth As Single
Dist As Single
State As String * 2
cc As String * 2
Ident As String * 51
comment As String * 51
Facility As String * 31
City As String * 25
addr As String * 51
Cross_Road As String * 51
End Type
Entre los datos suministrados por el receptor, los más destacables son el símbolo
(Smbl), un entero que representa el icono suministrado por el receptor; la altitud
(Alt), el nombre (Ident), una cadena de caracteres de hasta 51 caracteres; el
comentario (comment) y la posición del “waypoint” representada mediante dos
enteros largos de 32 bits cada uno. Se define el tipo Semicírculo como:
Private Type Semicircle_Type

Lat As Long
Lon As Long
End Type
A301 – Protocolo de transferencia de puntos GPS
El protocolo de transferencia de puntos se utiliza para enviar entre dispositivos todos

los grupos de puntos GPS almacenados en el sistema. Si el dispositivo emisor de la
información es el receptor GPS, este los enviará como si todos los puntos GPS
almacenados perteneciesen al mismo grupo, por lo tanto queda en manos de la
31
aplicación el dividir el bloque entero de información en pequeños grupos con

significado.

transmisión de puntos GPS.
Nombre del
N Dirección Tipo del paquete
paquete
0 Equipo 1ÍEquipo 2 Pid_Records Records_type
1 Equipo 1ÍEquipo 2 Pid_Trk_Data D301_Trk_Point_Type
2 Equipo 1ÍEquipo 2 Pid_Trk_Data D301_Trk_Point_Type
… … … …
n-2 Equipo 1ÍEquipo 2 Pid_Trk_Data D301_Trk_Point_Type
n-1 Equipo 1ÍEquipo 2 Pid_Xfer_Cmplt Command_Id_Type
Tabla 10-Protocolo de transferencia de puntos GPS
El primer y el ultimo paquete son los de inicio y fin estándar. El resto de los paquetes
contienen datos del GPS con el formato D301_Trk_Point_Type definido a
continuación:
Private Type D301_Trk_Point_Type

posn As Semicircle_Type
Time As Long
Alt As Single
Dpth As Single
new_trk As Boolean
End Type
El “waypoint” y los datos de longitud y latitud de los puntos se comunican mediante

el tipo Semicircle_Type. El campo new_trk informa a la aplicación de que un grupo
acaba y comienza otro.
32
A600 - Protocolo de transmisión de fecha
El protocolo de transmisión de fecha está diseñado para comunicar el día y la hora

entre los dispositivos. Si el receptor GPS está conectado a la constelación de
satélites, la información que envía es la suministrada por los satélites; en caso
contrario, la información es la del reloj interno del receptor.

es:

0 Equipo 1ÍEquipo 2 Pid_Date_Time_Data D600_Date_Time_Type
Tabla 11- Protocolo de transferencia de fecha
El tipo de datos D600_Date_Time_Type está definido como :
Private Type D600_Date_Time_Type

month As Byte
day As Byte
year As Integer
hour As Integer
minute As Byte
second As Byte
End Type
A800 – Protocolo de datos, tiempo y velocidad en tiempo real
El protocolo “Position, velocity and time” (en lo sucesivo PVT) se utiliza para
transmitir desde el GPS a la computadora, en tiempo real, los datos de posición,
tiempo y velocidad del receptor GPS. Esta información se transmite desde el receptor
una media de una vez por segundo. El envío de datos en tiempo real se inicializa con
CMD_Start_Pvt_Data y se finaliza mediante el envío de un paquete de comandos
con el identificador CMD_Stop_Pvt_Data.
33
El envío de los paquetes ACK y NAK es opcional para cada receptor. De forma
contraria a la de otros protocolos, el receptor GPS no retransmitirá un paquete PVT
aunque reciba un NAK de la computadora. Este protocolo realiza esta función para
preservar la continuidad y el orden de los datos.

se muestra en la Tabla 12.

0 Host Ì GPS Pid_Pvt_Data D800_Pvt_Data_Type
Tabla 12- Protocolo de transmisión de datos en tiempo real
El tipo de datos D800_Pvt_Data_Type está definido como:
Private Type D800_Pvt_Data_Type

alt As Single
errorposition As Single
errorpositionh As Single
errorpositionv As Single
pos_type As Integer
tow As Long
position As Radian_Type
velocity_east As Single
velocity_nort As Single
velocity_up As Single
msl_hght As Single
leap_scnds As Integer
day_number As Single
End Type
La posición del punto GPS tiene el formato definido como:
Private Type Radian_Type

Lat As Single
Lon As Single
End Type
34
Cabe destacar que el campo alt (altitud) representa la altitud sobre el elipsoide WGS
84. Para hallar la altura respecto al nivel del mar, se debe sumar el campo alt” con el
campo msl_hght (altura del elipsoide WGS 84 sobre el nivel del mar).
El campo tow (time of web) informa sobre el número de segundos desde el comienzo
de la semana actual que empieza a las 12 A.M del domingo. El campo day_number
informa sobre el numero de días desde el 31 de diciembre de 1989 hasta el día de
inicio de la semana actual. El campo pos_type identifica el tipo de muestra que ha
sido tomada. Si el valor está entre 0 y 1 la muestra no es válida, si está comprendido
entre 2 y 3, es una muestra normal, si el valor es 4 o 5, la muestra es diferencial
3. ESTADO DEL ARTE
Desde el momento en que el precio de los receptores GPS se apartó a las

posibilidades del usuario medio, coincidiendo con el desarrollo de nuevas
tecnologías como son los receptores MUX, la cantidad de aplicaciones existentes en
el mercado para tratar los datos sufrió un incremento considerablemente.
En un principio, la mayoría de las aplicaciones diseñadas estaban pensadas con la

única finalidad de almacenar y a la vez proteger los datos del receptor, y permitir la
captura de más datos, como por ejemplo el GARTRIP 2.04c [GART-02]
En un segundo paso, y adaptándose al usuario medio, comenzaron a aparecer los

sistemas de posicionamiento en tiempo real. Estas aplicaciones se ejecutan en una
gran diversidad de entornos:
• El control de un atleta a lo largo de una carrera. Es el caso de el programa
JOGMAN V1.0 [JOGM-02] que permite analizar en tiempo real, las
distancias recorridas, las calorías consumidas, velocidades de aproximación a
diversos puntos, velocidades medias, etc.
35
• Control de la dirección y la velocidad en los automóviles. Programas como el

COMPASS V1.0 [COMP-02] que muestra en todo momento la dirección del
vehículo respecto al norte geográfico, o el SPEEDTRAP BETA V1.1 [SPEE-
02] que a partir de unos determinados parámetros introducidos por el usuario,
avisa en el momento en el que el vehículo sobrepasa el límite de velocidad
preestablecido para ese tipo de vía.
• O simplemente determinar la posición del usuario dentro de un mapa.

Programas como el FUGAWI v 3.0.2.6 [FUGA-02], uno de los programas
más completos, que proporciona una interfaz sobre la que se sitúa un mapa de
la zona en la cual nos encontramos (en caso de que la aplicación posea el
mapa digitalizado) mostrándose todo el recorrido.
Figura 9- Imagen FUGAWI
Una tercera generación de aplicaciones para los GPS, entre la que se incluiría el
desarrollo del presente proyecto, son aquellas que permiten almacenar los datos del
receptor para posteriormente tratarlos en, por ejemplo, aplicaciones topográficas.
36
De entre estas aplicaciones destacan :

• OziExplorer V3.9 [OZIE-02] permite definir las rutas y los “waypoints” sobre un
mapa y transferirlos posteriormente al receptor GPS .
Figura 10- Imagen OziExplorer
• Tracmaker V11.3 [TRAK-02], que aún siendo uno de los primeros programas en
aparecer y sin tener una apariencia espectacular, se ha hecho con un amplio
sector de los usuarios, que además de poder transferir sus datos a la
computadora, permite añadir imágenes de fondo, proporcionando un mayor
realismo a la representación.
Figura 11- Imagen Trackmaker
37
• Waypoint + [WAYP-02], aplicación que aun siendo de las pocas que no tienen
una representación gráfica de la información, se mantiene gracias a que el
formato de almacenamiento se ha convertido en un estándar usado por la mayoría
de los grandes programas de representación gráfica de los datos GPS.
Figura 12- Imagen Waypoint +
Una característica común de todas los sistemas analizados, a excepción de

FUGAWI, es que son entornos “freeware” o “shareware”, y no todos ellos acceden a
suministrar un soporte contínuo de la aplicación. Otra característica que las
diferencia del sistema aquí presentado, es que son aplicaciones que necesitan de un
programa ejecutándose en el cliente. Esto conlleva a que las modificaciones de la
aplicación se hagan en base a actualizaciones del producto o a nuevas librerías que el
usuario tiene que reinstalar en su máquina.
La característica principal de la aplicación desarrollada, en el presente proyecto, es

que no requiere de ningún cliente especifico, ya que la interfaz que necesita es
únicamente un navegador que soporte el uso de objetos OCX, como es el “Microsoft
Internet Explorer” desde su versión 4.0. Debido al propio funcionamiento del
navegador, derivado de la forma de diseñar la aplicación, cualquier modificación en
los objetos de comunicación con el GPS, o bien en el objeto de visualización, se
actualiza automáticamente al entrar en la aplicación web, sin que el usuario tenga
necesidad de reinstalar nada. En el caso de que se realice alguna modificación en la
lógica interna de la aplicación, el usuario no será consciente del cambio (a no ser que
lo modificado sea la propia interfaz), lo único que se podrá observar es que la
aplicación está momentáneamente inaccesible durante el tiempo que se tarde en dar
de baja una librería y registrar la nueva, tiempo que normalmente no excede de un
38
minuto. Otro beneficio derivado de utilizar una aplicación cliente-servidor, es que los
datos son compartidos entre todos los usuarios del web, lo cual permite crear un
catálogo de rutas y “waypoints” disponible para cualquier usuario.
El hecho de trabajar con una metodología basada en el sistema DNA permite

distribuir la carga de trabajo en diferentes servidores físicos, de forma que un equipo
haga las funciones de “servidor de web”, otro de “servidor de aplicación”, donde
estarán instaladas las librerías y donde se ejecutaran los procesos, y un tercero, el
“servidor de datos”, donde estará ubicada físicamente la BD.
Cliente Servidor Web Servidor de aplicación Servidor de datos
Figura 13- Sistema de servidores DNA
4. METODOLOGÍA DE DESARROLLO
Para el desarrollo de la aplicación se seguirá una metodología clásica, además del

Lenguaje Unificado de Modelado, en inglés Unified Modeling Language (a partir de
ahora UML)
Desde un principio se define un claro requisito; la necesidad de una de arquitectura
cliente-servidor, ya que de esta manera se mantienen todos los datos sobre un único
servidor, evitando al usuario el tener que actualizar constantemente su cliente con
nuevas modificaciones. De entre las propuestas estudiadas, realizar la aplicación
sobre un entorno web fue la que más beneficios ofrecía. Otra ventaja es la clara
39
independencia de los clientes ante modificaciones de la aplicación. En la peor de las

situaciones, si uno de los objetos OCX de la interfaz se modifica, el propio
navegador deberá instalar una versión actualizada a partir de una URL prefijada.
Para poder trabajar sobre un entorno web, lo más normal es utilizar HTML, DHTML
o XHTML, combinados con distintos OCX o applets.
La principal problemática con la que nos encontramos, son las restricciones que tanto
el propio HTML (o variantes), como el navegador imponen para preservar la
seguridad del propio equipo cliente.
4.1. MODELADO
El UML es un lenguaje de modelado visual que se utiliza para especificar, visualizar,

construir y documentar artefactos de un sistema software. Captura decisiones y
conocimientos sobre los sistemas que se deben construir. Se usa para entender,
diseñar, configurar, mantener y controlar la información sobre tales sistemas. Está
pensado para usarse con todos los métodos de desarrollo, etapas del ciclo de vida,
dominio de la aplicación y medios.
UML capta la información sobre la estructura estática y el comportamiento dinámico

de un sistema. Un sistema se modela como una colección de objetos discretos que
interactúan para realizar un trabajo que finalmente beneficia a un usuario externo. La
estructura estática define los tipos de objetos importantes para un sistema y para su
implementación, así como las relaciones entre los objetos. El comportamiento
dinámico define la historia de los objetos en el tiempo y la comunicación entre
objetos para cumplir sus objetivos.
40
4.1.1. ACTOR
Un actor es una idealización de una persona externa, de un proceso, o de cualquier

cosa que interactúa con un sistema, un subsistema o una clase. En tiempo de
ejecución, un usuario físico puede estar ligado a uno o varios actores dentro del
sistema. Así mismo diferentes usuarios pueden estar ligados al mismo actor.
En el sistema a desarrollar existe un único actor, el usuario de la web que puede
realizar todas las acciones disponibles en la aplicación.
Figura 14- Actor
4.1.2. CASOS DE USO
Un caso de uso es una unidad coherente de funcionalidad, externamente visible,

proporcionada por una entidad del sistema y expresada por secuencias de mensaje
intercambiados por la unidad del sistema y uno o más actores. El propósito de un
caso de uso es definir una pieza de comportamiento coherente, sin revelar la
estructura interna del sistema. Los casos de uso de la aplicación se muestran el la
Figura 15.
41
<<extend>>
Ver Wayp propios

<<extend>>
Visual izar Waypoints
Ver Wayp comunes <<uses>>
<<extend>>
<<extend>> Ver rutas propias

Visualizar rutas
<<uses>>
<<uses>>
Ver rutas comunes
Introducir rutas
<<uses>>
Usuario
Iniciar transmision GPS <<uses>> Identificarse
<<uses>>
Introducir Waypoints
<<uses>>
Parar transmision GPS
Modificar Waypoints
Figura 15- Casos de uso
42
4.1.3. VISTA ESTÁTICA

La vista estática es la base del UML. Los elementos de la vista estática de un modelo
son los conceptos significativos en una aplicación, incluyendo conceptos del mundo
real, conceptos abstractos, conceptos de implementación, conceptos de computación
y todo tipo de conceptos del sistema.
La vista estática captura la estructura del objeto. Un sistema orientado a objetos
unifica la estructura de datos y características del comportamiento en una sola
estructura de objeto. La vista estática incluye todo lo concerniente a las estructuras
de datos tradicionales, así como la organización de las operaciones sobre los datos.
Waypoints
Id_way point
GPS Nombre Fichero
Puerto Descripcion Nombre
Tipo 1 Simbolo Tamaño
0..*
Comentario Tipo
Download_way p() 1 0..*
Download_tracks() Mostrar way points usuario() Ficheros_way point()
Iniciar reloj() Mostrar way points() Añadir()
Grabar()
1 Modif icar()
0..*
Puntos GPS
0..*
Latitud
Rutas
Longitud
Nombre Altura
Id_ruta Velocidad
Tiempo
Mostrar rutas usuario() 0..* 1..*
Mostrar rutas() Datos inicio-f in()
Grabar() Datos punto()
1 Grabar()
0..*
1
0..1
Imagen usuario
id usuario
Nombre
Apellidos
1
Mostrar datos()
Imagen 2D
Imagen 3D 0..1
session
Crear Latitud-Longitud()
Crear() IdUsuario
Crear Altura()
Mostrar()
Mostrar()
Comprobar()
Figura 16- Diagrama de clases
43
4.1.4. DIAGRAMAS DE SECUENCIA

Un diagrama de secuencia representa una interacción como un gráfico bidimensional.
La dimensión vertical es el eje del tiempo, que avanza hacia la parte inferior de la
página. La dimensión horizontal muestra los roles de clasificador que representan
objetos individuales en la colaboración. Cada rol de clasificador se representa
mediante una columna vertical (línea de la vida).
4.1.4.1. DIAGRAMA DE SECUENCIA DE IDENTIFICARSE
El caso de uso comienza cuando se inicia la aplicación y termina en el momento que

el usuario queda autentificado. Al iniciar la aplicación, el sistema espera a que el
usuario introduzca un nombre de usuario y una contraseña. Una vez que el sistema
obtiene los datos, se activa la función de autenticación y se actúa en consecuencia.
Una vez obtenido el identificador de usuario, se graba en el objetos Session, y se
devuelve el control al usuario.
Interface Usuario Session

: Usuario
login + pswd
Verificar
[id_usuario]
Grabar_usuario
Figura 19- Diagrama de secuencia del caso de uso identificarse
44
4.1.4.2. DIAGRAMA DE SECUENCIA DE INICIAR GPS
El caso de uso comienza cuando el usuario una vez autenticado, requiere que se
establezca la comunicación con el receptor GPS. El caso de uso finaliza en el
momento que el sistema recibe el primer mensaje por parte del GPS. Una vez
iniciado el caso de uso, el usuario debe introducir el puerto de comunicación , para
posteriormente inicializar la conexión con el receptor. Finalizado este proceso, la
interfaz realizará la llamada al objeto GPS que activará la comunicación a la vez que
inicializa el reloj interno.
Interface GPS
: Usuario
Seleccionar_puerto
Inicializar GPS
Inicializar ( puerto)
Activar Reloj
Figura 20- Diagrama de secuencia del caso de uso iniciar GPS
45
4.1.4.3. DIAGRAMA DE SECUENCIA PARAR GPS
El caso de uso comienza cuando el usuario determina que desea cortar la

comunicación con el receptor GPS y termina en el momento en que se devuelve el
control al usuario. Si el usuario selecciona la opcion “parar” la comunicación con
GPS, el interfaz le comunica al objeto GPS que la transmisión de datos va a ser
detenida, este desactiva el reloj y devuelve el control.
Interface GPS
: Usuario
Parar GPS
Stop ( puerto )
Desactivar Reloj
Figura 21- Diagrama de secuencia del caso de uso parar GPS
46
4.1.4.4. DIAGRAMA DE SECUENCIA INTRODUCIR “WAYPOINTS”

El caso de uso comienza cuando el usuario determina que desea transferir todos los
“waypoints” de su receptor a la computadora. El caso de uso termina en BD.
Cuando el usuario requiere al sistema que se transmitan todos los datos del receptor
al sistema, la interfaz le comunica al objeto GPS que inicialice la transmisión de
todos los “waypoints”. Con el retorno del control al usuario, se muestran todos los
waypoint transferidos y se indica al usuario que determine cuales de ellos desea
introducir en la BD.
Una vez seleccionados, tras seleccionar la opción de insertar en la BD, se comprueba
cual es el usuario actualmente conectado, insertando los “waypoint” seleccionados.
Para que un waypoint este guardado en la base de datos, hay que insertar los valores
del punto GPS en si mismo y después enlazarlo con el “waypoint”. Si se omite
cualquiera de los dos pasos , el “waypoint” no se grabará correctamente.
El diagrama de secuencia de introducir “waypoint” se muestra en la Figura 22.
47
Interface GPS Session Waypoint Punto GPS

: Usuario
Introducir waypoints
download_wayp
*Seleccionar wayp
Insertar en BD
Comprobar
[Id Usuario]
*Grabar
Grabar
Figura 22- Diagrama de secuencia del caso de uso introducir “waypoints”
48
4.1.4.5. DIAGRAMA DE SECUENCIA INTRODUCIR RUTAS
El caso de uso comienza cuando el usuario determina que desea transferir todos los
puntos almacenados en su receptor a la computadora. El caso de uso termina en el
momento que el último punto de la ultima ruta es transferido con éxito y ha sido
grabado en la BD.
Cuando el usuario decide introducir en la BD la totalidad o bien parte de las rutas
almacenadas en el receptor, la interfaz hace la llamada al objeto GPS requiriendole el
envío de todos los puntos de las rutas. Cuando el control vuelve al usuario, las rutas
han sido separadas y se muestra al usuario únicamente el punto inicial y el punto
final de la ruta en cuestión.
Cuando el usuario determina las rutas a insertar, se comprueba en primera instancia

el usuario conectado con la aplicación, después se almacenan los datos de la ruta, y
por último se almacenan todos los puntos que forman parte de la ruta uno por uno. Si
alguno de estos puntos no se pudiese almacenar por cualquier circunstancia, el
sistema volvería a la situación en la que se encontraba antes de haber grabado los
datos de la ruta.
El diagrama de secuencia de introducir “waypoint” se muestra en la Figura 23
49
Interface GPS Session Rutas Punto GPS

: Usuario
Introducir rutas
download_tracks
*Seleccionar rutas
Insertar en BD
Comprobar
[Id Usuario]
*Grabar
*Grabar
Figura 23- Diagrama de secuencia del caso de uso introducir rutas
50
4.1.4.6. DIAGRAMA DE SECUENCIA VER WAYPOINTS COMUNES

El caso de uso comienza cuando el usuario requiere visualizar todos los “waypoints”
almacenados en la BD. El caso de uso termina cuando el usuario visualiza los datos.
Cuando se inicia el caso de uso, la interfaz muestra los datos de cada uno de los
“waypoints” que se encuentren en la base de datos, así como los datos del punto
asociado con cada “waypoint”.
De forma opcional, el usuario puede requerir visualizar otros datos, lo cual haría que
se mostrasen, los datos de el “waypoint” seleccionado, los datos del punto asociado,
los datos de los ficheros asociados al “waypoint” seleccionado y los datos del usuario
que grabo el “waypoint” en nuestra BD.
El diagrama de secuencia se muestra en la Figura 24
4.1.4.7. DIAGRAMA DE SECUENCIA VER WAYPOINTS PROPIOS

El caso de uso comienza cuando el usuario requiere visualizar únicamente los
“waypoints” que ha almacenado él en la BD. El caso de uso termina cuando el
usuario visualiza los datos.
Cuando se inicia el caso de uso, la interfaz muestra los datos de cada uno de los
“waypoints” que son “propiedad” del usuario actual, así como los datos del punto
asociado con cada “waypoint”.
De forma opcional, el usuario puede requerir visualizar más datos, lo cual haría que
se mostrasen, los datos de el “waypoint” seleccionado, comprobándose previamente
el usuario actual, los datos del punto asociado y los datos de los ficheros asociados
al “waypoint”.
51
Interface Usuario Waypoint Punto GPS Fichero

: Usuario
Ver Waypoint
*Mostrar_Waypoints
Datos_punto
[opcional] mas datos

Mostrar_waypoints
Datos_punto
Ficheros_waypoint
Mostrar datos
Figura 24- Diagrama de secuencia del caso de uso ver “waypoints” comunes
52
Interface Session Usuario Waypoint Punto GPS Fichero

: Usuario
Ver Waypoint
Comprobar
[id usuario]
Mostrar datos
*Mostrar_Waypoints_usuario
Datos_punto
[opcional] mas datos

Comprobar
[id usuario]
Mostrar datos
Mostrar_waypoints_usuario
Datos_punto
Ficheros_waypoint
Figura 25- Diagrama de secuencia del caso de uso ver “waypoints” propios
53
4.1.4.8. DIAGRAMA DE SECUENCIA VER RUTAS COMÚNES
El caso de uso comienza cuando el usuario requiere visualizar todas las rutas
almacenadas en la BD
Cuando el usuario determina que quiere ver las rutas, el objeto rutas recoge los
puntos de inicio y fin de cada ruta, los datos del “propietario” y los muestra en la
interfaz.
Opcionalmente el usuario puede visualizar en 2D y 3D la ruta seleccionada.
4.1.4.9. DIAGRAMA DE SECUENCIA VER RUTAS PROPIAS
El caso de uso comienza cuando el usuario requiere visualizar todas sus rutas
almacenadas en la BD.
Cuando el usuario determina que quiere ver las rutas, lo primero que se hace es
comprobar el usuario activo y luego se recogen los datos de las rutas.
Opcionalmente el usuario puede visualizar en 2D y 3D la ruta seleccionada.

El diagrama de secuencia se muestra en la Figura 27.
54
Interface Usuario Rutas Punto GPS Imagen 3D Imagen 2D

: Usuario
Ver rutas
Mostrar rutas
Datos inicio-fin
Mostrar datos
[opcion] Ver 2D y 3D
Crear
Crear Latitud-Longitud
Crear Altura
Figura 26- Diagrama de secuencia del caso de uso ver rutas comunes
55
Interface Session Usuario Rutas Punto GPS Imagen 3D Imagen 2D

: Usuario
Ver rutas
Comprobar
[id usuario]
Mostrar datos
*Mostrar rutas usuario

Datos inicio-fin
[opcion] Ver 2D y 3D
Crear
Mostrar
Crear Latitud-Longitud
Mostrar
Crear Altura
Mostrar
Figura 27- Diagrama de secuencia del caso de uso ver rutas propias
56
4.1.4.10. DIAGRAMA DE SECUENCIA DEL CASO DE USO MODIFICAR

WAYPOINT
El caso de uso comienza cuando el usuario necesita modificar o ampliar los datos
asociados a un “waypoint”, como por ejemplo añadir un fichero o darlo de baja.
Cuando se requiere modificar datos, se nos muestran los datos del “waypoint” (caso
de uso ver “waypoint”), y se nos proporciona la posibilidad de modificar los datos o
bien añadir ficheros asociados al “waypoint”. Si se decide modificar, los valores
actuales se graban en el objeto “waypoints” y se devuelve el control al usuario.
Interface Waypoints Fichero

: Usuario
Modificar
[opcional] modificar datos

Modificar
[opcional] modificar ficheros

añadir
Figura 28- Diagrama de secuencia del caso de modificar “waypoint”
57
4.1.5. DIAGRAMA DE TRANSICIÓN DE ESTADOS

Un estado describe un período de tiempo durante la vida de un objeto de una clase.
Puede ser caracterizado de tres maneras complementarias: como conjunto de valores
del objeto cualitativamente similares ; como período de tiempo, durante el cual un
objeto espera que ocurra un evento; o como período de tiempo durante el cual realiza
una determinada actividad.
Una transición conecta siempre dos estados. Cuando un objeto está en un estado, es
sensible a los eventos correspondientes a las transiciones que salen del mismo.
Una transición que deja un estado define la respuesta de un objeto en ese estado a la
ocurrencia de un evento. En general, la transición tiene un evento que la activa, una
condición de guarda, una acción y un estado destino.
4.1.5.1. DIAGRAMA DE TRANSICIÓN DE ESTADOS DEL OBJETO GPS
Se definen cuatro estados para el objeto GPS, apagado, esperando por datos,
recibiendo datos o transmitiendo datos.
El estado transmitiendo datos comprende a todas las situaciones en las que el objeto
está transmitiendo, siendo estas, transmitiendo el tipo de receptor, transmitiendo la
hora, transmitiendo la lista de “waypoints” y transmitiendo la lista de puntos GPS.
Del estado transmitiendo puede pasar a si mismo únicamente si está transmitiendo

los datos de los “waypoints” o de los puntos, o bien si existen peticiones en cola.
58
Encendido
Esperando
Apagado
Recibiendo Transmitendo
Figura 29- Diagrama de transición de estados del objeto GPS
4.2. BASE DE DATOS DEL SISTEMA

Tras el estudio completo del dominio de la aplicación (apartado 2) se obtiene la
estructura lógica de la BD mostrada en la Figura 30 y la estructura física, mostrada
en la Figura 31. En este desarrollo se ha utilizado el modelo entidad-relacion (en
adelate E-R) y el modelo relacional
La nomenglatura de las tablas está orientada a facilitar la gestion del catálogo de la
BD. Las tablas resultantes son las siguientes:
DB01TB01
Tabla con los usuarios de la aplicación.
• db010010 (Entero) Identificador del usuario.
• db010020 (Char(50)) Nombre del usuario.
• db010030 (Char(50)) Apellidos del usuario
• db010040 (Entero) Número de accesos de los usuarios.
• db010050 (Char(50)) Contraseña del usuario.
59
DB02TB01
Tabla de las rutas almacenadas en la aplicación.
• db020010 (Entero) Identificador de la ruta.
• db020020 (dd/mm/aaaa) Fecha de toma de la ruta.
• db020030 (Char(50)) Nombre de la ruta.
• db020040 (Entero) Identificador del usuario que grabó la
ruta en la DB. (Clave foránea)
DB03TB01
Tabla de relación entre las rutas y los puntos que la componen.
• db030010 (Entero) Número de secuencia del punto dentro
de la ruta.
• db030020 (Entero) Identificador de la ruta. Clave foránea
• db030030 (Real) Latitud del punto GPS. Clave foránea
• db030040 (Real) Longitud del punto GPS. (Clave
foránea)
DB04TB01
Tabla con los puntos GPS.
• db040010 (Real) Latitud del punto GPS.
• db040020 (Real) Longitud del punto GPS.
• db040030 (Real) Altura del punto GPS.
• db040040 (Entero) Color del punto GPS.
• db040050 (dd/mm/aaaa hh:mm:ss) Hora en la que se tomo el punto.
• db040060 (Real) Profundidad del punto GPS. Es cero si
el punto GPS se encuentra por encima
del nivel del mar.
60
DB05TB01
Tabla con los datos de los “waypoints”
• db050010 (Entero) Identificador de “waypoint”
• db050020 (Char(100)) Comentario del “waypoint”.
• db050030 (Real) Latitud del punto GPS. Clave foránea
• db050040 (Real) Longitud del punto GPS. (Clave
foránea)
• db050050 (Real) Identificador del usuario que grabo el
“waypoint”. (Clave foránea)
• db050060 (Entero) Símbolo del “waypoint”.
• db050070 (char(50)) Nombre del “waypoint”.
DB10TB01
Tabla con los ficheros asociados a cada “waypoint”.
• db100010 (Entero) Identificador de “waypoint”. (Clave
foránea)
• db100020 (Char(100)) Nombre real del fichero.
• db100030 (Entero) Número secuencial.
• db100040 (Entero) Identificador del usuario que grabo el
fichero.
61
Figura 30- Representación lógica de la Base de Datos
62
Figura 31- Representación física de la Base de Datos
63
4.3. LENGUAJES Y HERRAMIENTAS
4.3.1. LENGUAJE HTML
El HTML (Hyper Text Markup Language) es un lenguaje para estructurar

documentos. Estos documentos normalmente se visualizan en los navegadores Web,
como “Netscape”, “Mosaic” o “Microsoft Explorer”. Por el momento no existe un
estándar de HTML ya que tanto “Netscape” como “Microsoft” se empeñan en incluir
directivas que solo funcionan con sus respectivos navegadores. De cualquier manera
existen diferentes revisiones o niveles de estandarización, el 1.0, el 2.0 y el 3.0, lo
que produce que algunos visores no "comprendan" en su totalidad el contenido de un
documento.
El HTML consta de una serie de órdenes o directivas, que indican al navegador la

forma de representar los elementos (texto, gráficos, etc...) que contenga el
documento
Un documento escrito en HTML contendría básicamente las siguientes directiva :
<HTML> Indica el inicio del documento

<HEAD> Inicio de la cabecera
<TITLE> Inicio del título del documento
</TITLE> Final del título del documento
</HEAD> Final de la cabecera del documento
<BODY> Inicio del cuerpo del documento
</BODY> Final del cuerpo del documento
</HTML> Final del documento
64
4.3.2. VBSCRIPT
Ya que el HTML puro no contiene ningún “tipo de dinamismo”, es necesario

complementar el uso de páginas HTML con algun lenguaje de tipo “Script”.
Como tanto el Visual Basic Script ( en adelante VBScript) y Java Script ( en adelante
JScript) son lenguajes de “script” totalmente válidos, y, en a ciertos niveles, casi
parejos, se decidió utilizar el VBScript, para proporcionar un aspecto de globalidad a
la aplicación. Por lo tanto, los componentes de comunicación, el gestor de BD e
incluso la tecnología aplicada al proyecto es propiedad de Microsoft. Por lo tanto es
una buena pauta a seguir el unificar todos los herramientas utilizadas bajo este tipo
de plataformas.
El VBScript es un lenguaje de “script”, directamente derivado de Visual Basic. Los

lenguajes de script son versiones de otros lenguajes. Estas versiones se utilizan para
su integración en páginas web. Un código escrito en un lenguaje de “script” se
incorpora directamente dentro de un código HTML y se ejecuta interpretado, no
compilado. Para incorporar un fragmento de código “script” en una página HTML se
introduce el “script” entre los tags <SCRIPT> y <SCRIPT> . Se distinguen dos
lenguajes de “script” en la actualidad: el VBScript (derivado de Visual Basic) y el
JScript (derivado de Java).
Se dice que los lenguajes de “script” se ejecutan interpretados, no compilados, ya que

un código escrito en un lenguaje de “script” no sufre ninguna transformación previa a
su ejecución. Cada línea de código se traduce al lenguaje máquina justo antes de su
ejecución. Posteriormente se ejecuta y la traducción no se conserva en ningún
sistema de almacenamiento (como discos, cintas, etc). Si es necesaria otra ejecución,
el intérprete se verá abocado a realizar una nueva traducción de cada línea de código.
65
Con la finalidad de adaptar el Visual Basic a su ejecución sobre web, fue necesario
restringir algunas de sus instrucciones:
• No existen tipos de datos, el VBScript utiliza únicamente el tipo de datos
Variant para almacenar la información.
• No existen las constantes. Normalmente se emulan las constantes mediante el uso
de variables. Para distinguir entre una variable y una constante se utilizan normas
de programación, por ejemplo, escribir las constantes completamente en
mayúsculas y las variables utilizando mayúsculas para la primera letra de cada
palabra dentro del nombre de la variable.
• No acepta caracteres que no se encuentren en código ASCII.
• No permite instanciar objetos. Por el contrario, el propio “script” ofrece una
colección de objetos, entre los que destacan los objetos siguientes:
• Window : Representa la ventana activa del navegador y es el mas alto de la
jerarquía.
• Document : Representa el documento activo.
• Form : Este objeto se refiere a un formulario empleado en el documento.
• Location : Contiene la URL de la página actual
• Navigator : Representa al navegador actual.
• History : Representa el historial de las páginas visitadas en la sesión actual.
• No permite acceder al portapapeles.

• No permite el uso de colecciones.
• No puede usar las instrucciones condicionales DoEvents,
Gosub…Return, Goto, On Error GoTo, On…Gosub, On...Goto,
Números de línea, etiquetas o With…End.
• No permite declarar llamadas a las librerias del sistema.
• No tiene acceso al sistema de ficheros.
• No existen métodos ni funciones graficas.
66
4.3.3. LENGUAJE ASP

Cuando se incluye dentro de una página HTML código en “script”, es cierto que se le
proporciona cierto nivel de dinamismo aunque con la potencia que ofrece el
VBScript, las páginas son estáticas, es decir, siempre es la misma página la que
muestra los mismos datos en el mismo orden. Si se quiere obtener una aplicación
sobre web, con acceso a datos, o con una lógica más o menos complicada, se necesita
incorporar una interfaz común de salida, en inglés Common Gateway Interfaz (en lo
sucesivo CGI) o de una tecnología como la de paginas activas en el servidor, en
inglés Active Server Pages ( a partir de ahora ASP).
Tal y como se ha comentado, el sistema englobara toda la aplicación sobre el entorno
Microsoft, con lo que las opciones quedan reducidas a utilizar CGI con Visual Basic
o bien paginas ASP. El hecho de que los CGI sean compilados y se tenga que
recompilar con cada modificación, apunta a la idoneidad de desarrollar el código
servidor en ASP.
Agrupadas en la categoría de lenguajes de “script”, las páginas ASP contienen

además de los “tags” habituales de HTML, fragmentos de código que el servidor
resolverá previamente a su envío al navegador.
La facilidad para conectar las páginas ASP con BD y, extraer y mostrar los datos de
la misma en el navegado de una forma dinámica, es la razón principal de su extenso
uso en Internet. Mediante los “drivers” de conexión a datos, “Open Data Base
Conectivity” (a partir de ahora ODBC), las páginas ASP se pueden conectar con BD
SQL, Access, Oracle, o cualquier otro gestor de bases de datos que disponga del
“driver” adecuado.
Para poder procesar una página ASP no existe ninguna restricción especial en el lado
cliente de la comunicación, ya que el navegador únicamente recibe páginas HTML,
por tanto se pude utilizar cualquier navegador existente (Internet Explorer o
Netscape Comunicator). Sin embargo el servidor de páginas ASP requiere tener
67
instalado la librería ASP.dll para poder interpretar el código ASP de las páginas. En
la actualidad unicamente los servidores de web Internet Information Server 3.0 o
superior, y el Personal Web Server ambos de Microsoft contienen el “software”
necesario para proporcionar servicio ASP. En el caso de plataformas Unix existen
servidores que añadiéndoles “software” adicional pueden procesar páginas ASP,
como por ejemplo el servidor “web Chilisoft”, el “Instant ASP” o bien el “Apache”,
aunque éste último sólo soporta ASP codificado bajo “Perl”.
Para que el interprete ASP reconozca código ASP, éste tiene que estar enmarcado
por los tags “<%” en el inicio, y “%>” al final del código..
<% Response.write (“Esto es una línea de código ASP”) %>
Además de los códigos HTML habituales una página ASP puede contener código
“script” con el fin de añadir dinamismo a las páginas finales. Este código “script”
puede estar escrito tanto en Vbscript como en JScript.
En una página ASP se puede declarar dentro del código propio de ASP variables con
el fin de mejorar la legibilidad del código. En ASP todas las variables son de tipo
Variant, por lo cual lo único que se tiene que hacer es determinar el nombre y
dimensionarlo:
<%
dim saludo
saludo = “Hola, buenos días”
%>
Al igual que en Visual Basic, no es necesario declarar todas las variables, pero es una
buena práctica. Para asegurar que todas las variables que se usen tengan que estar
declaradas se puede incluir la instrucción “Option Explicit” dentro del código
ASP y así, de esta forma, se nos avisará de las variables no declaradas con un error.
68
<%
Option explicit
dim saludo
saludo = “Hola, buenos días”
%>
Los objetos ASP son programas compilados e instalados en el servidor que han sido
programados para realizar un conjunto de operaciones fácilmente accesibles por las
páginas. Estas operaciones se denominan métodos.
Las páginas ASP proporcionar un modelo de objetos que facilita el uso del lenguaje
ASP. Estos objetos son:
Objeto Application
El objeto Application se utiliza con la finalidad de compartir y mantener información

entre los usuarios de una aplicación dada. Las variables almacenadas dentro del
objeto Application son visibles para todos los usuarios que están utilizando la misma
aplicación ASP. Para evitar que unos usuarios modifiquen los valores que
previamente han sido grabados por otros, el objeto Application posee la capacidad de
bloquear (Lock) o desbloquear (Unlock) una variable.
Nombre Descripción
Se ejecuta al terminar la
Eventos Application_OnEnd
ejecución del servidor web
Se ejecuta cuando entra por
Application_OnStart primera vez un usuario en la
aplicación web
Bloquea el objeto application
Métodos Lock para todos los usuarios excepto
el que ejecuta el método Lock
69
Unlock Desbloquea el objeto

Elimina un ítem especifico de
Contents.Remove
la colección Contents
Elimina todos los ítems de la
Contents.RemoveAll
colección Contents
Contiene los ítem añadidos al
Colecciones StaticObjects objeto Application mediante el
tag < OBJECT >
Contiene todos los ítems
Contents
añadidos al objeto Application
Tabla 13-Objeto Application
Objeto ASPError
El objeto ASPError sirve para obtener información detallada de una condición de

error producida durante la ejecución de la aplicación. Esta información se obtiene de
9 propiedades de sólo lectura, a las que solamente es posible acceder a través del
objeto Server y su método GetLastError
Nombre Descripción
Propiedades ASPcode Código de error
Descripción del código de
ASPDescription
error
Cadena que indica si se trata
de un error interno de ASP, del
Category
lenguaje de secuencia de
comandos o de un objeto
70
Entero que indica la posición

Column de la columna del archivo ASP
que generó el error.
Description Descripción del error
Cadena que contiene el
nombre del archivo ASP que
File
se estaba procesando cuando
se produjo el error.
Line Línea donde se genero el error
Entero que representa un
Number código de error estándar de
COM.
Cadena que contiene el código
Source fuente real, si está disponible y
la línea que causó el error.
Tabla 14- Objeto ASPError
Objeto Session
Cuando un usuario invoca por primera vez cualquiera de los ficheros de una
aplicación se le asigna un objeto Session. Este objeto será utilizado por la aplicación
para almacenar, compartir y recibir información del usuario. Por defecto, el objeto
será destruido después de 20 minutos de inactividad, aunque puede configurarse un
tiempo diferente, siendo una buena idea reducirlo si el servidor tiene una carga
elevada, a fin de que libere los recursos asignados al usuario cuanto antes.
Nombre Descripción
Propiedades CodePage El código de caracteres usado
Identificador de zona para
LCID
definir los formatos de fecha,
71
hora, decimales, etc.

SessionId Identificador de la sesión
Tiempo de inactividad para
Timeout
destruir la sesión
Ocurre justo antes de crear el
Eventos Session_Onstart
objeto Session
Se ejecuta cuando se elimina
Session_OnEnd
la sesión
Métodos Abandon Dar por terminada la sesión
Elimina un ítem especifico de
Contents.Remove
la colección Contents
Elimina todos los ítems de la
Contents.RemoveAll
colección Contents
Ítems añadidos al objeto
Colecciones Contents
Session
Contiene los ítem añadidos al
StaticObjects objeto Session mediante el tag
< OBJECT >
Tabla 15- Objeto Session
Objeto Request
El objeto Request permite el acceso a toda la información transmitida desde el

navegador del cliente y el servidor. Esta información se reparte y almacena entre
cinco colecciones. Los datos, una vez cargados, pueden ser accedidos
individualmente en cada colección a través de una única clave asignada a cada ítem.
72
Nombre Descripción
Número total de bytes
enviados por el cliente al
Propiedades TotalBytes
servidor en el cuerpo de la
llamada http
Datos que han sido enviados al
servidor desde el cliente a
Métodos BinaryRead (count) partir de un formulario. El
parámetro count indica el
numero de bytes a leer.
Esta colección tiene utilidad si
estamos escribiendo una
Colecciones ClientCertificate aplicación que utiliza el
protocolo Secure Socket
Layers (SSL)
La colección Cookies asigna
datos a un fichero existente, y
Cookies si éste no existe, crea uno
nuevo donde almacena estos
datos
Elementos de un formulario
usando el método post, donde
Elemento es el nombre del
Form(“Elemento”)
elemento del formulario que se
quiere recibir desde el
navegador
QueryString Los elementos del formulario
(“Elemento”) usando el método get
Esta colección contiene el
ServerVariables valor de las variables de
entorno del servidor
Tabla 16- Objeto Request
73
Objeto Response
Response (respuesta) es posiblemente el objeto más utilizado de todos, ya que sirve

para presentar en la pantalla del navegador del cliente el resultado de cualquier
código.
Nombre Descripción
Indica si la página HTML se
enviara una vez acabado la
Propiedades Buffer
traducción ASP o bien se
enviará a la vez que se traduce.
Esta propiedad permite a los
servidores “proxy” guardar en
CacheControl
su cache una copia de la
respuesta ASP
Define la tabla de caracteres a
Charset usar durante la codificación de
la página.
Esta propiedad especifica el
ContentType tipo de contenido del request
HTTP
Indica el número de minutos
que deben transcurrir antes de
Expires que la copia de la respuesta en
las caches del navegador sea
eliminada.
Igual que la anterior pero
ExpiresAbsolute define una fecha y horas
exactas para ser eliminada
Con esta propiedad se puede
saber si el cliente continua
IsClientConnected conectado al servidor desde la
última vez que la aplicación
escribió algo en la pantalla
Status valor de la línea de estado
HTTP devuelta por el servidor.
Asigna los valores a los
Colecciones Cookies ficheros temporales del
navegador ( cookies )
Este método permite añadir
Métodos AddHeader una nueva cabecera a la
respuesta http
74
Añadir un “string” al registro

AppendToLog que se genera con cada request
en el fichero de logs del IIS.
Escribe la salida HTTP en
BinaryWrite
binario
Elimina cualquier contenido
Clear
del “buffer” de salida
Detiene el proceso de la página
ASP actual y envía al cliente el
End
contenido del “buffer” de
salida
Provoca el envío inmediato al
Flush cliente del contenido del
“buffer” de salida.
Detiene el proceso de las
instrucciones de la página
Redirect
actual e intenta conectar el
cliente a una nueva dirección
Escribe los datos en el “buffer”
Write
de salida
Tabla 17- Objeto Request
Objeto Server
Este objeto proporciona acceso a distintas funciones de utilidad para el programador

de aplicaciones, todas ellas orientadas a ejecutarse en el servidor.
Nombre Descripcion
tiempo, medido en segundos,
Propiedades ScriptTimeOut
disponible por una página o
“script” para ejecutarse.
Crea instancias de los objetos
Métodos CreateObject
en el servidor
Permite llamar desde una
Execute
página ASP a otra página ASP
Devuelve el último error de
GetLastError
una página ASP
75
Convierte una cadena de

HTMLEncode caracteres HTML a código
visible
Traza un mapa de rutas físicas
MapPath (absolutas) partiendo de rutas
virtuales (relativas)
Permite llamar desde una
página ASP a otra página ASP.
Cuando la página llamada
Transfer
concluye su proceso, el control
no vuelve a la página inicial, y
concluye en la página llamada.
Convierte un “string” que
contiene una dirección URL en
URLEncode
formato ASCII a formato
URL-encoded.
Tabla 18- Objeto server
4.3.4. IIS (INTERNET INFORMATION SERVER )
Ya que toda la aplicación estará soportada por entornos Microsoft, el servidor de web
tendrá que ser o bien “Personal Web Server” (a partir de ahora PWS) de NT 4.0 o
bien el IIS de Microsoft Windows 2000 y posteriores. La razón para utilizar el IIS es
su capacidad para soportar lenguaje ASP, tal y como acabamos de comentar,
unicamente los servidores de Web propios de Microsoft tienen incluido entre su
código fuente el “software” necesario para tratar ASP.
Los problemas principales tanto del IIS como del PWS es su falta de seguridad frente
a virus (tipo “RedCode” o “Nimda”) y ante ataques de “hackers” informáticos. De
todas formas se trabaja para corregir estos problemas. En la pagina oficial de
Microsoft [MICR-02] existen diversos “parches” y consejos para minimizar los
riesgos.
76
El IIS 5.0 es el servidor de web propuesto por Microsoft incluido en el servidor

Windows 2000, que se instala de forma automática por defecto. Esta versión mejora
la confiabilidad, administración, seguridad y los servicios de aplicación.
En el IIS 4.0 de Windows NT se introdujo DCOM “Distributed Component Object

Modules” y MTS (Microsoft Transaction Service). El MTS permite el desarrollo de
aplicaciones que realizan transacciones que usan componentes COM y BD. En
Windows 2000 las tecnologías DCOM & MTS han sido fusionadas en el sistema
denominado COM+.
El IIS 5 incluye soporte para los últimos estándares usados en Internet. Implementa
el protocolo HTTP 1.1, compresión HTTP, SSL 3.0, CGI, y el servicio WebDAV que
permite la gestión remota del contenido de un directorio en un servidor web.
4.3.5. DNA ( DISTRIBUTED INTERNET APLICATIONS )
DNA propone un modelo para el desarrollo de aplicaciones para el Sistema

Operativo Windows. Este modelo especifica, entre otras, como:
• Desarrollar aplicaciones robustas, escalables y distribuidas utilizando la

plataforma Windows.
• Facilitar la extensión de datos existentes y aplicaciones externas a Internet
• Soportar un amplio rango de dispositivos cliente
Una aplicación de tres capas es aquella cuya funcionalidad se pueden dividir en tres
capas lógicas:
• Capa de presentación.
• Capa de aplicación.
• Capa de datos.
77
Un aspecto muy importante de la capa de aplicación es la capacidad de utilizar los

mismos componentes en varias aplicaciones. Es decir, los componentes son
reutilizables. Además es posible que los componentes presten servicio a los de su
mismo nivel, ademas de a los niveles adyacentes. Esto es muy importante, ya que se
debe de tener en cuenta que la capa de aplicación es una estructura lógica y los
componentes se comunican entre sí de la misma manera, estén o no en el mismo
nivel.
Las peticiones de servicios no pueden "saltar" niveles; es decir, los componentes de

la capa de presentación no se pueden comunicar directamente con los de la capa de
datos y viceversa
Capa de presentación
Los componentes de la capa de presentación proporcionan la interfaz visual que los

clientes utilizarán para visualizar la información y los datos.
En este nivel, los componentes son responsables de solicitar y recibir servicios de

otros componentes de la misma capa o de la capa de negocios.
Es muy importante destacar que, a pesar de que los componentes residen en este
nivel, uno de los servicios que proporcionan al usuario es la capacidad de ejecutar
funciones de aplicación.Aunque la lógica de aplicación se encapsula en componentes
la capa de aplicación, los componentes de la capa de presentación permiten al
usuario tener acceso a todos los procesos.
Los servicios de usuario normalmente están contenidos en la aplicación cliente

aunque no siempre es así. Por ejemplo, si se quiere implementar un conjunto estándar
de mensajes de error, aunque sin distribuirlo a todas las máquinas, lo ideal sería crear
esta capa de presentación como un ActiveX para situarlo en un servidor.
78
Capa de Aplicación o Negocios
Como la capa de presentación no pueden contactar directamente con la capa de

datos, es responsabilidad de los componentes de los servicios de negocio hacer de
puente entre ellos. Los objetos de negocio proporcionan servicios de negocio que
completan las tareas de negocio tales como verificar los datos enviados por el cliente.
Antes de llevar a cabo las funciones de aplicación para llamar a procedimientos

almacenados en la BD, los componentes de aplicación implementan dichos
procedimientos y definen los papeles de negocio.
Los componentes de la capa de aplicación también nos sirven para evitar que el
usuario tenga acceso directo a la Base de Datos. Las tareas de negocio que ejecutan
estos componentes, como escribir registros, imprimir listados, etc. quedan definidas
por los requisitos de la aplicación. Por lo tanto, una buena razón para dividir la lógica
de aplicación en componentes, es la probabilidad de que dicha lógica cambie,
teniendo que rescribir el código de la aplicación. De este modo, se rescribe
únicamente el componente correspondiente a la lógica de negocio afectada.
Un aspecto muy importante de la capa de negocios es la posibilidad de que los

componentes presten servicio a los componentes de su mismo nivel y no solo a los de
los niveles adyacentes. Esto es muy importante, ya que hay que tener en cuenta que
la capa de aplicación es una estructura lógica y los componentes se comunican entre
sí de la misma manera, estén o no en el mismo nivel.
Las peticiones de servicios no pueden "saltar" niveles: es decir, los componentes de

la capa de presentación no se pueden comunicar directamente con los de la capa de
datos, y viceversa
79
Capa de datos
La capa de datos incluye las típicas tareas de gestión de datos: altas, bajas,
modificaciones, etc. La clave está en que las funciones de aplicación no se
implementen aquí. Aunque un componente de la capa de datos es responsable de la
gestión de las peticiones realizadas por un objeto de aplicación, no lo es de
implementar los papeles de negocio.
Estos servicios pueden ser implementados como objetos en un Sistema Gestor de

Bases de Datos (SGBD) como procedimientos almacenados. Además, pueden
proporcionar acceso a datos en varias plataformas sobre cualquier número de
servidores. Una capa de datos apropiadamente implementado, debería permitir
cambiar su localización sin afectar a los servicios proporcionados por los
componentes de negocio.
4.3.6. ACTIVEX / COM
Una vez definidos los entornos y la metodología de trabajo será necesario estudiar el
modo de trabajo del usuario final. El usuario necesitará que la aplicación se conecte
con el receptor GPS con la finalidad de realizar la transferencia de datos. El
problema con el cual nos encontramos es que mediante los métodos descritos hasta el
momento, HTML, VBScript, ASP, es imposible acceder al equipo cliente. Esta
limitación, integrada en el propio HTML y en el navegador, está concebida para
proteger el equipo cliente de ciertas actividades de los usuario de la red. Para
solventar este problema existen varias soluciones, definir la comunicación sobre un
plugin para el navegador, o crear un componente OCX que se comunique con el
receptor GPS desde el propio navegador. La primera de las soluciones es quizá la
más elegante, pero requerirá que el usuario final instale el plugin en su maquina
después de cada modificación, característica poco deseada. Crear un componente
OCX e incluirlo en las páginas, provoca una cierta lentitud al cargar las páginas, ya
80
que a priori se carga y se instala en el sistema con cada acceso. El sistema ActiveX
de Microsoft evita esto último e incluso proporciona la ventaja de controlar la
versión de los componentes que en caso de no tener la versión adecuada, reinstala el
OCX sin necesidad de ninguna acción por parte del usuario, excepto la de dar su
autorización.
Los antecedentes de la tecnología ActiveX se remontan a la tecnología Object

Linking and Embedding (OLE versión 1.0 y 2.0), que se puede traducir por Objetos
Vinculados e Incrustados. Nació a partir de lo que se denominaba DDE, Dynamic
Data Exchange o Intercambio dinámico de Datos, la cual se implemento en
aplicaciones de Microsoft.
La idea básica de todas estas tecnologías es diseñar aplicaciones que puedan
intercambiar datos y compartir código, de forma que sean accesibles entre ellas. En
concreto los controles OLE actúan en forma de pequeños módulos de aplicaciones,
diseñados para ser incluidos por los programadores en aplicaciones finales.
La tecnología subyacente en ActiveX basada en OLE y COM (Component Object

Model), aunque se trata de una herramienta de programación general, fue
desarrollada con vistas a implementar páginas iNet (Internet e Intranets) más
interactivas y en las que se pudiera emplear diversos lenguajes de (Java, Visual
Basic, Visual C++, Borland C++, Delphi, etc.)
ActiveX, consta de dos partes diferenciadas: el servidor y los clientes. La plataforma

servidora debe contener los controles ActiveX o la referencia de su ubicación. En el
caso de no estar ya en la plataforma cliente se deberá transferir a ésta, registrarlos en
su sistema y ejecutar el código asociado.
Las características de trabajo de los ActiveX se centran en:
81
• Los módulos tienen unas características de autonomía propia. Por tanto, debe ser
código binario (compilado) que sea capaz de definir cuando iniciar y cuando
terminar su ejecución.
• El código generado ha de tener la capacidad de interactuar con otros módulos
ActiveX y, o, ejecutables finales. En las bases del estándar OLE, se definen dos
niveles: servidor y cliente. Un servidor es aquel que recibe peticiones de los
clientes, ejecuta las operaciones pertinentes y devuelve datos procesados. Un
cliente puede acceder a los datos de un a aplicación servidora y gestionar su
información como si de datos propios se tratara.
• La actualización del código de un control ActiveX no debe suponer una
reprogramación de las aplicaciones clientes (aquellas que lo utilicen).
Hay que tener en cuenta que en estos momentos, unicamente pueden visualizarse
páginas con controles ActiveX mediante “Microsoft Internet Explorer 3.x” o
superior. Se deberá esperar a las próximas versiones del navegador de “Netscape”
para poder utilizarlo con dichos controles. Alternativamente, se puede usar el
“plugin” de la empresa NCompass Labs Inc., que permite usar controles ActiveX
desde “Navigator”.
La estructura del tag de inserción de objetos ActiveX en el codigo HTML, en
la forma <OBJECT..> ....... </OBJECT>, es:
<OBJECT ID=......
CLASSID=...
CODEBASE=...
ALIGN=...
BORDER=...
WIDTH=...
HEIGHT=...
<PARAM NAME=... VALUE=...>
...
</OBJECT>
82
donde:
Campo Descripción
Un identificador único que sirve para referenciar los
ID parámetros y acceder a los valores de propiedades,
cuando se trabaje con código “script”, “Java” u otros
Contiene la clave del control ActiveX que ha de
ClassID
registrarse en la computadora cliente.
Indica, en forma de una cadena URL, en que lugar se
encuentra el control ActiveX. Si no se especifica nada,
Codebase
se supone que se encuentra en el URL base del
documento.
Fija el ancho y le alto que ocupará el control ActiveX
Width y Height
en la página html.
Align Fija el modo de alinear el control en la página html.
Fija el tipo de borde que aparecerá en el contorno de
Border
Control Actives
Aquí se fijan las propiedades (properties)
Parámetros
características del control ActiveX.
Tabla 19- Características de un OCX sobre HTML
4.3.7. VRML
A mayores de las imágenes generadas por el OCX, la aplicación muestra los datos de
la ruta en un entornos tres dimensiones. Para la creación de esta representación se
estudiaron diversos productos, aunque el único viable resulto ser el VRML debido
principalmente a su sencillez, a lo rápido que se transmite y a que únicamente
requiere de un pequeño “plugin” para poder verse.
83
VRML son las siglas de “Virtual Reality Modeling Languaje”, es decir lenguaje de
modelado de realidad virtual. A diferencia del HTML, donde se marcan o etiqueta el
texto para formatearlo, en el VRML se diseñan objetos tridimensionales y su
comportamiento, lo cual requiere una mayor planificación desarrollo de las páginas.
Se entenderá por Realidad Virtual aquel espacio en tres dimensiones desarrollado y
simulado mediante computadora. En estos mundos virtuales el usuario podrá
adentrarse, eligiendo entre varias perspectivas, e interactuar con objetos del modelo.
Esta tecnología es cada vez más accesible para el usuario medio, debido a que los
equipos son cada vez más potentes.
La propuesta pública sobre la posibilidad de crear un lenguaje que permitiese recrear

mundos virtuales surge en la conferencia sobre web que se celebró en Ginebra en
mayo de 1994.
Ante el amplio apoyo recibido en dicha conferencia y junto a la ayuda ofrecido por la
publicación periodica revista Wired, se estableció una lista de correo con el objetivo
de conseguir una primera especificación del lenguaje.
La alternativa presentada por Silicon Graphics, basada en su producto

“OpenInventor”, fue la que consiguió un mayor numero de votos, convirtiéndose en
el punto de partida del nuevo estándar. Finalmente en octubre de 1994 se presentó la
especificación de VRML 1.0.
Posteriormente se fundó el “VRML Architecture Group” o grupo de aquitectura

VRML, también conocido como VAG. Este grupo tenía la misión de ayudar en la
clarificación e implementación de la especificación inicial del lenguaje. Con
posterioridad este organismo ha sido sustituido por el consorcio VRML, entre cuyos
miembros se encuentran Netscape,. Microsoft, IBM, Silicon Graphics.
84
A principios de 1996, Silicon Graphics pone a disposición del público “QvLib”, el

primer “parser” VRML capaz de traducir el texto de una escena virtual a un formato
entendible por el navegador. Posteriormente se desarrolló “WebSpace”, el primer
navegador capaz de leer e interpretar código estándar WRML.
VRML 1.0 es el lenguaje para la descripción de mundos virtuales estáticos, que

cumple tres requisitos fundamentales
• Es independiente de la plataforma donde se ejecute el navegador.
• Posee la capacidad para trabajar de un modo eficiente en conexiones lentas
• Permite nuevas ampliaciones en el lenguaje
Sin embargo se observó que los mundos estáticos no satisfacían todas las
necesidades para las cuales había sido creado
En la conferencia “Siggraph” de 1996, la propuesta “Moving Wolds”, Mundos en

movimiento, fue ratificada por el VAG como la especificación oficial del VRML 2.0.
Esta nueva versión incremente las prestaciones de su predecesor, destacando sobre
todo:
• Posibilidad de especificar comportamientos para los objetos, ya sea usando el
propio lenguaje VRML o mediante “Scripts” en lenguajes externos (Javescript,
VisualBasic Script, etc.)
• Posibilidad de interacción con el usuario mediante la definición de sensores de
posición, contacto, colisión, etc. La información registrada por estos sensores es
enviada a los diferentes objetos que componen el mundo virtual para en función
de los datos recibidos actuar en consecuencia.
• Posee efectos de fondo, sonidos en tres dimensiones, efectos de niebla, etc.
VRML 2.0 permite interactuar con el mundo virtual, sin embargo no es posible
interactuar con otros usuarios que estén accediendo a ese mismo mundo. Living
85
Worlds (Mundos vivientes) es la propuesta de Silicon Graphics que esta actualmente

estudiando el consorcio VRML para la nueva versión 3.0 del estándar VRML.
4.3.8. SISTEMA GESTOR DE BASES DE DATOS
Después de estudiar los sistemas más conocidos como “SQL server”, “Oracle”, se
aprecia que, para las necesidades reales de la aplicación, cualquiera de estos
productos era demasiado potente. Una vez determinadas estas necesidades se llego a
la conclusión de que un gestor de bases de datos de nivel medio, era suficiente, como
todo el proyecto se está basando en herramientas del entorno Microsoft, se establece
como idóneo el uso de Microsoft Access 2000, que sin llegar a ser un gestor de bases
de datos excesivamente potente, cumple las necesidades iniciales. Considerando la
necesidad de que en un futuro fuese necesario modificar el gesto de bases de datos
por otro más potente, se decidió realizar todos los accesos mediante ODBC a través
de una librería dll de acceso a datos. De esta forma en el caso de que fuese necesario
modificar el gestor de BD, únicamente habria que modificar el ODBC y la DLL de
acceso a datos.
5. ARQUITECTURA GENERAL DE SISTEMA

Atendiendo a los requisitos específicos de los usuarios, se ha realizado una clara
división del sistema en los siguientes módulos (Figura 32):
• Módulo de acceso a datos

• Módulo de comunicaciones
• Módulo de visualización
• Módulo de gestión de negocio
El módulo de acceso a datos es el encargado de atender las peticiones de información

de los restantes módulos. Esto es, rige toda la política de transferencia de datos entre
86
dichos módulos y la BD del sistema. En el apartado ¡Error! No se encuentra el

origen de la referencia. del presente documento se incluye un estudio completo y el
correspondiente diseño de la BD.
El módulo de comunicaciones incluye los componentes encargados de la
transferencia de información entre el receptor GPS el módulo de acceso a la BD del
sistema. De esta forma, se establece un flujo de datos entre los receptores GPS y la
propia BD.
El módulo de visualización es el encargado de crear y visualizar las rutas de
navegación. Este módulo incluye tanto las posibilidades de visualización en 2D y
3D. Señalar que es de vital importancia la visualización 3D ya que los GPS gestionan
puntos del espacio euclídeo.
El módulo de negocio es el encargado, a través del modulo de acceso a datos, de la
gestión propia de la aplicación (altas, bajas, modificaciones y consultas de la BD).
Servidor de Modulo
aplicación negocio
Modulo de
acceso a BD Modulo de
visualización
Modulo de
comunicación
CLIENTES
Figura 32- Módulos del sistema
La implementación especifica de los módulos contemplo el desarrollo de un conjunto

de componentes OCX y librerias externas, destacando los siguientes componentes:
87
• En el módulo de comunicaciones, los objetos GPS_GARMIN, y

CONTROL_FTP
• En el módulo de visualización, el objeto VISOR.
Para el desarrollo de la aplicación se han implementado tres componentes OCX, uno
para la comunicación con el receptor, otro para enviar los datos del equipo cliente al
equipo servidor, y un tercero para visualizar las rutas.
El conjunto de componentes OCX, librerias implementadas para el desarrollo de la
aplicación presentada, junto como la aplicación web, y un ejemplo de BD, se
adjuntan en el CD-ROM que acompaña a la memoria de este proyecto.
El componente OCX GPS_GARMIN es el encargado de comunicar el receptor GPS
con el servidor. En la Tabla 20 se definen los métodos y propiedades del objeto.
Nombre Descripción
Propiedad Puerto Identifica el puerto de donde se
recogen los datos
Estado Indica si se está transmitiendo.
Métodos Inicializa_gps(puerto) Inicializa la comunicación con el
receptor en el puerto indicado
Termina_gps(puerto) Cierra la comunicación en el
puerto indicado
Get_product_data(puerto) Recoge el modelo del receptor
GPS una vez iniciada la
comunicación.
Get_waypoint_data(puerto) Recoge todos los “waypoints”
del receptor.
Get_track_data Recoge todos los puntos GPS
almacenados en el receptor.
Tabla 20- Propiedades y métodos del OCX gps_garmin
88
Todas las funciones devuelven una cadena de caracteres con los datos en formato
XML, con lo que se consigue una cierta independencia de la implementación, y un
gran portabilidad a otros entornos.
En la aplicación, a parte de un servidor de web, se incluye un servidor de FTP para

poder transmitir ficheros desde las aplicaciones clientes hasta el servidor, y así poder
mostrarse a todos los usuarios de la aplicación. Para que el acceso al servidor de FTP
sea cómodo para el usuario se ha implementado un componente OCX para realizar
las labores de transferencia de los datos del equipo cliente al equipo servidor.
Nombre Descripción
Métodos Subir_fichero(txtFileLocal, Envia el fichero txtFileLocal
txtFileRemote, txtServidor, al servidor de FTP
txtUsuario, txtPassword,, txtServidor con el nombre de
sobreescribir) txtFileRemote, accediendo al
servidor con el txtUsuario y
txtPassword. El campo
sobrescribir determina si se
sobrescribe el fichero en el
destino.
Tabla 21- Propiedades y métodos del OCX control_FTP
El componente VISOR.OCX, del modulo de visualización, fue diseñado para poder

representar los datos almacenados en la base de datos. El OCX utiliza una
representación 2D para reflejar la información 3D derivada de las rutas creadas por
los receptores GPS. La primera imagen representa la información sobre el eje X e Y y
la segunda sobre los ejes X y Z.
89
Nombre Descripción
Propiedad Color_fondo Marca el color del fondo de
la imagen. Por defecto es
blanco.
Color_punto Marca el color del trazado.
Por defecto es negro.
Tipo_bmp Determina el tipo de imagen
que se crea. Si el valor es 0
se genera la ruta en plano. Si
es 1, se genera el trazado de
la altura.
Métodos Carga (datos ) Se genera el archivo de
imagen seleccionado con los
datos. Estos datos tienen que
estar formateados en XML.
Tabla 22-Propiedades y métodos OCX visor
6. VALIDACIÓN DEL SISTEMA
Para la validación del sistema, se han seguido los siguientes pasos.
1. Selección de usuarios de GPS
Para la validación del sistema se ha contado con la colaboración del propio

director del proyecto, usuario asiduo de los sistemas de posicionamiento
mediante GPS en el ámbito deportivo de la espeleologia. En concreto, en la
localización y posicionamiento de cavidades.
90
2. Selección de casos reales
Para la validación del sistema, se aportan rutas de aproximaciones y

localizaciones concretas de cavidades pertenecientes a diferentes zonas
geográficas de España.
En concreto, se aportan los siguientes casos:
• O Caurel (Lugo)
Ruta y posicionamiento de la cueva “Tara do Tarelo”
Ruta y posicionamiento de la cueva “Chan do lindeiro”
• Murcia
Ruta y posicionamiento de la cueva del “Pulpo”
Ruta y posicionamiento de la cueva del “Puerto”
• Asturias
Ruta y posicionamiento de la cueva “Llonín”
• Cantabria
Ruta y posicionamiento del sistema “Cueto-Coventosa”
3. Pruebas de los módulos del sistema.

Tomando como referencia los casos del punto 2 y tras varias sesiones con el
director del proyecto como usuario validador, se ha comprobado el correcto
funcionamiento de:
• Entradas-salidas entre el receptor y la computadora.
• El sistema gestor, mediante el alta y modificación de “waypoint” reales.
• El sistemas de visualización 2D y 3D mediante la representación de rutas.
Como último punto de la validación señalar que el director del proyecto abandono la
aplicación que utilizaba habitualmente, el Waypoint + , sustituyéndolo por el
presente desarrollo.
91
7. CONCLUSIONES
En los últimos años se ha observado un fuerte crecimiento en las áreas de aplicación
de los sistemas de posicionamiento global por satélite, y su diversificación a todo
tipo de usuarios.
Unido a esto han aparecido en el mercado todo tipo de aplicaciones de gestión,

visualización y tratamiento de los datos proporcionados por los receptores GPS. Los
sistemas analizados presentan un bajo nivel de integración, así como unas reducidas
posibilidades a la hora de integrar las herramientas especificas de este tipo de
sistemas ( gestión de datos, visualización, etc..)
Con esto en mente, el presente proyecto aporta una potente herramientas para el
tratamiento de los datos en un entorno cliente-servidor. Además, el uso de sistemas
gestores de BD aporta todo tipo de funcionalidades: generación de vistas, integridad
de los datos, consistencia, niveles de seguridad, …
La metodología empleada, unida al modelo de aplicaciones DNA, garantiza la

escalabilidad de la aplicación, facilitando un esquema de modificaciones sistemáticas
independiente del usuario.
El sistema se ha validado con información real de rutas distribuidas por toda la

geografía española, con la ayuda de un usuario asiduo de los receptores GPS, en este
caso el propio director del proyecto.
Se puede concluir que la aplicación resultante de este proyecto, cubre con creces las
necesidades iniciales de los usuarios.
Como es lógico, todo proyecto o sistema es un ente en continua evolución. Entre las
posibles alternativas de futuro, destacan las posibilidades relacionadas con la
visualización 3D de las rutas sobre mapas topográficos, permitiendo la visualizacion
92
a tamaño real desde un entorno de realidad virtual. En este ámbito, se abre todo un
mundo de posibilidades del entorno de sistemas inmersivos e iterativos y su
aplicación en los sistemas de posicionamiento por satelite.
8. GLOSARIO DE TÉRMINOS
A-S (Anti-Spofing) Código para cifrar los datos de la señal GPS.
Banda L Rango de frecuencias entre los 1 GHz y 2 GHz . Asignado
principalmente a la telefonía móvil y las emisiones digitales de audio
a nivel mundial.
C/A (Coarse /Acquisition) Código de adquisición grueso. Componente de
la señal producida por los satélites GPS.
Death Lock Interbloqueo. Circunstancia que se da cuando un servicio acapara un
recurso y queda esperando por otro, mientras que otro servicio que
acapara el segundo está esperando por el primero.
DLL (Dinamic Link Library) Librería de acceso dinámico
Efemérides Parámetros orbitales precisos de cada satélite.
HOW (Hand Over World) Valor que marca la diferencia de ángulo entre las
dos señales que componen la señal GPS.
NAVSTAR (Navigation System and ranging) Sistema de navegación y
determinación de alcance
NMEA Nacional Marine Electronic Association
ODBC (Open DataBase connectivity) Objeto de conexión a base de datos
PVT (Position, Velocity, Time) Siglas con las que se conoce a la unión de
estos tres datos.
SA (Selective Availability) Disponibilidad selectiva. Error introducido en
la señal del satélite GPS.
93
TTFF (Time to fix first) Tiempo que tarda un receptor GPS en recibir la
primera posición de los satélites.
UTC (Universal time coordinated) Tiempo universal coordinado base
uniforme para medir la hora en cada zona del mundo.
Waypoint Punto en el camino
BIBLIOGRAFÍA
Sistemas de posicionamiento global por satélite
[1] Navstar GPS. http://www.tel.uva.es/~jpozdom/telecomunicaciones/
portadagps.html. 2002
[2] GPS Support center. http://www.spacecom.af.mil/usspace/gps_support/. 2002
[3] Documentos de interés para GPS. http://www.uco.es/~bb1rofra/
documentos.html. 2002
[4] Descripción técnica del GPS. http://dique1.ls.fi.upm.es/cuco/Documentos/
desgps.html. 2002
[5] Sistema de localización por satélite. http://www.eveliux.com/articulos/
gps01.html. 2002
[6] Mundo GPS. http://www.mundogps.com/. 2002
[7] GPS el sistema de posicionamiento global. http://www.nautigalia.com/gps/.
2002
[8] Jose Antonio Pardiñas García: “GPS: Sistema de Posicionamiento Global”.
Universidad de Santiago de Compostela. 1998
[9] El receptor GPS. http://members.tripod.com/~isolmar/gps.htm. 2002
[10] Tecnología GPS. http://www.uco.es/~bb1rofra/. 2002
[11] Garmin Internacional. http://www.garmin.com/. 2002
[12] R.B. Langley. “Innovation: Smaller and Smaller - The Evolution Of The GPS
Receiver”. GPS World. Vol.11, No.4, pag 54, 2000
94
[13] F. Lahaye, P. Collins, P. Heroux, M. Daniels, J.Popelar. “Innovation -

Monitoring GPS Receiver and Satellite Clocks in Real Time: A Network
Approach.”. GPS World Vol.12, No.11, pag 44, 2001
UML
[14] James Rumbaugh, Ivar Jacobson, Grady Booch: “El lenguaje unificado de
modelado. Manual de referencia”. Addison Wesley. 1999
[15] UML-Resource page. http://www.omg.org/technology/uml/. 2002
Herramientas y lenguajes
[16] Formato HTML. http://sestud.uv.es/manual.esp/indice.htm . 2002
[17] Herramientas de desarrollo. http://www.auladigital.com/. 2002
[18] Programación en Visual Basic. http://www.terra.es/personal/jrcabrera/. 2002
[19] J. Bobadilla, A. Alcocer, S. Alonso, A. Gutierrez: “HTML Dinámico, ASP y
Javascript a través de ejemplos”. Ra-Ma. 1999
[20] ASP. http://www.ayudaasp.com. 2002
[21] Chris Ullman, Ollie Cornes, Juan T. Libre, Chris Goode: “Beginning
ASP.NET Using VB.NET”. VRAX. 2000
[22] Baltazar Birnios, Mariano Birnios, Baltazer Birnios :” MS Visual Basic 6.0”.
MP Ediciones. 2000
[23] WEB 3D. http://www.wmaestro.com/web3d/. 2002
[24] VRML. http://www.iaz.com/iaz/cad/curso_vrml/welcome.html. 2002
[25] Windows DNA: Información. http://www.iespana.es/helpdna/prdnaart.htm.
2002
[26] MSDN en línea. http://www.microsoft.com/latam/msdn/articulos/1999/09/
art04/. 2002
[27] Documentación sobre DNA. http://www.terra.es/personal/jrcabrera/dna/
dna.htm. 2002
[28] Sten Sundblad, Per Sundblad, Sten : “Designing for Scalability with
Microsoft Windows DNA”. Microsoft Press. 2000
95
[29] Francesco Balena : “Programming Microsoft Visual Basic 6.0”. Microsoft

Press. 2000
REFERENCIAS
[GART-02] Software GRATRIP . http://www.gartrip.de/. 2002
[JOGM-02] Software JOGMAN http://www.mundogps.com/mundogps/
descarga/software/jogman.zip. 2002
[COMP-02] Software Lockcompass http://www.mundogps.com/mundogps/
descarga/software/lockCompass.zip. 2002
[SPEE-02] Software SpeedTrap http://www.mundogps.com/mundogps/
descarga/software/ SpeedTrap.zip. 2002
[FUGA-02] Software FUGAWI. http://www.fugawi.com/. 2002
[OZIE-02] Software OziEXPLORER http://homepage.powerup.com.au/
~oziexp2/esp/oziexp_esp.html. 2002
[TRAK-02] Software TrackMaker. http://www.gpstm.com/. 2002
[WAYP-02] Software Waypoint+. http://www.tapr.org/~kh2z/Waypoint/. 2002
[MICR-02] Coorporacion Microsoft . http://www.microsoft.com/. 2002
96
ANEXO I - ENTORNO DEL USUARIO

En este apartado se incluye todo tipo de información necesaria para la utilización del
Sistema Gestor de Puntos GPS desarrollado en el presente proyecto.
Configuraciones previas
Para poder utilizar correctamente la aplicacion es necesario modificar la
configuración de seguridad del Internet Explorer (a partir de ahora IE) para que
permita que los componentes ActiveX, insertados en la aplicación, puedan ser
utilizados sin problemas.
En el menú de “Herramientas” de la barra superior del IE, seleccionamos la opción
“Opciones de Internet …”
Figura 33- Menú herramientas, opciones de internet
En la nueva pantalla, se selecciona la pestaña “seguridad”, y en ella se elige la opción

“Sitios de confianza”, y pulsamos sobre el botón “Sitios…”
Figura 34- Opciones de internet, Sitios de confianza
97
En la nueva ventana se nos da la posibilidad de añadir direcciones web al grupo de

sitios de confianza. Escribimos la dirección http://gurrumito.dc.fi.udc.es/gps2 en el
campo “Agregar este sitio web a la zona”, pulsamos sobre el boton “Agregar”, y una
vez la dirección web se inserta en el campo “Sitios Web”, pulsamos sobre el boton
“Aceptar”:
Figura 35- Agregar nuevo web a los “sitios de confianza”
Volvemos a pulsar sobre “Aceptar” en la pantalla de “Opciones de Internet”, y la

aplicación esta lista para ser usada.
98
Manejo de la aplicación
La aplicación esta accesible en la dirección

http://gurrumito.dc.fi.udc.es/gps2/
En un primer momento, se muestra la pantalla de presentación (Figura 36)
Figura 36- Página de entrada a la aplicación
A partir de aquí, el usuario podrá autenticarse en el sistema mediante un nombre de

usuario y una clave
Si el usuario no está registrado, el acceso estará restringido a una simple
visualización de los datos
Si el usuario está registrado y la autenticación has sido satisfecha satisfactoriamente,
se proporcionará un acceso completo al sistema.
99
La siguiente pantalla permite al usuario configurar el puerto de conexión con el

receptor GPS. Pulsando sobre la opción “inicializar gps”, la comunicación se
establecerá siempre y cuando todo esté perfectamente interconectado.
Figura 37- Página de inicio de un usuario registrado
En ese momento el sistema nos comunicará el modelo y versión del receptor GPS
conectado mediante un mensaje emergente.
Figura 38- Mensaje con los datos del receptor
Si pulsamos sobre el botón “aceptar”, el sistema comienza a monitorizar la recepción

de paquetes. Mientras tenga lugar la monitorización, la imagen en la parte superior,
muestra la llegada de cada uno de los paquetes que proceden del receptor GPS.
Mientras no se realice ninguna nueva acción, el sistema proporcionará, cada
segundo, la fecha y hora almacenadas en el receptor.
Una vez iniciada la comunicación, podemos detenerla, pulsando sobre el botón

“parar gps”, o transferir las rutas o los waypoints almacenados en el receptor.
100
Si seleccionamos la opción de “Transferir rutas”, una ventana de transmisión de

datos aparecerá brevemente, y se cargará una nueva ventana donde podemos
visualizar los datos de las rutas recogidas del GPS.
Figura 39- Pantalla con las rutas recogidas
En esta pantalla se seleccionan las rutas a insertar en la base de datos con los datos
correspondientes. Si se quiere añadir los puntos de inicio y fin de una ruta como
“waypoint”, se deberá marcar la opción correspondiente.
Cuando el usuario esté seguro de lo que quiere insertar, solo tenemos que pulsar
sobre “Enviar datos”.
Desde la pantalla actual se puede acceder a las rutas almacenadas por el usuario en la
BD o a todas las rutas almacenadas en el sistema, pulsando sobre “Ver rutas usuario”
o “Ver todas las rutas” respectivamente.
Desde la pantalla de inicio de un usuario registrado, también podemos transferir los

datos de los “waypoints” almacenados en el receptor, pulsando sobre “Transferir
waypoints”. La pantalla que aparece a continuación nos muestra todos los
“waypoints” almacenados.
101
Figura 40- Waypoints almacenados en el receptor GPS
En la siguiente pantalla se seleccionan los “waypoint” a insertar en la BD y se pulsa

sobre el boton “insertar”
Toda esta información dispone de un conjunto de entornos para una oportuna gestión
de los datos, a nivel de alta de ficheros, modificaciónes, visualización, etc..(Figura
41, Figura 42, Figura 43)
Figura 41- Modificar el símbolo de un waypoint
102
Figura 42- Visualización de un waypoint
Figura 43- Visualización de una ruta
103

Silo - Tips - Desarrollo de Un Sistema Gestor de Rutas de PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Silo - Tips - Desarrollo de Un Sistema Gestor de Rutas de PDF

Cargado por

Copyright:

Formatos disponibles

)$&8/7$''(,1)250É7,&$

Departamento de Tecnologías de la Información y las Comunicaciones

PROXECTO DE FIN DE CARREIRA DE ENXEÑERÍA TÉCNICA EN

Desarrollo de un Sistema Gestor de Rutas de

Posicionamiento Global por Satélite

Autor: Miguel Penín Álvarez

A Coruña, 24 de Enero de 2002

2. DOMINIO DE LA APLICACIÓN. SISTEMAS GPS.............................. 5

2.1. EL SISTEMA NAVSTAR – GPS ............................................................................ 6

2.2. SERVICIOS GPS .................................................................................................... 12

2.3. CARACTERÍSTICAS DE LA SEÑAL DE LOS SATÉLITES GPS ................. 13

2.4. TIPOS DE RECEPTORES GPS ........................................................................... 15

2.5. GARMIN ETREX ................................................................................................... 19

3. ESTADO DEL ARTE............................................................................... 35

4. METODOLOGÍA DE DESARROLLO .................................................. 39

4.2. BASE DE DATOS DEL SISTEMA ....................................................................... 59

4.3. LENGUAJES Y HERRAMIENTAS ..................................................................... 64

5. ARQUITECTURA GENERAL DE SISTEMA....................................... 86

6. VALIDACIÓN DEL SISTEMA............................................................... 90

8. GLOSARIO DE TÉRMINOS .................................................................. 93

ANEXO I - ENTORNO DEL USUARIO............................................................ 97

Figura 32- Módulos del sistema.............................................................................. 87

Tabla 18- Objeto server.......................................................................................... 76

D. ANTONINO SANTOS DEL RIEGO, Profesor Titular de la

HACE CONSTAR QUE: La memoria titulada “Sistema Gestor de

A Coruña, 23 de Enero de 2002

Fdo: Prof. D. Antonino Santos Del Riego.

En este proyecto se aborda el diseño y desarrollo de un Sistema Gestor de

En todos los desarrollos o antecedentes analizados en este proyecto, la idea

GPS (Global Positioning System), NAVSTAR (NAVigation SysTem And Ranging),

equipamiento hardware (GPS), protocolo de comunicaciones, cableado y el propio

Con esto en mente, el presente proyecto se centrará en el estudio e integración de los

2. DOMINIO DE LA APLICACIÓN. SISTEMAS GPS

transcurrido en la transmisión de la señal entre el satélite y el receptor GPS. Al

2.1. EL SISTEMA NAVSTAR – GPS

Figura 1- Segmentos del sistema de satélites

El segmento espacial NAVSTAR – GPS está

Características de las constelaciones NAVSTAR Y GLONASS

Tabla 1- Comparación entre NAVSTAR y GLONASS

El segmento de control consta de cinco estaciones de monitorización localizadas en

Figura 3 - Segmento de control

El segmento de usuario está formado por receptores de GPS que proporcionan la

El sistema NAVSTAR GPS se basa en la medida simultánea de la distancia entre el

[0] Ri = Distancia (Satélitei, Receptor)

[1] R i = ∆T • c Donde Ri es la distancia real (sin error en los relojes)

[2] R i’ = ∆Tmedido • c Donde Ri’ es la pseudodistancia

Siendo “ ” el error derivado de la desviación de los relojes.

Entonces a partir de las ecuaciones [2] y [3] se tiene:

por [1] entonces

o lo que es lo mismo, la distancia real es:

Los satélites transmiten señales en dos frecuencias diferentes de la banda L, la señal

2.2. SERVICIOS GPS

El PPS es un servicio de determinación de la posición y tiempo con alta precisión,

El SPS es un servicio de posicionamiento global de baja precisión, pero accesible

2.3. CARACTERÍSTICAS DE LA SEÑAL DE LOS SATÉLITES GPS

• Momento en el que fue transmitido el mensaje.

Figura 5- Composición de la señal L1 y L2

2.4. TIPOS DE RECEPTORES GPS

2.4.1. RECEPTORES CONTINUOS

adquirir nuevos satélites. Debido principalmente a su gran complejidad, estos

2.4.2. RECEPTORES SECUENCIALES

Los receptores secuenciales de un canal calculan las pseudodistancias tanto en la

los satélites puede reducir sensiblemente la precisión del posicionamiento. Los