Mejora de la Disponibilidad de SBAS en Navegación Terrestre

Mejora de la Disponibilidad de SBAS en
Navegación Terrestre
José Santa Lozano
[email protected]
Directores:
Benito Úbeda Miñarro
Antonio Fernando Gómez Skarmeta
MEMORIA TESIS DE MASTER
Master en “Tecnologı́as de la Información y Telemática Avanzadas” – Curso 2007/08
Dpto. Ingenierı́a de la Información y las Comunicaciones
Dpto. Ingenierı́a y Tecnologı́a de Computadores
Facultad de Informática. Universidad de Murcia.
Campus de Espinardo. 30100 Murcia. Spain.
Mejora de la Disponibilidad de SBAS en Navegación Terrestre
1
Resumen Extendido
Actualmente, los sistemas SBAS (Satellite Based Augmentation System) se usan a nivel mundial
en una buena parte de los receptores GPS del mercado. Mediante SBAS, los receptores son capaces
de mejorar la precisión, fiabilidad y disponibilidad de la posición ofrecida por GPS. La información de
corrección ofrecida por SBAS llega al usuario mediante mensajes de corrección enviados desde satélites
geoestacionarios. Esta información es generada mediante un análisis de los datos recibidos en diversas
estaciones de monitorización emplazadas en lugares de la geografı́a donde el SBAS ofrece cobertura.
Los datos de estas estaciones son centralizados en una estación de procesamiento de datos, encargada
de enviar la información de corrección a los satélites geoestacionarios, los cuales realizan el reenvı́o a
todos los receptores que se encuentran en la zona del globo terrestre cubierta. Los SBAS presentan, sin
embargo, dos inconvenientes importantes. Por un lado, la recepción de dichos mensajes desde el satélite
geoestacionario, que cubre un área geográfica concreta, puede ser imposible en lugares donde no existe
una lı́nea de visión directa, como en el caso de la navegación terrestre en zonas urbanas o de montaña.
Además de esto, la decodificación de los mensajes SBAS presenta una tarea ciertamente compleja, por
lo que el soporte hardware, o por parte del firmware instalado en el receptor GPS, presenta un problema
en productos de bajo coste.
La tecnologı́a SISNeT (Signal In Space through the interNeT ), ideada por la ESA, ofrece desde hace
algunos años la posibilidad de obtener los mensajes transmitidos por el sistema SBAS Europeo EGNOS
(European Geostationary Navigation Overlay Service) a través de Internet. Dicho sistema soluciona
parcialmente el problema. En cualquier caso, si bien es cierto que se puede disponer de la señal SBAS
en lugares de baja cobertura, el receptor, no obstante, debe ser compatible con SBAS y, aún haciéndolo,
se añade el problema de soportar la recepción de los mensajes a través de un puerto local. Además, el
retardo de los mensajes recibidos desde SISNeT también supone un inconveniente añadido, ya que las
correcciones se degradan con el paso del tiempo.
Con la intención de solventar dichos problemas, y de ampliar el rango de uso de SBAS, el presente
trabajo presenta y analiza un sistema de recepción de mensajes SBAS basado en Internet con capacidades
de conversión hacia un formato de mensaje más común y de menor complejidad. Los mensajes SBAS se
pueden recibir tanto desde SISNeT como desde un servidor localizado en una estación de monitorización
de desarrollo propio. Esto evita los problemas de disponibilidad y retardo de SISNeT. Los mensajes
recibidos en un ordenador de a bordo (de bajo coste) pueden ser enviados directamente al receptor GPS,
o procesados en mensajes de corrección diferencial en formato RTCM SC-104. Dichos mensajes son
soportados por una amplia gama de receptores de gama baja, debido a su simplicidad de procesamiento
y a su amplia aceptación a nivel mundial.
Se ha desarrollado un prototipo en términos hardware y software, mediante una estación de monitorización que ofrece una alternativa a SISNeT, y un vehı́culo dotado del sistema remoto y capaz de
realizar la decodificación de mensajes para enviarlos a un receptor GPS de bajo coste. Dicho prototipo
ha sido usado para testear el sistema en entornos de funcionamiento real. A través de diversos recorridos
realizados con un vehı́culo prototipo, se ha analizado el funcionamiento del sistema en emplazamientos
rurales e interurbanos. Los resultados demuestran que es posible disponer de un sistema equivalente al
satelital mediante la recepción de mensajes EGNOS a través de Internet y su posterior conversión a
RTCM. Mediante la provisión continua de información sobre corrección es posible disminuir, además, la
degradación que se produce en las correcciones con el paso del tiempo en lugares en donde existe una
discontinuidad de la señal de EGNOS.
Palabras clave: SBAS, GPS, EGNOS, SISNeT, GNSS, Navegación Terrestre.
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
2
José Santa Lozano
1.
[email protected]
Introducción
Las correcciones diferenciales son aplicadas desde hace años en los sistemas de posicionamiento global
por satélite (GNSS o Global Navigation Satellite System). Generalmente, esta técnica se suele emplear
junto con el GNSS americano, esto es, GPS (o Global Positioning System); y es por esto que a las
técnicas de corrección diferencial se las suele denominar DGPS (Differential GPS ). El funcionamiento
básico de un sistema de corrección diferencial se centra en la transmisión de desviaciones en las medidas
de distancia hacia los satélites [3]. Dicho trabajo es llevado a cabo por una estación de referencia. En
el lado del usuario, el equipo receptor de la señal GNSS aplica las correcciones recibidas, con lo que
consigue mejorar la posición obtenida mediante el algoritmo de triangulación. Existen, sin embargo,
diversos métodos para ofrecer correcciones diferenciales.
Si tenemos en cuenta el momento en que se aplican las correcciones, podemos distinguir entre técnicas
de corrección diferencial en post-proceso o en tiempo real. En el primero de los casos, la información
de navegación recogida durante un periodo de funcionamiento del receptor es utilizada para aplicar
las correcciones diferenciales a posteriori, para obtener de esta manera una posición mejorada. Dicho
procedimiento es especialmente usado en labores de recolección de datos cartográficos, mediciones de
terrenos y estudios geográficos. Las correcciones suelen ofrecerse a través de Internet, como es el caso
del servicio ofrecido por la Consejerı́a de Industria y Medio Ambiente de la Región de Murcia1 . Por otro
lado, en los casos en los que es necesario disponer de buena precisión durante la navegación, es necesario
hacer uso de técnicas de corrección en tiempo real. En este caso, los mensajes son recibidos mediante un
enlace radio, y aplicados por el propio receptor en el momento de calcular la posición.
Atendiendo al rango de cobertura sobre el que funciona un sistema DGPS, podemos diferenciar entre
sistemas locales o LADGPS (Local Area DGPS ), y sistemas de área extensa o WADGPS (Wide Area
DGPS ). En el caso de las soluciones LADGPS, las estaciones de referencia están situadas en lugares
próximos a los usuarios potenciales. La idea en este caso se centra en que las desviaciones detectadas por
las estaciones de referencia también serán comunes para todos los usuarios situados en los alrededores,
puesto que las condiciones atmosféricas y geográficas son similares. La efectividad del sistema se ve
degradada, obviamente, por el aumento de la distancia entre el usuario y la estación de referencia. Por
otro lado, los sistemas WADGPS ofrecen correcciones sobre grandes zonas geográficas. En este caso, un
conjunto de estaciones de monitorización distribuidas por las zonas de cobertura del servicio realizan
medidas de rendimiento de GPS. Dichos datos son recogidos por una estación central, la cual se encarga
de realizar una distribución global de la información de corrección. Los WADGPS que usan como medio de
distribución satélites geoestacionarios son los llamados Satellite Based Augmentation Systems, o SBAS.
El Europeo EGNOS (European Geostationary Navigation Overlay Service) y el Norteamericano WAAS
(Wide Area Augmentation System) son ejemplos de dichos sistemas.
Dado que el caso de estudio está centrado en navegación terrestre para vehı́culos, nuestro interés
está en los mecanismos de provisión de correcciones de área extensa (WADGPS) y en tiempo real, como
es el caso de EGNOS. Puesto que los servicios que ofrece el vehı́culo dependen de la posición actual
del mismo, de nada servirı́a aplicar correcciones a posteriori; y, de la misma manera, no es factible el
despliegue de estaciones de referencia para ofrecer cobertura LADGPS por toda la red de carreteras
existente.
En lo referente a los tipos de mensajes empleados en los mecanismos de corrección diferencial, la
oferta es diversa, pero los más importantes se encuentran en la Tabla 1. El formato RINEX (Receiver
Independent Exchange) [2] utiliza una codificación ASCII para guardar medidas sobre pseudo-distancias
de los satélites, parámetros meteorológicos, y mensajes de navegación del GNSS. Existen multitud de estaciones de referencia alrededor del mundo que almacenan información de corrección para post-procesado
mediante RINEX. Los formatos de mensaje RTCM SC-104 [10], CMR (Compact Measurement Record )
[7] y RTCA/DO-217 [8] fueron concebidos para el envı́o de correcciones en sistemas locales y con requerimientos de tiempo real. Inicialmente, la propuesta ofertada por el estándar de RTCM (Radio Technical
Comission for Maritime services) pretendı́a ofrecer correcciones para barcos en la aproximación a los
puertos. CMR apareció como una propuesta de mensajes comprimidos que disminuı́an los requerimientos
1
http://gps.medioambiente.carm.es/
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
Mejora de la Disponibilidad de SBAS en Navegación Terrestre
3
del canal de transmisión de los datos. El estándar de RTCA (Radio Technical Comission for Aeronautics)
siguió una lı́nea de trabajo similar orientada hacia aviación, y propuso un conjunto de mensajes con un
mejor tratamiento de los errores de comunicación y estructuras de datos más reducidas. No obstante, el
estándar de RTCM se extenderı́a mucho más, y las siguientes versiones, hasta llegar a la 3.0, tratarı́an
los nuevos requerimientos de posteriores sistemas de corrección.
LADGPS
WADGPS
Post-proceso
RINEX
RTCA/DO-229C
Tiempo real RTCA/DO-217, RTCM SC-104, CMR RTCA/DO-229C
Tabla 1. Estándares de mensajes de corrección diferencial
En el ámbito de los sistemas de corrección global, el estándar RTCA/DO-229C ha sido el más extendido. Tanto WAAS como EGNOS utilizan dicho estándar para la transmisión de mensajes de mejora
de GPS en tiempo real. Incluso, la ESA ha considerado la posibilidad de ofertar dichos mensajes en
post-proceso a través de un servidor público en Internet, mediante el sistema EMS (EGNOS Message
Server ). El problema de dicho estándar radica, sin embargo, en la complejidad de procesamiento de los
mensajes. Esto hace más complejo y, por tanto, más caro desarrollar receptores compatibles.
En la Fig. 1 se muestra la arquitectura de EGNOS, el SBAS escogido para el desarrollo del sistema
propuesto. Como se puede observar, un conjunto de estaciones de monitorización, denominadas Reference
and Integrity Monitoring Stations (RIMS), son las encargadas de recoger datos sobre el funcionamiento
de los GNSS desplegados hasta el momento, el americano GPS y el ruso GLONASS. Los centros de
control de EGNOS, o Mission Control Centre (MCC), realizan un estudio del rendimiento de los sistemas
de posicionamiento y, posteriormente, generan información sobre corrección e integridad de la posición.
Generalmente, sólo un MCC está activo, quedando los demás de reserva para ofrecer fiabilidad al sistema.
La información generada por el MCC es entonces dirigida hacia las estaciones de transmisión o Navigation
Land Earth Station (NLES), las cuales se encargan de mandar los mensajes EGNOS hacia el satélite
geoestacionario, quien, a su vez, retransmite dicha información a los usuarios finales.
La recepción de los mensajes SBAS desde un vehı́culo implica, no obstante, diversos requerimientos
que en algunos casos son difı́ciles de solventar:
Es necesario disponer de un receptor capaz de interpretar los mensajes. Actualmente la mayorı́a de los
receptores de gama baja, tales como los incorporados en navegadores comerciales, los que se integran
en dispositivos móviles, o los que se venden con soporte Bluetooth por separado, no disponen de
soporte SBAS, por la complejidad que conlleva.
Los receptores heredados presentan el mismo problema, por no soportar el sistema.
Para recibir los mensajes SBAS es necesario disponer de cobertura hacia el satélite geoestacionario,
lo cual presenta un problema en la navegación por zonas urbanas y de montaña.
Según se ha comprobado en las pruebas realizadas, la discontinuidad en la calidad de la señal SBAS
afecta al algoritmo de cálculo de la posición. Esto es debido a la degradación de las correcciones con
el paso del tiempo.
En el año 2001 la ESA puso en funcionamiento la tecnologı́a SISNeT (Signal in Space through the
Internet) [13], con la que los mensajes EGNOS se retransmiten a través de Internet. La Fig. 1 ilustra este
sistema, en donde una estación de la ESA dotada de un receptor compatible SBAS recibe los mensajes
EGNOS y los manda al usuario final, el cual puede optar por usar EGNOS a través del satetélite
geoestacionario o a través de Internet. La integración de SISNeT en un sistema de navegación ofrece,
por tanto, disponibilidad de EGNOS en emplazamientos sin cobertura. El sistema propuesto en este
trabajo hace uso de esta tecnologı́a que, sin embargo, no resuelve todos los problemas presentados. Sin
un receptor que soporte SBAS, los mensajes no pueden ser procesados. Además, aún ofreciendo dicha
capacidad, surge una nueva necesidad: el receptor debe soportar la introducción de mensajes EGNOS
por un puerto local. Para solventar esto, nuestro sistema ofrece la posibilidad de convertir los mensajes
enviados según el estándar RTCA/DO-229C al RTCM SC-104, ampliamente soportado por una gran
cantidad de receptores. De esta manera, es posible disponer de correcciones SBAS aún no teniendo
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
4
José Santa Lozano
[email protected]
Figura1. Arquitectura de EGNOS y la incorporación de SISNeT
soporte nativo del receptor, y bajo condiciones de ocultación de la señal del satélite geoestacionario.
Además del desarrollo de un equipamiento de a bordo con dichas funcionalidades, el diseño de una
estación de monitorización y gestión de mensajes EGNOS soluciona problemas de disponibilidad de
SISNeT y posibles retardos inducidos por la red.
El resto del documento está organizado según los siguientes apartados. La Sección 2 encuadra el
presente trabajo a partir de diversas publicaciones previas en la materia. La Sección 3 describe el sistema
implementado para mejorar el soporte SBAS en navegación terrestre. La Sección 4 expone el algoritmo de
conversión de mensajes. El prototipo y los resultados obtenidos mediante diversas pruebas se muestran
en la Sección 5. Finalmente, la Sección 6 concluye el trabajo e indica las lı́neas de investigación derivadas
del mismo.
2.
Antecedentes
Las ventajas de la arquitectura SBAS Europea (EGNOS) frente al uso del GPS convencional son
evidentes desde las primeras etapas de su implantación [18]. Los errores cometidos en los cálculos de
pseudo-distancias a los satélites de la constelación GPS se pueden reducir en gran medida gracias a las
correcciones trasmitidas por EGNOS. Sin embargo, la misma ESA pronto fue consciente de los problemas
de cobertura de EGNOS en diversos entornos de navegación terrestre. Es por esto que su tecnologı́a
SISNeT comenzó a ser aplicada en diversos desarrollos, en muchos casos apoyados por la misma Agencia
Espacial Europea. En [12], por ejemplo, se presenta una solución en donde se explota la funcionalidad
de SISNeT. Los mensajes de EGNOS son recibidos a través de Internet mediante una conexión GPRS, y
la mejora que se obtiene frente a GPS es evidente en los resultados. En [1] se hace uso de SISNeT para
desarrollar un navegador para invidentes. Los mensajes a través de Internet aseguran la disponibilidad
de EGNOS y, por tanto, la fiabilidad del dispositivo en ciudad.
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
Mejora de la Disponibilidad de SBAS en Navegación Terrestre
5
El trabajo descrito en [15] evalúa el uso de SISNeT en vehı́culos en la circulación por entornos urbanos.
Las mejoras con respecto al uso de GPS solamente son evidentes en diferentes emplazamientos en donde
la señal de EGNOS a través del satélite geoestacionario se ve afectada. El problema de esta solución, y
de las anteriores, se encuentra en que o bien se aplican las correcciones en el propio software ejecutado en
el terminal conectado al receptor, o bien se aplican las correcciones ofrecidas por SISNeT en postproceso
para evaluar su rendimiento, como en este último caso. El presente trabajo desea, sin embargo, ofrecer
una solución más flexible, en donde no se haga necesario el uso de un software fuertemente acoplado
al receptor para ofrecer correcciones por software. De esta manera, las correcciones se transforman en
mensajes RTCM, soportados por una gran cantidad de receptores del mercado. En [5] se da una primera
aproximación al problema de la conversión de mensajes de EGNOS a RTCM. De esta manera, se presenta
el mecanismo de conversión utilizado y se comprueba numéricamente que las correcciones obtenidas
mediante RTCM son equivalentes a las dadas por EGNOS. Sin embargo, las pruebas no se realizan en
tiempo real, no se implementa el sistema y no se evalúa su utilidad en entornos reales. Estas implicaciones
sı́ son tenidas en cuenta en nuestro trabajo, ofreciendo un entorno completo de mejora del posicionamiento
GPS para navegación terrestre.
3.
Sistema Avanzado de Soporte SBAS
El sistema diseñado ofrece una solución completa para la provisión de correcciones SBAS a estaciones
remotas en circulación por entornos terrestres. La Fig. 2 muestra un esquema del sistema. Como se puede
observar, se pueden distinguir dos entidades fundamentales: la estación de monitorización y el equipo
remoto. En la primera de ellas se realizan labores de estudio de la señal GPS/EGNOS mediante un
equipamiento de altas prestaciones. Además del software de monitorización desarrollado, el PC usado
implementa un servidor SISNeT equivalente al ofrecido por la ESA, con la intención de solventar problemas de disponibilidad del servicio y posibles retardos de la red. El servidor de SISNeT es, sin embargo,
usado también, tal y como se puede observar. Ambos servidores son accedidos a través de una dirección
IP pública, y se encuentran conectados a un enlace cableado a Internet de alta velocidad.
Figura2. Sistema completo de ampliación SBAS mediante correcciones por Internet
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
6
José Santa Lozano
[email protected]
En la parte derecha de la Fig. 2 se encuentra una representación de la unidad de a bordo u OBU
(On-Board Unit). Dicho sistema se sitúa en el lado del vehı́culo. Como se puede observar, se hace uso de
un receptor GPS/EGNOS, aunque en este caso éste serı́a de mucho menor coste que el considerado en
la estación de monitorización. Mediante una conexión a Internet con la red celular (GPRS o UMTS), se
establece una conexión con alguno de los dos servidores de mensajes de EGNOS. El ordenador embarcado
incluye el software encargado de procesar dichos mensajes y de generar los paquetes RTCM resultantes
de la conversión al receptor, tal y como se verá posteriormente. Una interfaz gráfica opcional ofrece otros
servicios al conductor y ocupantes del vehı́culo, derivados de nuestros trabajos en el ámbito del OBU [6].
3.1.
Estación de Monitorización y Gestión de Mensajes SBAS
La estación de monitorización desarrollada es descrita en detalle en [11]. Tal y como muestra la Fig.
3, el emplazamiento de la estación se encuentra en un entorno rural, en donde no existen problemas de
cobertura de GPS y EGNOS. Mediante dos receptores conectados simultáneamente a la misma antena,
es posible realizar estudios de rendimiento del sistema de posicionamiento mediante diferentes configuraciones. Los receptores permiten obtener multitud de medidas sobre los satélites seguidos, además de
ofrecer la posibilidad de extraer los paquetes en crudo recibidos tanto de GPS como de EGNOS. El
PC se encuentra conectado a ambos receptores, e incluye un software de monitorización que muestra
información detallada de los satélites a la vista, estudios de error de la posición, diagramas de cobertura,
y detalles sobre el tipo de posición calculada.
El software descrito implementa además el servidor SISNeT. Para ello, utiliza los mensajes en crudo
de EGNOS, extraı́dos de forma continua desde uno de los receptores, y los ofrece a través de una dirección
y puerto públicos. En el momento de establecer la conexión se realiza un proceso de autenticación según
un nombre de usuario y contraseña, al igual que en SISNeT. A partir de este momento se pueden solicitar
mensajes EGNOS.
Figura3. Estación de monitorización del sistema
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
Mejora de la Disponibilidad de SBAS en Navegación Terrestre
4.
7
Conversión de Mensajes SBAS a RTCM SC-104
En esta sección se describen los detalles del algoritmo de transformación usado, explicando previamente las caracterı́sticas más relevantes de los mensajes SBAS y RTCM.
El sistema de conversión desarrollado está ilustrado en la Fig. 4. Como se puede observar, los mensajes EGNOS provenientes de SISNeT deben ser procesados mediante un un cliente SBAS. Esta parte
del software se encarga de decodificar los paquetes EGNOS y de extraer la información sobre corrección ofrecida por EGNOS. Utilizando estos datos de entrada, el algoritmo de conversión se encarga de
adaptar la diversa información de corrección de EGNOS a una representación numérica de corrección
diferencial mucho más sencilla, que puede insertarse directamente en los mensajes RTCM. Como se puede comprobar, el algoritmo de conversión necesita de cierta información de navegación para su correcto
funcionamiento. Concretamente, desde el receptor se extráen datos sobre la posición de los satélites, y
marcas de tiempo sobre la antigüedad de la información transmitida por GPS sobre sus efemérides. Finalmente, el generador de mensajes RTCM se encarga de crear mensajes de corrección, que son enviados
por un puerto local al receptor GPS.
Figura4. Esquema del sistema de conversión de mensajes
4.1.
Mensajes RTCA/DO-229C y RTCM SC-104
Tal y como se ha explicado antes, el sistema EGNOS hace uso de las recomendaciones dadas por
RTCA, en su documento RTCA/DO-229C [9]. Dichas directrices establecen los mensajes necesarios y
la manera de decodificarlos para obtener correcciones e información sobre integridad del sistema GPS.
Debido a que los mensajes transmitidos por un SBAS deben tener un cierto carácter local en su procesamiento en el lado del usuario, la información transmitida debe ser lo suficientemente genérica y extensa
como para que el receptor adecue las correcciones recibidas a su posición. De esta manera, no solo se
transmiten correcciones y datos relativos al error cometido por el sistema GPS (generalmente por errores
de reloj y de posición de los satélites), sino que también se envı́a información atmosférica para gran parte
del planeta, que será parcialmente usada por el receptor. Como resultado, la cantidad de mensajes que
es necesario procesar para decodificar las correcciones de las pseudodistancias a los satélites seguidos es
relativamente grande.
Desglosando la información dada por las recomendaciones de RTCA/DO-229C, los diferentes tipos
de correcciones disponibles son:
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
8
José Santa Lozano
[email protected]
Correcciones rápidas Estas correcciones atenúan los errores que se producen en GPS y que son altamente variables, como son los que se producen por desviaciones en el reloj de los satélites. Los
mensajes necesarios para decodificar dichas correcciones son la máscara que indica sobre qué satélites se va a enviar información (Tipo 1), los mensajes especı́ficos de corrección rápida (Tipo 0/2-5), el
mensaje sobre factores de degradación de las correcciones rápidas (Tipo 7), y el mensaje de parámetros de degradación general (Tipo 10).
Correcciones lentas Estas correcciones modelan errores con una menor velocidad de cambio, como las
desviaciones en las efemérides de los satélites. Para procesarlos es necesario disponer de la máscara
(Tipo 1) y de los mensajes especı́ficos de corrección lenta (Tipo 25).
Correcciones ionosféricas Estas correcciones dependen de condiciones variables de la ionosfera, las
cuales hacen que las señales de los satélites sufran un retardo. Su cálculo se basa en la elevación del
satélite desde la posición del usuario y en estado de la ionosfera en el lugar por el que pasa la señal
del satélite. Por tanto, es necesario disponer de la información de la ionosfera, que se recibe a través
de una máscara que indica sobre qué parte de la ionosfera se está informando (Tipo 18), y mediante
un mensaje especı́fico de retardos (Tipo 26).
Adicionalmente, se usa un mensaje mixto que incluye correcciones rápidas y lentas (Type 24 ).
En contraposición a la diversidad de mensajes que se dan en el sistema de RTCA, RTCM SC-104
ofrece un procesamiento mucho más sencillo, dado a que está destinado fundamentalmente a sistemas de
corrección diferencial de área local. De entre todos los mensajes disponibles en las recomendaciones, se
pueden escoger aquellos que resulten de interés para el sistema que se pretende, ya que son autocontenidos.
Los mensajes Tipo 1 y 9, por ejemplo, contienen información de corrección para satélites GPS, incluyendo
la corrección y el identificador del satélite. Todos los mensajes están formados por dos palabras iniciales
de cabecera (Fig. 5) con la siguiente información:
Preámbulo Es constante, y cumple labores de sincronización.
Tipo de mensaje Identifica la carga útil del paquete.
Identificador de estación Especifica un nombre para el emisor de los mensajes RTCM.
Z-Count Es una marca de tiempo del momento de la emisión del mensaje, medido en segundos dentro
de la hora GPS actual.
Número de secuencia Permite sincronizar los paquetes.
Longitud Indica el tamaño del paquete.
Estado de la estación Indica el nivel de precisión de la estación, y se interpreta como un factor de
escala sobre las correcciones.
Paridad La paridad se incluye para todas las palabras, y se calcula según [16][17].
Figura5. Cabecera de todos los mensajes RTCM
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
Mejora de la Disponibilidad de SBAS en Navegación Terrestre
9
La información sobre corrección diferencial en RTCM viene dada por los mensajes Tipo 1. El problema
es que estos mensajes deben incluir correcciones para todos los satélites a la vista, es por esto que en su
lugar se usan los mensajes Tipo 9 que, como se verá posteriormente, permiten introducir correcciones
para satélites individuales. El formato de la información contenida en los mensajes Tipo 1 y 9 se ilustra
en la Fig. 6, donde se muestran las dos primeras palabras de un mensaje Tipo 1. Dicho formato se
compone de los siguientes campos:
Factor de escala Se aplica junto con el estado de la estación de referencia para establecer la resolución
de la corrección.
UDRE El error de rango diferencial del usuario (o User Differential Range Error estima la incertidumbre
de la corrección.
Identificador de satélite Indica el satélite al que se refiere la corrección.
Corrección de pseudo-rango Corrección de la distancia al satélite, en metros.
Ratio de cambio Indica el ratio de cambio de la corrección, en m/s.
IOD El identificador de emisión de datos (o Issue of Data) especifica los datos de efemérides usados
por la estación de referencia.
Figura6. Información de corrección diferencial para un satélite en un mensaje RTCM Tipo 1 o 9
El mensaje que se usa para especificar correcciones debidas a la ionosfera es el Tipo 15 (Fig. 7), cuyos
paquetes comienzan con un campo reservado seguido de:
GNSS Indica el GNSS usado. Se establece con GPS generalmente.
Identificador de satélite Indica el satélite al que se refiere la corrección.
Retardo ionosférico Indica el retardo inducido por la ionosfera en centı́metros de la pseudo-distancia
al satélite.
Ratio de cambio Indica el ratio de cambio de la corrección, en cm/min.
4.2.
Comunicación con SISNeT
Tal y como se ha descrito anteriormente, para poder interpretar el amplio conjunto de mensajes de
EGNOS es necesario disponer de cierta información previa. Inicialmente se deben recibir los mensajes
con información sobre máscaras de transmisión y parámetros de degradación de las correcciones, ya que
hasta no disponer de estos datos no es posible decodificar las correcciones. Esto supone un problema
para los receptores compatibles con SBAS actuales, ya que estos mensajes son enviados en algunos casos
cada varios minutos.
Gracias al uso de SISNeT v3 [4] es posible reducir este tiempo de espera, puesto que se pueden
pedir estos mensajes iniciales en el proceso de arranque de la decodificación. Este es el proceso que sigue
nuestro sistema, con tal de demorar lo menos posible la generación de correcciones. Una ventaja añadida
de SISNeT v3 consiste en que no es necesario realizar una petición para recibir cada mensajes de EGNOS
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
10
José Santa Lozano
[email protected]
Figura7. Información de corrección debida a la ionosfera para un satélite en un mensaje RTCM Tipo 15
(tal y como pasaba en anteriores versiones), sino que se indica mediante un comando “START” el inicio
de la recepción de mensajes de EGNOS según están disponibles. Este mecanismo es soportado también
por nuestra implementación de SISNeT, ya que reduce en gran medida el retardo en la recepción de
mensajes RTCA.
4.3.
Algoritmo de Conversión
El algoritmo de conversión consta de un cliente SBAS encargado de procesar todos los paquetes recibidos desde SISNeT y de mantener las correcciones para cada satélite. Periódicamente dicha información
es utilizada para generar paquetes RTCM, siguiendo las especificaciones de temporización indicadas en
[10].
Cuando un mensaje RTCA Tipo 1 es recibido, y el CRC es comprobado (como en todos los mensajes),
se habilita el cálculo de correcciones lentas y rápidas. En el caso de las lentas, al recibir un mensaje Tipo 24
o 25, el valor de la corrección para el satélite concreto se guarda directamente, pero para las correcciones
rápidas el procesamiento es un tanto más complejo. Una pequeña caché de correcciones es necesaria
para mantener las correcciones rápidas recibidas a través de los mensajes Tipo 0/2-5 para cada satélite,
ya que se debe calcular el ratio de cambio de la corrección para poder realizar correcciones en base a
una estimación lineal en el tiempo. Dichas interpolaciones se realizan teniendo en cuenta, además, los
parámetros de degradación de los mensajes Tipo 7 y 10.
De acuerdo con lo anterior, se mantienen dos valores para cada satélite i en el caso de las correcciones rápidas, la propia corrección de pseudo-distancia (P RCf asti o pseudo-range correction), obtenida
directamente desde los mensajes de EGNOS; y el ratio de cambio (RCf asti o rate of change), calculado a
partir de la corrección rápida actual y una previa que debe cumplir ciertas condiciones de consistencia [9].
(1) y (2) muestran el calculo utilizado. tactual y tprevio representan el momento de la llegada del mensaje
de corrección rápida EGNOS actual y previo [19], y se utilizan para calcular el tiempo transcurrido entre
dichos instantes. Las marcas de tiempo que se utilizan son las que provee SISNeT por cada mensaje
EGNOS que recibe y posteriormente retransmite.
RCf asti =
P RCf astiactual − P RCf astiprevio
∆tf asti
∆tf asti = tf astiactual − tf astiprevio
(1)
(2)
Los valores obtenidos de EGNOS con las correcciones lentas constan de la propia corrección de
pseudo-distancia (P RCslow ), y el ratio de cambio (RCslow ), no usado actualmente por EGNOS. Estos
valores son dados, sin embargo, indicando la corrección que existe en la posición del satélite para sus
tres coordenadas, partiendo del sistema de referencia ECEF (Earth Centered Earth Fixed ). Este sistema
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
Mejora de la Disponibilidad de SBAS en Navegación Terrestre
11
de referencia usa el centro de la tierra como origen, dando de esta manera un posicionamiento absoluto
independiente del geoide. Para obtener la corrección diferencial final es necesario, por tanto, considerar
la posición del satélite, dada por (xi , yi , zi ), y obtenida del propio receptor GPS. La pseudo-distancia
medida por el receptor (P Ri ) se calcula como indica (3). A la posición del satélite se le aplica la corrección
diferencial y se vuelve a calcular la pseudo-distancia (P Ri0 ) según (4). La diferencia entre las pseudodistancias medida y corregida es la corrección diferencial final (5).
P Ri0 =
q
q
x2i + yi2 + zi2
(3)
(xi + P RCslowx )2 + (yi + P RCslowy )2 + (zi + P RCslowz )2
(4)
P Ri =
P RCslowi =
P Ri0
− P Ri
(5)
Cuando es necesario crear un mensaje RTCM, se busca una corrección válida para cada satélite y se
crea un mensaje RTCM Tipo 9. Para enviar dicha corrección se calcula la corrección de pseudo-distancia
(P RC) para la corrección rápida, acorde al tiempo que ha transcurrido desde la recepción del mensaje
EGNOS correspondiente (P RCf0 asti ). Tal y como se indica en (6), se utiliza el ratio de cambio para
ajustar la corrección. Este valor se suma con la corrección lenta para obtener la corrección final de
pseudo-distancia, según (7). El ratio de cambio para el mensaje RTCM se calcula solamente en base a
la proporción que tiene la corrección rápida en la corrección final, ya que EGNOS no ofrece actualmente
ratio de cambio para la corrección lenta. Finalmente, la hora de la corrección se establece a la hora actual,
ya que la información de la corrección se ha actualizado en el equipo del usuario.
P RCf0 asti = P RCf asti + RCf asti ∗ (tactual − tf astiactual )
P RCi =
P RCf0 asti
+ P RCslowi
RCP RCi = RCf asti ∗
P RCf0 asti
tP RCi
P RCi
= tactual
(6)
(7)
(8)
(9)
Si se observa el contenido del mensaje RTCM de corrección diferencial (Fig. 6), es necesario especificar
también el UDRE y el IOD. El valor de UDRE se extrae de los mensajes de corrección rápida (Tipo
0/2-5). El IOD es necesario ajustarlo para que el receptor sea consciente de que se ha usado la misma
información sobre las efemérides en el momento de calcular la corrección y al aplicarla. Para ello se
hace uso del valor de IOD disponible igualmente en los mensajes RTCA de corrección lenta (Tipo 25).
La disponibilidad de este valor limita, no obstante, la efectividad del algoritmo, ya que los mensajes de
corrección lenta pueden llegar a emitirse con una periodicidad muy alta. Es por esto que se incluye la
posibilidad de obtener el IOD a partir SISNeT o del propio receptor de forma alternativa, haciendo una
petición de los datos relativos a las efemérides.
Una cuestión destacable es que solamente se coloca información de corrección para un satélite en los
mensajes RTCM Tipo 9. Esto asegura que el momento de generación de la corrección tP RCi es situado
correctamente, ya que dicho valor es común para todas las correcciones que se incluyen en un paquete
de corrección diferencial.
Para el caso de las correcciones de la ionosfera, el mensaje RTCA de máscara que debe recibirse
previamente es el Tipo 18. Éste especifica qué puntos del grid con el que se modela la ionosfera serán
recibidos en los siguientes mensajes de corrección Tipo 26. Una vez se está en disposición del modelo de
la ionosfera, es posible generar correcciones y emitirlas en mensajes RTCM Tipo 15. Estos mensajes se
emiten con una frecuencia mucho menor [10], e incluyen información sobre todos los satélites en vista.
En este caso el problema de tener que compartir un mismo tiempo de generación del mensaje para todas
las correcciones no es, sin embargo, un gran problema, ya que las correcciones de la ionosfera cambian
de forma mucho menos frecuente, y se actualizan de forma consecutiva a través de ráfagas de mensajes
RTCA Tipo 26.
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
12
José Santa Lozano
[email protected]
Los valores necesarios para crear paquetes RTCM Tipo 15 (Fig. 7) son el retardo implicado por la
ionosfera para el satélite (IODei o IOnospheric Delay), el ratio de cambio de la corrección (RCIODei ), y
el momento de la generación de la corrección (tIODei ). Según (10) y (11), el valor para el ratio de cambio
se calcula considerando los dos últimos mensajes de corrección recibidos para el satélite i y comprobando
el tiempo transcurrido. Los instantes de tiempo se obtienen de la hora situada en los mensajes SISNeT. El
valor IODei se obtiene directamente de los mensajes RTCA Tipo 26, pero aplicando el ratio de cambio,
según se indica en (12). Finalmente, el valor tIODei se sitúa con la hora actual.
IODeiactual − IODeiprevio
∆t
= tIODeiactual − tIODeiprevio
RCIODei =
(10)
∆tIODei
(11)
IODei = IODeiactual + RCIODei ∗ (tactual − tIODeiactual )
(12)
tIODei = tactual
(13)
A diferencia de lo que ocurre con los mensajes RTCM Tipo 1 y 9, los relativos a la ionosfera (Tipo 15)
no son soportados por todos los receptores. Por este motivo se ha considerado una solución alternativa
en donde las correcciones diferenciales lentas, rápidas y de la ionosfera se transmiten de forma conjunta
mediante mensajes RTCM Tipo 9. Los cálculos necesarios en este caso se detallan en 14-16.
P RCi = P RCf0 asti + P RCslowi + IODei
RCP RCi = RCf asti ∗
P RCf0 asti
P RCi
tP RCi
5.
IODei
P RCi
= tactual
+ RCIODei ∗
(14)
(15)
(16)
Evaluación del Sistema
El sistema de corrección diferencial descrito ha sido implementado y probado en entornos de circulación real. Para ello se ha hecho uso de la estación de monitorización previamente explicada, la cual ha
estado a cargo de servir mensajes EGNOS a través del servidor SISNeT desarrollado cuando el rendimiento del servidor de la ESA presentaba periodos de discontinuidad. Se ha hecho uso de un vehı́culo
prototipo para llevar a cabo pruebas de campo, cuyos resultados han sido analizados.
5.1.
Prototipo Desarrollado
El algoritmo de conversión ha sido implementado en un software que provee de correcciones diferenciales mediante mensajes RTCM en tiempo real. Dicho software ha sido implementado en Java 1.5,
con lo que se asegura la portabilidad del programa a cualquier plataforma. Se ha añadido un soporte
para una amplia variedad de receptores GPS del mercado, y se permite la configuración del sistema para
funcionar en diversos modos de funcionamiento. Entre ellos, es posible establecer el receptor GPS para
que funcione en modo GPS estándar, en modo EGNOS, o en modo diferencial RTCM. Esto ha sido
utilizado para capturar logs de funcionamiento en diversas configuraciones.
El prototipo hardware usado para las pruebas se muestra en la Fig. 8. Este vehı́culo es usado en
la Universidad de Murcia en diversos proyectos de investigación dentro del campo de ITS (Intelligent
Transportation Systems). Incluye una pantalla táctil LCD integrada en el salpicadero, sensorización
inercial, y soporte para la conexión de un receptor GPS mediante una antena situada en la parte trasera.
En el vehı́culo se ha instalado un ordenador tipo SBC (Single Board Computer ) de pequeñas dimensiones
detrás del asiento del copiloto. Éste funciona como OBU, e incluye un sistema operativo Linux Fedora
Core 5 sobre una plataforma integrada VIA. Conectado a éste se encuentra un módem Novatel Wireless
Merlin U530, con soporte UMTS R99. El receptor GPS usado es un San Jose Navigation FV-21, con
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
Mejora de la Disponibilidad de SBAS en Navegación Terrestre
13
soporte para SBAS a través del satélite geoestacionario, pero no a través de puerto de conexión directa.
Sin embargo, uno de los puertos serie que incluye soporta correcciones RTCM. El otro puerto es utilizado
para obtener la información de navegación necesaria para el algoritmo de conversión.
Figura8. Vehı́culo prototipo usado para testear el sistema de corrección
5.2.
Funcionamiento del Sistema en Entornos Reales
Para comprobar el funcionamiento del sistema de correcciones, se han realizado pruebas tanto en
situaciones de buena cobertura, como en entornos urbanos, donde los edificios dificultan la propagación
correcta de la señal de los satélites hasta el vehı́culo. El receptor GPS usado, al igual que todos los de
bajo coste de la actualidad, está pensado para ofrecer posición aún en situaciones de gran atenuación
de la señal, ya que lo más importante en soluciones de navegación terrestre es proveer de una posición a
pesar de que ésta pueda estar degradada.
En la Fig. 9 se muestran los logs obtenidos en tres recorridos, configurando el receptor para funcionar
en modo GPS solamente (Single), usando EGNOS, o usando los mensajes de corrección RTCM generados
por el software de conversión. La ruta corresponde a una zona del Campus de Espinardo de la Universidad
de Murcia, con buena cobertura satelital. En el trayecto usando EGNOS, todas las posiciones extraidas
fueron marcadas por el receptor como corregidas. Sin embargo, se observa un desviación importante en
el tramo que se encuentra en la parte inferior izquierda. En dicha zona, el vehı́culo, que circula en el
sentido anti-horario, se encuentra de frente con un desnivel que oculta momentáneamente la señal del
satélite geoestacionario. Puesto que se dejan de recibir los mensajes de EGNOS durante un tiempo, las
correcciones comienzan a degradarse, lo cual se traduce en una desviación momentánea. La posición
vuelve a obtenerse correctamente una vez se ha superado la zona conflictiva. El recorrido realizado
mediante el sistema que hace uso de las correcciones en RTCM no sufre dicha alteración, ya que los
mensajes de EGNOS se reciben sin discontinuidad desde SISNeT.
La corrección aplicada por EGNOS es evidente en la Fig. 9. Si se observan los tres recorridos, las
posiciones obtenidas a través EGNOS y RTCM son prácticamente equivalentes en gran parte del trayecto.
Sin embargo, para el caso de la configuración usando solamente GPS, se observa un desplazamiento de
las posiciones hacia el sur, que se observa mejor en los tramos de navegación con mayor componente
horizontal en la imagen.
En el trayecto recogido en la Fig. 10 el vehı́culo circula por una calle de la ciudad de Murcia, en
donde la cobertura es baja por la presencia de edificios que dificultan la recepción de la señal de los
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
14
José Santa Lozano
[email protected]
Figura9. Funcionamiento del sistema en un entorno semi-rural
satélites. El vehı́culo circula en este caso desde la parte superior de la imagen a la inferior. Al llegar a
la zona más problemática, se observa una desviación importante para la configuración EGNOS, que en
el caso de GPS y RTCM no se observa. Esto es debido a la pérdida progresiva de la cobertura hacia el
satélite geoestacionario. La acumulación de posiciones que se observa en el centro de la imagen es debida
a que el vehı́culo estuvo parado en los tres recorridos en el mismo semáforo. Dicho efecto es usual en los
receptores GPS, ya que sus algoritmos de cálculo de la posición suponen la dinamicidad del usuario a
través de las posiciones previas para calcular una nueva. La pérdida de señal EGNOS es evidente en la
llegada al semáforo, momento en el cual las posiciones son recogidas desde el receptor marcadas como
GPS estándar. Esto se representa en la imagen mediante marcas de posición sin relleno en el recorrido
EGNOS. Tras superar la zona conflictiva y alcanzar una zona verde cercana, el funcionamiento se restituye
y, poco después, se vuelven a recibir posiciones EGNOS desde el receptor. En este caso el sistema de
conversión de mensajes EGNOS evita la discontinuidad de la señal. Un sistema de navegación integrado
con cartografı́a digital podrı́a haber considerado en el caso de EGNOS que el vehı́culo se encontraba en
la plaza situada en el centro de la imagen, ya que su algoritmo de map-matching podrı́a haber detectado
dicha zona como la más próxima.
La situación mostrada en la Fig. 11 expone un caso en donde el vehı́culo sale de la zona de baja
cobertura mostrada en el caso anterior, y se incorpora a una vı́a situada en una zona abierta por la
parte izquierda de la ilustración. En este caso el vehı́culo sale de la calle previa usando una pequeña
cantidad de satélites, lo cual ocasiona que la posición calculada se vea sujeta a importantes desviaciones.
En el caso de RTCM se aplican constantemente las correcciones asociadas a las pseudo-distancias de los
satélites usados, pero para el caso de GPS estándar y EGNOS esto no es ası́. Como se observa, el vehı́culo
sale de la zona conflictiva sin disponer de EGNOS, por lo que las posiciones recogidas son equivalentes
a las GPS sin corrección. Esto se refleja en la desviación existente al principio del recorrido. Debido a
que se entra a una zona abierta, se comienzan a usar más satélites para la solución, lo que ocasiona que
la posición los casos de GPS estándar y EGNOS comience a estabilizarse. Poco después de comenzar a
circular de forma paralela al rı́o, esta mejora de la cobertura se traduce en que el receptor vuelve a emitir
posiciones EGNOS.
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
Mejora de la Disponibilidad de SBAS en Navegación Terrestre
15
Figura10. Funcionamiento del sistema bajo condiciones crı́ticas de cobertura
Figura11. Funcionamiento del sistema en una situación de recuperación progresiva de la cobertura
El funcionamiento del sistema de posicionamiento considerando todas las posiciones recogidas en
Murcia a través de las diferentes pruebas se ve recogido en la Tabla 2. En ella se observa cómo el uso del
sistema de corrección a través de la conversión de mensajes a través de RTCM permite disponer de un
modo de funcionamiento diferencial durante todos los recorridos. Esto hubiera sido imposible de realizar
haciendo uso de SISNeT solamente, ya que el receptor no soporta la inserción directa de mensajes EGNOS
por ninguno de sus dos puertos. Los problemas de cobertura de la señal de EGNOS se ven reflejados en
la segunda columna, en donde se muestra que una alta proporción de las posiciones recogidas (el 39 %)
en la configuración con EGNOS no fueron en modo diferencial. Se observa, además, cómo el receptor
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
16
José Santa Lozano
[email protected]
Single
No GPS
GPS
DGPS
0
380
0
0%
100 %
0%
EGNOS
0
160
248
0%
39.22 %
60.78 %
RTCM
0
0
397
0%
0%
100 %
Tabla 2. Posiciones recogidas en Murcia en los tres modos de funcionamiento
permitió recoger posiciones (al menos) GPS en todo momento, lo cual se explica por su adaptación para
la navegación terrestre.
Tras las pruebas realizadas se demuestra cómo con la solución presentada es posible disfrutar de
las ventajas de un sistema SBAS en entornos con problemas de cobertura y con receptores de gama
media/baja o heredados, solventando, además, los problemas ocasionados en el posicionamiento en situaciones de discontinuidad temporal de la señal del satélite geoestacionario.
6.
Conclusiones y Lı́neas de Trabajo Relacionadas
El trabajo presentado muestra un solución para la recepción continua de la información que ofrecen
los SBAS para mejorar la navegación estándar GPS. La provisión de mensajes de EGNOS a través
de Internet permite disponer de información de corrección en lugares donde no existe cobertura al
satélite geoestacionario, o donde existe discontinuidad del servicio. Dicho mecanismo de envı́o de mensajes
EGNOS es ofrecido por la arquitectura SISNeT de la ESA, sin embargo, en el sistema propuesto esto se
ve respaldado por una implementación propia de una estación SISNeT que sigue las mismas directrices,
lo cual amplia la disponibilidad del servicio. En el equipo localizado en el lado del vehı́culo los mensajes
EGNOS recibidos a través de Internet son convertidos a un formato de paquete de corrección mucho más
extendido, como es RTCM. Esto solventa los problemas de compatibilidad con SBAS de los receptores
de gama media/baja, ya que el algoritmo de transformación opera en la OBU del vehı́culo.
Las pruebas realizadas sobre un prototipo real hardware/software, y en entornos reales, demuestran la
viabilidad del sistema y ofrecen un análisis del rendimiento obtenido en la navegación a través de mensajes
RTCM, realizando una comparación con configuraciones basadas en GPS estándar y en EGNOS. Se
ha comprobado cómo en entornos rurales las discontinuidades de pequeña duración de SBAS pueden
degradar la posición, lo cual se solventa con una recepción continuada de los mensajes a través de
Internet. En situaciones de mayores problemas de cobertura, como son las calles encerradas por edificios
de gran envergadura en ciudad, el sistema ofrece un 100 % de disponiblidad de la señal de EGNOS, y
evita las desviaciones en la posición inducidas por discontinuidades en la señal de EGNOS. En dichas
pruebas se ha demostrado, además, como un receptor GPS que no soporta la interpretación de mensajes
SBAS a través sus puertos serie puede disfrutar de información de corrección continuada a través del
sistema de conversión a paquetes RTCM.
Las labores llevadas a cabo en el procesamiento de mensajes de EGNOS han posibilitado la investigación en medidas de integridad de la posición [20]. Los sistemas SBAS, además de transmitir correcciones diferenciales, ofrecen información sobre parámetros de funcionamiento de GPS. Este mecanismo
está suscitando un especial interés en los últimos años, debido a que GALILEO incluye dicha capacidad.
La información proveniente de SBAS sobre integridad es procesada junto con los datos de la geometrı́a
de los satélites usados en la posición para calcular los llamados Niveles de Protección. Mediante los niveles de protección horizontal (HPL o Horizontal Protection Level ) y vertical (VPL o Vertical Protection
Level ) es posible cuantificar la fiabilidad de las posiciones calculadas por el receptor. Dicha información
está siendo usada en trabajos actuales para ofrecer un sistema de navegación fiable para ámbitos de
funcionamiento en los que la vida de los usuarios pueda correr peligro, o para aquellos en los que existan
cuestiones legales de por medio. Servicios con tales caracterı́sticas están dentro de, por ejemplo, sistemas
de asistencia al conductor en situaciones de accidente (como e-call ), en los cuales la información sobre la
fiabilidad de la posición pueda implicar la asignación de recursos para búsqueda y rescate. Los sistemas
actuales de peaje electrónico por carretera mediante GNSS son también un importante ámbito de aplicación de esta lı́nea de trabajo, dentro de los cuales se encuentra trabajando la Universidad de Murcia
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
Mejora de la Disponibilidad de SBAS en Navegación Terrestre
17
[21]. En estos sistemas, el algoritmo usado para cobrar al usuario debe tener seguridad de que la ruta
almacenada corresponde con la real, con lo que la integridad del sistema de navegación es un elemento
clave para un funcionamiento correcto.
Agradecimientos
El tesinando y los directores del presente trabajo desean agradecer el soporte ofrecido por el Programa
FPU del Ministerio de Ciencia e Innovación del Gobierno Español, a través de la ayuda AP2005-1437,
ası́ como el continuo apoyo del Ministerio de Fomento a través de diversos proyectos en el ámbito de los
ITS.
Tanto el tesinando como los directores se encuentran dentro del Grupo de Investigación de Sistemas
Inteligentes de la Universidad de Murcia, incluido dentro del Registro de Grupos de Excelencia de la
Fundación Séneca - Agencia de Ciencia y Tecnologı́a de la Región de Murcia, siendo beneficiario de la
ayuda 04552/GERM/06.
Referencias
1. Busnadiego-Gutiérrez, C. and Gutierrez-Lanza, S. Navigator for Blind People on a Mobile Phone. European
Navigation Conference, Manchester, 2006.
2. Gurtner, W. and Estey, L. RINEX: The Receiver Independent Exchange Format Version 3.00. Astronomical
Institute. University of Berne, 2007.
3. Kaplan, E. and Hegarty C. Understanding GPS. Principles and Applications. Artech House, Inc., 2005.
4. Raj, A., Toran-Marti, F. y Ventura-Traveset, J. SISNeT User Interface Document, Issue 3, Rev. 1. ESA
Technical Note, 2006.
5. Schone, L., Zunker, H., Toran-Marti, F. and Ventura-Traveset, J. Applying SISNeT through RTCM Interface.
European Navigation Conference, Rotterdam, 2004.
6. Santa, J., Ubeda, B. and Skarmeta, A.F.G. A Multiplatform OSGi Based Architecture for Developing Road
Vehicle Services. IEEE Consumer Communications and Networking Conference, Las Vegas, 2007.
7. Talbot, N.C. Compact Data Transmission Standard for High-Precision GPS. ION GPS-96 Conference,
Kansas City, 1996.
8. The Radio Technical Commission for Aeronautics. RTCA DO-217. Minimum Aviation System Performance
Standards - DGNSS Instrument Approach System: Special Category I (SCAT-I), 1995.
9. The Radio Technical Commission for Aeronautics. RTCA DO-229C. Minimum Operational Performance
Standards for Global Positioning System / Wide Area Augmentation System Airborne Equipment, 2001.
10. The Radio Technical Commission for Maritime Services. RTCM Recommended Standards for Differential
GNSS (Global Navigation Satellite Systems) Service. Version 2.3, 2001.
11. Santa, J., Ubeda, B., Toledo, R. and Sotomayor, C. A Facility for GPS/EGNOS Signal Monitoring Workshop
on EGNOS Performance and Applications, Gdynia, 2005.
12. Toledo, M., Gonzalez, E., Toran, F. and Ventura, J. Proposal of an Internet-Based EGNOS Receiver:
Architecture and Demonstration of the SISNeT Concept. IAIN World Congress, Berlin, 2003.
13. Toran, F. and Ventura-Traveset, J. The ESA SISNeT Project: Current Status and Future Plans. European
Navigation Conference. Manchester, 2006.
14. Toran-Marti, F. and Ventura-Traveset, J. EGNOS Message Server (EMS). User Interface Document, Issue
2. ESA Technical Note, 2004.
15. Toran-Marti, F., Ventura-Traveset, J., Gonzalez, E., Toledo, M., Catalina, A., Barredo, C. and Salonico, A.
Positioning Via Internet: SISNeT Catches GPS in Urban Canyons. GPS World, 15(4): 28-35, 2004.
16. United States Coast Guard Navigation Center. Global Positioning System Standard Positioning Service
Signal Specification, 1995.
17. United States Coast Guard Navigation Center. ICD-GPS-200C, Navstar GPS Space Segment / Navigation
User Interfaces, 2003.
18. Ventura-Traveset, J., Gauthier, L., Toran, F., de Lesthievent, C. and Bedu J.Y. EGNOS Status, performances
and Planeed Evolutions (2006-2010). European Navigation Conference, Munich, 2005.
19. Walter, T. WAAS MOPS: Practical Examples. National Technical Meeting of the Institute of Navigation,
San Diego, 1999.
20. Santa, J., Ubeda, B., Toledo, R. and Skarmeta, A.F.G. Monitoring the Position Integrity in Road Transport
Localization Based Services Vehicular Technology Conference Fall, Montreal, 2006.
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
18
José Santa Lozano
[email protected]
21. Sanchez, R., Paniagua, J., Gutierrez, S., Jordan, J.G., Santa, J., Fernandez, I. and Gomez, P. Proyecto
GIROADS: Sistema de Peaje Basado en GNSS sobre una Plataforma Multiservicio LBS Congreso Español
sobre ITS, Valencia, 2007.
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
Mejora de la Disponibilidad de SBAS en Navegación Terrestre
A.
19
Publicaciones Relevantes
El presente apéndice incluye dos publicaciones relevantes al trabajo llevado a cabo en la tesis de
máster2 . La primera de ellas corresponde a un artı́culo presentado en el congreso Workshop on EGNOS
performance and applications, organizado por la ESA. El artı́culo describe la estación de monitorización
implementada para analizar el funcionamiento de EGNOS, ası́ como diversas pruebas iniciales que se
llevaron a cabo usando el sistema de corrección diferencial presentado. Una de las primeras versiones del
algoritmo de cálculo de la integridad de la posición es también descrito en dicha publicación. Sin embargo,
el trabajo presentado al congreso IEEE Vehicular Technology Conference analiza en mayor profundidad
una mejorada versión de dicho sistema. En este artı́culo se realiza un análisis de los resultados obtenidos
en la integridad de la posición a partir de diversas pruebas tanto en estático como en dinámico, estudiando
el efecto de la pérdida de cobertura en la red celular cuando se usa SISNeT para disponer de EGNOS.
2
El conjunto completo de publicaciones del tesinando puede consultarse en http://ants.inf.um.es/∼josesanta/
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
Proceedings of the “Workshop on EGNOS performance and applications”
Gdynia, Poland
October 27-28, 2005
A FACILITY FOR GPS/EGNOS SIGNAL MONITORING
José Santa1, Benito Úbeda1, Rafael Toledo2 and Cristina Sotomayor1
1
Department of Information and Communication Engineering. Computer Science Faculty.
University of Murcia, Campus de Espinardo, 30071 Murcia, Spain.
e-mail: [email protected] | [email protected] | [email protected]
2
Department of Electronics, Computer Technology and Projects. Telecommunications
Faculty. Technical University of Cartagena, Campus Muralla del Mar, Cuartel de
Antiguones, 30202 Cartagena, Murcia, Spain.
e-mail: [email protected]
The imminent implementation of the final EGNOS version will allow users to obtain not only
an improved GPS position, but also better integrity and availability capabilities than the
standard GPS. A detailed observation of both the GPS and the EGNOS positioning systems
enables the study of the incoming GPS+GALILEO potential features. Thus, our work has
been focused on the development of a hardware/software environment for displaying in an
intuitive manner a complete set of real time GPS/EGNOS parameters, such as satellite status
information, HPLSBAS, GDOP or HPE values. Additionally, some results obtained in real tests
performed in urban areas are shown. These results allow the analysis of the services offered
by EGNOS.
1. INTRODUCTION
Most of the GPS manufactures provide GPS information software for monitoring purposes
included in the sensors. Real time satellite status information, satellite position, type of GPS
solution and its quality are usually supplied. Unfortunately, these software programs are
proprietary and depend on every GPS receiver.
In terms of the integrity parameters of the current position, most of the receivers are based
on GDOP (Geometry Dilution Of Precision) calculations. Various parameters are based on
this concept: PDOP (Position Dilution Of Precision), TDOP (Time Dilution Of Precision),
HDOP (Horizontal Dilution Of Precision), and VDOP (Vertical Dilution Of Precision). The
algorithms used to calculate these values can be found in [1]. All of them are based
exclusively on the satellite constellation geometry used in the GPS solution, and errors
caused by a wrong measure of the distance to each satellite are not considered. In order to
- 183 -
José Santa, Benito Úbeda, Rafael Toledo, Cristina Sotomayor
mitigate this lack, EGNOS offers to their client equipments the possibility of calculating an
indicative value of position integrity which considers pseudorange errors. This factor, named
the Horizontal Protection Level, or HPLSBAS1, can be calculated as explained in [2]. The
relevance of the HPLSBAS factor in order to apply GPS/EGNOS to the problem of precise
positioning in vehicles can be seen in [3].
Although the GPS/EGNOS monitoring in static stations is useful for researching and
control tasks, probably its main benefit is in the dynamic field. For dynamic applications, the
navigation software and recently, the freight tracking solutions are more and more considered
as fundamental tools for travel guidance and remote management in the road transportation
area. An example of a road pricing application which can benefit the resultant GPS/EGNOS
system can be found in [4].
The work presented in this paper is based on a GPS/EGNOS monitoring station extensible
to any type of receiver, where information of all satellites in orbit, state of the current
position, and an historic of the integrity parameters for the solution, included the HPLSBAS,
are displayed (section 2). Additionally, an application of EGNOS to a land vehicle navigation
system and real results in city environments are also shown in this paper (section 3). The
main conclusions of our work are discussed in section 4.
2. GPS/EGNOS MONITORING
The monitoring station is situated in one of the external laboratories of our research group,
located in the Campus of Espinardo in the city of Murcia. Next, a description of the
components and software used is presented.
Fig. 1: Hardware used in the monitoring station.
2.1.
The hardware deployment
As can be observed in Fig. 1, the GPS antenna has been situated over the roof of the
laboratory to maximize the reception of signal. The GNSS sensors used are: Novatel
Millenium OEM3 Fw 4.521/2.03, Novatel Millenium OEM3 Fw 4.521S1/2.03, Novatel
Millenium OEM4 Fw 2.210, Thales DG16, San Jose Navigation FV-21, and Trimble Lassen
iQ. The antenna used was included in the Thales kit with the DG16 receiver. By using a
power splitter, we can duplicate the signal coming from the antenna and perform test with
two sensors at the same time. The computer used is a PC with a Pentium 4.2 GHz processor,
512 MB of RAM and 70 GB of hard disk. The operating system used is Linux Fedora Core 4.
1
This value is usually called HPLWAAS, but the term HPLSBAS expresses better the algorithm capability to
integrate any Satellite Based Augmentation System (SBAS) correction.
- 184 -
A Facility for GPS/EGNOS Signal Monitoring
2.2.
The GPS Control Station Application
GPS Control Station is a software tool developed in Java 1.5 with an intuitive interface
which displays the current state of the GPS/EGNOS system. The implementation developed
allows us to extend the amount of receivers supported with a low programmatic complexity.
Actually, the receivers included in the application are all listed in section 3. Due to the great
amount of information which is required by the receiver, it is not possible to use a standard
communication protocol, as NMEA, so the access to the device must be implemented.
An interesting feature of the software is its capacity of saving logs at specified rate in the
same unified format for all the devices, quite useful in postprocess studies. This format
registers all the information available every epoch, including all the data concerning current
position, GDOP values, HPLSBAS, and information of GPS and SBAS satellites tracked.
2.3.
Controlling the current state of GPS
Fig. 2 shows two screen shots and a zoom of the upper zone of the main window. In the
upper zone the current position data is shown. On the left, the current position in
latitude/longitude and ECEF and the type of position can be seen, and on the right side, the
DOP (Dilution Of Precision) values and the GPS time are displayed.
Fig. 2: Satellite information and calculated position.
The lower side of Fig. 2 shows two modes of GPS, EGNOS and WAAS constellation
satellite tracking. The left window provides information in text mode concerning the tracked
satellites. On the right window the satellites are plotted in a polar diagram, being the red ones
SBAS satellites.
2.4.
Monitoring the quality and integrity of position
As seen in section 2.3, continuous information about the quality of the position is obtained
by the GDOP calculations. However, some other parameters can show the reliability of the
- 185 -
José Santa, Benito Úbeda, Rafael Toledo, Cristina Sotomayor
solution calculated by the receiver in a more complete manner. Thus, HPE, VPE and
HPLSBAS indicators have been also included.
Fig. 3: Position error and HPL graphs.
The HPE (Horizontal Position Error) and the VPE (Vertical Position Error) values are
shown in the left side of the Fig. 3. To calculate the HPLSBAS integrity factor it is necessary to
determine, not only the situation of each satellite used and the current position of the receiver,
but also information of the pseudorange measurement precision, which is included in the
EGNOS messages [2]. Due to this, a continuous flow of EGNOS messages has to be
maintained, and a WAAS client must be used to process this information.
Fig. 4 shows the whole system proposed in this paper. Since some receivers can not
provide the EGNOS messages, we have considered an alternative approach. On one hand, our
software owns functionality to receive EGNOS messages from a capable receiver with an
additional communication port (Local GPS/EGNOS Sensor). On the other hand, the local PC
(Fig. 4) runs a SISNeT client implemented in the GPS Control Station application, allowing
the reception of the messages via Internet [5]. As result, the HPLSBAS value can be displayed.
Fig. 4: System architecture.
- 186 -
A Facility for GPS/EGNOS Signal Monitoring
Equations (1), (2) and (3) show intuitively the iterative calculations required for obtaining
the HPLSBAS value. In (1), the KH,NPA parameter is a constant for Non Precision Approach
mode (NPA) of EGNOS. As observed in (2), the dmajor value is calculated in a set of
operations whose input is the geometry of the satellites used in the solution (φi), and a value
of the error variance in the pseudorange measurements (σ2i). As shown in (3), the parameters
used to calculate this variance are the fast and long term correction residuals, ionospheric
delay, airborne receiver errors, and the tropospheric errors variances, σ2i,flt, σ2i,UIRE, σ2i,air and
σ2i,tropo respectively. Details about the complete calculation can be read in [2].
HPLSBAS = K H , NPA • d major
d major = φi × σ i
2
σ i 2 = σ i , flt 2 + σ i ,UIRE 2 + σ i ,air 2 + σ i ,tropo 2
(1)
(2)
(3)
The right side of Fig. 3 shows a screen shot of our application when the HPLSBAS view is
selected. This historic shows the Stanford graph, where horizontal axis are HPE values and
vertical axis the HPLSBAS. In this graph, an intensive colour represents a big concentration of
points with similar parameters. In non precision approach mode of EGNOS, the HAL
(Horizontal Alert Limit) value is set to 40 for the HPLSBAS parameter.
3. EGNOS CORRECTIONS IN ROAD TRANSPORT
In addition to the monitoring station, road application issues have been also investigated.
For this purpose, the OBU shown on the right side of Fig. 4. has been developed.
A standard car was equipped with a laptop used as onboard computer. A PCMCIA UMTS
card enables the connection of the computer to the Internet. The GPS sensor used in the trials
was the San Jose Navigation FV-21 model, with a portable antenna easy to fix on the
vehicle’s roof. The sensor is powered by the car lighter. The positions are logged into the
hard disk of the laptop for postprocess studies. The software developed by our group permits
the provision of the EGNOS corrections, whether directly to the receiver, or performing a
previous conversion to RTCM (a standard supported by many GPS receivers). Thus, a low
cost receiver can be used as a Remote GPS/EGNOS Sensor (Fig. 4). In both cases, the
EGNOS messages are received from SISNeT via the Internet, so the HPLSBAS value can be
monitored by using the method explained in section 2.4.
A simple implementation of a SISNeT server has been developed following the guidelines
exposed in [6]. This server, named UMU SISNeT server (Fig. 4), is connected to the receiver
in the test laboratory and provides controlled and small delay communications. Fig. 6 shows a
test of three trajectories following the same itinerary with different configurations: single
position, EGNOS, and EGNOS obtained from SISNeT through a RTCM interface. Results
can be whether plotted on GIS maps, or superposed on real photos of the trial zone.
- 187 -
José Santa, Benito Úbeda, Rafael Toledo, Cristina Sotomayor
4. ACKNOWLEDGEMENTS
The Authors would like to thank the Spanish Ministerio de Fomento, European Space
Agency (ESA) and the C. A. Región de Murcia for sponsoring the research activities under
the grants FOM/3595/2003, GIROADS 332599 and ISIS/2I04SU009, respectively.
Fig. 5: Test performed in Murcia, Spain, (photograph by Google Earth).
REFERENCES
[1] Kaplan, Elliott D., Understanding GPS. Principles and Applications, Artech House, Inc,
1996.
[2] RTCA DO-229C. Minimum Operational Performance Standards for Global Positioning
System / Wide Area Augmentation System Airborne Equipment, The Radio Technical
Commission for Aeronautics. November 2001.
[3] Skarmeta A.G., Martínez H., Zamora M.A., Úbeda B., Gómez F.C. and Tomás
L.M., MIMICS: Exploiting Satellite Technology for an Autonomous Convoy, IEEE
Intelligent System. N IV. V. vol. 17, pp. 85-89, 2002.
[4] Úbeda B., Toledo R., A Theoretical and Practical Analysis of GNSS Based Road Pricing
Systems, considering the Egnos/SISNeT Contributions, ESA/ESTEC, Noordwijk, the
Netherlands. 8-10 December 2004.
[5] Torán-Martí, F., Ventura-Traveset, J. and Chen, R., The ESA SISNeT Technology:
Real-Time Access to the EGNOS Services through Wireless Networks and the Internet,
In ION GPS 2002, Portland, September 2002.
[6] Torán-Martí, F. and Ventura-Traveset, J., SISNeT User Interface Document 2.1,
European Space Agency. May 2002.
- 188 -
Monitoring the position integrity in road transport
localization based services
José Santa, Benito Úbeda, Rafael Toledo, Antonio F. G. Skarmeta
Department of Information and Communications Engineering
Computer Science Faculty
University of Murcia
Campus de Espinardo, 30071 Murcia, Spain
Email: [email protected]|[email protected]|[email protected]|[email protected]
Abstract— Nowadays, a new generation of civil location based
services (LBS) included in the intelligent road transport systems
(ITS-R) field is emerging. The reliability of positioning sensors
and the communication infrastructure will be the key to the success of such services. A recommended basic onboard equipment
(OBE) can include a GNSS based sensor, an embedded computer,
a communication equipment and some other aiding sensors. The
current GPS based sensors, operating in standard positioning
service (SPS) or differential GPS (DGPS) modes, supply the
level of accuracy required by many services of interest. However,
the solution availability and the integrity monitoring are the
main problems for GNSS based road applications, where the cost
plays a significant role. In this paper, an embedded software for
monitoring the availability and integrity of a GNSS positioning
system is presented. The software developed allows the study
of the HPLSBAS (Horizontal Protection Level) parameter as a
reliable integrity indicator of the positioning system performance.
Its suitability for road applications, and the importance of the
geostationary satellite visibility and the GPRS/UMTS coverage
are analyzed in this paper. Finally, selected results of these
investigations and their conclusions are commented.
Index Terms— Intelligent Transport Systems, GNSS, Satellite
Based Augmentation Systems, Horizontal Protection Level, Location Based Services.
I.
The use of SBAS systems allows the calculation of useful
integrity factors, such as the HPL (Horizontal Protection
Level) and VPL (Vertical Protection Level) parameters, as
described in the RTCA DO-229 [1] specifications. In Fig.
1 the usefulness of the position integrity is shown. Here a
typical ITS-R case is illustrated. The vehicle goes through
the true path (green), but the navigation system indicator
estimates that the trajectory is the red one. The difference
between the erroneous and correct paths is the horizontal
position error (HPE). Here the HPL parameter is vital in
order to bound the confidence area of the GNSS sensor,
providing a good estimation (i.e. 10−7 /hour probability) of
the system reliability on the fact that the true position is within
a circle around the computed position. The horizontal alert
limit (HAL) can be defined as a proper upper bound for the
HPL value. If HPL > HAL the integrity alarm is triggered and
the navigation system could switch to a secondary navigation
sensor. Both HPL and VPL are commonly named as HPLSBAS
and VPLSBAS in order to distinguish between the SBAS
based computations and the receiver autonomous integrity
monitoring (RAIM) algorithm factors.
I NTRODUCTION
The new generation of civil location based services (LBS),
as a part of the intelligent road transport systems (ITS-R),
requires positioning sensors with a high level of accuracy,
availability, integrity and liability. Moreover, cost considerations must be done if a mass market implementation is
pretended. After selective availability (SA) was disabled in
the year 2000, and the satellite based augmentation systems
(SBAS: WAAS, EGNOS, MSAS, GAGAN) were operative,
most of the GNSS sensors in the market offer a good accuracy
in locations where there is good visibility of the GNSS and
GEO satellites. However, the lack of availability, specially
in urban areas, is a known problem for the GNSS/SBAS.
Although SBAS offers a slight improvement in the calculated
position, another aspect considered as crucial for several road
applications is the integrity of this position. Monitoring the
integrity implies that the goodness of the positions received
from the GNSS sensor can be known anytime. In several
current road applications such as road pricing systems, or
intelligent pay-per-use insurances, this issue becomes critical.
1-4244-0063-5/06/$2000 (c) 2006 IEEE
u
Tr
e
th
pa
t
ca
di
In
ed
th
pa
HPE
HAL
HPL
Confidence area
Fig. 1. Horizontal protection level
To improve the quality of the positioning performance of the
vehicle, recent researchers propose a combination of inertial
and GNSS sensors [2]. However, cost considerations must be
done regarding the use of inertial units, and low cost sensors,
based on micro-electro-mechanical (MEM) technology usually
provide very low levels of accuracy. In [3] an alternative
integrity parameter for the road applications and based on a
combined GNSS/INS integrated system is proposed. Despite
of the improvements of this approach not only based on the
GNSS sensors, the strong dependency on the filter parameters
encourages further investigations. [4] shows a positioning
receiver implemented in software which monitors the EGNOS
integrity. However this approach only deals with static non
realtime scenarios. In [5], the authors describe the application
of the EGNOS corrections broadcasted via Internet using the
data saved in previous static or dynamic observations. The
software proposed in that work, allows the simulation of the
positions obtained in several operation modes, facilitating the
inference in real results in a concrete environment.
In the same research line, the work presented is focused
on monitoring position integrity and applying EGNOS online
through cellular networks. An exhaustive study about the
current state of WAAS and EGNOS can be found in [6].
Here, the tests carried out show a double vision of the SBAS
performance. Firstly, an internal observation of the key factors
in the SBAS operation is showed. Secondly, the performance
at user level is evaluated. However, this study just points
static environments and employs postprocessing calculations.
This low level monitoring is not suitable for our applied road
environment.
Our investigations have considered an European scenario,
where the GPS/EGNOS availability is assumed as high, e.g. a
vehicle along a highway. Preliminary works can be found in
[7], where the evaluation is performed only on a static wide
open scenario. In the current paper, an improved integrity
algorithm applied to a dynamic environment is presented.
Associated problems using the EGNOS/SISNeT technology
available in Europe are also shown.
The rest of the paper is structured as follows. Firstly, the
established basis of the preliminary work made in [8] are
commented. In this paper, a prototype of sensorized vehicle
takes into account the basic idea of calculating the HPL
parameter as a reliability factor of the position. Section II
presents some concrete items on the necessary calculations to
obtain the HPL. In section III, the architecture of the designed
system is explained. Section IV shows the results obtained
in our HPL observation, and the usefulness of the integrity
information applied to onboard vehicle services. Finally, main
conclusions achieved in our work are presented.
II.
C OMPUTING HPL
The calculation of the integrity parameters is based on
the real time processing of the data broadcasted by EGNOS,
which contains correction information for all pseudorange
measurements. These data arrive to the user position by
many types of messages coordinated through Issues of Data
(IOD): types of messages 1, 2 to 5, 6, 7, 9, 12, 24 and
25 provide the fast and long term corrections, and UDRE,
those due to ephemeris and clock errors. Messages 18 and 26
contain ionospheric corrections and GIVE. Finally, message
10 contains degradation parameters. Once these values are
available, the integrity algorithm must proceed to evaluate
the mathematical expressions described in [1], summarized
in this section. In both the message processing and the HPL
calculation, several considerations related to the road transport
environment must be taken into account. The first of them is
that an ENU coordinate system is used.
HP LSBAS = KH · dmayor = 6,18 · dmayor
(1)
(1) shows the calculation used to compute the HPL value.
For the choice of the KH constant, the RTCA standard
differentiates between the non precision approach (NPA) and
the precision approach (PA) modes of operation. In the
present work, the mathematical expressions for NPA mode
have been chosen due to the fact that the road environment
does not require high levels of integrity (mainly directed to
safety life applications). Moreover, the operation of EGNOS
(ESTB), was not completely deployed during the trials, and
the delay requirements associated to the precise mode might
be counterproductive for the integrity calculations.
(2) shows all the errors considered to obtain the final estimation for the error variance in the pseudorange measurements
of the satellite used (σi2 ). Here, σf2 lt is the error variance
caused by the imprecisions in slow and fast corrections,
2
σU
IRE is the error variance caused by ionospheric effects in
2
is the error
the transmission of the satellite signals, σi,tropo
2
variance caused in a similar way by the troposphere and σi,air
is the error variance caused by the user receiver. [1] explains
the process to obtain all these values in the implementation of
a SBAS client. However some explanations are recommended
regarding the temporization of the reception of messages, [10].
2
, requires a special mention
The last of these parameters, σi,air
and it is explained in the next section.
2
2
2
2
σi2 = σi,f
lt + σi,U IRE + σi,tropo + σi,air
(2)
II-A. GNSS sensor error variance
The GNSS sensor contributes with the term σi,air and is
necessary to obtain a good estimation. For this purpose, we
must consider the four classes of equipment described in [1].
In our case, we assume the class two for our equipment, hence
(3) must be considered in order to obtain σi,air .
2
2
2
2
σi,air
= σi,noise
+ σi,multipath
+ σi,divg
−Eli /10
σi,multipath = 0,13 + 0,53 · e
(3)
(4)
The errors caused by multipath phenomena in the transmission of the satellite signals (σi,multipath ) are estimated
by (4), where Eli is the elevation angle of the line of sight
between SVi and the user antenna. However, there is not
a fixed model for estimating σnoise and σdivg . The first of
these values considers the errors caused in the operations
made by the receiver and in the transmission of the signals
due to thermal noise and interferences. σdivg estimates the
errors occasioned in the receiver filter, causing an ionospheric
divergence. The standard establishes a feasible range for the
sum of these two values, based on the elevation of the satellite.
0,0225 F or min elevation
+
≤
0,0121 F or max elevation
1,8 F or min elevation
2
2
σi,noise + σi,divg ≤
1,0 F or max elevation
2
σi,noise
III.
2
σi,divg
(5)
Navigation data
Message
processor
L1
Com1
GNSS/SBAS
SENSOR
Com2
SBAS
client
Integrity
processor
SISNeT
GPRS
(6)
Fig. 2. System architecture
A RCHITECTURE OF THE PROPOSED SYSTEM
The onboard equipment (OBE) is a GNSS/EGNOS sensor and an embedded computer (PC) provided with cellular
network (CN) communication connectivity. Fig. 2 shows the
OBE block diagram. The PC software reads positioning data
from GNSS sensor by the COM1 RS232 serial port. To
calculate the integrity factors the SBAS/EGNOS messages
come via two alternative ways: the GEO satellite and Internet.
In the first case, an EGNOS capable GPS sensor provides
the EGNOS messages via another RS232 port. When the line
of sight between the geostationary satellite and the receiver
is blocked by obstacles such as buildings, bridges or other
vehicles, the application switch automatically to the second
option, where the SBAS/EGNOS messages broadcasted via
Internet by SISNeT [9] are received by the vehicle through a
GPRS/UMTS link. The SISNeT version used (v3.0) supplies
the possibility of demanding specific EGNOS messages, an
interesting feature to allow a fast initialization of the system.
Once the SBAS/EGNOS messages have been received, each
one enters the first step of software processing in the onboard
computer. In the Message Processor stage some preliminary
tasks are performed to transform the message into a generic
format. In this way, for example, the SISNeT messages are
processed to extract the specific field which contains the
SBAS/EGNOS package. The task to be made now consists of
identifying the content of the common fields to all messages
and, after that, processing each type of message. A detailed
description of each type of SBAS/EGNOS message can be
found in [1]. Once each SBAS/EGNOS message is split into
its fields, the SBAS Client will be in charge of processing
it, maintaining the state of corrections and calculating the
error estimations. These values are finally used in the Integrity
Processor stage, which calculates and supplies the integrity
parameters, available for the rest of applications.
IV.
Embedded Computer
Raw EGNOS
messages
(5) and (6) indicate the value to be considered in every edge,
for conventional and SBAS satellites respectively. Because a
value of this sum is needed according to the real satellite
elevation, a linear interpolation has been assumed, considering
the minimum level of signal at 5 degrees of elevation and the
maximum at 90 degrees.
R ESULTS AND PRACTICAL APPLICATIONS OF THE
INTEGRITY PROVISION IN ONBOARD SERVICES
In the static tests, an exhaustive observation of the integrity
have been carried out. Dynamic trials show the behavior of
the integrity parameters in the location based services field.
The software has been developed in Java, allowing portability
among different platforms. This software has been designed
to support a wide variety of receivers. In the tests presented
Fig. 3. Stanford graph of HPL results in a static environment
in this paper, a Novatel Millennium OEM3 has been used. For
the static tests, the antenna was located over the roof of one
of our external laboratories, whereas in the dynamic tests it
was located over the vehicle. Finally, the Internet connectivity
with the onboard PC was possible thanks to an UMTS Novatel
Merlin U530 PCMCIA adapter, which allows GPRS/UMTS
connections.
Fig. 3 shows a graphic of HPL values obtained as the result
of a 24 hours test using our monitoring software in a static
wide open environment. This graph presents the HPL value
against the real position error considered with regard to the
correct position of the antenna. It is visible how the 99.43 %
of the values are located in the zone of normal operation, a
0.27 % of the values in the system unavailability zone, and
just a 0.3 % in the misleading information zone. The most of
the HPL values are located in the range from 5 to 15 meters.
In dynamic environments, several tests were focused on the
reception of the EGNOS messages via SISNeT and the geostationary satellite. Fig. 4 shows the results obtained performing
a route through the Campus of Espinardo of the University of
Murcia. At the first glance, the results obtained in a dynamic
environment differs from the one observed in a static location,
where the visibility and the reception of EGNOS messages
are much better. In this sense, taking into account the good
conditions of all the satellites used in the GPS solution during
HPL (m)
30
20
10
EGNOS (GEO)
0
4210
4209.5
4209
4208.5
660.3
660.4
660.5
North (Km)
660.6
660.7
660.8
660.9
660.7
660.8
660.9
East (Km)
30
HPL (m)
20
10
EGNOS (SISNeT)
0
4210
4209.5
4209
4208.5
660.3
660.4
660.5
North (Km)
660.6
East (Km)
Fig. 4. HP LEGN OS obtained with GEO (top) and SISNeT (bottom)
Distribution
1
GEO
0.9
SISNeT
0.8
0.7
0.6
F(x)
the trials, the main factors to be considered in the analysis of
the results are the visibility of the GPS and the geostationary
satellites, and the quality of the GPRS connection. The impact
occasioned by the lack of GPS signal availability due to the
poor visibility of the satellites can be seen in the zone of 660.6
km. east (longitude) and 4209.7 km. north (latitude). However,
the main problem caused by the surrounding buildings is not
the loss of GPS satellite coverage, but the major latency in the
GPRS connection and the loss of EGNOS satellite visibility.
These two last effects can be seen in the upper and lower
images of Fig. 4 respectively. When the GPRS connection gets
worse or the GEO satellite is hidden, the ratio of the received
EGNOS messages decreases, so the HPL value increases due
to the degradation of corrections. It is worth mentioning how
the operation of the integrity subsystem is better in the case of
using the GEO messages extracted from the receiver, as can
be seen in Fig. 5. Here, a cumulative distribution of the HPL
values obtained in both GEO and SISNeT cases is shown. As
can be seen, all the HPL values in the GEO case remain in
the range between 5 and 15 meters, whereas in the SISNeT
case, values nearby the 20 meters represent about the 12 %.
In Fig. 6 the values obtained from the integrity subsystem are
plotted in a histogram. The peaks in the HPL outcome using
SISNeT are in the range from 200 to 450 meters. However, it
is noticeable how the most of the values obtained in both the
GEO and SISNeT cases are lower than 20 meters. Another fact
of importance extracted from our results is the unavailability
of the HPL. This can be clearly seen in Fig. 5, where the
SISNeT cumulative distribution line begins at a value greater
than 0. This is due to the fact that the unavailability of the
HPL is expressed with a fixed value of -1.
Although the results presented show that the use of the GEO
satellite as the source of the EGNOS messages seems to be a
better option, some considerations of the environment where
the tests were made should be taken into account. Although
the visibility of the geostationary satellite signal in wide open
areas is good, the results obtained in urban canyons encourage
the use of SISNeT, being the visibility of the GEO satellite
worse in built-up areas and the GPRS coverage better.
There are different manners in which this integrity information of the positioning system can be integrated in onboard
services in vehicles. As a first approach, in our work we
have developed the integrity monitoring tool presented in
Fig. 7. In this software, the HPL value coming from the
integrity subsystem is used to show graphically the state of
this parameter. The user is warned when the HPL exceeds
a preestablished threshold. Although this an interesting monitoring tool, the integrity information is specially useful in
larger scope services. As an example, biohazard good haulers
could be truthfully tracked while riding life-critical areas.
Additionally, the HPL parameter could play a significant role
as an estimator of the confidence level in road pricing systems,
where a critical decision of the road ridden must be made. In
Fig. 8 a screenshot of a navigation application developed in
our group which uses the integrity information is shown. This
software has been used in our research group for several works
0.5
0.4
0.3
0.2
0.1
0
0
5
10
15
HPL
20
25
30
Fig. 5. HP LEGN OS cumulative distribution for both cases
140
120
EGNOS GEO
100
80
60
40
20
0
6
7
8
9
10
11
12
13
14
15
400
450
HPL
400
EGNOS SISNeT
300
200
100
0
−50
0
50
100
150
200
HPL
250
300
350
Fig. 6. HP LEGN OS histogram for both cases
Fig. 7. Integrity Monitor service
in the dynamic tests performed show how integrity values are
better when the SBAS messages are received from the GEO
in good visibility areas, as compared with the SISNeT option.
Regarding the location based services field, the investigations were focused on realtime warning of malfunctions of
the underlying positioning system, and the usefulness of the
integrity capabilities in the GIS navigation and electronic fee
collection applications.
In the paper presented, the communication technology used
has been GPRS, since the UMTS technology is not fully
operative in the south of Spain. However, the use of UTMS
is considered as a key factor in the future of LBS. Future
researches will be focused on the exhaustive study of the
influence of the communication delay and the loss of packets
in the reception of SBAS messages when an Internet connection is used through a cellular network connection, against the
reception of the messages via the GEO satellite.
VI.
ACKNOWLEDGMENTS
The authors would like to thank the Spanish Fundación
Séneca, the Agencia de Ciencia y Tecnologı́a de la Región de
Murcia, and the Spanish Ministerio de Fomento for sponsoring
the research activities under the grant 02622/BPS2/05, in
frames of the 2003-2006 PCTRM program, and the project
Evaluación y Prototipado de Servicios de Seguridad Activa
basados en GNSS, respectively.
R EFERENCES
Fig. 8. Navigation service
with GIS and road pricing. It uses the integrity provided by
the proposed architecture to warn the user when the position
of the vehicle is not guaranteed, attending the HPL value.
V.
C ONCLUSIONS
In this paper, the integrity information provided by the
broadcasted SBAS messages has been shown as applicable
to the road transport environment, as compared with the
traditional aviation purposes. Our software approximation executed in a standard PC has been presented as a valid system
for decoding the integrity parameters HPL and VPL. In the
proposed architecture two alternative ways of obtaining the
SBAS messages have been presented. First approach is based
on the possibility that the receiver provides the messages
directly from the geostationary satellite, while second employs
an Internet connection with a SISNeT server provided by the
ESA. When using this last choice, current cellular networks
play a key role in the performance of the integrity system, at
the same level than the visibility of the geostationary satellite
in the first case. The results obtained for the HPL parameter
[1] RTCA DO-229C. “Minimum Operational Performance Standards for
Global Positioning System/Wide Area Augmentation System Airborne
Equipment”. The Radio Technical Commission for Aeronautics. November 2001.
[2] Toledo, R., Zamora, M.A., Úbeda, B., Skarmeta A.G. “An Integrity Navigation System based on GNSS/INS for Remote Services Implementation
in Terrestrial Vehicles”. 2004 IEEE Intelligent Transportation Systems
Conference, Washington, D.C. pp. 477-480. October 2004.
[3] Philipp, A. B., Zunker, H. “Integrity Hits the Road”. GPS World Jul 2005.
pp. 30-36. July 2005.
[4] Bacci, G., Principe, F., Luise, M., Terzi, C., Casucci, M. “SOFT-REC:
A GPS Real-Time Software Receiver with EGNOS Augmentation”.
Workshop on EGNOS performance and applications, Gdynia, Poland.
October 2005.
[5] Opitz, M., Weber, R. “Testing the performance of SISNeT - ”SISSIM””.
The Navigation View. N III, pp. 28-33. 2005.
[6] Alcantarilla, I., Zarraoa, N., Caro, J., Hernando, C.J. “EGNOS Signal
In Space Performance”. NAVITEC 2004, Noordwijk, The Netherlands.
December 2004.
[7] Santa, J., Úbeda, B., Toledo, R., Sotomayor, C. “A Facility for
GPS/EGNOS Signal Monitoring”. Workshop on EGNOS performance and
applications, Gdynia, Poland. October 2005.
[8] Skarmeta A.G., Martı́nez H., Zamora M.A., Úbeda B., Gómez F.C, Tomás
L.M. “MIMICS: Exploiting Satellite Technology for an Autonomous
Convoy”. IEEE Intelligent System. N IV. V. vol. 17, pp. 85-89. July 2002.
[9] Toran-Marti, F. and Ventura-Traveset, J. “The ESA SISNeT Project:
Current Status and Future Plans”. European Navigation Conference GNSS
2004, Rotterdam. May 2004.
[10] Walter, T. “WAAS MOPS: Practical Examples”. Proceedings of the
National Technical Meeting of the Institute of Navigation, San Diego.
January 1999.
Mejora de la Disponibilidad de SBAS en Navegación Terrestre
B.
31
Detalles sobre el Software de Conversión de Mensajes
El software de conversión de mensajes desarrollado forma parte de un programa con diversa funcionalidad para analizar los GNSS bajo diferentes configuraciones. Este apéndice describe brevemente las
capacidades de dicho programa, denominado SisnetTrans, y su modo de uso.
B.1.
Receptores Soportados
El software SisnetTrans soporta varios receptores del mercado. A pesar de que todos suelen incorporar
un protocolo de comunicación NMEA estándar, la información que incorporan los mensajes en este
formato no es suficiente para las labores que desempeña el software. De esta manera, se hace necesario
implementar el protocolo de comunicación propietario de cada fabricante, e incluso de cada dispositivo.
Hasta la fecha, los receptores soportados son:
Thales DG16.
Novatel Millenium OEM3.
Novatel Millenium OEM4.
San Jose Navigation FV-21.
Thales Lassen iQ.
Thales GG24.
Todos estos receptores han sido testeados y usados en diversos trabajos relativos a la navegación
terrestre. Todos ellos disponen de soporte para GPS y para EGNOS y, adicionalmente, el modelo GG24
incorpora soporte para GLONASS también, lo cual lo hace perfecto para pruebas de disponibilidad
mediante doble constelación. El modelo OEM3 ha sido usado para pruebas de rendimiento con SISNeT,
ya que dispone de la posibilidad de decodificar los mensajes de EGNOS a través de la inserción de
los mensajes por puerto serie. El FV-21, por otra parte, ha sido útil para las pruebas del sistema de
conversión de mensajes presentado, ya que es un ejemplo tı́pico de un receptor de gama media para
navegación terrestre, pero con soporte para correcciones RTCM por puerto serie.
B.2.
Requerimientos para el Uso de SisnetTrans
Puesto que el software está implementado en Java, su ejecución es posible en cualquier arquitectura
para la que exista una máquina de virtual. Es necesaria, sin embargo, una librerı́a para el acceso al
puerto serie. A través del uso de SisnetTrans se han usado dos librerı́as fundamentalmente, la propia
implementación de Sun, llamada JavaComm, y la implementación que ofrece RXTX, que presenta sin
duda mayores beneficios, puesto que está disponible para diversas arquitecturas, entre las que se encuentran UNIX, Windows, y Solaris. Programando la aplicación con esta última librerı́a no se hace necesario
compilar el software nuevamente para plataformas sin soporte de JavaComm.
B.3.
Modos de Ejecución del Programa
El software funciona a modo de comando tı́pico de UNIX, de forma que es posible incluir diversos
parámetros que definen la configuración deseada. Suponiendo que la máquina virtual, las librerı́as y las
clases de la aplicación están situadas correctamente en el path del sistema, el programa se invoca con el
formato siguiente:
java sisnettrans.SisnetTrans [opciones] [modo_funcionamiento]
Tanto las opciones como el modo de funcionamiento son opcionales, existiendo una configuración que
se ejecuta por defecto, tal y como se indica posteriormente. El conjunto de las opciones disponibles se
incluye a continuación:
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
32
José Santa Lozano
[email protected]
[opciones]
-help
-logoutput <nombre_fichero>
-test
-time <seg>
-configFile <nombre_fichero>
-central <IP>
La utilidad de cada una de estas opciones es la siguiente:
-help Muestra la lı́nea de llamada y los parámetros posibles.
-logoutput <nombre fichero> Especifica un nombre para el fichero de log de salida. Por defecto el
fichero usado es SisnetTrans.log.
-test El programa se ejecuta mostrando información de conversión y de navegación por pantalla. Por
defecto esta opción está habilitada.
-time <seg> Especifica un tiempo de funcionamiento en segundos, tras el cual el programa termina.
Por defecto, este tiempo se establece a 3600 seg.
-configFile <nombre fichero> Indica el fichero de opciones del programa a usar, el cual se explica
posteriormente. Por defecto, el fichero usado es SisnetTrans.properties.
-central <IP> Configura un servidor de seguimiento hacia donde mandar la posición periódicamente.
Para ello se debe situar la dirección IP del servidor. Si no se indica lo contrario, esta opción no es
usada.
Con el modo de funcionamiento es posible establecer la configuración en la que se quiere que el
programa se ejecute. Solamente es posible usar uno de los siguientes modos de forma simultánea:
[modo_funcionamiento]
-rtcm [opciones_rtcm]
-loginput <nombre_fichero>
-sisnet
-egnos
-single
-auto
-egnosRcvInput
-egnosEgnosRcvInput
El significado de todos ellos es el siguiente:
-rtcm [opciones rtcm ] El programa realiza una conversión de mensajes desde RTCA DO-229C a
RTCM, usando como fuente de mensajes EGNOS a SISNeT. El receptor se configura en modo
diferencial para que acepte las correcciones a través de puerto serie.
-loginput <nombre fichero> El funcionamiento es análogo a la opción de generación de RTCM
estándar, pero utiliza un fichero de entrada de log para obtener la información de navegación y los
mensajes EGNOS. El formato del fichero de log de entrada es el mismo que el que usa el programa
para generar los logs de salida.
-sisnet El programa recibe información de EGNOS a través de SISNeT, y manda los mensajes RTCA
DO-229C a través del puerto serie. El receptor se configura en modo diferencial para que acepte
SBAS a través del puerto serie.
-egnos El receptor se configura en modo SBAS y, aunque se generan mensajes RTCM a partir de
SISNeT, estos no se mandan a través de los puertos locales.
-auto El receptor se configura con SBAS, según el modo anterior, pero cuando la posición obtenida no
es diferencial se comienzan a enviar los mensajes de corrección por el puerto serie.
-single El receptor se configura en modo GPS estándar, y no se mandan correcciones a través de los
puertos locales.
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
Mejora de la Disponibilidad de SBAS en Navegación Terrestre
33
-egnosRcvInput El receptor se configura en modo SBAS y, además, se guardan los mensajes RTCA
DO-229C capturados por el receptor y extraı́dos por un puerto local. No se generan correcciones
RTCM.
-egnosEgnosRcvInput Se configura el receptor en modo SBAS y se generan correcciones RTCM a
partir de SISNeT, aunque no son mandadas al receptor. Además de esto, se arranca otro motor de
procesamiento que guarda los mensajes RTCA DO-229 desde el receptor, según el modo anterior.
El comportamiento obtenido es el resultado de combinar los modos -egnos y -egnosRcvInput. Como
resultado, se generan dos logs de salida, uno para cada modo.
En los modos de ejecución en los que el software dispone de un medio de entrada de mensajes RTCA
DO-229C, a través de SISNeT o del propio receptor, se calculan además los factores de integridad de
la posición, que también se guardan en los logs de salida. Mediante el modo -egnosEgnosRcvInput se
dispone de una doble entrada de mensajes SBAS, por lo que los factores de integridad se calculan por
duplicado. Esto es útil, por ejemplo, para testear la disponibilidad de integridad sobre el sistema de
navegación cuando se recibe SBAS a través del satélite geoestacionario y a través de Internet.
En la generación de mensajes RTCM es posible, además, indicar dos parámetros de funcionamiento
alternativos acerca de cómo tratar la generación de correcciones diferenciales de la ionosfera:
[opciones_rtcm]
-noIOcorr
-simulateIOcorr
El significado de estos parámetros es el siguiente:
-noIOcorr No se mandan correcciones diferenciales sobre la ionosfera.
-simulateIOcorr La información de corrección sobre la ionosfera se incluye en los mensajes de corrección
diferencial convencionales.
Solamente se puede usar una de estas opciones y, en caso de no usar ninguna, se generarán mensajes
RTCM Tipo 15 de corrección de los efectos de la ionosfera.
B.4.
Fichero de Configuración Básica
La configuración básica del software SisnetTrans se incluye a través de un fichero de configuración
que se lee en el arranque. El conjunto de opciones que se incluyen en él se pueden observar en el siguiente
ejemplo:
# SISNeT Data Server address
dsAddress=131.176.49.142
# SISNeT Data Server port
dsPort=7777
# SISNeT communication timeout, in milliseconds
dsTimeout=5000
# Login for SISNeT connection
sisnetUser=XXXX
# Password for SISNeT connection
sisnetPasswd=XXXX
# RTCM reference station identifier
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
34
José Santa Lozano
[email protected]
rtcmReferenceStationId=23
# Interval for RTCM type 9 message generation, in milliseconds
rtcm9MessageInterval=10000
# Interval for RTCM type 15 message generation, in milliseconds
rtcm15MessageInterval=30000
# GPS receiver to be used
receiver=NovatelMilleniumOEM3Receiver
# Receiver port to send the log commands
receiverLogCOMPort=1
# Receiver port to send differential correction messages
receiverCorrectionCOMPort=2
# Receiver port for obtaining the SBAS messages
receiverRawDataCOMPort=2
# Host port to be used to send log commands
localLogCOMPort=COM1
# Host port to be used to send differential correction messages
localCorrectionCOMPort=COM5
# Machine port to be used for receiving SBAS messages from receiver
localRawDataCOMPort=COM5
# Interval for asking for navigation data to receiver
receiverPollingInterval=500
# Time to wait for receiver initialization, in milliseconds
receiverInitializationTimeout=200000
# PRN of the SBAS satellite to be used
waasSatellite=120
# Connection port to the monitorization central
centralPort=7776
Las opciones que incluye el fichero de configuración son las siguientes:
dsAddress Dirección IP del servidor SISNeT.
dsPort Puerto de conexión al servidor SISNeT.
dsTimeout Tiempo de espera máximo de contestación del servidor SISNeT, en milisegundos.
sisnetUser Usuario de conexión al servidor SISNeT.
sisnetPasswd Contraseña de conexión al servidor SISNeT.
rtcmReferenceStationId Identificador de la estación de monitorización emulada por el PC, el cual
genera las correcciones. Este valor se sitúa en los mensajes RTCM.
rtcm9MessageInterval Intervalo a esperar entre cada mensaje RTCM Tipo 9 generado por el programa.
rtcm15MessageInterval Intervalo a esperar entre cada mensaje RTCM Tipo 15 generado por el programa.
receiver El identificador del receptor que se desea utilizar.
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08
Mejora de la Disponibilidad de SBAS en Navegación Terrestre
35
receiverLogCOMPort El identificador del puerto del receptor usado para la comunicación con el PC
y para la recepción de datos de navegación.
receiverCorrectionCOMPort El identificador del puerto del receptor usado para enviar correcciones
diferenciales en RTCM.
receiverRawDataCOMPort El identificador del puerto del receptor usado para recibir en el PC
mensajes en crudo de SBAS y de GPS.
localLogCOMPort Puerto del PC usado para la comunicación con el receptor y para la petición de
datos de navegación.
localCorrectionCOMPort Puerto del PC usado para emitir mensajes de corrección RTCM.
localRawDataCOMPort Puerto del PC usado para recibir mensajes en crudo de GPS y SBAS desde
el receptor.
receiverPollingInterval Intervalo a esperar entre cada petición de datos de navegación al receptor.
receiverInitializationTimeout Tiempo de inicialización máxima que se espera en la configuración
inicial del receptor.
waasSatellite Número identificativo del satélite geoestacionario SBAS usado.
centralPort Puerto usado por defecto para la conexión a una central de seguimiento.
Master “Tecnologı́as de la Información y Telemática Avanzadas” - Curso 2007/08