Estado Del Arte GPS

)$&8/7$''(,1)2507,&$
Departamento de Tecnologas de la Informacin y las Comunicaciones
PROXECTO DE FIN DE CARREIRA DE ENXEERA TCNICA EN

INFORMTICA DE XESTIN
Desarrollo de un Sistema Gestor de Rutas de

Posicionamiento Global por Satlite
Autor: Miguel Penn lvarez

Tutor: Antonino Santos del Riego
A Corua, 24 de Enero de 2002
SISTEMA GESTOR DE RUTAS DE POSICIONAMIENTO GLOBAL POR SATLITE
RESUMEN ............................................................................................................. 3
1.
INTRODUCCIN ...................................................................................... 4
2.
DOMINIO DE LA APLICACIN. SISTEMAS GPS.............................. 5
2.1.
EL SISTEMA NAVSTAR GPS ............................................................................ 6
2.2.
SERVICIOS GPS .................................................................................................... 12
2.3.
CARACTERSTICAS DE LA SEAL DE LOS SATLITES GPS ................. 13
2.4.
TIPOS DE RECEPTORES GPS ........................................................................... 15
2.5.
GARMIN ETREX ................................................................................................... 19
3.
ESTADO DEL ARTE............................................................................... 35
4.
METODOLOGA 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.
VALIDACIN DEL SISTEMA............................................................... 90
7.
CONCLUSIONES .................................................................................... 92
8.
GLOSARIO DE TRMINOS .................................................................. 93
BIBLIOGRAFA.................................................................................................. 94
REFERENCIAS ................................................................................................... 96
ANEXO I - ENTORNO DEL USUARIO............................................................ 97
NDICE DE FIGURAS
Figura 1- Segmentos del sistema de satlites ............................................................ 6
Figura 2- Constelacin de satlites ........................................................................... 7
Figura 3 - Segmento de control................................................................................. 8
Figura 4- Posicionamiento mediante esferoides ........................................................ 9
Figura 5- Composicin de la seal 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 transicin de estados del objeto GPS ................................ 59
Figura 30- Representacin lgica de la Base de Datos ............................................ 62
Figura 31- Representacin fsica de la Base de Datos ............................................. 63
II
Figura 32- Mdulos 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- Pgina de entrada a la aplicacin........................................................... 99
Figura 37- Pgina 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 smbolo de un waypoint .................................................. 102
Figura 42- Visualizacin de un waypoint.............................................................. 103
Figura 43- Visualizacin de una ruta .................................................................... 103
NDICE DE TABLAS
Tabla 1- Comparacin entre NAVSTAR y GLONASS............................................. 7
Tabla 2- Comparacin receptores ........................................................................... 20
Tabla 3- Ejemplo protocolo NMEA........................................................................ 23
Tabla 4-Estructura paquete de conexin ................................................................. 25
Tabla 5- Paquetes bsicos del protocolo Garmin..................................................... 27
Tabla 6-Protocolo de transmisin de datos ............................................................ 27
Tabla 7- Protocolo de transmisin de comandos ..................................................... 29
Tabla 8- Comandos permitidos............................................................................... 29
Tabla 9- Protocolo de transmisin de waypoints ................................................. 30
Tabla 10-Protocolo de transferencia de puntos GPS ............................................... 32
Tabla 11- Protocolo de transferencia de fecha ....................................................... 33
Tabla 12- Protocolo de transmisin 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- Caractersticas de un OCX sobre HTML ................................................ 83
Tabla 20- Propiedades y mtodos del OCX gps_garmin ......................................... 88
Tabla 21- Propiedades y mtodos del OCX control_FTP........................................ 89
Tabla 22-Propiedades y mtodos OCX visor .......................................................... 90
IV
D. ANTONINO SANTOS DEL RIEGO, Profesor Titular de la

Universidade da Corua.
HACE CONSTAR QUE: La memoria titulada Sistema Gestor de

Rutas de Posicionamiento Global por Satlite ha sido realizada por
D. MIGUEL PENN LVAREZ, bajo mi direccin, en el
departamento
de
Tecnologas
de
la
Informacin
las
Comunicaciones de la Universidad de La Corua, y constituye su

proyecto que presenta para optar al Grado de INGENIERO
TCNICO en Informtica de la UDC.
A Corua, 23 de Enero de 2002
Fdo: Prof. D. Antonino Santos Del Riego.
RESUMEN
En este proyecto se aborda el diseo y desarrollo de un Sistema Gestor de
Posicionamiento Global por Satlite, en la forma de una aplicacin clienteservidor,
que proporcione acceso al mayor nmero de usuarios posibles. Adems, tambin se
incluir la posibilidad de funcionamiento en la forma de aplicacin centralizada, sin
un entorno cliente.
En todos los desarrollos o antecedentes analizados en este proyecto, la idea
predominante es la de disponer de una aplicacin y nicamente compartir los datos
entre usuarios mediante ficheros, generados con la informacin de posicionamiento
para su transmisin. Por otro lado, las Bases de Datos (en adelante BD) con puntos o
rutas de posicionamiento global por satlite, en ingls Global Positioning System (en
adelante GPS) consultadas, no permiten una transferencia de la informacin
directamente desde el receptor GPS. Las herramientas ms 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
tecnologa Distributed interNet Aplications (en adelante DNA), permite un acceso
directo del receptor GPS a una BD compartida entre todos los usuarios de la
aplicacin. La tecnologa DNA proporciona en todo momento un servidor virtual de
web, otro de aplicacin y un tercero de datos, aun cuando los tres sean el mismo
fsicamente o, por ejemplo, el servidor de datos est distribuido entre varias
mquinas 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 comunicacin
directa con el receptor y que proporcione un alto grado de integridad, ciertos niveles
de seguridad, y, entre otros, un adecuado entorno de visualizacin, 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 +
1. INTRODUCCIN
Las tcnicas de posicionamiento y navegacin por satlite y por GPS, han
evolucionado de manera vertiginosa desde su aparicin, traspasando los fines para
los que en un principio fueron diseadas 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 electrnicos, los que han permitido que estas
tcnicas lleguen a todo tipo de usuarios, traspasando la pequea comunidad militar o
cientfica para las que fueron diseadas. Aunque el posicionamiento global por
satlite naci con fines militares, continuamente se le estn encontrando nuevos usos
civiles.
La tecnologa GPS puede ser utilizada en cualquier lugar, menos en aquellos en los
cuales es imposible recibir seal, como por ejemplo dentro de edificios, subterrneos
o bajo el agua. En el aire, los GPS son utilizados para la navegacin area, tanto en
aeronutica militar como en aviacin comercial y general. En el mar, los GPS
tambin son utilizados por aficionados a la nutica, pescadores y marinos
profesionales. Las aplicaciones terrestres en cambio estn ms diversificadas. La
comunidad cientfica, por ejemplo, utiliza la tecnologa GPS para obtener datos de
posicin y tiempo muy precisos.
Los usos recreativos del GPS son casi tan numerosos como el nmero 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 ubicacin o posicin geogrfica, encontrar su
camino quizs en medio de condiciones hostiles o saber la direccin y velocidad en
que se desplaza puede sacar provecho de los beneficios del Sistema de
Posicionamiento Global.
La aplicacin presentada abordar el diseo 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,
equipamiento hardware (GPS), protocolo de comunicaciones, cableado y el propio

desarrollo software sobre una arquitectura clienteservidor. Este tipo de entornos
proporcionan acceso a un gran numero de usuarios, y permiten la introduccin de la
aplicacin en el mundo Internet. En todo momento se pens en una interfaz acorde a
los posibles usuarios, intentando siempre disearla sobre una plataforma web.
Con esto en mente, el presente proyecto se centrar en el estudio e integracin 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.
Gestin de puntos GPS
Desarrollo de un sistema de visualizacin en 2D de rutas creadas a partir de

los puntos GPS.
Desarrollo de un sistema de visualizacin 3D
Adems, se abordar el diseo y la construccin de una aplicacin en el dominio del

posicionamiento global por satlite. De esta manera, los usuarios podrn disponer de
una avanzada herramienta que les sirva de ayuda a la hora de recolectar o tratar la
informacin.
2. DOMINIO DE LA APLICACIN. SISTEMAS GPS

El GPS es un sistema mundial de localizacin constituido por una constelacin de
satlites, cada uno de ellos dotado con relojes atmicos, computadoras, emisores y
receptores de radio y por estaciones terrestres que monitorizan constantemente a cada
uno de los satlites. Los receptores de GPS utilizan a estos satlites como puntos de
referencia para calcular la latitud, longitud, altitud, velocidad y tiempo exacto.
Para ello, cada satlite transmite a la Tierra su posicin y tiempo exacto 1000 veces
por segundo, donde cada milisegundo un receptor computerizado puede calcular la
distancia con el satlite, multiplicando la velocidad de la luz por el tiempo
transcurrido en la transmisin de la seal entre el satlite y el receptor GPS. Al

combinar las seales de varios satlites, el receptor puede establecer con exactitud
su propia posicin.
2.1.
EL SISTEMA NAVSTAR GPS
El sistema NAVSTAR GPS, al igual que cualquier otro sistema de satlites, est
constituido por tres segmentos:
1. Segmento espacial
2. Segmento de control
3. Segmento de usuario
Figura 1- Segmentos del sistema de satlites
El segmento espacial NAVSTAR GPS est

constituido por una constelacin de 24 satlites,
localizados a 20200 Km de la superficie de la
Tierra. Los satlites son la parte fundamental, ya
que se encargan de emitir constantemente las
seales hacia los receptores GPS, cubriendo todo el
globo terrestre. Actualmente los dos sistemas de
satlites ms conocidos son el NAVSTAR GPS y el
GLONASS ruso (GLObal NAvigation Satellite
System) con unas caractersticas y operatoria muy
Figura 2- Constelacin de satlites
similares.
Caractersticas de las constelaciones NAVSTAR Y GLONASS

Caracterstica
NAVSTAR GPS
GLONASS
Departamento de Defensa
Compaa Impulsora
de los Estados Unidos de

Amrica por medio de la
Gobierno Ruso
NAVSTAR System Ltd

Numero de satlites
Tipo de rbita
Frecuencias
Mtodo de acceso
Vida til Aprox.
24 en 6 planos orbitales
24 en 6 planos orbitales
Media ( 20,200 Km)
Media ( 19,200 Km)
Inclinacin 63
Inclinacin 64.8
Periodo de 12h
Periodo de 11h 15min
Banda L
Banda L
L1 = 1.57542 GHz
L1 = 1.609 GHz
L2 = 1.2276 GHz
L2 = 1.251 GHz
CDMA ( Espectro
CDMA ( Espectro
Esparcido)
Esparcido)
7,5 aos
7,5 aos
Tabla 1- Comparacin entre NAVSTAR y GLONASS
El segmento de control consta de cinco estaciones de monitorizacin localizadas en

Hawai, Kwajelein, Isla Ascensin, Diego Garca y Colorado Springs; tres estaciones
terrestres con antenas en Isla Ascensin, Diego Garca y Kwajelein, y una Estacin
Maestra de Control, en ingls Master control Station (MCS), localizada en la base
area de Falcon Colorado, la cual mantiene los satlites en posicin orbital y su
respectiva regulacin. Las estaciones de monitorizacin rastrean todos los satlites
que se encuentran a la vista, acumulando la informacin monitorizada. Esta
informacin se procesa en la MCS para determinar las rbitas de los satlites y para
actualizar cada uno de sus mensaje de navegacin.
Figura 3 - Segmento de control
El segmento de usuario est formado por receptores de GPS que proporcionan la

posicin, altitud, velocidad y tiempo preciso al usuario desde cualquier parte del
mundo las 24 horas del da.
El sistema NAVSTAR GPS se basa en la medida simultnea de la distancia entre el

receptor y al menos 4 satlites. A partir de cada una de las seales, el receptor GPS
puede
generar
ecuacin
de
esferoide.
interseccin
esferoides
la
un
La
de
los
generados
por los cuatro satlites

proporciona la posicin
exacta del receptor
GPS.
Aunque el clculo de
los retardos temporales
entre 3 de los satlites
y
Figura 4- Posicionamiento mediante esferoides
el
receptor
GPS
proporcionan un punto
en el espacio (Xi, Yi,
Zi), esta situacin exigira una precisin extraordinaria y una gran estabilidad de los
relojes, tanto del satlite como del receptor. Si bien los satlites cumplen estas dos
condiciones, puesto que incorporan un reloj atmico, este no es el caso de la gran
mayora de los receptores. La solucin a este problema introduce una nueva
incgnita en el sistema de ecuaciones debido a la diferencia existente entre el reloj
del satlite y el reloj del usuario, lo que conlleva a la utilizacin de un cuarto satlite
como mnimo.
La suposicin de que el sistema GPS se basa en distancias es ahora falsa , tal y como
se ha visto en el clculo de la distancia. En realidad no se miden distancias sino
pseudodistancias.
Supongamos:
[0]
Ri = Distancia (Satlitei, 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 seal parte del satlite hasta que
llega al receptor, Tmedido la diferencia de tiempo entre el reloj atmico del satlite
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 desviacin 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 satlite son conocidas, se tienen cuatro ecuaciones,
una por satlite, 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 satlite i en el momento de
enviar la seal.
Con las cuatro ecuaciones, 1 por cada satlite, se genera un sistema de ecuaciones
con cuatro incgnitas que proporciona una nica solucin.Si existen mas de cuatro
satlites visibles, se calculan las pseudodistancias respecto a todos ellos, obteniendo
as un sistema con ms ecuaciones que incgnitas, simplificando considerablemente
el clculo de la posicin.
Los satlites transmiten seales en dos frecuencias diferentes de la banda L, la seal

denominada Link 1 (a partir de ahora L1) a 1575.42 MHz y la seal Link 2 (a
partir de ahora L2) a 1227.6 MHz. Las seales se transmiten utilizando la tcnica de
espectro ensanchado, empleando dos cdigos de seales diferentes, un cdigo de
adquisicin grueso (cdigo C/A) a 1.023 MHz en la L1 y un cdigo de precisin
(cdigo P) tanto en la seal L1 como en la L2.
Tanto el cdigo C/A como el cdigo P pueden ser utilizados para el clculo de las
pseudodistancias entre el satlite y el usuario; sin embargo, el cdigo P est
normalmente cifrado. Cuando est cifrado, el cdigo P se denomina cdigo Y. Sobre
estos dos cdigos, el cdigo C/A y el cdigo P (o Y si est cifrado), se superpone el
11
mensaje de navegacin del GPS. Este mensaje proporciona informacin tal como la
hora del satlite, los datos orbitales precisos de cada satlite (a partir de ahora
efemrides) o los datos relacionados con los parmetros orbitales de toda la
constelacin de satlites.
2.2.
SERVICIOS GPS
Existen dos niveles proporcionados por el sistema NAVSTAR GPS, el servicio

preciso de localizacin, Precise Positioning System en ingls (PPS) y el servicio
estndar de localizacin, en ingls Simple Positioning System (SPS).
El PPS es un servicio de determinacin de la posicin y tiempo con alta precisin,

accesible nicamente por usuarios autorizados. El PPS est destinado principalmente
a entornos militares. El uso de dicho servicio est condicionado a la autorizacin del
Departamento de Defensa de los Estados Unidos. Esta autorizacin se concede en
funcin 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 Cartografa de los EEUU. El sistema PPS proporciona una precisin
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
tcnicas criptogrficas, Disponibilidad Selectiva, en ingls Selective Avaliability
(a partir de ahora SA) y tcnicas de autenticacin de anti-spoofing(en adelante AS). La tcnica SA se usa para reducir la precisin de la posicin GPS, la velocidad e
incluso el tiempo a los usuarios no autorizados. El sistema A-S opera introduciendo
un error pseudoaleatorio dentro de la seal del satlite y permanece activo en todos
los satlites con el fin de proteger la seal de una posible intromisin o modificacin
en los datos de la misma.
12
Los receptores PPS pueden utilizar tanto el cdigo P como el C/A, o bien los dos a la
vez. El mayor nivel de fiabilidad se alcanza con los cdigos P de las dos seales L1 y
L2 conjuntamente. Aun cuando un receptor est diseado para soportar el servicio de
posicionamiento preciso, normalmente se utiliza el cdigo C/A para establecer la
comunicacin con los satlites.
El SPS es un servicio de posicionamiento global de baja precisin, pero accesible

desde cualquier receptor GPS. En situacin internacional normal, el nivel del SA est
controlado para ofrecer un error predecible de 100 metros horizontalmente y 156
metros verticalmente. El sistema de degradacin de la seal se puede incrementar o
variar en caso de crisis o guerra.
2.3.
CARACTERSTICAS DE LA SEAL DE LOS SATLITES GPS
Para analizar las caractersticas de las seales emitidas desde los satlites, se han de
estudiar tres aspectos:
El cdigo C/A
El cdigo P(Y)
Los mensajes de navegacin
El cdigo C/A est compuesto por una seal de ruido de 1023 bits pseudoaleatorios
(PRN) con una frecuencia de 1.023 MHz. La longitud corta de la secuencia del
cdigo C/A est diseada para permitir al receptor una rpida adquisicin de la seal
del satlite que incluye la seal con el cdigo P. Cada satlite GPS tiene asignada
una secuencia PRN diferente, seleccionada de entre un grupo de cdigos
denominados Gold codes. Estos cdigos estn diseados para minimizar la
probabilidad de que el receptor GPS confunda un cdigo con otro. El cdigo C/A
slo es transmitido junto con la seal L1. Este cdigo no est cifrado y est
disponible para todos los receptores GPS.
13
El cdigo P (o bien cdigo Y si est cifrado) es una seal PRN con una frecuencia de
reloj de 10.23 MHz y un periodo de 267 das. Cada uno de los satlites GPS tiene
asociado un nico segmento de 7 das, el cual se reinicia cada medianoche del
domingo, asignando secuencias semanales distintas a cada satlite. El cdigo P est
normalmente cifrado con la finalidad de proteger la seal. El cdigo P es transmitido
por cada satlite tanto en la seal L1 como en la L2.
La seal de datos enviada por el satlite, de una frecuencia de 50Hz, est superpuesta
tanto sobre el cdigo P(Y) como sobre el cdigo C/A. El mensaje de navegacin
incluye datos nicos del satlite emisor y ciertos datos comunes a todos los satlites.
Los mensajes del satelite contienen la siguiente informacin:
Momento en el que fue transmitido el mensaje.
Ajuste de la transicin desde el cdigo C/A al cdigo P(Y).
Modelo para corregir los errores del reloj.
Una referencia a la situacin de la constelacin de satlites.
Modelo para corregir los errores producidos por la propagacin de la seal en

la ionosfera y troposfera.
Informacin sobre el estado de funcionamiento del satlite emisor.
Informacin sobre el estado de funcionamiento de todos los satlites.
Parmetros orbitales de todos los satlites.
Coeficientes para el clculo de UTC
El mensaje de navegacin 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 seal 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 informacin crtica del satlite emisor cada 30 segundos. La
14
subtrama N 1 contiene la informacin sobre el modelo para corregir los errores del
reloj, as como parmetros sobre la precisin y el funcionamiento del satlite emisor.
La segunda y la tercera subtramas contienen informacin precisa de la rbita del
satlite emisor, parmetros necesarios para el clculo de la posicin exacta del
satlite, que se utilizan para obtener la pseudodistancia entre el satlite y el receptor.
Las subtramas cuarta y quinta varan en cada uno de las 25 tramas, y contienen la
informacin comn a todos los satlites y los datos menos crticos para el receptor
GPS.
Figura 5- Composicin de la seal 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 bsqueda continua tiene al menos cinco o ms canales hardware,

cuatro para seguir los cuatro satlites simultneamente y un quinto a mayores para
15
adquirir nuevos satlites. Debido principalmente a su gran complejidad, estos

receptores son los ms caros, aunque tambin los que ofrecen el mejor de los
servicios. Los receptores multicanal utilizan el quinto canal para leer el mensaje de
navegacin de un nuevo satlite GPS, cuando el receptor GPS cambia los satlites
seleccionados. Por separado, los canales de seguimiento dedicados permiten a los
receptores mantener la precisin de la localizacin bajo un movimiento extremo,
proporcionan el mejor sistema anti-interferencias y poseen el tiempo ms bajo para
fijar todos los satlites, en ingls time to fix first (a partir de ahora TTFF). Este
tipo de receptores GPS est destinado a vehculos de gran velocidad, como puede ser
un avin de combate, vehculos que requieran un TTFF bajo, como son los
submarinos, o bien para aquellos usuarios que necesiten de un sistema antiinterferencias para recibir la seal.
2.4.2. RECEPTORES SECUENCIALES
Un receptor secuencial fija los satlites mediante uno o dos canales hardware. El
sistema fija un satlite detrs de otro y los combina cuando la pseudodistancia a los
cuatro satlites est calculada. Estos receptores GPS son los ms econmicos. En
contrapartida no son capaces de operar a grandes velocidades y poseen el sistema de
fijacin de satlites ms 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 posicin y compensar el
retardo de la seal en la ionosfera. Para poder obtener un posicionamiento preciso, el
receptor GPS necesita calcular por separado la posicin de cada uno de los satlites,
obtener las orbitas exactas y a partir de estos datos, generar un modelo que le permita
calcular la posicin de todos los satlites en el mismo momento. Cualquier
movimiento del receptor durante el tiempo en que se reciben los datos de posicin de
16
los satlites puede reducir sensiblemente la precisin del posicionamiento. Los

receptores secuenciales monocanales tienen limitado su uso a aquellas funciones en
las que el movimiento sea mnimo.
Los receptores secuenciales bicanal estn diseados para su utilizacin en vehculos

de velocidad reducida, como pueden ser automviles o helicpteros. Durante la
conexin inicial con los satlites opera como un receptor secuencial monocanal, pero
en el momento en que los cuatro satlites estn fijados, el segundo canal se dedica a
establecer la conexin con todos los satlites, recibiendo la posicin de cada uno,
mientras que el otro se dedica a leer el mensaje de navegacin de cada uno de los
satlites. 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 comparacin con un
receptor monocanal.
2.4.3. RECEPTORES MLTIPLES
Un receptor mltiple(o receptores MUX) conmuta de la seal de un satlite a la seal

de otro a una gran frecuencia (habitualmente unas 50 veces por segundo), recogiendo
continuamente datos para mantener de dos a ocho seales procesndose mediante
software. Adicionalmente, el receptor lee continuamente el mensaje de navegacin
de todos los satlites. En un receptor mltiple 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 recepcin continuos sean idneos 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 precisin de la medicin GPS, se desarroll una tcnica

conocida comoDifferential Global Positioning System(a partir de ahora DGPS). La
precisin en el receptor GPS depende de muchos factores de entre los que destacan el
sistema SA, la desviacin de los relojes o el retraso de la seal provocado por la
ionosfera.
La idea principal del sistema DGPS se basa en el hecho de que los satlites estn
situados a una gran altura 20200 Km. Ante esta situacin, el tiempo que tarda la
seal en llegar a dos puntos cualesquiera situados a una distancia considerable entre
si, por ejemplo 200 Km, debera contener el mismo error de medicin.
El sistema DGPS utiliza

estaciones
terrestres
referencia
de
(bases
pertenecientes a la Guardia
Costera de los EEUU y a
agencias
que
internacionales
establecen
estaciones
alrededor
sus
de
puertos y ros navegables).

La Estacin de referencia
(con coordenadas exactas ya
conocidas)
en
lugar
Figura 6- Funcionamiento DGPS
de
calcular su posicin de nuevo, establece el tiempo de travesa (TC) para cada uno de
los satlites que tiene a la vista y los compara con el tiempo proporcionado por cada
satlite (TS). La diferencia entre el TC y el TS se conoce como Error de correccin
(EC). Cuando un receptor GPS con tecnologa DGPS fija los satlites, la estacin 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 lder del mercado de receptores GPS de mano,

compitiendo con empresas como Thales Navigation o Holux Technology Inc.
La empresa Garmin ofrece una extensa documentacin sobre los protocolos que
utilizan sus productos.
El modelo bsico de la serie eTrex ofrece la mejor

relacin 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
determinacin de la posicin del usuario, el Garmin
eTrex crea, almacena y etiqueta una localizacin 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 direccin del
Figura 7- Garmin eTrex
movimiento, tiempo y distancia al destino. A partir de estos datos bsicos, el GPS

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

Garmin eTrex y su comparativa con otros modelos de la misma compaa y de
otras existentes en el mercado.
Caracterstica
Blazer 12
Garmin 12
Garmin eTrex
100
500
500
4 caracteres
6 caracteres
6 caracteres
Batera externa
Bateras
I/0 computadora
No
Capacidad DGPS
No
Waypoints
Nombres
Tabla 2- Comparacin receptores
2.5.1. INTERFAZ ENTRADA / SALIDA
La interfaz de entrada-salida permite al receptor GPS conectarse con aparatos

externos como pueden ser perifricos de la Nacional Marine Electronic
Association (a partir de ahora NMEA), balizas con receptores DGPS (con el fin de
mejorar la seal), 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 seales DGPS provenientes de una baliza

con receptor DGPS, utilizando para la comunicacin 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 estndar NMEA 0183 versin 2.0.
Salida de texto. Transmisin de salida en formato ASCII con datos tales como la
localizacin o la velocidad, pero no permite ningn 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 estndar RTMC SC-104

a la vez que permite una salida de datos en formato NMEA 0183 versin 2.0.
RTMC/texto. Soporte para la entrada de datos en formato RTMC SC-104 y salida

en formato texto.
2.5.2. CONEXIN HARDWARE
La conexin hardware para los receptores de la compaa Garmin renen los

requerimientos mnimos necesarios para establecer una conexin con un sistema
NMEA. Es tambin compatible con la mayora 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
automticamente la mejor velocidad de transmisin adaptada a cada tipo de
conexin. La interfaz de conexin solo posee una lnea de entrada de datos, una lnea
de salida y una toma de conexin a tierra. Adems de la lnea de conexin de datos,
el GPS aporta una lnea de corriente externa con el fin de poder suministrar corriente
al receptor en cualquier circunstancia.
Con el fin de utilizar la conexin hardware del GPS Garmin eTrex con cualquiera
de los perifricos anteriormente sealados, es necesario de un cable con los
conectores apropiados. Este cable, en el caso de una conexin 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 interconexin entre los dos conectores.
Figura 8- Conector GPS - PC mediante puerto serie
21
2.5.3. PROTOCOLO NMEA
La NMEA desarroll una especificacin que defina la interfaz entre varios

equipamientos electrnicos marinos. El estndar permite el envi de informacin
hacia una computadora u otro componente electrnico. La comunicacin de los
sistemas GPS esta definida siguiendo este estndar. La gran mayora de los
programas de posicionamiento en tiempo real requieren que la informacin tenga un
formato estndar NMEA. La idea principal del formato NMEA es la de enviar
paquetes de mensajes, llamados sentencias, con toda la informacin aportada por el
receptor GPS, haciendo independientes unos paquetes de otros.
Todas las sentencias enviadas en formato estndar NMEA tienen dos primera letras
de prefijo las cuales definen el perifrico que utilizan esa sentencia (para los
receptores GPS, este prefijo es GP). Estos dos caracteres estn seguidos por tres
letras que definen el contenido de la sentencia. Adicionalmente a las existentes, el
estandar NMEA permite a los fabricantes la definicin de sentencias propias. Todas
las sentencias nuevas debern comenzar con el carcter 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 lnea. El formato NMEA
incluye todos los datos necesarios separados mediante comas en forma ASCII.
Un ejemplo de cdigo 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 interpretacin del cdigo NMEA.
GGA
123519
4807.038,N
Global Positioning System Fix Data

Recogida a las 12:35:19 UTC
Latitud 48 0.738 N
22
01131.000,E
Longitud 11 31.000 E
Calidad de la recogida
0 = invalido
1 = GPS
2 = DGPS
08
Nmeros de satlites seguidos
0.9
Error en la medicin horizontal
545.4
46.9
Vaco
Vaco
*42
Altitud en metros sobre el nivel del mar

Correccin de la altura del nivel del mar
sobre el elipsoide WGS84
Tiempo en segundos desde la ultima
correccin DGPS
Numero de estacin DGPS
Suma de control de los datos ( Checksum )
Tabla 3- Ejemplo protocolo NMEA
Cada tipo de dato tiene su propia interpretacin en el estndar NMEA. La sentencia

del ejemplo proporciona al receptor la posicin actual del usuario. Otras sentencias
pueden proporcionar la misma informacin pero con datos aadidos. En el estndar
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 informacin al receptor mediante
el sistema NMEA, esta slo 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 reenve determinado paquete.
23
La versin actual del estndar NMEA es la llamada 0182 Versin 2. Este estndar
define que la transmisin se debe hacer a 4800 baudios. Diversas versiones anteriores
del estndar NMEA requieren diferentes velocidades de transmisin, as la versin
0182 requiere 1200 baudios y la 0183 Versin 1.5, solo aceptada por algunos
receptores de la marca Garmin, transmite a una velocidad de 9600 baudios.
Las principales sentencias del estndar NMEA son:
GPBOD
GPGGA Datos de localizacin
GPGLL
Datos de latitud / longitud
GPGSA
Datos de los satlites en general
GPGSV
Datos de un satlite detallado
GPRMC Datos mnimos de posicionamiento, tiempo y velocidad
GPRTE
Datos de una ruta ( datos de entrada-salida )
GPWPL
Datos de un waypoint (datos de entrada-salida)
Recorrido de origen a destino
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
HCHDG Datos de salida del comps ( Soportado por Garmin eTrex Summit )
Datos de control de las balizas
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 constelacin de
24
satlites. A continuacin se describe el protocolo de conexin del Garmin eTrex.,

conocido como protocolo de conexin L001
En el protocolo L001, todos los datos estn dispuestos en paquetes de bytes. Un

paquete siempre comienza con tres bytes (DLE, ID, tamao) seguidos de un nmero
variable de bytes de datos, y finalizando con un grupo de tres bytes (Checksum,
DLE, ETX ). La Tabla 4 muestra la estructura.
Nmero de byte
Descripcin del byte
Data Link Escape ( DLE )
ID del paquete
3 hasta n-4
Tamao del paquete de

datos
Paquete de datos
Notas
Carcter 16 del
cdigo ASCII
Identifica el tipo de
paquete
Solo el tamao del
paquete de datos , es
decir n-7 bytes
0 hasta 255 bytes
Complemento a 2 de
n-3
Checksum
la suma de todos los

bytes desde el byte 1
hasta el byte n-4
n-2
Data Link Escape ( DLE )
n-1
Fin de texto
Carcter 3 del cdigo

ASCII
Tabla 4-Estructura paquete de conexin
En el caso de que cualquier byte en el campo tamao, paquete de datos, o

checksum sea igual al DLE, se insertar otro carcter DLE a continuacin. Este
carcter no se incluir ni en el tamao del paquete, ni en el clculo del checksum.
25
Con este proceso se permite que el carcter 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 ningn otro paquete hasta que se recibe el paquete ACK o NAK.
El paquete ACK tiene un identificador igual al carcter 6 del cdigo ASCII, mientras
que el paquete NAK tiene por identificador el carcter 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 comunicacin 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 slo se utilizan para representar errores a nivel de
conexin, no en los protocolos de alto nivel.
Con la finalidad de que la comunicacin 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 volvera a enviar el
ultimo paquete, con lo que la comunicacin se volvera a establecer.
La Tabla 5 muestra los paquetes bsicos definidos en el protocolo Garmin:
Nombre del paquete
Carcter
Nombre del paquete
ASCII
Carcter
ASCII
ID_Date_Time
ID_Rte_Wpt_Data
30
ID_ACK_Byte
ID_Almanac_Data
31
ID_Position_Data
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 bsicos del protocolo Garmin
2.5.4.1. PROTOCOLO DE APLICACIN
Cada uno de los protocolos de aplicacin tiene un identificador nico que lo

distinguen de otros. El entorno est abierto a la incorporacin de nuevos protocolos o
a la mejora de los protocolos ya existentes.
A000 - Protocolo de transmisin de producto
Todos los GPS estn diseados para transmitir los datos relativos al receptor, tales
como el modelo, versin de software instalado, etc.
La Tabla 6 muestra la secuencia de paquetes correspondiente al protocolo de
transmisin:
N
0
1
Direccin
Host GPS
Host GPS
Nombre del paquete
Tipo del paquete
Pid_Product_Rqst
Pid_Product_Data
Product_data_type
Tabla 6-Protocolo de transmisin 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 ms cadenas de caracteres terminadas por un carcter nulo
(vbNullChar). El primer entero identifica el tipo de receptor GPS con el identificador
del producto; el segundo identifica la versin multiplicada por 100, por ejemplo la
versin 3.11 se indica como 311. La primera de las cadenas de caracteres contiene la
descripcin del modelo de receptor en formato legible para el usuario final.
La definicin de la clase cProduct_Data es:
Option
Public
Public
Public
Public
Explicit
Product_ID
Software_Version
Product_Description_1
Product_Description_2
As
As
As
As
Integer
Integer
String
String
A010 - Protocolo de comandos
Esta seccin describe la manera de hacerle llegar al receptor GPS las necesidades del
usuario. Todos los GPS admiten como mnimo 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 operacin.
Hay que recordar que cualquiera de los dos lados de la comunicacin (GPS o
computadora) pueden hacer una peticin de transferencia de datos, por lo que la
aplicacin que se est comunicando con el GPS deber considerar tambin las
peticiones del receptor.
28
La secuencia de paquetes correspondiente al protocolo de transmisin de comandos

es:
N
0
Direccin
Nombre del paquete
Tipo del paquete
Equipo 1Equipo 2
Pid_command_Data
Command_Id_Type
Tabla 7- Protocolo de transmisin de comandos
El paquete 0 contiene los datos necesarios para indicar el comando requerido, esos
datos estn codificados en un nico entero de 16 bits conforme a la Tabla 8
Operacin
Valor
Comentario
CMD_Reset_Transfer
Cancela la transferencia de datos en curso
CMD_Transfer_Alm
Transferir del almanaque de los satlites
CMD_Transfer_Posn
Transferir la posicin
CMD_Transfer_Prx
Transferir los waypoint prximos al

punto actual
CMD_Transfer_Rte
Transferir las rutas almacenadas en el GPS
CMD_Transfer_Time
Transferir la hora y el da
CMD_Transfer_Trk
Iniciar la transferencia de todos los puntos

almacenados en el receptor
CMD_Transfer_Wpt
Transferir waypoint almacenados en el

GPS
MD_Turn_Off_Pwr
Apagar el receptor GPS
CMD_Start_Pvt_Data
49
Iniciar la transmisin de la posicin en

tiempo real
CMD_Stop_Pvt_Data
50
Finalizar la transmisin de la posicin en

tiempo real
Tabla 8- Comandos permitidos
29
A100 - Protocolo de transferencia de Waypoints
Una vez transmitido el comando de envo de waypoints (CMD_Transfer_Wpt), se

pone en funcionamiento el protocolo que enva desde el receptor GPS todos los
waypoints almacenados en su BD.

transmisin de waypoints es:
Direccin
Nombre del paquete
Tipo del paquete
Equipo 1Equipo 2
Pid_Records
Records_type
Equipo 1Equipo 2
Pid_Wpt_Data
D108_Wayp_Type
Equipo 1Equipo 2
Pid_Wpt_Data
D108_Wayp_Type
n-2
Equipo 1Equipo 2
Pid_Wpt_Data
D108_Wayp_Type
n-1
Equipo 1Equipo 2
Pid_Xfer_Cmplt
Command_Id_Type
Tabla 9- Protocolo de transmisin de waypoints
El primer y el ltimo paquete son los de inicio y fin estndar. El primero de los
paquetes se compone de un nico entero de 16 bits que representa el nmero de
paquetes de datos que se envan a continuacin (sin contar con el paquete
Pid_Xfer_Cmplt). El ltimo de los paquetes tambin contiene un nico entero, que se
corresponde con el cdigo de operacin que se acaba de completar.
El tipo de datos D108_Wayp_Type que se muestra a continuacin 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
Color
Dspl
attr
Smbl
subclass(17)
posn
Alt
Dpth
Dist
State
cc
Ident
comment
Facility
City
addr
Cross_Road
End Type
As
As
As
As
As
As
As
As
As
As
As
As
As
As
As
As
As
As
Byte
Byte
Byte
Byte
Integer
Byte
Semicircle_Type
Single
Single
Single
String * 2
String * 2
String * 51
String * 51
String * 31
String * 25
String * 51
String * 51
Entre los datos suministrados por el receptor, los ms destacables son el smbolo
(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 posicin del waypoint representada mediante dos
enteros largos de 32 bits cada uno. Se define el tipo Semicrculo 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
informacin 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
aplicacin el dividir el bloque entero de informacin en pequeos grupos con

significado.

transmisin de puntos GPS.
Nombre del
Direccin
Tipo del paquete
paquete
Equipo 1Equipo 2
Pid_Records
Records_type
Equipo 1Equipo 2
Pid_Trk_Data
D301_Trk_Point_Type
Equipo 1Equipo 2
Pid_Trk_Data
D301_Trk_Point_Type
n-2
Equipo 1Equipo 2
Pid_Trk_Data
D301_Trk_Point_Type
n-1
Equipo 1Equipo 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 estndar. El resto de los paquetes
contienen datos del GPS con el formato D301_Trk_Point_Type definido a
continuacin:
Private Type
posn
Time
Alt
Dpth
new_trk
End Type
D301_Trk_Point_Type
As Semicircle_Type
As Long
As Single
As Single
As Boolean
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 aplicacin de que un grupo
acaba y comienza otro.
32
A600 - Protocolo de transmisin de fecha
El protocolo de transmisin de fecha est diseado para comunicar el da y la hora

entre los dispositivos. Si el receptor GPS est conectado a la constelacin de
satlites, la informacin que enva es la suministrada por los satlites; en caso
contrario, la informacin es la del reloj interno del receptor.

es:
Direccin
Equipo 1Equipo 2
Nombre del paquete
Tipo del paquete
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
month
day
year
hour
minute
second
End Type
D600_Date_Time_Type
As Byte
As Byte
As Integer
As Integer
As Byte
As Byte
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 posicin,
tiempo y velocidad del receptor GPS. Esta informacin se transmite desde el receptor
una media de una vez por segundo. El envo de datos en tiempo real se inicializa con
CMD_Start_Pvt_Data y se finaliza mediante el envo de un paquete de comandos
con el identificador CMD_Stop_Pvt_Data.
33
El envo 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 funcin para
preservar la continuidad y el orden de los datos.

se muestra en la Tabla 12.
N
0
Direccin
Host GPS
Nombre del paquete

Pid_Pvt_Data
Tipo del paquete

D800_Pvt_Data_Type
Tabla 12- Protocolo de transmisin 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 posicin del punto GPS tiene el formato definido como:
Private Type Radian_Type

Lat
Lon
End Type
As Single
As Single
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 nmero 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 das desde el 31 de diciembre de 1989 hasta el da 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 vlida, 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
tecnologas 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 mayora de las aplicaciones diseadas estaban pensadas con la

nica finalidad de almacenar y a la vez proteger los datos del receptor, y permitir la
captura de ms datos, como por ejemplo el GARTRIP 2.04c [GART-02]
En un segundo paso, y adaptndose 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 caloras consumidas, velocidades de aproximacin a
diversos puntos, velocidades medias, etc.
35
Control de la direccin y la velocidad en los automviles. Programas como el

COMPASS V1.0 [COMP-02] que muestra en todo momento la direccin del
vehculo respecto al norte geogrfico, o el SPEEDTRAP BETA V1.1 [SPEE02] que a partir de unos determinados parmetros introducidos por el usuario,
avisa en el momento en el que el vehculo sobrepasa el lmite de velocidad
preestablecido para ese tipo de va.
O simplemente determinar la posicin del usuario dentro de un mapa.

Programas como el FUGAWI v 3.0.2.6 [FUGA-02], uno de los programas
ms completos, que proporciona una interfaz sobre la que se sita un mapa de
la zona en la cual nos encontramos (en caso de que la aplicacin posea el
mapa digitalizado) mostrndose todo el recorrido.
Figura 9- Imagen FUGAWI
Una tercera generacin de aplicaciones para los GPS, entre la que se incluira el
desarrollo del presente proyecto, son aquellas que permiten almacenar los datos del
receptor para posteriormente tratarlos en, por ejemplo, aplicaciones topogrficas.
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 an 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 adems de poder transferir sus
datos a la
computadora, permite aadir imgenes de fondo, proporcionando un mayor

realismo a la representacin.
Figura 11- Imagen Trackmaker
37
Waypoint + [WAYP-02], aplicacin que aun siendo de las pocas que no tienen
una representacin grfica de la informacin, se mantiene gracias a que el
formato de almacenamiento se ha convertido en un estndar usado por la mayora
de los grandes programas de representacin grfica de los datos GPS.
Figura 12- Imagen Waypoint +
Una
caracterstica comn de todas los sistemas analizados, a excepcin de
FUGAWI, es que son entornos freeware o shareware, y no todos ellos acceden a

suministrar un soporte contnuo de la aplicacin. Otra caracterstica que las
diferencia del sistema aqu presentado, es que son aplicaciones que necesitan de un
programa ejecutndose en el cliente. Esto conlleva a que las modificaciones de la
aplicacin se hagan en base a actualizaciones del producto o a nuevas libreras que el
usuario tiene que reinstalar en su mquina.
La caracterstica principal de la aplicacin desarrollada, en el presente proyecto, es

que no requiere de ningn 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 versin 4.0. Debido al propio funcionamiento del
navegador, derivado de la forma de disear la aplicacin, cualquier modificacin en
los objetos de comunicacin con el GPS, o bien en el objeto de visualizacin, se
actualiza automticamente al entrar en la aplicacin web, sin que el usuario tenga
necesidad de reinstalar nada. En el caso de que se realice alguna modificacin en la
lgica interna de la aplicacin, 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
aplicacin est momentneamente inaccesible durante el tiempo que se tarde en dar
de baja una librera y registrar la nueva, tiempo que normalmente no excede de un
38
minuto. Otro beneficio derivado de utilizar una aplicacin cliente-servidor, es que los
datos son compartidos entre todos los usuarios del web, lo cual permite crear un
catlogo de rutas y waypoints disponible para cualquier usuario.
El hecho de trabajar con una metodologa basada en el sistema DNA permite

distribuir la carga de trabajo en diferentes servidores fsicos, de forma que un equipo
haga las funciones de servidor de web, otro de servidor de aplicacin, donde
estarn instaladas las libreras y donde se ejecutaran los procesos, y un tercero, el
servidor de datos, donde estar ubicada fsicamente la BD.
Cliente
Servidor Web
Servidor de aplicacin
Servidor de datos
Figura 13- Sistema de servidores DNA
4. METODOLOGA DE DESARROLLO
Para el desarrollo de la aplicacin se seguir una metodologa clsica, adems del

Lenguaje Unificado de Modelado, en ingls 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 aplicacin
sobre un entorno web fue la que ms beneficios ofreca. Otra ventaja es la clara
39
independencia de los clientes ante modificaciones de la aplicacin. En la peor de las

situaciones, si uno de los objetos OCX de la interfaz se modifica, el propio
navegador deber instalar una versin actualizada a partir de una URL prefijada.
Para poder trabajar sobre un entorno web, lo ms normal es utilizar HTML, DHTML
o XHTML, combinados con distintos OCX o applets.
La principal problemtica 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,
disear, configurar, mantener y controlar la informacin sobre tales sistemas. Est
pensado para usarse con todos los mtodos de desarrollo, etapas del ciclo de vida,
dominio de la aplicacin y medios.
UML capta la informacin sobre la estructura esttica y el comportamiento dinmico

de un sistema. Un sistema se modela como una coleccin de objetos discretos que
interactan para realizar un trabajo que finalmente beneficia a un usuario externo. La
estructura esttica define los tipos de objetos importantes para un sistema y para su
implementacin, as como las relaciones entre los objetos. El comportamiento
dinmico define la historia de los objetos en el tiempo y la comunicacin entre
objetos para cumplir sus objetivos.
40
4.1.1. ACTOR
Un actor es una idealizacin de una persona externa, de un proceso, o de cualquier

cosa que interacta con un sistema, un subsistema o una clase. En tiempo de
ejecucin, un usuario fsico 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 aplicacin.
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 ms actores. El propsito 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 aplicacin 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
<<uses>>
Iniciar transmision GPS
Identificarse
<<uses>>
Introducir Waypoints
<<uses>>
Parar transmision GPS
Modificar Waypoints
Figura 15- Casos de uso
42
4.1.3. VISTA ESTTICA
La vista esttica es la base del UML. Los elementos de la vista esttica de un modelo
son los conceptos significativos en una aplicacin, incluyendo conceptos del mundo
real, conceptos abstractos, conceptos de implementacin, conceptos de computacin
y todo tipo de conceptos del sistema.
La vista esttica captura la estructura del objeto. Un sistema orientado a objetos
unifica la estructura de datos y caractersticas del comportamiento en una sola
estructura de objeto. La vista esttica incluye todo lo concerniente a las estructuras
de datos tradicionales, as como la organizacin de las operaciones sobre los datos.
Waypoints
GPS
Puerto
Tipo
0..*
Download_way p()
Download_tracks()
Iniciar reloj()
Id_way point
Nombre
Descripcion
Simbolo
Comentario
Fichero
Nombre
Tamao
Tipo
Mostrar way points usuario()

Mostrar way points()
Grabar()
Modif icar()
1 0..*
Ficheros_way point()
Aadir()
0..*
Puntos GPS
0..*
Latitud
Longitud
Altura
Velocidad
Tiempo
Rutas
Nombre
Id_ruta
Mostrar rutas usuario()
Mostrar rutas()
Grabar()
0..*
1..*
Datos inicio-f in()
Datos punto()
Grabar()
0..*
1
0..1
Imagen
usuario
id usuario
Nombre
Apellidos
Mostrar datos()
1
Imagen 2D
Crear Latitud-Longitud()
Crear Altura()
Mostrar()
Imagen 3D
0..1
session
Crear()
Mostrar()
IdUsuario
Comprobar()
Figura 16- Diagrama de clases
43
4.1.4. DIAGRAMAS DE SECUENCIA
Un diagrama de secuencia representa una interaccin como un grfico bidimensional.

La dimensin vertical es el eje del tiempo, que avanza hacia la parte inferior de la
pgina. La dimensin horizontal muestra los roles de clasificador que representan
objetos individuales en la colaboracin. Cada rol de clasificador se representa
mediante una columna vertical (lnea de la vida).
4.1.4.1. DIAGRAMA DE SECUENCIA DE IDENTIFICARSE
El caso de uso comienza cuando se inicia la aplicacin y termina en el momento que

el usuario queda autentificado. Al iniciar la aplicacin, el sistema espera a que el
usuario introduzca un nombre de usuario y una contrasea. Una vez que el sistema
obtiene los datos, se activa la funcin de autenticacin y se acta 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 comunicacin 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 comunicacin , para
posteriormente inicializar la conexin con el receptor. Finalizado este proceso, la
interfaz realizar la llamada al objeto GPS que activar la comunicacin 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

comunicacin 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 comunicacin con
GPS, el interfaz le comunica al objeto GPS que la transmisin 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 transmisin 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 opcin 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 despus 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
envo 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 cuestin.
Cuando el usuario determina las rutas a insertar, se comprueba en primera instancia

el usuario conectado con la aplicacin, despus 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 volvera a la situacin 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 hara 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 ms datos, lo cual hara que
se mostrasen, los datos de el waypoint seleccionado, comprobndose 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 COMNES
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 aadir 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 aadir 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
: Usuario
Waypoints
Fichero
Modificar
[opcional] modificar datos
Modificar
[opcional] modificar ficheros
aadir
Figura 28- Diagrama de secuencia del caso de modificar waypoint
57
4.1.5. DIAGRAMA DE TRANSICIN DE ESTADOS
Un estado describe un perodo 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 perodo de tiempo, durante el cual un
objeto espera que ocurra un evento; o como perodo de tiempo durante el cual realiza
una determinada actividad.
Una transicin 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 transicin que deja un estado define la respuesta de un objeto en ese estado a la
ocurrencia de un evento. En general, la transicin tiene un evento que la activa, una
condicin de guarda, una accin y un estado destino.
4.1.5.1. DIAGRAMA DE TRANSICIN 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 transicin de estados del objeto GPS
4.2.
BASE DE DATOS DEL SISTEMA
Tras el estudio completo del dominio de la aplicacin (apartado 2) se obtiene la

estructura lgica de la BD mostrada en la Figura 30 y la estructura fsica, 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 catlogo de la
BD. Las tablas resultantes son las siguientes:
DB01TB01
Tabla con los usuarios de la aplicacin.
db010010 (Entero)
Identificador del usuario.
db010020 (Char(50))
Nombre del usuario.
db010030 (Char(50))
Apellidos del usuario
db010040 (Entero)
Nmero de accesos de los usuarios.
db010050 (Char(50))
Contrasea del usuario.
59
DB02TB01
Tabla de las rutas almacenadas en la aplicacin.
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 fornea)
DB03TB01
Tabla de relacin entre las rutas y los puntos que la componen.
db030010 (Entero)
Nmero de secuencia del punto dentro

de la ruta.
db030020 (Entero)
Identificador de la ruta. Clave fornea
db030030 (Real)
Latitud del punto GPS. Clave fornea
db030040 (Real)
Longitud del punto GPS. (Clave

fornea)
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 fornea
db050040 (Real)
Longitud del punto GPS. (Clave

fornea)
db050050 (Real)
Identificador del usuario que grabo el

waypoint. (Clave fornea)
db050060 (Entero)
Smbolo del waypoint.
db050070 (char(50))
Nombre del waypoint.
DB10TB01
Tabla con los ficheros asociados a cada waypoint.
db100010 (Entero)
Identificador de waypoint. (Clave

fornea)
db100020 (Char(100))
Nombre real del fichero.
db100030 (Entero)
Nmero secuencial.
db100040 (Entero)
Identificador del usuario que grabo el

fichero.
61
Figura 30- Representacin lgica de la Base de Datos
62
Figura 31- Representacin fsica 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
estndar de HTML ya que tanto Netscape como Microsoft se empean en incluir
directivas que solo funcionan con sus respectivos navegadores. De cualquier manera
existen diferentes revisiones o niveles de estandarizacin, 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, grficos, etc...) que contenga el
documento
Un documento escrito en HTML contendra bsicamente las siguientes directiva :
<HTML>
<HEAD>
Indica el inicio del documento

Inicio de la cabecera
<TITLE>
Inicio del ttulo del documento
</TITLE>
Final del ttulo 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 ningn tipo de dinamismo, es necesario

complementar el uso de pginas 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 vlidos, y, en a ciertos niveles, casi
parejos, se decidi utilizar el VBScript, para proporcionar un aspecto de globalidad a
la aplicacin. Por lo tanto, los componentes de comunicacin, el gestor de BD e
incluso la tecnologa 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 integracin en pginas web. Un cdigo escrito en un lenguaje de script se
incorpora directamente dentro de un cdigo HTML y se ejecuta interpretado, no
compilado. Para incorporar un fragmento de cdigo script en una pgina 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 cdigo escrito en un lenguaje de script no sufre ninguna transformacin previa a
su ejecucin. Cada lnea de cdigo se traduce al lenguaje mquina justo antes de su
ejecucin. Posteriormente se ejecuta y la traduccin no se conserva en ningn
sistema de almacenamiento (como discos, cintas, etc). Si es necesaria otra ejecucin,
el intrprete se ver abocado a realizar una nueva traduccin de cada lnea de cdigo.
65
Con la finalidad de adaptar el Visual Basic a su ejecucin 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 informacin.
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 programacin, por ejemplo, escribir las constantes completamente en
maysculas y las variables utilizando maysculas para la primera letra de cada
palabra dentro del nombre de la variable.
No acepta caracteres que no se encuentren en cdigo ASCII.
No permite instanciar objetos. Por el contrario, el propio script ofrece una

coleccin de objetos, entre los que destacan los objetos siguientes:
Window : Representa la ventana activa del navegador y es el mas alto de la

jerarqua.
Document : Representa el documento activo.
Form : Este objeto se refiere a un formulario empleado en el documento.
Location : Contiene la URL de la pgina actual
Navigator : Representa al navegador actual.
History : Representa el historial de las pginas visitadas en la sesin actual.
No permite acceder al portapapeles.
No permite el uso de colecciones.
No
puede
usar
las
instrucciones
condicionales
DoEvents,
GosubReturn, Goto, On Error GoTo, OnGosub, On...Goto,

Nmeros de lnea, etiquetas o WithEnd.
No permite declarar llamadas a las librerias del sistema.
No tiene acceso al sistema de ficheros.
No existen mtodos ni funciones graficas.
66
4.3.3. LENGUAJE ASP
Cuando se incluye dentro de una pgina HTML cdigo en script, es cierto que se le
proporciona cierto nivel de dinamismo aunque con la potencia que ofrece el
VBScript, las pginas son estticas, es decir, siempre es la misma pgina la que
muestra los mismos datos en el mismo orden. Si se quiere obtener una aplicacin
sobre web, con acceso a datos, o con una lgica ms o menos complicada, se necesita
incorporar una interfaz comn de salida, en ingls Common Gateway Interfaz (en lo
sucesivo CGI) o de una tecnologa como la de paginas activas en el servidor, en
ingls Active Server Pages ( a partir de ahora ASP).
Tal y como se ha comentado, el sistema englobara toda la aplicacin 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 modificacin, apunta a la idoneidad de desarrollar el cdigo
servidor en ASP.
Agrupadas en la categora de lenguajes de script, las pginas ASP contienen

adems de los tags habituales de HTML, fragmentos de cdigo que el servidor
resolver previamente a su envo al navegador.
La facilidad para conectar las pginas ASP con BD y, extraer y mostrar los datos de
la misma en el navegado de una forma dinmica, es la razn principal de su extenso
uso en Internet. Mediante los drivers de conexin a datos, Open Data Base
Conectivity (a partir de ahora ODBC), las pginas 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 pgina ASP no existe ninguna restriccin especial en el lado
cliente de la comunicacin, ya que el navegador nicamente recibe pginas HTML,
por tanto se pude utilizar cualquier navegador existente (Internet Explorer o
Netscape Comunicator). Sin embargo el servidor de pginas ASP requiere tener
67
instalado la librera ASP.dll para poder interpretar el cdigo ASP de las pginas. 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 aadindoles software adicional pueden procesar pginas ASP,
como por ejemplo el servidor web Chilisoft, el Instant ASP o bien el Apache,
aunque ste ltimo slo soporta ASP codificado bajo Perl.
Para que el interprete ASP reconozca cdigo ASP, ste tiene que estar enmarcado
por los tags <% en el inicio, y %> al final del cdigo..
<% Response.write (Esto es una lnea de cdigo ASP) %>
Adems de los cdigos HTML habituales una pgina ASP puede contener cdigo
script con el fin de aadir dinamismo a las pginas finales. Este cdigo script
puede estar escrito tanto en Vbscript como en JScript.
En una pgina ASP se puede declarar dentro del cdigo propio de ASP variables con
el fin de mejorar la legibilidad del cdigo. 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 das
%>
Al igual que en Visual Basic, no es necesario declarar todas las variables, pero es una
buena prctica. Para asegurar que todas las variables que se usen tengan que estar
declaradas se puede incluir la instruccin Option Explicit dentro del cdigo
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 das
%>
Los objetos ASP son programas compilados e instalados en el servidor que han sido
programados para realizar un conjunto de operaciones fcilmente accesibles por las
pginas. Estas operaciones se denominan mtodos.
Las pginas 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 informacin

entre los usuarios de una aplicacin dada. Las variables almacenadas dentro del
objeto Application son visibles para todos los usuarios que estn utilizando la misma
aplicacin 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
Eventos
Application_OnEnd
Descripcin
Se ejecuta al terminar la
ejecucin del servidor web
Se ejecuta cuando entra por
Application_OnStart
primera vez un usuario en la

aplicacin web
Bloquea el objeto application
Mtodos
Lock
para todos los usuarios excepto

el que ejecuta el mtodo Lock
69
Unlock
Contents.Remove
Contents.RemoveAll
Desbloquea el objeto
Elimina un tem especifico de
la coleccin Contents
Elimina todos los tems de la
coleccin Contents
Contiene los tem aadidos al
Colecciones
StaticObjects
objeto Application mediante el

tag < OBJECT >
Contents
Contiene todos los tems

aadidos al objeto Application
Tabla 13-Objeto Application
Objeto ASPError
El objeto ASPError sirve para obtener informacin detallada de una condicin de

error producida durante la ejecucin de la aplicacin. Esta informacin se obtiene de
9 propiedades de slo lectura, a las que solamente es posible acceder a travs del
objeto Server y su mtodo GetLastError
Nombre
Propiedades
ASPcode
ASPDescription
Descripcin
Cdigo de error
Descripcin del cdigo de
error
Cadena que indica si se trata
Category
de un error interno de ASP, del

lenguaje de secuencia de
comandos o de un objeto
70
Entero que indica la posicin

Column
de la columna del archivo ASP

que gener el error.
Description
Descripcin del error

Cadena que contiene el
nombre del archivo ASP que
File
se estaba procesando cuando

se produjo el error.
Line
Lnea donde se genero el error

Entero que representa un
Number
cdigo de error estndar de

COM.
Cadena que contiene el cdigo
Source
fuente real, si est disponible y

la lnea que caus el error.
Tabla 14- Objeto ASPError
Objeto Session
Cuando un usuario invoca por primera vez cualquiera de los ficheros de una
aplicacin se le asigna un objeto Session. Este objeto ser utilizado por la aplicacin
para almacenar, compartir y recibir informacin del usuario. Por defecto, el objeto
ser destruido despus 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
Propiedades
CodePage
LCID
Descripcin
El cdigo de caracteres usado
Identificador de zona para
definir los formatos de fecha,
71
hora, decimales, etc.

SessionId
Timeout
Eventos
Session_Onstart
Session_OnEnd
Mtodos
Abandon
Contents.Remove
Contents.RemoveAll
Colecciones
Contents
Identificador de la sesin
Tiempo de inactividad para
destruir la sesin
Ocurre justo antes de crear el
objeto Session
Se ejecuta cuando se elimina
la sesin
Dar por terminada la sesin
Elimina un tem especifico de
la coleccin Contents
Elimina todos los tems de la
coleccin Contents
tems aadidos al objeto
Session
Contiene los tem aadidos al
StaticObjects
objeto Session mediante el tag

< OBJECT >
Tabla 15- Objeto Session
Objeto Request
El objeto Request permite el acceso a toda la informacin transmitida desde el

navegador del cliente y el servidor. Esta informacin se reparte y almacena entre
cinco colecciones. Los datos, una vez cargados, pueden ser accedidos
individualmente en cada coleccin a travs de una nica clave asignada a cada tem.
72
Nombre
Propiedades
TotalBytes
Mtodos
BinaryRead (count)
Colecciones
ClientCertificate
Cookies
Form(Elemento)
QueryString
(Elemento)
ServerVariables
Descripcin
Nmero total de bytes
enviados por el cliente al
servidor en el cuerpo de la
llamada http
Datos que han sido enviados al
servidor desde el cliente a
partir de un formulario. El
parmetro count indica el
numero de bytes a leer.
Esta coleccin tiene utilidad si
estamos escribiendo una
aplicacin que utiliza el
protocolo Secure Socket
Layers (SSL)
La coleccin Cookies asigna
datos a un fichero existente, y
si ste no existe, crea uno
nuevo donde almacena estos
datos
Elementos de un formulario
usando el mtodo post, donde
Elemento es el nombre del
elemento del formulario que se
quiere recibir desde el
navegador
Los elementos del formulario
usando el mtodo get
Esta coleccin contiene el
valor de las variables de
entorno del servidor
Tabla 16- Objeto Request
73
Objeto Response
Response (respuesta) es posiblemente el objeto ms utilizado de todos, ya que sirve

para presentar en la pantalla del navegador del cliente el resultado de cualquier
cdigo.
Nombre
Propiedades
Buffer
CacheControl
Charset
ContentType
Expires
ExpiresAbsolute
IsClientConnected
Status
Colecciones
Cookies
Mtodos
AddHeader
Descripcin
Indica si la pgina HTML se
enviara una vez acabado la
traduccin ASP o bien se
enviar a la vez que se traduce.
Esta propiedad permite a los
servidores proxy guardar en
su cache una copia de la
respuesta ASP
Define la tabla de caracteres a
usar durante la codificacin de
la pgina.
Esta propiedad especifica el
tipo de contenido del request
HTTP
Indica el nmero de minutos
que deben transcurrir antes de
que la copia de la respuesta en
las caches del navegador sea
eliminada.
Igual que la anterior pero
define una fecha y horas
exactas para ser eliminada
Con esta propiedad se puede
saber si el cliente continua
conectado al servidor desde la
ltima vez que la aplicacin
escribi algo en la pantalla
valor de la lnea de estado
HTTP devuelta por el servidor.
Asigna los valores a los
ficheros temporales del
navegador ( cookies )
Este mtodo permite aadir
una nueva cabecera a la
respuesta http
74
AppendToLog
BinaryWrite
Clear
End
Flush
Redirect
Write
Aadir un string al registro

que se genera con cada request
en el fichero de logs del IIS.
Escribe la salida HTTP en
binario
Elimina cualquier contenido
del buffer de salida
Detiene el proceso de la pgina
ASP actual y enva al cliente el
contenido del buffer de
salida
Provoca el envo inmediato al
cliente del contenido del
buffer de salida.
Detiene el proceso de las
instrucciones de la pgina
actual e intenta conectar el
cliente a una nueva direccin
Escribe los datos en el buffer
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
Propiedades
ScriptTimeOut
Mtodos
CreateObject
Execute
GetLastError
Descripcion
tiempo, medido en segundos,
disponible por una pgina o
script para ejecutarse.
Crea instancias de los objetos
en el servidor
Permite llamar desde una
pgina ASP a otra pgina ASP
Devuelve el ltimo error de
una pgina ASP
75
HTMLEncode
MapPath
Transfer
URLEncode
Convierte una cadena de

caracteres HTML a cdigo
visible
Traza un mapa de rutas fsicas
(absolutas) partiendo de rutas
virtuales (relativas)
Permite llamar desde una
pgina ASP a otra pgina ASP.
Cuando la pgina llamada
concluye su proceso, el control
no vuelve a la pgina inicial, y
concluye en la pgina llamada.
Convierte un string que
contiene una direccin URL en
formato ASCII a formato
URL-encoded.
Tabla 18- Objeto server
4.3.4. IIS (INTERNET INFORMATION SERVER )
Ya que toda la aplicacin 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 razn 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
cdigo 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 informticos. 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 automtica por defecto. Esta versin mejora
la confiabilidad, administracin, seguridad y los servicios de aplicacin.
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 tecnologas DCOM & MTS han sido fusionadas en el sistema
denominado COM+.
El IIS 5 incluye soporte para los ltimos estndares usados en Internet. Implementa
el protocolo HTTP 1.1, compresin HTTP, SSL 3.0, CGI, y el servicio WebDAV que
permite la gestin 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 extensin de datos existentes y aplicaciones externas a Internet
Soportar un amplio rango de dispositivos cliente
Una aplicacin de tres capas es aquella cuya funcionalidad se pueden dividir en tres
capas lgicas:
Capa de presentacin.
Capa de aplicacin.
Capa de datos.
77
Un aspecto muy importante de la capa de aplicacin es la capacidad de utilizar los

mismos componentes en varias aplicaciones. Es decir, los componentes son
reutilizables. Adems 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 aplicacin es una estructura lgica y los
componentes se comunican entre s de la misma manera, estn o no en el mismo
nivel.
Las peticiones de servicios no pueden "saltar" niveles; es decir, los componentes de

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

clientes utilizarn para visualizar la informacin 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 aplicacin.Aunque la lgica de aplicacin se encapsula en componentes
la capa de aplicacin, los componentes de la capa de presentacin permiten al
usuario tener acceso a todos los procesos.
Los servicios de usuario normalmente estn contenidos en la aplicacin cliente

aunque no siempre es as. Por ejemplo, si se quiere implementar un conjunto estndar
de mensajes de error, aunque sin distribuirlo a todas las mquinas, lo ideal sera crear
esta capa de presentacin como un ActiveX para situarlo en un servidor.
78
Capa de Aplicacin o Negocios
Como la capa de presentacin 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 aplicacin para llamar a procedimientos

almacenados en la BD, los componentes de aplicacin implementan dichos
procedimientos y definen los papeles de negocio.
Los componentes de la capa de aplicacin tambin 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 aplicacin. Por lo tanto, una buena razn para dividir la lgica
de aplicacin en componentes, es la probabilidad de que dicha lgica cambie,
teniendo que rescribir el cdigo de la aplicacin. De este modo, se rescribe
nicamente el componente correspondiente a la lgica 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 aplicacin es una estructura lgica y los componentes se comunican entre
s de la misma manera, estn o no en el mismo nivel.
Las peticiones de servicios no pueden "saltar" niveles: es decir, los componentes de

la capa de presentacin no se pueden comunicar directamente con los de la capa de
datos, y viceversa
79
Capa de datos
La capa de datos incluye las tpicas tareas de gestin de datos: altas, bajas,
modificaciones, etc. La clave est en que las funciones de aplicacin no se
implementen aqu. Aunque un componente de la capa de datos es responsable de la
gestin de las peticiones realizadas por un objeto de aplicacin, 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. Adems, pueden
proporcionar acceso a datos en varias plataformas sobre cualquier nmero de
servidores. Una capa de datos apropiadamente implementado, debera permitir
cambiar su localizacin sin afectar a los servicios proporcionados por los
componentes de negocio.
4.3.6. ACTIVEX / COM
Una vez definidos los entornos y la metodologa de trabajo ser necesario estudiar el
modo de trabajo del usuario final. El usuario necesitar que la aplicacin 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 mtodos descritos hasta el
momento, HTML, VBScript, ASP, es imposible acceder al equipo cliente. Esta
limitacin, 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 comunicacin 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
ms elegante, pero requerir que el usuario final instale el plugin en su maquina
despus de cada modificacin, caracterstica poco deseada. Crear un componente
OCX e incluirlo en las pginas, provoca una cierta lentitud al cargar las pginas, 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
versin de los componentes que en caso de no tener la versin adecuada, reinstala el
OCX sin necesidad de ninguna accin por parte del usuario, excepto la de dar su
autorizacin.
Los antecedentes de la tecnologa ActiveX se remontan a la tecnologa Object

Linking and Embedding (OLE versin 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 dinmico de Datos, la cual se implemento en
aplicaciones de Microsoft.
La idea bsica de todas estas tecnologas es disear aplicaciones que puedan
intercambiar datos y compartir cdigo, de forma que sean accesibles entre ellas. En
concreto los controles OLE actan en forma de pequeos mdulos de aplicaciones,
diseados para ser incluidos por los programadores en aplicaciones finales.
La tecnologa subyacente en ActiveX basada en OLE y COM (Component Object

Model), aunque se trata de una herramienta de programacin general, fue
desarrollada con vistas a implementar pginas iNet (Internet e Intranets) ms
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 ubicacin. En el
caso de no estar ya en la plataforma cliente se deber transferir a sta, registrarlos en
su sistema y ejecutar el cdigo asociado.
Las caractersticas de trabajo de los ActiveX se centran en:
81
Los mdulos tienen unas caractersticas de autonoma propia. Por tanto, debe ser
cdigo binario (compilado) que sea capaz de definir cuando iniciar y cuando
terminar su ejecucin.
El cdigo generado ha de tener la capacidad de interactuar con otros mdulos

ActiveX y, o, ejecutables finales. En las bases del estndar 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 aplicacin servidora y gestionar su
informacin como si de datos propios se tratara.
La actualizacin del cdigo de un control ActiveX no debe suponer una

reprogramacin de las aplicaciones clientes (aquellas que lo utilicen).
Hay que tener en cuenta que en estos momentos, unicamente pueden visualizarse
pginas con controles ActiveX mediante Microsoft Internet Explorer 3.x o
superior. Se deber esperar a las prximas 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 insercin 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
Descripcin
Un identificador nico que sirve para referenciar los
ID
parmetros y acceder a los valores de propiedades,

cuando se trabaje con cdigo script, Java u otros
ClassID
Contiene la clave del control ActiveX que ha de

registrarse en la computadora cliente.
Indica, en forma de una cadena URL, en que lugar se
Codebase
encuentra el control ActiveX. Si no se especifica nada,

se supone que se encuentra en el URL base del
documento.
Width y Height
Align
Border
Parmetros
Fija el ancho y le alto que ocupar el control ActiveX

en la pgina html.
Fija el modo de alinear el control en la pgina html.
Fija el tipo de borde que aparecer en el contorno de
Control Actives
Aqu se fijan las propiedades (properties)
caractersticas del control ActiveX.
Tabla 19- Caractersticas de un OCX sobre HTML
4.3.7. VRML
A mayores de las imgenes generadas por el OCX, la aplicacin muestra los datos de
la ruta en un entornos tres dimensiones. Para la creacin de esta representacin se
estudiaron diversos productos, aunque el nico viable resulto ser el VRML debido
principalmente a su sencillez, a lo rpido que se transmite y a que nicamente
requiere de un pequeo 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 disean
objetos tridimensionales y su
comportamiento, lo cual requiere una mayor planificacin desarrollo de las pginas.

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 tecnologa es cada vez ms accesible para el usuario medio, debido a que los
equipos son cada vez ms potentes.
La propuesta pblica 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
publicacin periodica revista Wired, se estableci una lista de correo con el objetivo
de conseguir una primera especificacin del lenguaje.
La alternativa presentada por Silicon Graphics, basada en su producto

OpenInventor, fue la que consigui un mayor numero de votos, convirtindose en
el punto de partida del nuevo estndar. Finalmente en octubre de 1994 se present la
especificacin de VRML 1.0.
Posteriormente se fund el VRML Architecture Group o grupo de aquitectura

VRML, tambin conocido como VAG. Este grupo tena la misin de ayudar en la
clarificacin e implementacin de la especificacin 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 disposicin del pblico 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 cdigo estndar WRML.
VRML 1.0 es el lenguaje para la descripcin de mundos virtuales estticos, 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 estticos no satisfacan todas las
necesidades para las cuales haba sido creado
En la conferencia Siggraph de 1996, la propuesta Moving Wolds, Mundos en

movimiento, fue ratificada por el VAG como la especificacin oficial del VRML 2.0.
Esta nueva versin 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 interaccin con el usuario mediante la definicin de sensores de

posicin, contacto, colisin, etc. La informacin registrada por estos sensores es
enviada a los diferentes objetos que componen el mundo virtual para en funcin
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 estn 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 versin 3.0 del estndar VRML.
4.3.8. SISTEMA GESTOR DE BASES DE DATOS
Despus de estudiar los sistemas ms conocidos como SQL server, Oracle, se

aprecia que, para las necesidades reales de la aplicacin, cualquiera de estos
productos era demasiado potente. Una vez determinadas estas necesidades se llego a
la conclusin 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 idneo 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 ms potente, se decidi realizar todos los accesos mediante ODBC a travs
de una librera 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 especficos de los usuarios, se ha realizado una clara
divisin del sistema en los siguientes mdulos (Figura 32):
Mdulo de acceso a datos
Mdulo de comunicaciones
Mdulo de visualizacin
Mdulo de gestin de negocio
El mdulo de acceso a datos es el encargado de atender las peticiones de informacin

de los restantes mdulos. Esto es, rige toda la poltica de transferencia de datos entre
86
dichos mdulos 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 diseo de la BD.
El mdulo de comunicaciones incluye los componentes encargados de la
transferencia de informacin entre el receptor GPS el mdulo 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 mdulo de visualizacin es el encargado de crear y visualizar las rutas de
navegacin. Este mdulo incluye tanto las posibilidades de visualizacin en 2D y
3D. Sealar que es de vital importancia la visualizacin 3D ya que los GPS gestionan
puntos del espacio eucldeo.
El mdulo de negocio es el encargado, a travs del modulo de acceso a datos, de la
gestin propia de la aplicacin (altas, bajas, modificaciones y consultas de la BD).
Servidor de
aplicacin
Modulo
negocio
Modulo de
acceso a BD
Modulo de
visualizacin
Modulo de
comunicacin
CLIENTES
Figura 32- Mdulos del sistema
La implementacin especifica de los mdulos contemplo el desarrollo de un conjunto

de componentes OCX y librerias externas, destacando los siguientes componentes:
87
En
el
mdulo
de
comunicaciones,
los
objetos
GPS_GARMIN,
CONTROL_FTP
En el mdulo de visualizacin, el objeto VISOR.
Para el desarrollo de la aplicacin se han implementado tres componentes OCX, uno

para la comunicacin 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
aplicacin presentada, junto como la aplicacin web, y un ejemplo de BD, se
adjuntan en el CD-ROM que acompaa 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 mtodos y propiedades del objeto.
Nombre
Propiedad
Puerto
Descripcin
Identifica el puerto de donde se
recogen los datos
Mtodos
Estado
Indica si se est transmitiendo.
Inicializa_gps(puerto)
Inicializa la comunicacin con el

receptor en el puerto indicado
Termina_gps(puerto)
Cierra la comunicacin en el
puerto indicado
Get_product_data(puerto)
Recoge el modelo del receptor

GPS una vez iniciada la
comunicacin.
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 mtodos 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 implementacin, y un
gran portabilidad a otros entornos.
En la aplicacin, 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 aplicacin. Para que el acceso al servidor de FTP
sea cmodo 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
Mtodos
Subir_fichero(txtFileLocal,
txtFileRemote,
txtUsuario,
sobreescribir)
Descripcin
Envia el fichero txtFileLocal
txtServidor, al
servidor
de
FTP
txtPassword,, txtServidor con el nombre de

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 mtodos del OCX control_FTP
El componente VISOR.OCX, del modulo de visualizacin, fue diseado para poder

representar los datos almacenados en la base de datos. El OCX utiliza una
representacin 2D para reflejar la informacin 3D derivada de las rutas creadas por
los receptores GPS. La primera imagen representa la informacin sobre el eje X e Y y
la segunda sobre los ejes X y Z.
89
Nombre
Propiedad
Color_fondo
Descripcin
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.
Mtodos
Carga (datos )
Se genera el archivo de
imagen seleccionado con los
datos. Estos datos tienen que
estar formateados en XML.
Tabla 22-Propiedades y mtodos OCX visor
6. VALIDACIN DEL SISTEMA
Para la validacin del sistema, se han seguido los siguientes pasos.
1. Seleccin de usuarios de GPS
Para la validacin del sistema se ha contado con la colaboracin 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
localizacin y posicionamiento de cavidades.
90
2. Seleccin de casos reales
Para la validacin del sistema, se aportan rutas de aproximaciones y

localizaciones concretas de cavidades pertenecientes a diferentes zonas
geogrficas de Espaa.
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 Llonn
Cantabria
Ruta y posicionamiento del sistema Cueto-Coventosa
3. Pruebas de los mdulos 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 modificacin de waypoint reales.
El sistemas de visualizacin 2D y 3D mediante la representacin de rutas.
Como ltimo punto de la validacin sealar que el director del proyecto abandono la
aplicacin que utilizaba habitualmente, el Waypoint + , sustituyndolo por el
presente desarrollo.
91
7. CONCLUSIONES
En los ltimos aos se ha observado un fuerte crecimiento en las reas de aplicacin
de los sistemas de posicionamiento global por satlite, y su diversificacin a todo
tipo de usuarios.
Unido a esto han aparecido en el mercado todo tipo de aplicaciones de gestin,

visualizacin y tratamiento de los datos proporcionados por los receptores GPS. Los
sistemas analizados presentan un bajo nivel de integracin, as como unas reducidas
posibilidades a la hora de integrar las herramientas especificas de este tipo de
sistemas ( gestin de datos, visualizacin, etc..)
Con esto en mente, el presente proyecto aporta una potente herramientas para el
tratamiento de los datos en un entorno cliente-servidor. Adems, el uso de sistemas
gestores de BD aporta todo tipo de funcionalidades: generacin de vistas, integridad
de los datos, consistencia, niveles de seguridad,
La metodologa empleada, unida al modelo de aplicaciones DNA, garantiza la

escalabilidad de la aplicacin, facilitando un esquema de modificaciones sistemticas
independiente del usuario.
El sistema se ha validado con informacin real de rutas distribuidas por toda la

geografa espaola, con la ayuda de un usuario asiduo de los receptores GPS, en este
caso el propio director del proyecto.
Se puede concluir que la aplicacin resultante de este proyecto, cubre con creces las
necesidades iniciales de los usuarios.
Como es lgico, todo proyecto o sistema es un ente en continua evolucin. Entre las
posibles alternativas de futuro, destacan las posibilidades relacionadas con la
visualizacin 3D de las rutas sobre mapas topogrficos, permitiendo la visualizacion
92
a tamao 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
aplicacin en los sistemas de posicionamiento por satelite.
8. GLOSARIO DE TRMINOS
A-S
(Anti-Spofing) Cdigo para cifrar los datos de la seal GPS.
Banda L
Rango de frecuencias entre los 1 GHz y 2 GHz . Asignado

principalmente a la telefona mvil y las emisiones digitales de audio
a nivel mundial.
C/A
(Coarse /Acquisition) Cdigo de adquisicin grueso. Componente de

la seal producida por los satlites 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) Librera de acceso dinmico
Efemrides
Parmetros orbitales precisos de cada satlite.
HOW
(Hand Over World) Valor que marca la diferencia de ngulo entre las
dos seales que componen la seal GPS.
NAVSTAR
(Navigation System and ranging) Sistema de navegacin y

determinacin de alcance
NMEA
Nacional Marine Electronic Association
ODBC
(Open DataBase connectivity) Objeto de conexin a base de datos
PVT
(Position, Velocity, Time) Siglas con las que se conoce a la unin de

estos tres datos.
SA
(Selective Availability) Disponibilidad selectiva. Error introducido en

la seal del satlite GPS.
93
TTFF
(Time to fix first) Tiempo que tarda un receptor GPS en recibir la

primera posicin de los satlites.
UTC
(Universal time coordinated) Tiempo universal coordinado base

uniforme para medir la hora en cada zona del mundo.
Waypoint
Punto en el camino
BIBLIOGRAFA
Sistemas de posicionamiento global por satlite
[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
inters
para
GPS.
http://www.uco.es/~bb1rofra/
documentos.html. 2002
[4] Descripcin tcnica del GPS. http://dique1.ls.fi.upm.es/cuco/Documentos/
desgps.html. 2002
[5] Sistema de localizacin por satlite. 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 Pardias Garca: GPS: Sistema de Posicionamiento Global.
Universidad de Santiago de Compostela. 1998
[9] El receptor GPS. http://members.tripod.com/~isolmar/gps.htm. 2002
[10]
Tecnologa 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] Programacin en Visual Basic. http://www.terra.es/personal/jrcabrera/. 2002
[19] J. Bobadilla, A. Alcocer, S. Alonso, A. Gutierrez: HTML Dinmico, ASP y
Javascript a travs 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: Informacin. http://www.iespana.es/helpdna/prdnaart.htm.
2002
[26] MSDN en lnea. http://www.microsoft.com/latam/msdn/articulos/1999/09/
art04/. 2002
[27] Documentacin 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 informacin necesaria para la utilizacin del
Sistema Gestor de Puntos GPS desarrollado en el presente proyecto.
Configuraciones previas
Para poder utilizar correctamente la aplicacion es necesario modificar la
configuracin de seguridad del Internet Explorer (a partir de ahora IE) para que
permita que los componentes ActiveX, insertados en la aplicacin, puedan ser
utilizados sin problemas.
En el men de Herramientas de la barra superior del IE, seleccionamos la opcin
Opciones de Internet
Figura 33- Men herramientas, opciones de internet
En la nueva pantalla, se selecciona la pestaa seguridad, y en ella se elige la opcin

Sitios de confianza, y pulsamos sobre el botn Sitios
Figura 34- Opciones de internet, Sitios de confianza
97
En la nueva ventana se nos da la posibilidad de aadir direcciones web al grupo de

sitios de confianza. Escribimos la direccin 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 direccin 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

aplicacin esta lista para ser usada.
98
Manejo de la aplicacin
La aplicacin esta accesible en la direccin

http://gurrumito.dc.fi.udc.es/gps2/
En un primer momento, se muestra la pantalla de presentacin (Figura 36)
Figura 36- Pgina de entrada a la aplicacin
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
visualizacin de los datos
Si el usuario est registrado y la autenticacin has sido satisfecha satisfactoriamente,
se proporcionar un acceso completo al sistema.
99
La siguiente pantalla permite al usuario configurar el puerto de conexin con el

receptor GPS. Pulsando sobre la opcin inicializar gps, la comunicacin se
establecer siempre y cuando todo est perfectamente interconectado.
Figura 37- Pgina de inicio de un usuario registrado
En ese momento el sistema nos comunicar el modelo y versin del receptor GPS
conectado mediante un mensaje emergente.
Figura 38- Mensaje con los datos del receptor
Si pulsamos sobre el botn aceptar, el sistema comienza a monitorizar la recepcin

de paquetes. Mientras tenga lugar la monitorizacin, 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 accin, el sistema proporcionar, cada
segundo, la fecha y hora almacenadas en el receptor.
Una vez iniciada la comunicacin, podemos detenerla, pulsando sobre el botn

parar gps, o transferir las rutas o los waypoints almacenados en el receptor.
100
Si seleccionamos la opcin de Transferir rutas, una ventana de transmisin 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 aadir los puntos de inicio y fin de una ruta como
waypoint, se deber marcar la opcin 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, tambin podemos transferir los

datos de los waypoints almacenados en el receptor, pulsando sobre Transferir
waypoints. La pantalla que aparece a continuacin 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 informacin dispone de un conjunto de entornos para una oportuna gestin
de los datos, a nivel de alta de ficheros, modificacines, visualizacin, etc..(Figura
41, Figura 42, Figura 43)
Figura 41- Modificar el smbolo de un waypoint
102
Figura 42- Visualizacin de un waypoint
Figura 43- Visualizacin de una ruta
103

Estado Del Arte GPS

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Estado Del Arte GPS

Uploaded by

Copyright:

Available Formats

)$&8/7$''(,1)2507,&$

Departamento de Tecnologas de la Informacin y las Comunicaciones

PROXECTO DE FIN DE CARREIRA DE ENXEERA TCNICA EN

Desarrollo de un Sistema Gestor de Rutas de

Autor: Miguel Penn lvarez

SISTEMA GESTOR DE RUTAS DE POSICIONAMIENTO GLOBAL POR SATLITE

DOMINIO DE LA APLICACIN. SISTEMAS GPS.............................. 5

EL SISTEMA NAVSTAR GPS ............................................................................ 6

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

CARACTERSTICAS DE LA SEAL DE LOS SATLITES GPS ................. 13

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

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

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

METODOLOGA DE DESARROLLO .................................................. 39

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

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

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

VALIDACIN DEL SISTEMA............................................................... 90

GLOSARIO DE TRMINOS .................................................................. 93

SISTEMA GESTOR DE RUTAS DE POSICIONAMIENTO GLOBAL POR SATLITE

SISTEMA GESTOR DE RUTAS DE POSICIONAMIENTO GLOBAL POR SATLITE

Figura 32- Mdulos del sistema.............................................................................. 87

SISTEMA GESTOR DE RUTAS DE POSICIONAMIENTO GLOBAL POR SATLITE

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

SISTEMA GESTOR DE RUTAS DE POSICIONAMIENTO GLOBAL POR SATLITE

SISTEMA GESTOR DE RUTAS DE POSICIONAMIENTO GLOBAL POR SATLITE

D. ANTONINO SANTOS DEL RIEGO, Profesor Titular de la

HACE CONSTAR QUE: La memoria titulada Sistema Gestor de

Comunicaciones de la Universidad de La Corua, y constituye su

A Corua, 23 de Enero de 2002

Fdo: Prof. D. Antonino Santos Del Riego.

SISTEMA GESTOR DE RUTAS DE POSICIONAMIENTO GLOBAL POR SATLITE

SISTEMA GESTOR DE RUTAS DE POSICIONAMIENTO GLOBAL POR SATLITE

SISTEMA GESTOR DE RUTAS DE POSICIONAMIENTO GLOBAL POR SATLITE

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

Con esto en mente, el presente proyecto se centrar en el estudio e integracin de los

Sistemas de entrada / salida de datos

Sistemas de almacenamiento centralizado de datos en bases de datos, lo que

Gestin de puntos GPS

Desarrollo de un sistema de visualizacin en 2D de rutas creadas a partir de

Desarrollo de un sistema de visualizacin 3D

Adems, se abordar el diseo y la construccin de una aplicacin en el dominio del

2. DOMINIO DE LA APLICACIN. SISTEMAS GPS

SISTEMA GESTOR DE RUTAS DE POSICIONAMIENTO GLOBAL POR SATLITE

transcurrido en la transmisin de la seal entre el satlite y el receptor GPS. Al

EL SISTEMA NAVSTAR GPS

Figura 1- Segmentos del sistema de satlites

SISTEMA GESTOR DE RUTAS DE POSICIONAMIENTO GLOBAL POR SATLITE

El segmento espacial NAVSTAR GPS est

Figura 2- Constelacin de satlites

Caractersticas de las constelaciones NAVSTAR Y GLONASS

de los Estados Unidos de

NAVSTAR System Ltd

Media ( 20,200 Km)

Media ( 19,200 Km)

Periodo de 11h 15min

Tabla 1- Comparacin entre NAVSTAR y GLONASS

SISTEMA GESTOR DE RUTAS DE POSICIONAMIENTO GLOBAL POR SATLITE

El segmento de control consta de cinco estaciones de monitorizacin localizadas en

Figura 3 - Segmento de control

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

SISTEMA GESTOR DE RUTAS DE POSICIONAMIENTO GLOBAL POR SATLITE

El sistema NAVSTAR GPS se basa en la medida simultnea de la distancia entre el

por los cuatro satlites