ES2655910T3 - Pago automático y/o registro de tasas relacionadas con el tráfico - Google Patents

Abstract

Un sistema para el pago automático de tasas de circulación para vehículos, comprendiendo el sistema - una pluralidad de unidades móviles, estando cada unidad adaptada para colocarse en un vehículo, y - una unidad de base que está adaptada para comunicarse con la pluralidad de unidades móviles, en el que cada unidad móvil comprende un receptor de sistema de navegación basado en satélite y medios de comunicación para transmitir una pluralidad de observables de posición que contienen pseudorrangos a la unidad de base, y en el que la unidad de base comprende medios de comunicación para comunicarse con la pluralidad de unidades móviles, y medios de procesador para procesar dichas posiciones observables para determinar una primera posición del vehículo en relación con la información de tasas de circulación precargada almacenada en la unidad de base o accesible desde la misma, caracterizado porque dicho medio de procesador está además adaptado para calcular una posición corregida del vehículo en caso de que la primera posición del vehículo caiga dentro de un rango predeterminado de una sección de carretera donde se han de pagar tasas de circulación, comparar la posición corregida calculada del vehículo con la información de tasas de circulación precargada almacenada o accesible desde la unidad de base y determinar si el vehículo ha entrado en una sección de carretera donde se deben pagar las tasas de circulación.

Description

5

10

15

20

25

30

35

40

45

50

55

DESCRIPCION

Pago automático y/o registro de tasas relacionadas con el tráfico Campo de la invención

La presente invención se refiere a un sistema, un procedimiento y una unidad móvil/dispositivo móvil para determinar con precisión la posición de una unidad portátil o móvil, tal como por ejemplo un vehículo. La presente invención se refiere además al pago o al registro automático de tasas o impuestos relacionados con el tráfico, tales como, por ejemplo, tasas de circulación.

Antecedentes de la invención

La Solicitud de patente estadounidense 2002/0143611 divulga un sistema y un procedimiento para realizar transacciones de pago de vehículos. El sistema del documento US 2002/0143611 incluye un vehículo con un componente que determina la ubicación y un componente de comunicación, y un servidor con un componente de comunicación, un componente de identificación de la ubicación del vehículo y un componente que completa la transacción. El componente que determina la ubicación determina la ubicación del vehículo, y el componente de comunicación del vehículo envía la información de ubicación del vehículo determinada al servidor. El componente de comunicación del servidor recibe la información de ubicación del vehículo determinada desde el vehículo. El componente de identificación de la ubicación del vehículo determina si la ubicación del vehículo enviado ubica el vehículo en una ubicación de pago. Si el componente de identificación de la ubicación del vehículo determina que el vehículo se encuentra en una ubicación de pago, el componente que completa la transacción completa una transacción de pago.

La determinación de emplazamiento componente del documento US 2002/0143611 se describe como un receptor GPS independiente. Por ejemplo, en los párrafos 15, 16 y 20 se afirma que la ubicación del vehículo se determina mediante coordenadas de GPS.

Es un inconveniente del sistema divulgado en el documento US 2002/0143611 que la determinación de la posición del vehículo solo lleva a una precisión de alrededor de 3-20 metros porque solo se utilizan coordenadas GPS no corregidas. Para la determinación de la ubicación en relación con, por ejemplo, el pago automático de tarifas de estacionamiento de vehículos, una precisión de 3-20 metros es insuficiente ya que en los límites entre dos zonas de aparcamiento vecinas que tienen diferentes niveles de tarifa de aparcamiento es imposible determinar en qué zonas vecinas está ubicado el vehículo en realidad. Además, resulta muy difícil determinar si un vehículo está aparcado dentro o fuera de un área de aparcamiento en caso de que el vehículo esté aparcado en una de las cabinas de aparcamiento más alejadas del área de aparcamiento. Como consecuencia, si la posición del vehículo no puede determinarse correctamente, una tarifa de aparcamiento asociada no puede determinarse correctamente y, por lo tanto, pagarse correctamente.

Por lo tanto, existe un riesgo potencial de que la ubicación real de un vehículo se determina erróneamente cuando se aplican solo coordenadas GPS sin corregir.

Con el fin de ser capaz de determinar la posición de un vehículo con suficiente precisión la posición del vehículo debe ser determinable con una precisión de alrededor de la mitad de la anchura del vehículo. Esto implica que la posición de un vehículo debe poder determinarse con una precisión horizontal estática que se aproxime a la mitad del ancho de un vehículo estándar.

El GPS ordinario se basa en hacer observaciones de las señales GPS en el receptor (cliente) y realizar una serie de operaciones matemáticas en los datos a través de procesamiento de señal digital para lograr una estimación de posición. Es conocido y reconocido por aquellos familiarizados con el GPS y la navegación satelital en general, que la precisión alcanzable de las estimaciones de posición alcanzables a través de receptores de GPS independientes (o cualquier otro receptor de navegación satelital independiente) es limitada, y que existen varios procedimientos para introducir medidas para obtener una mayor precisión que la proporcionada por un receptor GPS solo.

La precisión de la estimación de la posición que es alcanzable en un receptor GPS solo soporte básico está en gran medida limitada por los errores que se imponen a las señales GPS. También se reconoce que el nivel de complejidad y la sofisticación del procesamiento de la señal digital empleado en el receptor influye en la precisión alcanzable en gran medida, es decir, se espera que un receptor avanzado y costoso rinda mejor que un receptor simple y económico dadas las mismas condiciones de operación. Está bien establecido que se pueden emplear varios procedimientos para obtener estimaciones de posición con mayor precisión, tales como DGPS (GPS diferencial) y SBAS (sistemas de aumento basados en satélites).

Un sistema y procedimiento para la carga automática de aparcamiento de vehículos que se sugiere en el documento EP 0 952 557 A. En el documento EP 0 952 557 A el DGPS se presenta como el medio para obtener la precisión suficiente. Además, el documento US 5970481 A describe un sistema y procedimiento para el pago automático de tasas de circulación, donde la determinación de la ubicación del vehículo puede llevarse a cabo ya sea por la unidad móvil del vehículo o remotamente por la unidad de base. El principio de DGPS es utilizar las diferencias observables

5

10

15

20

25

30

35

40

45

50

55

del GPS en lugar de las observaciones absolutas en sí mismas. Las diferencias se obtienen al restar las correcciones diferenciales de las observaciones realizadas en el receptor del cliente. Las correcciones diferenciales se realizan en una estación de referencia diferencial (también llamada baliza DGPS) y las correcciones se difunden al receptor del cliente típicamente a través de comunicaciones inalámbricas, emitidas como una señal de radio local (típicamente a una frecuencia de onda larga de alrededor de 300 kHz ) Un efecto secundario de utilizar diferencias de observaciones GPS para calcular la posición del receptor cliente es que en lugar de la posición absoluta, se encuentra la posición del receptor con respecto a la estación de referencia (es decir, un vector de referencia entre la estación de referencia y el receptor del cliente).

La idea que subyace detrás de DGPS es que el error que limita la precisión alcanzable está - hasta cierto punto - presente en las señales GPS, tanto en la estación de referencia y el receptor del cliente (matemáticamente, los errores están correlacionados). Esto significa que cuando se forman diferencias, los errores que son comunes tanto a la estación de referencia como al receptor del cliente se cancelan por sustracción. Por lo tanto, DGPS se basa en la suposición de que los errores en la estación de referencia y el receptor del cliente son los mismos.

Este supuesto, por supuesto, solo es del todo cierto cuando el receptor del cliente se encuentra en la misma ubicación geográfica como la estación de referencia. Los errores están altamente correlacionados cuando los receptores están muy cerca, y en este caso la aplicación de correcciones diferenciales puede dar como resultado una precisión de posicionamiento dramáticamente mejorada. Sin embargo, esta mejora se deteriora a medida que aumenta la separación geográfica entre la estación de referencia y el receptor cliente (y la correlación espacial disminuye) y cuando la distancia entre los dos excede unas pocas decenas de kilómetros, el efecto beneficioso se reduce significativamente.

Los errores predominantes que se cancelan de esta manera son las tasas por la ionosfera en que las señales de satélite se distorsionan de una manera algo sistemática cuando las señales pasan a través de la ionosfera y la troposfera - el primero de los dos siendo el más significativo. Ambas fuentes de error pueden variar localmente a corto plazo principalmente debido a centelleos de la ionosfera y variaciones troposféricas, como la humedad del aire, por lo que los errores comunes del GPS que pueden cancelarse con DGPS pueden variar mucho cuando la distancia entre la estación de referencia y el receptor del cliente está incrementada.

Por lo tanto, para obtener correcciones diferenciales eficientes, se requiere una red de estaciones de referencia para proporcionar una cobertura local. Esto, a su vez, significa que las estaciones de referencia deben considerarse parte de la infraestructura local para cualquier sistema que dependa de DGPS para un funcionamiento adecuado. Cuanto mayor sea el requerimiento de precisión de posicionamiento, más precisa será la cuadrícula de las estaciones de referencia.

Por lo tanto, este documento EP 0 952 557 A sugiere la corrección de la posición mediante el uso de DGPS, la precisión de la posición disponible dependiendo en gran medida de la densidad de las estaciones de referencia. Además, es una desventaja de DGPS que la precisión de posición disponible puede variar de un área geográfica a otra área geográfica.

En contraste con DGPS, la idea detrás del SBAS es emplear un número de estaciones de monitorización satelital, que calculan los datos de aumento que puede ser difundida a través de los satélites en lugar de estaciones de referencia locales para llegar a los usuarios en una región mucho más amplia. Uno de los propósitos principales de SBAS es obviar la necesidad de una red de estaciones de referencia locales. Por lo tanto, usar SBAS significará independencia de la infraestructura local.

El principio de SBAS es el uso de un número de estaciones RIMS ubicados estratégicamente (estaciones del monitor de integridad y rango) para observar la constelación GPS. Las RIMS reciben las señales de GPS y comparan las estimaciones de posición que pueden determinarse a partir de los observables de GPS con las ubicaciones conocidas de las RIMs. Esto se usa para formar correcciones que se envían desde la RIMS a un centro de procesamiento central. En el sistema EGNOS, los datos se recopilan en el centro de control de la misión donde se calculan (1) errores a largo plazo de las órbitas de los satélites, (2) errores a corto y largo plazo de los relojes del satélite, (3) rejillas de corrección de la ionosfera y (4) información de integridad. Estos se combinan para formar el conjunto de datos de aumento de EGNOS.

En lo que respecta a aumentar la precisión de posicionamiento, las rejillas de corrección de la ionosfera son la característica más importante. El flujo continuo de observaciones de la red RIMS se usa para formar un "mapa" del TEC (contenido total de electrones) en la ionosfera para el área cubierta por las estaciones RIMS (que para EGNOS es toda Europa). TEC es el número de electrones en una columna de una sección transversal de un metro cuadrado a lo largo de un trayecto de señal a través de la ionosfera, y esto describe con precisión el error que la ionosfera impone en la señal del GPS.

Los mapas de TEC se envían a los satélites geoestacionarios SBAS que los retransmiten a proporcionar los receptores de cliente con la información que necesitan para llevar a cabo la corrección de los efectos de la ionosfera. Utilizando el mapa TEC, los receptores GPS del cliente pueden calcular el "punto de perforación", es decir, el punto donde la señal del satélite GPS penetra en la ionosfera y el retraso de la señal de cada satélite utilizado para

5

10

15

20

25

30

35

40

45

50

55

calcular la posición y luego corregir los datos para una mayor precisión en la determinación de posición.

En SBAS las estaciones de monitorización no proporcionan correcciones individuales aisladas, pero los datos de todas las estaciones juntas se combinan para calcular un mapa de corrección para un área amplia. Cada receptor individual luego corrige su propia posición mediante el uso de estos datos. De esta forma, la precisión que se puede lograr es incluso mejor que con DGPS, excepto en los casos en que el receptor del cliente está muy cerca de una estación de referencia, donde el DGPS puede superar al SBAS.

En conclusión, la clave del SBAS es que las correcciones que se aplican se calculan en base a la posición del receptor del cliente y que esto es independiente de la ubicación de las estaciones de monitorización. Esto proporciona una amplia cobertura independiente de la infraestructura local. No se proporciona un mapa TEC en los DGPS convencionales basados en estaciones de referencia diferenciales, por lo que en DGPS la reducción de los errores de la ionosfera depende únicamente de la proximidad a una estación de referencia. A diferencia de DGPS, se puede esperar que el SBAS se desempeñe de manera consistente a lo largo de una amplia área independiente de las estaciones de referencia.

Debido a las frecuencias de radio utilizadas en los sistemas DGPS y SBAS, la aplicación práctica de DGPS y SBAS difiere de manera fundamental. El DGPS utiliza transmisiones de radio de onda larga alrededor de 300 kHz, que es equivalente a longitudes de onda de alrededor de 1 km, mientras que GPS usa la frecuencia de radio UHF 1575,42 MHz para el portador GPS L1, que es equivalente a una longitud de onda de solo 19,029 cm. Esto implica que no es factible prácticamente recibir la señal DGPS con una antena de parche GPS normal ya que la geometría y el tamaño físico de la antena GPS se determinan a partir de una determinada fracción de la longitud de onda de 19,029 cm que nuevamente está determinada por las características dieléctricas de los materiales cerámicos utilizados en la antena.

La frecuencia GPS permite el uso de antenas de bajo perfil baratas, compactas, tales como antenas de parche de microcinta de cerámica, mientras que la señal DGPS con su longitud de onda siendo aproximadamente 5000 veces más larga requiere una tecnología de antena significativamente diferente, a saber, una antena mucho más grande, más cara y de latón voluminoso o de núcleo de ferrita.

Las señales SBAS, por otro lado, se emiten en la misma frecuencia de portadora que las señales GPS, permitiendo de este modo que se utilice la misma antena GPS y el frontal de radio para la recepción de las SBAS. Por lo tanto, el uso de DPGS dará como resultado una arquitectura de hardware del receptor mucho más heterogénea que es más compleja y más costosa que la de los receptores basados en SBAS.

Puede verse como un objeto de la presente invención es proporcionar un sistema de coste eficiente y un procedimiento para determinar la posición de una unidad móvil, tal como un vehículo, con una precisión horizontal estática que se aproxima la mitad de la anchura de un vehículo estándar.

Es un objeto adicional de la presente invención proporcionar un sistema y un procedimiento que es un sistema esencialmente independiente y un procedimiento que es esencialmente independiente de la infraestructura local. La única infraestructura local requerida es la cobertura de la red celular que está fácilmente disponible donde se desea la operación del sistema.

Es un objeto adicional más de la presente invención es proporcionar un sistema y un procedimiento que en combinación con la determinación de la posición de, por ejemplo, un vehículo, también ofrece pago automático o el registro de tasas relacionadas con el tráfico de posición, tales como tasas de circulación en relación con la tarificación vial.

Es un objeto adicional más de la presente invención es proporcionar un sistema y un procedimiento que es fácil de mantener y actualizar cuando sea necesario.

Sumario de la invención

Los objetos de la presente invención indicados anteriormente se consiguen mediante el sistema y el procedimiento para el pago automático de tasas de circulación para vehículos de, respectivamente, las reivindicaciones 1 y 8. En su aspecto más general, la presente invención se refiere a un sistema o procedimiento para el pago automático o el registro automático de tarifas relacionadas con el tráfico para vehículos, tales como tasas de circulación en relación con la tarificación vial. Para pagar o registrar las tarifas relacionadas con el tráfico de una manera aceptable, la posición precisa del vehículo debe ser determinable. Además, para obtener las aprobaciones pertinentes de varias autoridades legales o de tráfico para dicho sistema y procedimiento, la posición del vehículo debe poder determinarse con una precisión que se aproxime a la mitad del ancho de un vehículo estándar.

En el contexto anterior, el pago automático debe tomarse en el sentido de una transacción financiera realizada inmediatamente después de que haya ocurrido un evento dado. Por ejemplo, una transacción financiera en forma de pago de una tarifa de aparcamiento puede seguir inmediatamente a la retirada de un vehículo de un aparcamiento. La cantidad a pagar puede depender de la posición del aparcamiento y el tiempo que el vehículo ha estado estacionado en el lugar específico. El pago puede realizarse sacando el monto de la cuenta bancaria del propietario

5

10

15

20

25

30

35

40

45

50

del vehículo.

Por el registro automático se entiende que la transacción financiera mencionada anteriormente puede no seguir inmediatamente a un evento dado. El pago de, por ejemplo, tarifas de aparcamiento puede acumularse durante un período de tiempo, por ejemplo, un mes, como se conoce en los acuerdos de tarjetas de crédito. Por lo tanto, las tarifas de aparcamiento acumuladas se facturan una vez al mes, generalmente al final de un mes, y la suma total a pagar proviene de la cuenta bancaria del propietario.

Del mismo modo, tasas de circulación también se pueden pagar de forma automática o acumularse automáticamente en un registro y posteriormente facturados para el pago automático al final de cada mes.

En un primer aspecto, la presente invención se refiere a un sistema para el pago automático de tasas de circulación para vehículos según la reivindicación 1.

El receptor de sistema de navegación basado en satélites puede comprender un receptor GPS o un receptor de GALILEO. Los medios de comunicación de cada una de la pluralidad de unidades móviles pueden adaptarse para comunicarse a través de una red celular, tal como GSM, GPRS, EDGE, iDEN, D-AMPS; PDC, W-CDMA, CDMA2000 o TD-SCDMA.

Los medios de procesamiento de la pluralidad de unidades móviles pueden formar parte de medios de procesamiento de los medios de comunicación de las unidades móviles. De esta forma, se guarda un procesador por separado.

Los medios de comunicación de la unidad de base pueden estar adaptados para comunicarse con la pluralidad de unidades móviles a través de un proveedor de servicios Internet.

La unidad de base puede comprender una o más unidades de base opcionalmente posicionadas en diferentes lugares físicos. De hecho, la unidad de base puede implementarse preferiblemente como una unidad redundante que comprende un número de unidades de base esencialmente idénticas posicionadas opcionalmente en diferentes ubicaciones físicas. Al implementar un sistema redundante, se reduce significativamente el riesgo de caída o fallo del sistema. La unidad de base puede comprender una pluralidad de bases de datos, en donde una primera base de datos comprende información relacionada con secciones de carreteras donde deben pagarse tasas de circulación, y en donde una segunda base de datos comprende señales de corrección de posición para aplicar a observables de posición generados por unidades móviles, y en el que una tercera base de datos comprende información relacionada con la cuenta del usuario. La unidad de base puede estar operativamente conectada a una pluralidad de proveedores de servicios externos, tales como un proveedor de servicios de pago, un servicio redundante que proporciona señales de corrección de posición, etc.

En un segundo aspecto, la presente invención se refiere a un procedimiento para el pago automático de tasas de circulación para vehículos según la reivindicación 8.

La etapa de calcular una posición corregida del vehículo puede implicar la aplicación de correcciones SBAS a la primera posición del vehículo, dicha primera posición del vehículo está representado por al menos un conjunto de GPS observables o las coordenadas GPS.

En una primera forma de realización, la etapa de calcular una posición corregida del vehículo consiste en aplicar correcciones EGNOS a la primera posición del vehículo, dicha primera posición del vehículo está representada por al menos un conjunto de GPS observables o las coordenadas GPS. Existen al menos dos formas de utilizar los datos de aumento de EGNOS para lograr una mejor estimación de la posición GPS. Los datos de aumento de EGNOS pueden usarse para formar una corrección a una estimación de la posición del GPS ya calculada, o los datos de aumento de EGNOS pueden aplicarse directamente a las observaciones/observables de GPS para corregirlos antes del cálculo de la estimación de la posición del GPS. El último de los dos es ventajoso, ya que proporciona un mejor aumento general, lo que resulta en una corrección más eficiente que conduce a una estimación de la posición del GPS más precisa.

En una segunda forma de realización, la etapa de calcular una posición corregida del vehículo consiste en aplicar correcciones WAAS a la primera posición del vehículo, dicha primera posición del vehículo está representada por al menos un conjunto de gPs observables o las coordenadas gPs.

Finalmente, en una tercera realización, la etapa de calcular una posición corregida del vehículo consiste en aplicar correcciones MSAS a la primera posición del vehículo, dicha primera posición del vehículo está representada por al menos un conjunto de gPs observables o coordenadas GPS

El procedimiento puede comprender además la etapa de completar una transacción financiera, comprendiendo dicha transacción financiera la etapa de extraer una cantidad correspondiente a una tasa de circulación calculada a partir de una cuenta de un individuo registrado como el propietario de la unidad móvil, y el depósito de esta cantidad en una cuenta del propietario del área de aparcamiento.

5

10

15

20

25

30

35

40

45

50

Alternativamente, el procedimiento puede comprender además la etapa de completar una transacción financiera, comprendiendo dicha transacción financiera la etapa de registrar una cantidad correspondiente a una tasa de circulación calculada, y almacenar esta cantidad registrada para permitir un depósito posterior de una cantidad correspondiente a cantidades registradas acumuladas, siendo dicho depósito a una cuenta del propietario de la tasa de circulación. De acuerdo con esta realización, se puede extraer un importe acumulado correspondiente a tasas de circulación acumuladas, por ejemplo, una vez al mes, desde una cuenta de un individuo registrado como el propietario de la unidad móvil y depositado en una cuenta del propietario de la tasa de circulación.

Alternativamente, el procedimiento puede comprender además la etapa de completar una transacción financiera, comprendiendo dicha transacción financiera la etapa de extraer una cantidad correspondiente a una tasa de circulación calculada a partir de una cantidad de prepago pagada por un individuo registrado como el propietario de la unidad móvil.

Breve descripción de la invención

La presente invención se explicará ahora con mayores detalles con referencia a las figuras adjuntas, dentro de

La figura 1 muestra una ilustración general esquemática del sistema de alto nivel del sistema según la presente invención,

La figura 2 muestra un aparcamiento con un vehículo,

La figura 3 muestra un diagrama de bloques esquemático de un sistema según la presente invención,

La figura 4 ilustra el flujo de comunicación durante un evento relacionado con el tráfico,

La figura 5 ilustra el flujo de decisión durante un evento relacionado con el tráfico,

La figura 6 muestra un aparcamiento presentado en forma compacta y simplificada mediante una aproximación circular.

Aunque la invención es susceptible de diversas modificaciones y formas alternativas, realizaciones específicas se han mostrado a modo de ejemplo en los dibujos y se describirán en detalle en este documento. Sin embargo, debe entenderse que la invención no está destinada a limitarse a las formas particulares descritas. Más bien, la invención es para cubrir todas las modificaciones, equivalentes y alternativas que caen dentro del espíritu y alcance de la invención como se define en las reivindicaciones adjuntas.

Descripción detallada de la invención

Como ya se ha mencionado la presente invención se refiere, en su aspecto más general, a un sistema o un procedimiento para el pago automático o el registro automático de las tasas relacionadas con el tráfico para los vehículos. Tales tarifas relacionadas con el tráfico pueden ser tasas de circulación en relación con los precios de las carreteras. Para pagar o registrar las tarifas relacionadas con el tráfico de una manera aceptable, la posición precisa del vehículo debe ser determinable. Además, para obtener las aprobaciones pertinentes de varias autoridades legales o de tráfico para dicho sistema y procedimiento, la posición del vehículo debe poder determinarse con una precisión superior a aproximadamente la mitad del ancho de un vehículo típico. La presente invención tiene como objetivo determinar la posición horizontal de un vehículo con una precisión de aproximadamente 0,8 metros.

Con el fin de lograr la precisión mencionada anteriormente, la información de posición a partir de diversos sistemas, tales como GPS, Galileo y EGNOS, es obligatoria. Por ejemplo, se aplica el GPS para determinar la posición del vehículo con una precisión en el rango de 3-20 metros. Dicha precisión es insuficiente y se aplica un valor de corrección proporcionado por EGNOS para aumentar la precisión a alrededor de 0,8 metros.

Aunque la descripción también se refiere al pago de tarifas de aparcamiento, los principios generales de los sistemas, procedimientos y unidades móviles según la presente invención también se aplican al pago automático de otros tipos de tarifas relacionadas con el tráfico, tales como tasas de circulación, tarifas de puente, etc. De este modo, aplicando todos los principios de la presente invención, puede determinarse cuando un vehículo entra en una sección de carretera, por ejemplo, un camino elevado, un puente, etc., donde deben pagarse las tasas de circulación.

En lo que sigue, el sistema y procedimiento de acuerdo con la presente invención se describirá con referencia a pago automático de las tarifas de aparcamiento, pero como se mencionó anteriormente el escenario podría así estar relacionada con el pago automático de cualquier tarifa relacionada con el tráfico, tal como, por ejemplo, tasas de circulación.

Se prevé que el sistema debe ser capaz de soportar un gran número de usuarios simultáneos, con el tiempo se contaban por millones, por lo que es de vital importancia que el precio de coste de cada producto para el usuario final sea barato de fabricar. Es igualmente importante que la operación y el mantenimiento diarios del sistema (como las actualizaciones del área de aparcamiento) se puedan llevar a cabo sin acceso a los productos de los usuarios

5

10

15

20

25

30

35

40

45

50

55

finales debido a su gran volumen. Esto impone la necesidad de una arquitectura de sistema cliente-servidor y que el cliente se mantenga lo más simple posible. Tal sistema se representa en la figura 1, donde una pluralidad de clientes, aquí vehículos, se comunican con un servidor central.

Un aparcamiento simple con un vehículo aparcado en una cabina de aparcamiento se representa en la figura 2. Para determinar en qué cabina de aparcamiento está aparcado el vehículo, o para determinar si el vehículo está aparcado en una cabina de aparcamiento exterior, como se representa en la figura 2, o fuera del aparcamiento, la posición del vehículo debe poder determinarse con una precisión que se aproxima a la mitad del ancho del vehículo. Si se logra tal precisión, puede determinarse en qué parte de una pluralidad de cabinas de aparcamiento contiguas y contiguas se encuentra el vehículo.

Con referencia ahora a la figura 3, cada cliente compra una unidad móvil (A), un cliente, así como un servicio que proporciona acceso automatizado a una unidad central (C), el servidor. Cada cliente está registrado en un sistema de cuenta en el servidor donde tiene una suscripción asociada a su identidad y la identidad de su producto. Cada cliente recibe un número de identificación único durante la fabricación.

El sistema comprende una única unidad central, un gran número de unidades móviles y un número de proveedores de servicios externos (B, E y F). También se emplea (D) un receptor de GPS (Sistema de Posicionamiento Global) que es EGNOS (Servicio de Superposición de Navegación Geoestacionaria Europea).

El diagrama de bloques de la figura 3 comprende los siguientes bloques:

A unidad móvil: Un módulo de usuario final con un código de identificación único ubicado en el vehículo del cliente. La unidad móvil se hace consciente de la ubicación a través de GPS.

B MNO (operador de red móvil) e ISP (proveedor de servicios de Internet): La infraestructura necesaria para que las unidades móviles se comuniquen con "el resto del mundo". Las unidades móviles establecen conexiones inalámbricas a las redes de telefonía móvil de los MNO y los MNO pasan la comunicación a un ISP. El ISP enruta la información hacia/desde Internet, lo que de hecho permite que las unidades móviles se comuniquen con el servidor a través de Internet.

C Unidad central: El servidor maneja la comunicación a todas las unidades móviles. El servidor contiene toda la información sobre las áreas de aparcamiento y las tarifas asociadas con el aparcamiento, por lo que esta información se puede actualizar fácilmente sin acceso a todos los clientes. El servidor también maneja todas las transacciones. La accesibilidad del servidor es vital para que el sistema propuesto funcione, por lo que es de suma importancia que esto se implemente de manera robusta y con una cantidad de unidades físicas redundantes para maximizar la robustez y el tiempo de actividad del sistema.

D Un receptor GPS compatible con EGNOS: Uno de los medios para obtener las correcciones de EGNOS que se necesitarán para garantizar el funcionamiento correcto del sistema.

E SISNET: Un servicio basado en Internet que proporciona la ESA (Agencia Espacial Europea). Este es uno de los medios para obtener las correcciones de EGNOS necesarias para garantizar el funcionamiento correcto del sistema.

F PSP (Proveedor de servicios de pago): Un servicio, como el Danish PBS (Pengeinstitutternes Betalingsservice), que permite al operador realizar transacciones financieras a todos los propietarios del área P.

Si se desea, es posible encriptar el tráfico de datos entre los clientes y el servidor. Existen procedimientos bien conocidos para aplicar la criptografía, y se puede emplear cualquier procedimiento apropiado que sea conveniente. Por ejemplo, los protocolos criptográficos como SSL (Secure Sockets Layer) y su sucesor, TLS (Transport Layer Security) son procedimientos bien conocidos para proporcionar comunicaciones seguras en Internet para una serie de cosas como navegación web, correo electrónico y otras transferencias de datos. SSL y TLS se ejecutan en capas debajo de los protocolos de la aplicación (como HTTP, FTP, SMTP y NNTP) y por encima del protocolo de transporte TCP o UDP, que forman parte del conjunto de protocolos TCP/IP. Pueden agregar seguridad a cualquier protocolo que utilice conexiones confiables (como TCP) y han encontrado un uso generalizado con HTTP para formar HTTPS. Las implementaciones actuales de SSL/TLS se basan en procedimientos como RSA (Rivest, Shamir y Adleman), Triple DES (Estándar de cifrado de datos triple) y AES (Estándar de cifrado avanzado), por lo que generalmente se consideran muy seguros.

El principio general de funcionamiento del sistema representado en la figura 3 es el siguiente:

La unidad móvil usa el GPS para detectar cuándo se está estacionando. El software del ordenador principal de la unidad móvil hace esto simplemente monitoreando el flujo continuo de estimaciones de posición del módulo de GPS y detectando cuando una cantidad suficiente de datos de GPS sugiere que el vehículo ya no se mueve, sino que está aparcado. También se pueden incorporar otros medios para confirmar que el vehículo está aparcado (como el estado de la llave de encendido, las mediciones del acelerómetro, etc.). La unidad móvil usa el módem GSM/GPRS para conectarse y señalizar esto al servidor.

5

10

15

20

25

30

35

40

45

50

El servidor responde mediante la aplicación de la última serie de correcciones EGNOS a la posición GPS dada por la unidad móvil para obtener una estimación de la posición corregida que tiene un mayor grado de precisión. Esta estimación de posición corregida se compara con la ubicación y los límites de las áreas de aparcamiento registradas que están asociadas con las tarifas de aparcamiento y determina si el vehículo aparcado se encuentra dentro de una zona de pago.

Si este es el caso, el servidor hace una entrada de registro para el código de identificación de la unidad móvil dado que indica que un evento de aparcamiento ha comenzado. Si el usuario tiene una cuenta y una suscripción válida al servicio, se prepara una transacción y el servidor envía una señal a la unidad móvil de que el evento de aparcamiento está registrado y se está llevando a cabo dentro de un área de pago. Esto también se indica en la parte externa visible de la unidad móvil para que cualquier asistente de aparcamiento en el área de aparcamiento pueda verificar que el vehículo esté aparcado legalmente y que se realice el pago.

Cuando el vehículo se mueve, la unidad móvil detecta esto y el servidor se pone en contacto de nuevo. El servidor calcula la duración del evento de aparcamiento, lo compara con la tabla de tarifas de aparcamiento potencialmente dependientes del tiempo para el área de aparcamiento dada y finalmente calcula la tarifa total de aparcamiento. El servidor completa el pago realizando la transacción que transfiere la tarifa de la cuenta de los usuarios al propietario del área de aparcamiento. El servidor también indica a la unidad móvil que efectivamente se ha realizado el pago del aparcamiento y muestra al usuario cuánto se pagó. El flujo de comunicación general durante un evento de aparcamiento se ilustra en la figura 4.

El sistema representado en la figura 3 comprende un número de sub-módulos - la funcionalidad de estos submódulos se explicará en lo siguiente:

1. Un receptor de GPS. Debe proporcionar estimaciones de posición precisas incluso en áreas urbanas.

2. Un módem GSM (Sistema Global para Comunicaciones Móviles) con instalaciones de transmisión/recepción GPRS (Servicio General de Radio por Paquetes) para la comunicación de datos.

3. Un ordenador integrado con un software de sistema que gobierna la toma de decisiones en la unidad móvil. En lugar de implementar este software de control en un microprocesador separado, el software requerido se implementa directamente en el módem GSM que normalmente tiene algunos recursos libres de microprocesador para la programación de aplicaciones.

4. Una cantidad de operadores de redes móviles que tienen una red agregada GSM, 3G o EDGE cubre el área dentro de la cual se desea la cobertura del servicio.

5. Los operadores también suelen funcionar como proveedores de servicios de Internet, por lo que podrán realizar un puente de datos entre las unidades móviles de la red GSM e Internet.

6. El software del sistema central que gobierna y coordina todas las operaciones en el lado del servidor de la comunicación que tiene lugar entre la unidad central y los clientes. El software del sistema contiene todas las funciones requeridas para calcular las tarifas de aparcamiento basadas en información de ubicación y duración del aparcamiento, maneja todo el intercambio de información con el proveedor de servicios de pago y lleva a cabo las correcciones de EGNOS en las estimaciones de la posición del GPS de la unidad móvil para garantizar que se utilizan posiciones suficientemente precisas. El software del sistema hace uso de una serie de bases de datos para estos fines.

7. Una base de datos que contiene información sobre la ubicación física y los límites de las áreas de aparcamiento cubiertas por el servicio provisto. La base de datos también contiene tarifas de aparcamiento, información sobre cuándo se aplican las tarifas e información sobre a quién debe efectuarse las transacciones de pago para las diferentes áreas de aparcamiento.

8. Una base de datos que contiene todos los mensajes de datos de navegación divulgados en EGNOS.

9. Una base de datos con información específica del cliente, como datos de cuenta asociados con el código de identificación único de cada unidad móvil, actividades registradas y otras estadísticas.

10. Un receptor GPS/EGNOS utilizado para monitorizar los satélites geoestacionarios EGNOS. El receptor está equipado con una antena de alta ganancia y esta antena debe ubicarse en un alto punto de elevación en comparación con el entorno físico para garantizar buenas condiciones de recepción. Al monitorizar continuamente los satélites EGNOS, la base de datos de mensajes de EGNOS (punto "8") se puede mantener constantemente actualizada con el conjunto más reciente de datos de corrección.

11. Un servicio basado en Internet llamado SISNET (Signal-In-Space a través de interNET) proporcionado por ESA. SISNET proporciona a los usuarios acceso a los mismos mensajes EGNOS que se difunden a través de los satélites geoestacionarios. Esto garantiza un suministro redundante de datos de EGNOS.

12. Un servicio basado en Internet, como el proporcionado por el Danish PBS, que le permite realizar

5

10

15

20

25

30

35

40

45

50

transacciones financieras al propietario de las áreas de aparcamiento cubiertas.

En la figura 3 se representa una pluralidad de canales de comunicación entre los diversos módulos y submódulos. La siguiente es una descripción de estos canales de comunicación:

'21' Una transmisión inalámbrica desde los satélites en el GPS y el receptor GPS en el bloque (A). Protocolo: Especificado en el Centro de navegación USCG (US Coast Guard) "Documento de control de interfaz (ICD-GPS- 200c)" versión PT IRN-200C-004.

'22' Una conexión en serie RS-232 entre el módulo GPS y el software principal del ordenador. Protocolo: "NMEA- 0183" para datos específicos de GPS.

'23' Una conexión inalámbrica entre las unidades móviles y los operadores de redes móviles. Protocolo: Datos formateados TCP/IP enviados a través de paquetes GPRS a través de GSM.

'24' Una conexión de DSL (línea digital de abonado) de tarifa fija (o equivalente) entre el proveedor de servicios de Internet y el servidor central. Protocolo: Datos formateados TCP/IP enviados a través de internet.

'25' Una conexión de puerto TCP (Protocolo de control de transmisión) entre el software de aplicación principal del servidor y una base de datos (para información de área de aparcamiento), como una base de datos MySQL (u otra base de datos adecuada). Protocolo: Comandos propietarios definidos por el operador que se adhiere al estándar SQL.

'26' Una conexión de puerto TCP entre el software de aplicación principal del servidor y una base de datos (para mensajes de datos EGNOS), como una base de datos MySQL (u otra base de datos adecuada). Protocolo: Comandos propietarios definidos por el operador que se adhiere al estándar SQL.

'27' Una conexión de puerto TCP entre el software de aplicación principal del servidor y una base de datos (para información específica del cliente), como una base de datos PostgreSQL (u otra base de datos adecuada). Protocolo: Comandos propietarios definidos por el operador que se adhiere al estándar SQL.

’28' Una conexión en serie RS-232 entre el receptor GPS/EGNOS y el servidor central. Protocolo: "NMEA-0183" para datos específicos de GPS.

'29' Una conexión DSL comercial de tarifa fija (o equivalente) entre el servidor central y el servidor de datos ESA SISNET. Protocolo: Datos formateados TCP/IP que se adhieren al estándar SISNET especificado por ESA.

'30' Una conexión DSL comercial de tarifa fija (o equivalente) entre el servidor central y los proveedores de servicios de pago utilizados para llevar a cabo las transacciones financieras. Protocolo: Datos formateados TCP/IP que cumplen con el estándar especificado por los proveedores de servicios de pago utilizados.

Las conexiones DSL '24', '29' y '30' pueden ser una conexión compartida con el ISP local. Además, la arquitectura del sistema ilustrada en la figura 3 no muestra la configuración propuesta del servidor redundante. Sin embargo, consistirá principalmente en que el bloque (C) se duplique varias veces, así como algunos equipos adicionales de monitorización y conmutación de red. La unidad central duplicada (C) puede colocarse en una ubicación física diferente para minimizar el riesgo de falla del sistema o frenar en caso de, por ejemplo, fallo de energía, incendio, etc.

La figura 5 ilustra el flujo de decisión que tiene lugar cuando se produce un evento de aparcamiento. Cuando el sistema según la presente invención se inicializa, el servidor está inactivo y el cliente está ocupado esperando, sondeando el estado de la llave de encendido del vehículo. Seguirá haciéndolo hasta que la llave de encendido se apague.

Cuando la llave de encendido del vehículo está apagada, el software del sistema principal cliente simplemente espera un período de tiempo determinado, digamos por ejemplo 5 segundos, para la recogida de actualizaciones de la posición del GPS durante este período de espera. Después del período de espera, el software del sistema del cliente calcula el mejor promedio de las actualizaciones de posición y lo evalúa para determinar si el vehículo se está moviendo o está parado. Si se está moviendo, si, por ejemplo, el vehículo es remolcado o transportado de otra manera, y por lo tanto no está aparcado, el cliente regresa a su ciclo de espera ocupado inicial. Si el vehículo está parado y se cumplió la precondición de "llave de contacto desconectada", el vehículo se define como estacionado.

Si se encuentra que el vehículo está aparcado, el cliente señala al servidor central que el vehículo del usuario está aparcado. Transfiere el tiempo del evento de aparcamiento y el número de identificación único del producto del cliente para que el servidor sepa quién debe pagar el aparcamiento si se encuentra en una ubicación de peaje. El cliente también transfiere la posición promediada del vehículo, así como una serie de observaciones cruzadas del GPS para permitir que el servidor realice el procesamiento posterior de algunos datos GPS seleccionados.

El servidor responde mediante el inicio de una secuencia de control que se hará cargo del procesamiento de datos del lado del servidor apropiado para el resto de este período de aparcamiento particular. La tarea principal es

5

10

15

20

25

30

35

40

45

50

55

determinar si el vehículo se aparca en o cerca de un área de aparcamiento de peaje. Por razones prácticas, esta verificación debe ser inicialmente lo más simple posible para abortar rápidamente cualquier procesamiento posterior si el vehículo no está dentro o cerca de las áreas de aparcamiento de peaje. Se requiere esta verificación inicial, ya que la cantidad de eventos tentativos de aparcamiento informados de la suma de los clientes puede ser potencialmente muy grande, con una cantidad de millones por día. Esto se detalla más en la siguiente descripción del software del servidor central.

Si se determina que el vehículo sea aparcado fuera de las áreas conocidas de pago registrados el cliente es notificado de que el aparcamiento está llevando a cabo de forma gratuita, o al menos no se encuentra en la base de datos, y la secuencia de procesamiento de datos es simplemente abortada. Si, por otro lado, parece que el vehículo estaba aparcado en o cerca de un área de pago, se realiza una verificación adicional en el servidor. Los datos observables de GPS sin procesar se utilizan con el último conjunto de correcciones de EGNOS para obtener una estimación de posición aumentada/mejorada con mayor precisión. Esta estimación de posición mejorada se utiliza para verificar minuciosamente si el vehículo está aparcado en un área de pago.

De nuevo, si se comprueba que el vehículo está aparcado fuera de un área de pago registrado se indica al usuario que el aparcamiento está teniendo lugar gratis y el procesamiento de datos se interrumpe. Si se determina que el vehículo efectivamente está aparcado dentro de un área de pago, el servidor procede a verificar si el usuario tiene una cuenta de cliente válida con una suscripción activa. Si este no es el caso, por ejemplo, si la suscripción del cliente ha caducado o la cuenta ha sido sobregirada, el servidor no podrá realizar el pago en nombre del usuario, por lo que se le enviará un mensaje de error informándole al respecto. Este mensaje de error puede complementarse con consejos para aparcarse en un área cercana sin peaje o sugerirle que pague manualmente por el evento de aparcamiento. Opcionalmente, se puede ingresar en el registro de la base de datos de usuario en el servidor que el usuario particular realizó un evento de aparcamiento fallido, así como la razón por la que esto fue así. Nuevamente, esto terminará la secuencia de procesamiento de datos ya que el sistema no podrá realizar el servicio de pago para el cliente.

Si se descubre que el cliente tiene una cuenta activa con una suscripción válida del servidor hace una entrada de registro con el período de aparcamiento (lugar, tiempo y código de usuario, etc.), de modo que será capaz de determinar la duración del evento de aparcamiento cuando se termina, es decir, el usuario mueve el vehículo.

Las señales servidor al cliente que se ha registrado en período de aparcamiento, que está teniendo lugar dentro de un área de peaje y confirma que el cliente tiene una cuenta válida con una suscripción activa. Esto confirma al usuario que se realizará el pago para que el usuario sepa que puede dejar el vehículo de manera segura sin temor a ser multado incorrectamente por aparcar sin pagar. Además, puede informar al usuario cuál es la tarifa de aparcamiento actual por unidad de tiempo en la ubicación actual (tal vez incluso incluye tarifas adicionales si el área de aparcamiento opera con múltiples tasas en función del tiempo). Naturalmente, también se señala en una pantalla que es visible desde el exterior del vehículo por lo que cualquier asistente de aparcamiento que revisa el vehículo se le informa que el propietario del vehículo efectivamente pagará el aparcamiento a través de un medio aprobado de pago automático.

Esto termina la 'primera mitad' de la secuencia de control de procesamiento de datos, el servidor suspende el hilo que se encarga de la particular, ID de cliente hasta nuevo aviso y el cliente se deja ocupado de espera, sondeando el estado de la llave de encendido del vehículo (que continuaría hasta que se encienda el encendido).

Cuando el usuario arranca su vehículo, el mismo procedimiento se utiliza en el cliente para determinar si el vehículo aún está aparcado como cuando el sistema deja originalmente el estado de inicialización. El software del cliente espera durante un período de tiempo, recopilando actualizaciones de posición del GPS. Cuando una cantidad significativa de datos de GPS sugiere que el vehículo ya no está aparcado, se contacta al servidor y el cliente indica que el evento de aparcamiento con la identificación de producto asociada ha finalizado.

El servidor responde mediante la reactivación del hilo suspendido cuidado de esta Identificación del producto en particular, reanudando la secuencia de control, finalizando de este modo el procesamiento de datos. El software del servidor calcula la duración del evento de aparcamiento y calcula la tarifa total de aparcamiento, teniendo en cuenta que el evento de aparcamiento puede haber abarcado varias zonas horarias con diferentes tarifas de aparcamiento. El servidor ejecuta la transacción de pago, utilizando una pasarela de pago basada en Internet, transfiriendo el monto apropiado de la cuenta del cliente al propietario del área de aparcamiento de peaje que se utilizó. Alternativamente, las cantidades relacionadas con un número de eventos de aparcamiento dentro de un período de tiempo dado, por ejemplo, un mes, se pueden acumular en el servidor. Luego, el servidor ejecuta una única transacción de pago una vez al mes para una cuenta de cliente determinada.

El servidor actualiza el registro de usuario con las actividades realizadas para permitir el análisis estadístico posterior de la base de datos de usuario para controlar (y optimizar) el funcionamiento del sistema. El servidor le indica al cliente que se ha realizado la transacción de pago, muestra la tarifa transferida y muestra opcionalmente la información del estado de la cuenta del cliente. Esto concluye la secuencia de procesamiento de datos para el evento de aparcamiento, el servidor cierra el hilo para la identificación del producto particular y el cliente se queda ocupado esperando, sondeando nuevamente el estado de la llave de encendido del vehículo.

5

10

15

20

25

30

35

40

45

50

55

Todo debe ocurrir durante la menor cantidad de tiempo que es posible en la práctica. El usuario debe tener una retroalimentación casi instantánea y no tener que esperar largos períodos de tiempo para las respuestas del sistema. Sería deseable que el sistema responda y confirme al usuario dentro de los 10 segundos desde que se apagó la llave de encendido que el aparcamiento está correctamente registrado. Asimismo, sería deseable que el sistema responda dentro de los 10 segundos a partir de la ignición encendida (y del vehículo movido) que se ha producido la transacción de pago y cuál fue la cantidad total que se transfirió.

La siguiente es una descripción de las funciones primarias, parámetros requisito y diseño, notas y consideraciones para los submódulos de la arquitectura del sistema propuesto se muestra en la figura 3:

1 cliente GPS

Función:

El receptor GPS puede, por ejemplo, usar la señal de código GPS L1 C/A @ 1575,42 MHz. Como alternativa, tal vez para futuras generaciones del sistema, otros sistemas de navegación basados en satélites, como Galileo, también serían viables. El receptor utilizará una antena de parche de perfil bajo para fines prácticos de instalación. Realiza un seguimiento continuo de las señales de satélite GPS visibles (hasta un máximo de 12 satélites simultáneamente) y calcula las actualizaciones de estimación de la posición m por segundo (por ejemplo, 5 por segundo). Las actualizaciones de posición se pasan al software del ordenador principal de la unidad móvil. El receptor GPS en sí no evalúa si las posiciones GPS indican un vehículo aparcado o en movimiento.

Requisitos:

El módulo de GPS es sensible al coste ya que está situado en la unidad móvil. Esto hace que sea un gran desafío encontrar módulos GPS comercialmente disponibles (COTS) que sean aplicables.

El requisito principal para el módulo GPS es proporcionar estimaciones de posición suficientemente precisas para mantener el funcionamiento adecuado del sistema. Es deseable obtener una precisión de menos de 1,0 m, independientemente del entorno local de la unidad móvil y las condiciones de recepción. Este requerimiento está acoplado al tamaño de una cabina de aparcamiento "estándar" y al tamaño de los vehículos que se espera que empleen el sistema y el procedimiento de acuerdo con la presente invención. Se espera que la precisión del receptor GPS sea vital para garantizar que el producto se pueda aprobar legalmente como medio válido de pago para el aparcamiento.

Es muy poco probable que un código GPS L1 C/A receptor autónomo estándar será capaz de cumplir con este requisito. Incluso los módulos de GPS autónomos de frecuencia única de relativamente alta calidad que son órdenes de magnitud demasiado caras como para tener alguna relevancia para la implementación de la presente invención probablemente no cumplirán con el requisito. Por lo tanto, definitivamente se requiere un aumento de algún tipo. Las primeras pruebas de EGNOS realizadas con ESTB (EGNOS System Test Bed) indicaron que un receptor de código GPS L1 C/A podría modificarse para proporcionar estimaciones de posición con una precisión de aproximadamente 0,8 m al emplear las correcciones proporcionadas por el sistema de aumento EGNOS. Resultados como estos se obtuvieron en condiciones de recepción de señal en las que el entorno ofrecía un escenario de señal libre de trayectos múltiples. La interferencia de trayectos múltiples se produce cuando las señales del GPS rebotan en los objetos cercanos y hacen que la señal del satélite llegue a la antena a través de rutas distintas de la línea de visión directa. Esto causa un efecto perjudicial en el procesamiento de la señal del receptor GPS y deteriora el rendimiento del receptor. Mientras que los módulos autónomos de bajo coste de GPS L1 C/A tienden a tener una precisión en el rango de 3-10 m en condiciones óptimas (entornos libres de trayectos múltiples), la interferencia de trayectos múltiples puede reducir el rendimiento de posicionamiento al rango de 5-20 m.

Para lograr una precisión de 1,0 m (o mejor) en ambientes urbanos, donde la interferencia de trayectos múltiples es de esperar, debido a edificios circundantes, el receptor GPS debe emplear medios eficaces de suprimir el efecto de trayectos múltiple, así como el empleo de correcciones EGNOS. Actualmente, la propagación por trayectos múltiples en los sistemas de navegación basados en satélites constituye un área de investigación importante que incluye una gran cantidad de desafíos. A partir de ahora no se ha establecido una forma simple, universal y bien definida de eliminar totalmente el efecto de trayectos múltiples. Sin embargo, la comunidad de investigación ha propuesto una serie de procedimientos, cada uno con un grado de efectividad variable. Se establece que la mitigación de trayectos múltiples requerirá el procesamiento digital de la señal y que ciertos componentes del receptor GPS deben soportarlo, en particular, la parte delantera de la radio RF debe tener un ancho de banda relativamente amplio de al menos alrededor de 12-15 MHz para que el procesamiento de señal sea efectivo.

El requisito de que la precisión deseable también se debe alcanzar en entornos urbanos influye en la forma en que se obtienen las correcciones EGNOS. Es muy poco probable que los edificios circundantes permitan una visión clara de los satélites EGNOS en general en entornos urbanos (esto se detalla en la sección "10 GPS/EGNOS" a continuación). Por lo tanto, se propone que las correcciones de EGNOS se obtengan centralmente en lugar de que los clientes intenten recibir las señales de EGNOS.

Esto deja a la arquitectura del sistema de elección de si (1) la difusión de los datos de aumento de EGNOS desde el

5

10

15

20

25

30

35

40

45

50

servidor a todos los clientes o (2) se reúnen los GPS observables 'en bruto' correctos de los clientes y transferirlos al servidor y aplicar los datos de aumento centralmente. Parece que la opción número dos es ventajosa, ya que es probable que limite la cantidad de datos que se deben transferir a/desde los clientes a través de las conexiones inalámbricas. Como una visión general aproximada de la cantidad de datos que se transferirán en cada caso (solo se consideran aquí los datos de posicionamiento GPS, no se puede comparar la sobrecarga para comunicar la identificación del cliente, el estado del sistema, los protocolos de enlace, etc.). Un conjunto completo de correcciones EGNOS de los tres satélites EGNOS consta de tres conjuntos de 17 mensajes, cada uno de los cuales consta de 33 bytes, lo que da un total de 3x17x33 = 1683 bytes. Un conjunto de observaciones sin formato que consta de 12 pseudorrangos (supuestos empaquetados en representaciones de 4 bytes) ocupan solo 12x4 = 48 bytes, aunque también deben transferirse algunos otros parámetros, como la marca de tiempo del receptor.

La explotación de esto da lugar a un requisito adicional para el receptor de GPS en el cliente: Debe ser capaz de suministrar los observables de GPS sin formato (pseudorrangos) al servidor central.

Algunos de los requisitos secundarios: El consumo de energía o el tamaño físico del receptor no es demasiado crítico. Se espera que estos requisitos se cumplan fácilmente. Sin embargo, la antena debe ubicarse físicamente de modo que tenga la mejor vista despejada "clara" del cielo. Se reconoce que es muy probable que los fabricantes de autos deseen tener la última palabra en cuestiones tales como la disposición física y la colocación de la antena si el producto va a instalarse de fábrica en los automóviles.

En general, el receptor GPS del cliente es un componente crítico, tanto con respecto al rendimiento alcanzable y con respecto al precio de coste unitario de los módulos. Es probable que el sistema presentado requiera un módulo GPS hecho a medida y adaptado a los requisitos de la aplicación.

2 Módem GSM Función:

El propósito principal del módem GSM es permitir que los paquetes de datos GPRS sean enviados a/desde la unidad móvil, proporcionando así la conectividad a Internet. Además, otros sistemas de telefonía móvil, como los diversos sistemas 3G, también pueden ser viables. Como efecto secundario de emplear un módem GSM en la unidad móvil, también se proporciona un microprocesador integrado parcialmente disponible. Debido a problemas de costes, es muy conveniente no tener que implementar un microprocesador separado para manejar el software del sistema de toma de decisiones en la unidad móvil, por lo que esta tarea podría implementarse en un software directamente en el módem GSM.

Requisitos:

Las cantidades de datos que se transfieren durante la comunicación normal de cliente-servidor se espera que sean bastante limitadas, tal vez para tan poco como unos pocos cientos de bytes por período de aparcamiento. Esto, por supuesto, está influenciado si los servicios de valor agregado se adjuntan al servicio central. De hecho, puede ser posible implementar esta comunicación a través del tráfico SMS (Servicio de Mensajes Cortos). Se espera que el tráfico GPRS, por otro lado, opere con una latencia suficientemente baja para satisfacer los requisitos dictados por el funcionamiento general del sistema. Con velocidades de transferencia de datos GPRS realistas de alrededor de 3080 kbit/s, las duraciones de transferencia no deberían ser un problema.

Por lo tanto, cualquier módem GSM moderno debería ser suficiente para manejar las transferencias de datos de una manera adecuada. No se requiere transferencia de voz por lo que una gran cantidad de módems GSM disponibles en el mercado serán excesivos para la aplicación actual. El módem GSM es sensible a los costes ya que está ubicado en la unidad móvil. Puede resultar un desafío encontrar módulos suficientemente baratos, especialmente COTS (como el motor celular Siemens MC35i o equivalente), por lo que podría ser necesaria una versión más barata y reducida de un diseño de módem GSM existente, hecho a medida para esta aplicación.

3 Software de ordenador principal Función:

Los propósitos principales del software de sistema del cliente son para controlar la corriente de cambios de la posición del GPS para determinar si el vehículo está parado cada vez que la llave de encendido se ha apagado y de nuevo cuando se ha encendido, y para iniciar y manejar la comunicación con el servidor cuando se encuentra el vehículo aparcado o cuando está terminando un evento de aparcamiento.

Requisitos:

La clave para garantizar un funcionamiento fiable y adecuado del sistema es la capacidad de determinar si el vehículo está aparcado o no (y dónde) de una manera robusta y confiable. Esto requiere estimaciones de posición de alta precisión y la lógica de evaluación y decisión adecuadas. Se propone que la evaluación se base en una serie de actualizaciones de posición, como por ejemplo las últimas 25 actualizaciones que corresponderían a 5 segundos

5

10

15

20

25

30

35

40

45

50

de datos si el módulo GPS se configurara para proporcionar 5 actualizaciones por segundo. El software del cliente realiza una prueba de hipótesis estadística basada en un nivel de confianza definido para determinar si hay suficientes datos estadísticamente significativos que sugieran que el vehículo está estacionario y, por lo tanto, aparcado. Tal procedimiento garantizaría un comportamiento bien definido con una baja probabilidad fija y conocida de "falsos positivos", es decir, casos en los que se evalúa que el vehículo está aparcado, aunque no asuma que el módulo GPS funciona como algo que se da por sentado en las estadísticas. También se deben considerar características como el rechazo de valores atípicos. Si se emplean sensores externos, como acelerómetros, etc., las mediciones de estos también deberían correlacionarse con las actualizaciones de posición del GPS.

Notas sobre los errores en la prueba de hipótesis estadística:

- Falso positivo (error de tipo I): se evalúa que el vehículo está aparcado cuando en realidad no lo esté.

- Falso negativo (error tipo II): no evaluar un vehículo como aparcado, aunque realmente lo esté.

Si se produce un falso negativo, no se cobra a un vehículo aparcado una tarifa de aparcamiento. Esto, por supuesto, no es deseable ya que el propietario de la zona de aparcamiento pierde la tarifa de aparcamiento que le correspondía. Aunque no es deseable, la consecuencia de esto es pequeña si el error ocurre raramente. El sistema debe ajustarse a una tasa de falsos negativos adecuadamente baja, ya que un evento de aparcamiento de clientes no detectado podría costar al propietario del vehículo una multa de aparcamiento que, con toda la razón, es probable que el operador conozca y se le solicite que reembolse.

Un falso positivo por el contrario significaría que un vehículo se evaluó erróneamente que ser aparcado y que el dueño es potencialmente injustamente acusado de un aparcamiento que no realizó. Dichos errores pueden hacer que el usuario pierda confianza en el producto y sin duda debe evitarse.

Las funciones restantes son; enviar una señal al servidor cada vez que ocurra un evento de aparcamiento, enviando observaciones GPS crudas al servidor y esperando la evaluación de si el evento de aparcamiento se lleva a cabo dentro de una zona de pago, proporcionar una indicación visible tanto al asistente de aparcamiento (pantalla visible externamente) como al usuario si el aparcamiento se lleva a cabo dentro de una zona de pago y si el servidor ha encontrado una cuenta válida para pagar el aparcamiento; por el contrario muestra un mensaje de error si este no es el caso, indicando al servidor cuando finaliza un evento de aparcamiento y mostrando las tarifas de aparcamiento y las tarifas totales cuando así lo informa el servidor. Estas son tareas muy simples que no deberían plantear ningún problema.

Este software cliente incorporado debe coexistir con el software que se ejecuta en el módem GSM. Debe codificarse para obtener la máxima eficacia para garantizar un consumo mínimo de recursos y la menor huella posible (requisitos de memoria), pero esto no debería ser un problema, ya que las funciones del cliente son realmente bastante simples.

A pesar de que el software del sistema del cliente realiza una función vital, lo mismo es cierto para el resto de los módulos del sistema. Con respecto al rendimiento, solo el proceso de evaluar con firmeza si el vehículo está aparcado o no requiere una atención especial.

4 Operador de red móvil Función:

La única función del operador de red móvil es proporcionar cobertura de la red para el área de operación. Este es un servicio estándar bien establecido que ya se ofrece, por lo que se considera poco probable que cause complicaciones.

Requisitos:

Se debe tener cuidado en encontrar los mejores tipos de suscripción (que probablemente sería simplemente el servicio más barato que tenga suficiente garantía de que el tráfico GPRS llegue a su destino) y los MNO que los tienen disponibles. Como es poco probable que un solo operador tenga cobertura para la región de operación deseada, se deben hacer acuerdos de itinerancia para alcanzar la cobertura de red apropiada.

5 Proveedor de servicios de Internet Función:

De nuevo, la única función del proveedor de servicios de Internet es facilitar el acceso de los clientes a Internet para el área de operación.

Requisitos:

Los paquetes GPRS simplemente deberían enrutarse a/desde Internet a través de nodos de enrutamiento estables

5

10

15

20

25

30

35

40

45

50

55

que tengan un funcionamiento confiable y un alto tiempo de actividad, lo cual se espera que sea una tarea trivial para cualquier ISP bien establecido.

6 Software del servidor central

Función:

Las tareas principales del software del sistema del servidor central son recibir transmisiones de las unidades móviles, procesar la información suministrada e iniciar la acción adecuada en el servidor en función de los datos de la unidad móvil y el estado de la cuenta de usuarios correspondiente, así como enviar mensajes apropiados a la unidad móvil.

Las acciones primarias en el servidor incluyen iniciar extracciones de información de base de datos, realizar la corrección EGNOS de las posiciones de GPS suministradas y las observaciones crudas correspondientes, realizar una verificación en dos etapas de si la unidad móvil se encuentra en áreas de pago, realizar verificaciones de cuenta de cliente, calcular las tarifas de aparcamiento, realizar las transacciones de pago, actualizar el registro del usuario con estadísticas y asegurarse de que la base de datos EGNOS se actualice continuamente desde dos fuentes independientes. Además, el servidor debe proporcionar funciones para actualizar la base de datos del área P, actualizar la base de datos del usuario y realizar análisis estadísticos sobre la información en el registro del usuario.

Requisitos:

El software de la aplicación debe implementarse de una manera flexible y escalable para acomodar una gran flota de clientes distribuidos. Mientras que el software de cliente integrado está optimizado para un espacio mínimo para ejecutarse en una plataforma de bajo recurso, el software del lado del servidor puede aprovechar la capacidad de computación de los grandes ordenadores disponibles comercialmente sin un aumento significativo en el coste total del sistema. Todavía una gran cantidad de solicitudes podrían ocurrir simultáneamente, por lo que el software debería diseñarse e implementarse con una estricta optimización del rendimiento. Esto afectará tanto la arquitectura del software de la aplicación como las bases de datos subyacentes.

Una opción obvia de plataforma podría ser un parque de servidores Linux distribuido y redundante con sistemas operativos baratos (o gratuitos) con bases de datos baratas (o gratuitas). El software de aplicación podría tener múltiples subprocesos para la escalabilidad y las bases de datos deberían estructurarse para permitir una gran cantidad de solicitudes simultáneas.

Como consecuencia de la arquitectura del sistema y del flujo de información y decisión en el sistema, cuando un vehículo equipado con el producto del cliente tiene la llave de contacto apagada y el vehículo está parado, este evento (un evento tentativo de aparcamiento) “activará” que el servidor se ponga en contacto con información (información de GPS, etc.) del cliente. Por lo tanto, es de esperar que una vez que el sistema se implemente de manera generalizada, se envíe al servidor un gran número de solicitudes todos los días, incluso para los automóviles que no se aparcaron en áreas de pago y que por lo tanto no necesitan servicio.

Sería prudente reducir efectivamente la carga de procesamiento en el servidor filtrando rápidamente las solicitudes que no requieren ningún servicio, por lo que se necesita un procedimiento de búsqueda geográfica 'inicial' rápido para determinar si un vehículo aparcado está cerca o dentro de una zona de pago. Esto no es necesariamente una tarea trivial debido a los diseños geográficos potencialmente complejos ('formas') de las áreas de aparcamiento de peaje y el gran número de áreas de aparcamiento que pueden registrarse en el sistema. Se propone un esquema de evaluación de clasificación aproximada simple y muy eficiente, basado en aproximaciones circulares a áreas de aparcamiento para realizar esta verificación inicial.

Supongamos que se inspecciona un área de aparcamiento y se mide la ubicación de todos los puntos externos del área de manera que los límites (lineales) entre los puntos definen la extensión física del área cerrada. Las áreas con formas simples podrían definirse por tres o cuatro puntos, mientras que las áreas con formas complejas podrían requerir cualquier cantidad de puntos. Todas las áreas de aparcamiento se ingresan en la base de datos en su "forma completa" con todos los puntos límites registrados, así como las aproximaciones circulares del área de aparcamiento asignada en un plano tangencial (2D) de la región, reduciéndose a solo dos parámetros (1) medio geográfico de todos los puntos límites, y (2) la distancia desde el centro hasta el punto más alejado del centro.

Esto permitiría una evaluación rápida de si un vehículo está en o cerca de un área de aparcamiento registrada en función de la relación simple entre la distancia plana de dos puntos (la ubicación media del área de aparcamiento y la ubicación del vehículo aparcado) y comparar el radio de la aproximación circular del área de aparcamiento con la distancia entre los dos puntos. Si la distancia entre los dos puntos es menor que el radio del círculo, el vehículo se define como dentro o cerca del área de aparcamiento.

Con referencia ahora a la figura 6, P1 es un ejemplo de un área de aparcamiento de forma algo compleja. El polígono A define los límites exteriores del aparcamiento en toda su forma. La cruz C marca el 'centro' (media geográfica) del aparcamiento, que se encuentra al promediar las coordenadas x e y para los puntos que constituyen el polígono A. P2 muestra la misma área de aparcamiento que en P1, así como la aproximación circular B, usando el

5

10

15

20

25

30

35

40

45

50

55

punto C como centro, y teniendo un radio correspondiente a la distancia entre el centro y el punto en el polígono A más alejado del centro.

Naturalmente, se debe llevar a cabo una evaluación posterior exhaustiva para determinar con precisión si el vehículo está ubicado dentro del área de aparcamiento con una forma potencialmente compleja si la evaluación inicial resultó ser cierta. Esto podría basarse en dividir parcialmente las áreas complejas en formas simples (en última instancia reducidas solo a triángulos) o cualquier procedimiento que se considere apropiado.

Las tareas de realizar extracción de información de base de datos o ingresar información nueva en una base de datos son bastante simples ya que las bases de datos están equipadas con administradores de bases de datos que proporcionan funciones de alto nivel para interactuar con la base de datos. Se propone que se consideren los modelos de bases de datos relacionales que siguen una implementación de SQL (lenguaje estructurado de consulta).

Utilizando los gestores de bases de datos respectivos es simple extraer los últimos datos de aumento de EGNOS para corregir el conjunto de observaciones gPs, extraer información de la cuenta del cliente para verificar si una solicitud del cliente está asociada a una suscripción de servicio válida o extraer información sobre la ubicación geográfica y los límites de las áreas de aparcamiento ya que las funciones macro simples se pueden ensamblar para buscar (consultar) las bases de datos para la información requerida.

Del mismo modo, no debería plantear ningún problema aplicar los datos de aumento de EGNOS a las observaciones del GPS, ya que existen algoritmos conocidos para tal fin. Cuando se calcula la duración de los eventos de aparcamiento (comparando las marcas de tiempo de inicio y final de los eventos) y se extrae de la base de datos la información sobre las tarifas de aparcamiento aplicables para la ubicación determinada, es una tarea trivial calcular la tarifa total del evento de aparcamiento. Y cuando se encuentra la tarifa total para un evento de aparcamiento, la información de los clientes se extrae de la base de datos, es simple realizar las transacciones de pago a los propietarios del área de aparcamiento utilizando los proveedores de servicios de pago.

En general, el servidor es un componente altamente crítico. La operación del sistema depende completamente de un servidor del sistema en funcionamiento ya que los clientes no podrán proporcionar ningún servicio sin el servidor. Esto hace que sea absolutamente necesario que el servidor se implemente como un parque de servidores redundante en lugar de una sola unidad, por lo que se evita un único punto de fallo. Esto implica duplicar los componentes del sistema (servidores y bases de datos) varias veces, asegurándose de que son realmente independientes y redundantes (por ejemplo, están ubicados en diferentes ubicaciones físicas) en cada nivel para que las comunicaciones del cliente se enruten a los servidores apropiados no importa cuál sea el estado del sistema del servidor.

El (los) servidor(es) y el software del servidor deben ser escalables para acomodar un número grande (y creciente) de clientes distribuidos. Esto es prácticamente posible utilizando técnicas y prácticas de software de subprocesos múltiples que están bien establecidas.

7 Base de datos de la P-área

Función:

El propósito de la base de datos del área de aparcamiento es verificar si un automóvil aparcado se encuentra dentro de un área de pago y determinar cuánto es la tarifa para un aparcamiento dado en el área.

Requisitos:

Cada área de aparcamiento individual que está asociada con una tarifa de aparcamiento existe como una entrada separada en la base de datos. Cada entrada podría consistir en una lista de coordenadas GPS que forman el límite exterior del área de aparcamiento, su punto geométrico promedio, la extensión física máxima del área en cualquier dirección desde el punto central medio (así como otros parámetros) para facilitar una comprobación muy fácil y rápida para ver si las coordenadas GPS de la unidad móvil se encuentran dentro de un área de aparcamiento en particular.

Se prevé que cualquier área de aparcamiento dada se pueda asignar fácilmente usando un receptor geodésico de levantamiento GPS estratégicamente ubicado en los extremos exteriores del área de aparcamiento. Las entradas de la base de datos deben tener una tabla de tarifas de aparcamiento (en función del tiempo) asociadas a ella, así como también la información requerida para realizar pagos a los propietarios de las áreas de aparcamiento. La precisión del registro del área de aparcamiento debe ser al menos comparable (o preferiblemente mejor) a la precisión objetivo del módulo GPS de la unidad móvil.

Existe una cantidad de bases de datos SQL gratuitas (o baratas) de las cuales se podría usar mucho para los diversos propósitos de la base de datos en el sistema propuesto. Dos candidatos muy obvios son las bases de datos MySQL y PostgreSQL. MySQL está disponible como software libre bajo la GNU GPL (Licencia Pública General), pero también está disponible bajo los acuerdos de licencia patentados tradicionales para casos donde el uso

5

10

15

20

25

30

35

40

45

previsto es incompatible con la GPL. PostgreSQL se lanza bajo una licencia flexible de estilo BSD (Berkeley Software Distribution).

Resumido de manera simplista, MySQL se construyó con la velocidad como característica principal, PostgreSQL se construyó con características más robustas como desencadenadores, pero carecía de la velocidad de MySQL. Como ambas están madurando, se están moviendo hacia la otra. MySQL 5 agrega desencadenantes y procedimientos almacenados, mientras que PostgreSQL se centra en mejorar el rendimiento.

MySQL es utilizada por grandes archivos de información de Internet, como Wikipedia, que actualmente atiende más de 200 millones de consultas y 1,2 millones de actualizaciones por día con cargas pico de 11.000 consultas por segundo. Actualmente hay más de 6 millones de instancias de MySQL en todo el mundo, por lo que la base de datos gratuita se ha sometido a pruebas y depuración sustanciales.

PosgreSQL quizás tenga una ventaja sobre MySQL cuando se trata de garantizar operaciones atómicas, consistentes y aisladas, lo que lo hace ideal para las transacciones. Las operaciones atómicas son operaciones compuestas que se llevan a cabo en la base de datos como una ocurrencia aparentemente única (de modo que parte de la operación compuesta no se puede ejecutar sin que se lleve a cabo 'todo' de la operación compuesta). PostgreSQL también admite funciones integradas para que las operaciones complejas de alto nivel definidas por el usuario se puedan ejecutar directamente en el administrador de la base de datos.

La base de datos del área de aparcamiento probablemente se implementa mejor con MySQL. El enfoque principal al implementar esta base de datos debe ser la accesibilidad y la velocidad. Una base de datos de aparcamiento basada en MySQL manejará fácilmente la cantidad de información requerida para cubrir todas las áreas de aparcamiento que se incluirán incluso en las principales regiones de operación.

8 Base de datos EGNOS Función:

El propósito de la base de datos EGNOS es simplemente mantener los datos de aumento de EGNOS utilizados para corregir las estimaciones de la posición del GPS.

Requisitos:

La base de datos debe actualizarse constantemente para contener los mensajes de datos EGNOS más recientes. Esta es una tarea muy simple usando SISNET y el receptor EGNOS/GPS como fuentes de datos.

Los mensajes EGNOS en sí mismos son bastante compactos, consistiendo (por el momento) solo de 17 mensajes, ocupando cada uno 33 bytes, por satélite EG EGOS, por lo que el tamaño de la base de datos será muy limitado.

La base de datos EGNOS se implementa fácilmente con MySQL. El enfoque principal al implementar esta base de datos debe ser la accesibilidad y la velocidad.

9 Base de datos de usuario Función:

El propósito de la base de datos del usuario es contener toda la información de cuenta y suscripción de usuario, así como un registro de eventos históricos.

Requisitos:

La base de datos contendrá información vital del usuario (como información de cuenta y suscripción, estado actual del vehículo del usuario, datos de transacciones temporales, información registrada y estadísticas de usuario, etc.) y servirá como base para realizar transacciones de pago. Es fundamental que la base de datos se mantenga constante en todo momento para que la información del usuario nunca se corrompa.

La base de datos de información del usuario probablemente se implementa mejor con PostgreSQL. El enfoque principal de esta base de datos y los procedimientos implementados para acceder a la base de datos debe ser la coherencia, ya que se utiliza para las transacciones.

Receptor GPS/EGNOS 10

Función:

El objetivo del receptor GPS/EGNOS ubicado en el centro es proporcionar una fuente de datos de aumento de EGNOS.

Requisitos:

5

10

15

20

25

30

35

40

45

50

Un receptor de GPS compatible con EGNOS bajo el control del operador debería estar ubicado cerca del servidor central. Los satélites EGNOS se colocan en órbitas geoestacionarias (sobre el ecuador) para proporcionar un área de cobertura amplia. Esto significa que cuando se ven desde la Tierra los satélites tendrán ángulos de elevación bastante bajos sobre el horizonte cuando se observen desde altas latitudes como el norte de Europa (en Dinamarca, por ejemplo, a 56° grados norte, el ángulo de elevación al satélite EGNOS más alto es de aproximadamente 7,5° arriba el horizonte). Por lo tanto, es vital colocar la antena de este receptor en un punto de gran altitud en una vista despejada de los satélites EGNOS (como en la parte superior de un edificio alto). También se recomienda utilizar una antena direccional de antena de alta ganancia para maximizar la relación señal-ruido del receptor, particularmente para el proceso de demodulación del mensaje de datos EGNOS.

Los sistemas de aumento tales como EGNOS, que se basan en correcciones basadas en satélites, se mencionan generalmente en SBAS (Satellite Based Augmentation System). EGNOS es un sistema de aumentación que cubre el funcionamiento en la región europea y africana. Equivalente a esto, la región estadounidense está cubierta por el sistema WAAS (Sistema de aumento de área amplia) y Japón y la región de Asia oriental están cubiertos por el sistema de aumento de satélites multifuncional (MSAS).

Los tres sistemas SBAS se adhieren a la misma especificación de señal, "RTCA MOPS DO 229C" (
http://www.rtca.org/downloads/ListofAvailableDocsWEBAUG_2005.htm). La RTCA (Radio Technical Commission for Aeronautics), desarrolla estándares relacionados con la FAA (Administración Federal de Aviación) que es una agencia del Departamento de Transporte de los Estados Unidos con autoridad para regular y supervisar todos los aspectos de la aviación civil en los Estados Unidos.

El receptor EGNOS/GPS podría ser uno de un número de receptores adecuados disponibles en el mercado, siempre y cuando el receptor es capaz de proporcionar los mensajes EGNOS crudos para la base de datos. Alternativamente, se podría utilizar una versión modificada del receptor GPS del cliente (es decir, se debe incluir el soporte de recepción EGNOS en esta versión del receptor del cliente).

11 SISNET Función:

El propósito de la conexión SISNET es proporcionar una fuente redundante de los datos de EGNOS.

Requisitos:

SISNET está disponible tanto como un servicio gratuito como un servicio comercial. El servicio gratuito se proporciona "tal cual" sin garantías, el servicio comercial cuenta con algunas garantías de acceso y disponibilidad. Se recomienda que el operador se suscriba al servicio comercial para garantizar la recepción adecuada de los mensajes de datos de EGNOS.

Actualmente ESA utiliza un protocolo patentado de capa de aplicación llamado 'DS2DC', explicado en detalle en 'Documento de interfaz de usuario SISNET' (disponible en

http://esamultimedia.esa.int/docs/egnos/estb/Publications/SISNET /SISNET_UID_3_1.pdf)

La implementación del software requerido para conectarse al servidor de datos SISNET y la descarga continua de mensajes para actualizar la base de datos EGNOS es una tarea bastante directa basada en la especificación del protocolo. Se espera que no sea crítico para alcanzar el rendimiento deseado.

12 Proveedor de servicios de pago Función:

El propósito del proveedor de servicios de pago es actuar como una pasarela de pago que facilite las transacciones financieras a través de Internet.

Requisitos:

Los proveedores de servicios como el PBS danés parecen candidatos obvios. Se debe tener cuidado de encuestar las condiciones marcadas y comparar el servicio de los candidatos potenciales. Al igual que el operador de red móvil/proveedor de servicios de Internet, se debe realizar un trato especial con el proveedor de servicios de pago elegido, ya que potencialmente se realizará una gran cantidad de transacciones diariamente (lo que debería reducir la incidencia de costes de transacción). Se espera que no sea crítico para alcanzar el rendimiento deseado.

La descripción del sistema antes mencionada tiene su origen en una disposición de determinación de posición que aplica GPS/EGNOS. La siguiente es una breve descripción de cómo los desarrollos tecnológicos futuros pueden afectar la arquitectura del sistema descrita anteriormente y las características y funciones proporcionadas por el sistema.

5

10

15

20

25

30

35

40

45

50

1 cliente GPS

El sistema europeo de navegación por satélite Galileo se encuentra actualmente en desarrollo. En general, se espera que Galileo supere (o al menos haga coincidir) el GPS tal como lo conocemos hoy en todos los aspectos. El proyecto Galileo ha sufrido numerosas demoras significativas y no se espera que tenga una constelación de satélites completamente desplegada antes de quizás el año 2010.

Como una respuesta más o menos directa a este desarrollo, el GPS se está modernizando para proporcionar a los usuarios señales de posicionamiento de mejor rendimiento. Actualmente se están desplegando los satélites 'GPS IIR-M' (versiones modernizadas de los actuales satélites de bloque IIR) y se han elaborado especificaciones detalladas para la siguiente generación, 'GPS IIF'. Una generación de GPS completamente revisada, llamada 'GPS- III' también se está sometiendo a un análisis inicial en este momento.

Es probable que los futuros receptores de navegación por satélite de alto rendimiento estén diseñados para aprovechar una combinación de las señales disponibles. Sin embargo, no está claro en este momento si los datos de aumentación SBAS como los proporcionados por EGNOS serán una parte integral de los futuros sistemas de navegación o si estos seguirán siendo proporcionados por sistemas de aumentación separados. Está claro que los receptores que combinan datos de varios sistemas generalmente serán más caros que aquellos basados en sistemas únicos, en particular, el número de frecuencias de portadoras lo indican.

Los sistemas que no contienen los datos de aumento de estilo EGNOS como parte integral pueden beneficiarse significativamente del principio de recopilar observables de GPS sin procesar (o señales de navegación por satélite equivalentes en general) en el cliente y enviarlos al servidor para su posterior aumento y corrección de SBAS para una mayor precisión de posicionamiento. Dado que es probable que el GPS en su forma actual esté disponible durante varios años, es muy poco probable que el principio de recopilar y aplicar las correcciones de aumento de forma centralizada quede obsoleto en el corto plazo.

2 Módem GSM

Mientras que GSM se considera un sistema de teléfono móvil 2G (segunda generación), GPRS se describe a menudo como un sistema "2.5G". Los sistemas 3G se están desplegando actualmente, pero hasta ahora solo han alcanzado una cobertura total en Dinamarca en áreas urbanas y ciudades densamente pobladas y en ciertos segmentos de autopistas. La implementación puede tener un estado diferente en otros países europeos.

El requisito primario de la tecnología de acceso inalámbrico utilizado en el sistema es la cobertura, ya que las tasas de transferencia de datos son fácilmente suficiente en las redes 2.5G incluso debido a las cantidades muy limitadas de datos a ser transferidos en la operación típica.

Con la cobertura actual, 3G es probablemente muy inadecuado para el sistema propuesto. Esto, por supuesto, puede cambiar una vez que la cobertura sea más completa. Además, según las características y servicios futuros que desee el sistema, las redes de telefonía móvil 3G/4G pueden resultar ventajosas si las características/servicios requieren grandes y rápidas transferencias de datos entre los clientes y el servidor.

3 Software de ordenador principal

Es poco probable que la función básica del software del sistema en el cliente cambie en futuras versiones del sistema. Sin embargo, el software de aplicación del cliente puede ampliarse para admitir cualquier número de posibles aumentos. Por ejemplo, las capacidades de entrada/salida y/o visualización más avanzadas del usuario pueden incluirse fácilmente si las funciones/servicios futuros necesarios lo requieren. También se puede incluir cualquier cantidad de sensores y transductores, por ejemplo, sensores de alarma del vehículo.

4 Operador de red móvil

Ver el punto 2 anterior. Es probable que el papel del operador de red móvil permanezca prácticamente inalterado como resultado del empleo de futuras tecnologías de sistemas móviles. La única función principal seguirá siendo proporcionar cobertura de acceso inalámbrico para los clientes distribuidos en el área de operación.

5 Proveedor de servicios de Internet

Al igual que el operador de red, es probable que la función del proveedor de servicios de Internet no se modifique.

6 Software del servidor central

Las características/servicios adicionales en un sistema futuro pueden implementarse fácilmente añadiendo los módulos de procesamiento de datos relevantes en el servidor central. La arquitectura del servidor se puede ampliar fácilmente con servidores adicionales para proporcionar las funciones deseadas.

7 Base de datos del área P

Se pueden incluir bases de datos adicionales para facilitar nuevas características o servicios tales como una variedad de diferentes esquemas de precios de carreteras. Se puede incorporar cualquier cantidad de bases de datos adicionales.

5 8 Base de datos EGNOS

Ver el punto 1 anterior. Aunque Galileo puede incluir datos de aumento al estilo EGNOS como parte integral, esta base de datos podría ser muy relevante siempre que se utilice el GPS.

9 Base de datos de usuario

Es probable que permanezca sin cambios. Es probable que el funcionamiento del sistema dependa de una base de 10 datos de cuenta de usuario.

10 Receptor GPS/EGNOS

Ver el punto 8 anterior.

11 SISNET

Ver el punto 8 anterior.

15 12 Proveedor de servicios de pago

Es probable que la función del proveedor de servicios de pago permanezca inalterada en futuras versiones del sistema. Siempre que el pago automático sea parte del servicio proporcionado, el sistema dependerá de alguna forma de pasarela de pago.

Claims (12)

1. 5

   10

   15

   20

   25

   30

   35

   40

   45

   50

   REIVINDICACIONES

   1. Un sistema para el pago automático de tasas de circulación para vehículos, comprendiendo el sistema

   - una pluralidad de unidades móviles, estando cada unidad adaptada para colocarse en un vehículo, y

   - una unidad de base que está adaptada para comunicarse con la pluralidad de unidades móviles,

   en el que cada unidad móvil comprende un receptor de sistema de navegación basado en satélite y medios de comunicación para transmitir una pluralidad de observables de posición que contienen pseudorrangos a la unidad de base, y

   en el que la unidad de base comprende medios de comunicación para comunicarse con la pluralidad de unidades móviles, y medios de procesador para procesar dichas posiciones observables para determinar una primera posición del vehículo en relación con la información de tasas de circulación precargada almacenada en la unidad de base o accesible desde la misma,

   caracterizado porque dicho medio de procesador está además adaptado para calcular una posición corregida del vehículo en caso de que la primera posición del vehículo caiga dentro de un rango predeterminado de una sección de carretera donde se han de pagar tasas de circulación, comparar la posición corregida calculada del vehículo con la información de tasas de circulación precargada almacenada o accesible desde la unidad de base y determinar si el vehículo ha entrado en una sección de carretera donde se deben pagar las tasas de circulación.
2. 2. Un sistema de acuerdo con la reivindicación 1, en el que el receptor del sistema de navegación basado en satélite comprende un receptor GPS o un receptor GALILEO.
3. 3. Un sistema de acuerdo con la reivindicación 1 o 2, en el que los medios de comunicación de cada una de la pluralidad de unidades móviles están adaptados para comunicarse a través de una red celular, tal como GSM, GPRS, EDGE, iDEN, D-AMPS; PDC, W-CDMA, CDMA2000 o TD-SCDMA.
4. 4. Un sistema de acuerdo con cualquiera de las reivindicaciones 1a 3, en el que los medios de comunicación de la unidad de base están adaptados para comunicarse con la pluralidad de unidades móviles a través de un Proveedor de Servicios de Internet.
5. 5. Un sistema de acuerdo con cualquiera de las reivindicaciones 1a 4, en el que la unidad de base comprende una o más unidades de base opcionalmente colocadas en diferentes ubicaciones físicas.
6. 6. Un sistema de acuerdo con la reivindicación 5, en el que la unidad de base se implementa como una unidad redundante que comprende un número de unidades básicas esencialmente idénticas posicionadas opcionalmente en diferentes ubicaciones físicas.
7. 7. Un sistema según cualquiera de las reivindicaciones 1 a 6, en el que la unidad de base está operativamente conectada a una pluralidad de proveedores de servicios externos, tales como un proveedor de servicios de pago, un servicio redundante que proporciona señales de corrección de posición, etc.
8. 8. Un procedimiento para el pago automático de tasas de circulación para vehículos, comprendiendo el procedimiento las etapas de

   - proporcionar una unidad móvil adaptada para colocarse en un vehículo, proporcionando la unidad móvil una pluralidad de observables de posición que contienen pseudorrangos por unidad de tiempo;

   - transmitir un número de observables de posición a una unidad de base, y

   - procesar, en dicha unidad de base, dicho observable de posición transmitida para determinar una primera posición del vehículo en relación con la información de tasas de circulación precargada almacenada en la unidad de base o accesible desde la misma

   caracterizado porque se calcula una posición corregida del vehículo en caso de que la primera posición del vehículo caiga dentro de un rango predeterminado de un tramo de carretera donde se han de pagar tasas de circulación, comparando la posición corregida calculada del vehículo con la información de tasas de circulación precargada almacenada en, o accesible de, la unidad de base y completando una transacción financiera cuando se ha determinado que el vehículo ha ingresado en una sección de carretera, donde se deben pagar las tasas de circulación.
9. 9. Un procedimiento de acuerdo con la reivindicación 8, en el que la etapa de calcular una posición corregida del vehículo implica aplicar correcciones SBAS, EGNOS, WAAS o MSAS a la primera posición del vehículo, estando representada dicha primera posición del vehículo por al menos un conjunto de Observables GPS o coordenadas GPS.
10. 10. Un procedimiento de acuerdo con cualquiera de las reivindicaciones 8-9, que comprende además la etapa de completar una transacción financiera, comprendiendo dicha transacción financiera la etapa de retirar un importe correspondiente a una tasa de circulación calculada de una cuenta de una persona registrada como titular del móvil. unidad, y deposite esta cantidad en una cuenta del propietario de la tasa de circulación.
11. 11. Un procedimiento de acuerdo con cualquiera de las reivindicaciones 8-9, que comprende además la etapa de completar una transacción financiera, comprendiendo dicha transacción financiera la etapa de registrar una cantidad correspondiente a unas tasas de circulación calculadas, y almacenar esta cantidad registrada para permitir un depósito posterior de un cantidad correspondiente a los importes registrados acumulados, siendo dicho depósito a

    5 una cuenta del propietario de la tasas de circulación.
12. 12. Un procedimiento de acuerdo con cualquiera de las reivindicaciones 8-9, que comprende además la etapa de completar una transacción financiera, comprendiendo dicha transacción financiera la etapa de retirar un importe correspondiente a unas tasas de circulación calculadas de un importe pagado por adelantado por una persona registrada como propietario de la unidad móvil.

    10