gina: aplicaciÓn de gnss/galileo para ruc y servicios de valor aÑadido. demostraciÓn a gran...

GINA: APLICACIÓN DE GNSS/GALILEO PARA RUC Y SERVICIOS DE VALOR AÑADIDO. DEMOSTRACIÓN A GRAN ESCALA Y RESULTADOS

GNSS for INnovative road Applications

06/04/2011

XI Congreso ITS España, Barcelona

INTRODUCCIÓN


X Congreso ITS España, Madrid

Company’s

logo06/04/2011


INTRODUCCION (I) GINA: proyecto financiado bajo el Call 1 de Galileo en FP7 por la GSA / EC y coordinado por GMV

GINA: Nuevo proyecto de I+D en el area de aplicaciones GALILEO como anteriores proyectos de otros FP como ADVANTIS, GIROADS, etc…

Datos claves de GINA:

Collaborative Project

24 meses de duracion

2.2 M€ (~1.3 M€ funded)

12 socios de 7 nacionalidades

Objetivos proyecto GINA:

Análisis del contexto y mercado Trials: Demostrador a gran escala de un sistema RUC a escala Nacional Diseminación: contribución a la adopción del GNSS en los sistemas de pago por uso de la infraestructura

Constituye un paso más para la adopción real del uso de los sistemas GNSS (EGNOS, Galileo) en el sector de la carretera

Los resultados obtenidos y las metodologías empleadas pueden dar un paso mas hacia la implantación a gran escala de estas aplicaciones



Company’s

logo06/04/2011


INTRODUCCION (II) Las bases de una aplicación de EFC/RUC basada en un sistema GNSS serian las siguientes:

GP0

GP1 GP2

GP3

GP4

GP5

1 Extensión de la aplicación EFC

2 Definicion de áreas de cobro + tarifa

Toll

Colle

ctor

Toll

Colle

ctor

Serv

ice P

rovid

er

Serv

ice P

rovid

er

3 Detección de zonas de cobro con integridad de posición

1 OBU EFC + VAS

ProtectionLevel

Error

2 Calculo PVT + PLs


FOTs GINA



Company’s

logo06/04/2011


FOTS PROYECTO GINA Implementación de un demostrador a gran escala de una aplicación EFC + VAS basado en

GNSS, Escala nacional (Holanda) Voluntarios “reales” Cumplimiento de los requisitos determinados reales Diferentes tipos de test + análisis

Evaluación de objetivos técnicos, funcionales y comerciales de las distintas funciones presentes Demostración de la validez de un sistema EFC basado en GNSS Implementación de un modulo VAS en la misma plataforma EFC Validación de las prestaciones del sistema GNSS para RUC y VAS Valor añadido de los sistemas EGNOS (GALILEO) y otras tecnologías complementarias (uso del

odómetro del CANBUS, integridad de la posición) a la solución GNSS Metodología de evaluación de sistemas GNSS

Descripción de los test a realizar y principales características de los mismos

FOTsNumero vehiculos

DuracionVehiculos/

ConductoresVAS

Sistema de Referencia

CAN BUS Evaluacion Escenarios

Globales o extensivos

100 6 meses aproxVoluntarios (ARVAL)

Si No No Alto nivelVariables y no

controlados

Exhaustivos 2 4-5 semanasControlados por el

proyectoNo Si Si

Prestaciones GNSS

Definidos en el proyecto



Company’s

logo06/04/2011


OBJETIVOS FOTS

ExhaustivosExhaustivos Extensivos o globalesExtensivos o globales

Identificación de Geo-Objects

Evaluación de las prestaciones GNSS

Prestaciones de calculo de distancias recorridas

Análisis de las prestaciones de cobro

Exactitud Posición

Riesgo de Integridad

Disponibilidad de PLs

Exactitud Distancia

Identificación Correcta/Incorrecta

Efectos sobre calculo de distancias

Media de precisión de cargos y distancias

Prestaciones de cobro

Integridad de cobro

Evaluación de las prestaciones de la aplicación con respecto a los requisitos

definidos por ABvM

Recabar opinión de usuarios finales sobre la funcionalidad del servicio y sus

beneficios

Evaluación de prestaciones de las OBUs ante distintos geo-objects y

configuraciones

Implementación y demostración del valor añadido de otros servicios (VAS)

sobre la plataforma EFC

Metodologias de definicion



Company’s

logo06/04/2011


FUNDAMENTOS DISEÑO FOTS

Los test globales o extensivos se centran en la viabilidad a alto nivel de una aplicación EFC + VAS escala nacional Los usuarios hacen sus recorridos normales con las OBUS grabando datos y comprobando sus cobros a través de un

portal web El feedback obtenido de los usuarios sirve para comprobar la aceptación de la iniciativa Configuraciones de GNSS con y sin EGNOS recogidas y evaluadas

1. OBU sistema GNSS 2. Escala Nacional 3.Definicion geobjects

Rutas de Evaluación OBU sistema GNSS Sistema Referencia GNSS Definicion geobjects

Los test exhaustivos se centran en las prestaciones aportadas por el sistema GNSS frente a requisitos establecidos

Es necesario por tanto disponer de la información de referencia para contrastar prestaciones Los recorridos deben suponer una muestra de situaciones difíciles para el sistema GNSS Las zonas de cobro (geo-objects) tienen que simular diferentes, áreas y zonas para evaluar 4 Diferentes configuraciones del sistema probadas: GNSS (G), GNSS+EGNOS (E), GNSS+CANBUS (C),

GNSS+CANBUS+EGNOS (A)


De palabra, puedes dar detalles sobre los vehículos utilizados en cada caso, las características y duración de las rutas etc. (en el caso de los exhaustivos, además, puedes mencionar la parte de Navteq por encima).Si lo prefieres, puedes añadir otra transparencia con esta información, aunque debería ser muy ligera y sinténtica en este casoSe podría añadir por ejemplo una transparencia con las estadísticas de los trials también, lo que evaluamos etc. (tienes info en la presentación del Workshop#1 de GINA)

RESULTADOS



Company’s

logo06/04/2011


RESULTADOS: DISTANCIA/POSICION

Error de Posición Absoluto (global) Error Relativo de Distancia Recorrida (global)

Los datos recogidos muestran que los errores de distancia total son de valor bajo mayoritariamente para el percentil 50, alcanzando valores en todas las configuraciones inferiores al 0.33% de la distancia real

Las configuraciones que hacen uso del odómetro del CANBUS en su sistema presentan los mejores resultados pasando al 0.23% de error en el percentil 95 y de apenas 0.05% para el percentil 50

Las configuraciones que hacen uso de la información del odómetro del CANBUS presenta los mejores resultados en todo tipo de escenarios, sin merma de prestaciones en entornos densamente urbanos


Por favor Chema, pon las gráficas que se han utilizado en el paper. Por otro lado, utiliza las cifras que se detallan en el paper a la hora de dar resultados (es decir, siendo más precisos, hablamos de percentiles (p.e. 95, 0.23%) destacando las cifras para el caso del CANBUS etc. Por ejemplo, en el paper la gráfica de la izquierda no se usa, sino la de error de posición


Company’s

logo06/04/2011


RESULTADOS: GEOBJECTS

Los geobjects definidos como alternativos presentan valores de prestaciones peores que los oficiales

Mayor numero de geobjects no detectados

Mas del 50% distancia recorrida dentro de los mismos

La metodología empleada en la definición de geobjects es un factor clave para las prestaciones de un sistema RUC

Geo-objects estrechos (<0.5km) considerados “alternativos” frente a otros adecuados a la topografía de las carreteras considerados “oficiales” evaluados

Geobjects oficiales fueron detectados en su totalidad (100%) sin error

0% de geo-objects (oficiales y alternativos) identificados incorrectamente

Distancia total no computada (en los Geo-objects oficiales) de un 1.64%. La distancia recorrida dentro de los mismos detectada de forma errónea <0.1% de la distancia dentro del geoobject


Geo-objects Oficiales Geo-objects Alternativos

Variable Definicion

No-detection

Identificación incorrecta de Geo-object,

Where GEOOBJECT_X = 0 TRUTH_GEOOBJECT_X = 1 or

Where GEOOBJECT_X = 1 TRUTH_GEOOBJECT_X = 0

Requisito cla

ve para un

sistema RUC


Company’s

logo06/04/2011


RESULTADOS: PRECISIÓN COBRO


2 metodologías de calculo de distancia dentro de geobject usadas 2 posiciones consecutivas dentro de la zona y calculo de la Media Distancia entre la primera posición dentro y primera fuera de zona

La segunda metodología muestra valores mas bajos cobro por defecto

En todos los casos los eventos de cobro en exceso fueron del 0%.

Resultados en línea con los requisitos de un sistema RUC real como el de Holanda

Configuration

Method C: GPS+CANBUSA: GPS+CANBUS+

EGNOS

G: GPS

E: GPS+

EGNOS

Main -0.74% -0.74%-

0.66%

-0.65%

Alternative

-0.57% -0.57%-

0.44%

N/A

Comparativa Error Relativo de Cobro según metodologías usadas

En linea co

n requisit

os ABvM.

Yo quitaría esta transparencia porque esto no aparece en el paper que hemos mandado.Por contra, incluiría una transparencia con los resultados de las prestaciones de cobro en el sector de autovía (figura 6 en el paper), con sus correspondientes explicaciones


Company’s

logo06/04/2011


RESULTADOS: SECCION AUTOVIA

Error de Posición Absoluto Valores HPL El análisis de los datos globales fue extendido a un subconjunto de datos en entornos con buena visibilidad, para

analizar las prestaciones de EGNOS (cuando sigue el estándar definido para aviación civil)

Las prestaciones de GNSS+EGNOS en este entorno pasan a ser las primeras en cuanto a precisión de la posición. Para el percentil 95 la configuración con EGNOS daba resultados de error en la posición < 3 metros y para el resto < 6 metros

Los valores del HPL (Horizontal Protection Level) para la misma configuración y escenario también producen valores satisfactorios de integridad. Los valores del HPL eran <15 metros (percentil 99) para la configuración GNSS+EGNOS con un error de Integridad asociado de 3x10e-4 (probabilidad que el error de posición sea mayor que el valor del HPL computado)

Errores de cobro en secciones de autovía dentro de los rangos vistos para el conjunto de datos globales (entre -0.07% y -0.15% para todos los recorridos, entre 0.21% y 0.38% para percentil 95)


Error de Cobro Relativo


Company’s

logo06/04/2011


RESULTADOS: TEST GLOBALES O EXTENSIVOS

El análisis de los datos globales está en proceso de finalización, resultados generales preliminares disponibles

Las prestaciones del sistema en entorno libre, para GNSS y sobre todo para GNSS+EGNOS muestran resultados satisfactorios

TTFF, disponibilidad, continuidad del sistema y valor de los HPLs dentro de márgenes aceptables

La opinión de los usuarios finales sobre el sistema será añadida dentro de los resultados del proyecto a la vista del comportamiento del sistema


CONCLUSIONES



Company’s

logo06/04/2011


CONCLUSIONES

Actualmente existe un gran interés tanto político como económico en Europa con relación a la introducción de aplicaciones RUC a nivel nacional

El uso de la navegación por satélite presenta grandes ventajas respecto a otras tecnologías en las aplicaciones de pago por uso en particular por su flexibilidad y bajo coste para grandes redes. No obstante el sistema GPS tiene algunas debilidades, el uso de la Integridad aparece como la solución más eficiente

GINA tiene como base de la arquitectura de la solución propuesta, el uso de sistemas GNSS basados en la provisión de Integridad de la posición como mecanismo de protección de los usuarios frente al cobro erróneo

GINA provee análisis exhaustivos de prestaciones del sistema mediante demostraciones a gran escala así como la evaluación y análisis de diferentes configuraciones del sistema GNSS para comparar las prestaciones, con un sistema GNSS/INS en línea con las técnicas más avanzadas

GINA analiza las mejores metodologías de definición de sistemas RUC para maximizar las prestaciones del sistema GNSS en términos de configuración del sistema y definición de elementos como los geo-objects donde la metodología empleada es clave para maximizar la eficiencia del sistema.

Los resultados de los test exhaustivos sobre el vehículo I muestran la fiabilidad y viabilidad del uso del GNSS en sistemas RUC y las configuraciones evaluadas muestran que el uso de INS (CANBUS) da mejores resultados en cuanto a la correcta estimación de la distancia recorrida, base del cómputo del cobro a efectuar.

Como conclusión general, GINA presenta un sistema de RUC basado en GNSS que utiliza Integridad de posición+ odómetro del CANBUS para: Distintos esquemas de RUC, discretos y continuos Escenarios urbanos e interurbanos No requiere el uso de cartografía y técnicas de mapmatching Permite el uso de OBUs sencillas y de bajo coste Proporciona garantía del cumplimiento de prestaciones mínimas Adecuada para distintas arquitecturas de la OBU (ligera (thin), inteligente (smart) o pesada (thick)) Cumplimiento de los requisitos definidos por sistemas exigentes reales como el ABvM que se definió en

Holanda


Gracias

Jose Maria Martin Bobis – [email protected]

gina: aplicaciÓn de gnss/galileo para ruc y servicios de valor aÑadido. demostraciÓn a gran...

Documents