ES2544443T3 - Comunicaciones de vehículos - Google Patents

Abstract

Un aparato de comunicaciones (400) para un vehículo, comprendiendo el aparato (400): un primer almacén (422) para almacenar un identificador de vehículo portador, para identificar un vehículo portador sobre o en el que está funcionando el aparato (400); un receptor (410) para recibir mensajes directamente desde fuentes de mensajes en las proximidades del vehículo portador; un segundo almacén (421) para almacenar al menos un identificador de vehículo objetivo; un transmisor (415) para transmitir mensajes directamente a destinos de mensajes en las proximidades del vehículo portador; y estando el aparato (400) adaptado para: recibir desde una fuente de mensajes un mensaje que contiene un identificador de vehículo objetivo y almacenar el identificador de vehículo objetivo en el segundo almacén (421); comparar un identificador de vehículo objetivo recibido con el identificador de vehículo portador con el fin de establecer si el vehículo portador es el vehículo objetivo respectivo; y en respuesta a establecer que el vehículo portador no es el vehículo objetivo respectivo, propagar el mensaje recibido a uno o más destinos de mensajes; caracterizado por que el aparato (400) está adaptado para: recibir desde un destino de mensajes una respuesta a un mensaje propagado y determinar, basándose en la respuesta, que el destino del mensaje respectivo es un vehículo objetivo.

Description

15

25

35

45

55

65

E11799261

31-07-2015

DESCRIPCIÓN

Comunicaciones de vehículos

Campo

La presente invención pertenece al campo de las comunicaciones de vehículos y, en particular, pero no exclusivamente, se refiere a las comunicaciones entre vehículos con el fin de la propagación de información.

Antecedentes

Tal como se usa en el presente documento, un "vehículo" puede ser cualquier tipo de vehículo a motor, tal como un coche, un camión, una motocicleta, un tren, un autocar o un barco. Además, un vehículo puede ser cualquier tipo de contenedor, que puede transportarse, por ejemplo, por cualquier tipo de vehículo a motor. En el sentido más amplio, un vehículo puede ser cualquier objeto móvil, incluyendo los objetos inanimados y también los seres humanos y los animales, en o sobre el que puede montarse o transportarse una unidad de comunicaciones del tipo descrito en el presente documento.

Algunas realizaciones de la presente invención encuentran aplicación en el campo de la recuperación de vehículos robados (SVR). Algunas otras realizaciones de la invención encuentran aplicación en la retirada de vehículos, por ejemplo, cuando un fabricante de vehículos necesita retirar una marca de vehículo a motor para reparar un fallo. Otras realizaciones de la invención se refieren a la determinación del estado del vehículo.

En la figura 1 se ilustra un sistema SVR conocido de manera general. Un tipo de producto SVR disponible en el mercado es TRACKER Locate™, producido y vendido por TRACKER Network (UK) Limited. En un sistema SVR conocido de este tipo, se instala una unidad de transceptor montada en vehículo (VMTU) en un vehículo 115, y puede activarse, por ejemplo, mediante señales de activación de radio inalámbricas, cuando se informa por el propietario de que se ha robado el vehículo. Una vez activa, la VMTU emite una señal de radio periódica, que puede detectarse por las unidades de detección montadas en los vehículos policiales. Más especialmente, cuando se ha informado del robo de un vehículo, un sistema de control SVR central 100 puede comunicarse con y activar la VMTU (no mostrada) del vehículo robado 115 a través de una red celular de transmisores de radio 105, 110. Las comunicaciones para activar una VMTU pueden emplear un tipo adecuado de comunicaciones inalámbricas, por ejemplo, GSM, GPRS o UMTS, por nombrar solo unas cuantas opciones, y pueden emplear la tecnología celular del tipo habitualmente asociado con los aparatos de telefonía móvil.

Los productos tales como TRACKER Locate han resultado especialmente exitosos en facilitar la detección y la recuperación de vehículos robados. Sin embargo, el coste de capital de la instalación y el mantenimiento de una red de torres de radio, y los costes por unidad de las VMTU habilitadas por radio y las unidades de detección montadas en vehículos policiales, son relativamente altos.

El documento US6792351 desvela un método y un aparato para la comunicación multivehículo, en el que un mensaje que se recibe en un vehículo puede retransmitirse a otros vehículos.

Sumario

De acuerdo con un primer aspecto, la presente invención proporciona un aparato de comunicaciones para un vehículo, comprendiendo el aparato:

un primer almacén para almacenar un identificador de vehículo portador, para identificar un vehículo portador sobre o en el que está funcionando el aparato;

un receptor para recibir mensajes directamente desde fuentes de mensajes en las proximidades del vehículo portador;

un segundo almacén para almacenar al menos un identificador de vehículo objetivo;

un transmisor para transmitir mensajes directamente a destinos de mensajes en las proximidades del vehículo portador; y

estando el aparato adaptado para:

recibir desde una fuente de mensajes un mensaje que contiene un identificador de vehículo objetivo y almacenar el identificador de vehículo objetivo en el segundo almacén;

comparar un identificador de vehículo objetivo recibido con el identificador de vehículo portador con el fin de establecer si el vehículo portador es el vehículo objetivo respectivo; y

E11799261

31-07-2015

en respuesta a establecer que el vehículo portador no es el vehículo objetivo respectivo, propagar el mensaje recibido a uno o más destinos de mensajes;

caracterizado por que el aparato está adaptado para:

5 recibir una respuesta a un mensaje propagado desde un destino de mensajes y determinar, basándose en la respuesta, que el destino de mensajes respectivo es un vehículo objetivo.

Tal como se usa en el presente documento, "propagar" significa que una fuente de mensajes puede comunicar a lo

10 largo del tiempo un mensaje a múltiples destinos, por lo que cada destino puede comunicar a lo largo del tiempo el mensaje a otros múltiples destinos, y así sucesivamente. Cada fuente de mensajes puede comunicar el mismo mensaje una pluralidad de veces, por ejemplo, de manera repetida, periódica, no periódica, aleatoria o en respuesta a algún tipo de desencadenante, de manera que, a lo largo del tiempo, una pluralidad de destinos diferentes tienen la oportunidad de recibir el mensaje. Dichas comunicaciones también pueden denominarse "comunicaciones

15 virales".

Breve descripción de los dibujos

Diversas características y ventajas de la invención resultarán evidentes a partir de la siguiente descripción de las 20 realizaciones de la invención, proporcionada solo a modo de ejemplo, que se hace con referencia a los dibujos adjuntos, en los que:

La figura 1 es un diagrama esquemático de un sistema de recuperación de vehículos robados conocido;

25 La figura 2 es un diagrama esquemático de un escenario y un sistema ejemplares adecuados para realizar la recuperación de vehículos robados de acuerdo con una realización de la presente invención;

La figura 3 es un diagrama de bloques funcional de un punto de inicio y de recepción óptico ejemplar, de acuerdo con una realización de la presente invención;

30 La figura 4 es un diagrama de bloques funcional de una unidad de transceptor óptico montada en vehículo ejemplar, de acuerdo con una realización de la presente invención;

La figura 5a es un diagrama de un mensaje de solicitud de recuperación de vehículo robado ejemplar, de 35 acuerdo con una realización de la presente invención;

La figura 5b es un diagrama de un mensaje de respuesta de recuperación de vehículo robado ejemplar, de acuerdo con una realización de la presente invención;

40 La figura 5c es un diagrama de un mensaje de retirada de vehículo ejemplar, de acuerdo con una realización de la presente invención;

La figura 6a es un diagrama de flujo que representa el funcionamiento ejemplar de un sistema de ordenador central y un punto de inicio óptico, de acuerdo con una realización de la presente invención;

45 La figura 6b es un diagrama de flujo que representa el funcionamiento ejemplar de un transceptor óptico montado en vehículo que realiza la recuperación de vehículos robados, de acuerdo con una realización de la presente invención;

50 La figura 7 es un diagrama de flujo que representa el funcionamiento ejemplar de un transceptor óptico montado en vehículo que realiza la retirada de vehículos, de acuerdo con una realización de la presente invención;

La figura 8a es un diagrama de un mensaje de solicitud de estado ejemplar, de acuerdo con una realización de la presente invención; y

55 La figura 8b es un diagrama de un mensaje de solicitud de estado ejemplar, de acuerdo con una realización de la presente invención.

Descripción detallada

60 A continuación, se describirán en más detalle diversas realizaciones de la presente invención con referencia a los dibujos adjuntos. Se apreciará que la invención no está limitada en su aplicación a los detalles del método y la disposición de los componentes como se establece en la siguiente descripción o se ilustra en los dibujos. Para los expertos en la materia será evidente que son posibles otras realizaciones de la presente invención no detalladas en

65 la descripción y que pertenecen al alcance de las presentes reivindicaciones. En consecuencia, la siguiente

15

25

35

45

55

65 E11799261

31-07-2015

descripción no debe interpretarse como limitante en modo alguno, y el alcance de la protección se define solamente por las reivindicaciones adjuntas a la misma.

Con referencia al diagrama de la figura 2, una realización SVR de la invención prescinde de una red celular de torres de radio. En esta realización, las comunicaciones por radio se sustituyen por comunicaciones ópticas. Los mensajes SVR se comunican de manera viral a las VMTU ópticas (OVMTU) o bien por puntos de inicio o por OVMTU montadas sobre o en otros vehículos. De acuerdo con la realización, cada OVMTU maneja los mensajes SVR de acuerdo con una lógica básica, que toma la forma:

Para cada mensaje SVR recibido por una OVMTU:

¿Se identifica un vehículo objetivo en el mensaje recibido por el vehículo en el que está montada la OVMTU destinataria?

Si es "sí", entonces generar y enviar un mensaje de respuesta que indique que el vehículo destinatario es el vehículo objetivo (es decir, el mensaje indica que la OVMTU destinataria está montada en un vehículo robado);

Si es "no", entonces propagar el mensaje.

De esta manera, la naturaleza del mensaje, o al menos una parte del mismo, está determinada por el resultado de la comparación entre el vehículo objetivo identificado en el mensaje recibido y la identidad del vehículo en el que está montado la OVMTU. En este ejemplo, se espera que al menos un identificador de vehículo objetivo aparezca en ambos tipos de mensaje.

Haciendo referencia a la figura 2, un sistema de ordenador central 200 está en comunicación con al menos un punto de inicio 210 a través de una red 205. El sistema de ordenador central 200 es, por ejemplo, un sistema basado en PC que funciona conforme a un sistema operativo Windows™ y que realiza operaciones SVR de acuerdo con un software de aplicación SVR. Durante el funcionamiento, por ejemplo, un operador del sistema de ordenador central 200 puede recibir un mensaje del propietario de un vehículo robado, a través de una llamada telefónica, y controlar el sistema de ordenador central 200 para confrontar los detalles de registro del propietario y el vehículo con una base de datos (no mostrada) que contiene un identificador de vehículo único pre-registrado y asociado (por ejemplo, un número de identificación de vehículo, o VIN). El sistema de ordenador central 200 puede, a continuación, comunicar el identificador de vehículo único al punto de inicio 210, a través de la red 205.

En principio, para que las realizaciones de la invención funcionen, como será evidente a partir de la siguiente descripción, solo es necesario tener un único punto de inicio que actúe como una fuente de propagación de mensajes. Sin embargo, las realizaciones de la invención tienen habitualmente una pluralidad de puntos de inicio, distribuidos de acuerdo con consideraciones tales como la geografía, las características del tráfico de vehículos y la velocidad de los requisitos de detección.

La red 205 puede ser una red privada o una red pública como Internet. En algunas realizaciones, algunos o todos los puntos de inicio pueden estar en comunicación con el sistema de ordenador central 200 usando transmisiones inalámbricas, por ejemplo empleando una red de radio celular GSM (no mostrada), por lo que los puntos de inicio están equipados con receptores de radio dispuestos, por ejemplo, para recibir mensajes SMS convencionales o similares. Como se comprenderá y se apreciará, podría emplearse cualquier tipo de norma y de sistema de comunicaciones alternativo para facilitar las comunicaciones entre un sistema de ordenador central y los puntos de inicio asociados.

De acuerdo con la presente realización, como se describirá con más detalle en lo sucesivo en el presente documento, un punto de inicio 210 comprende, en general, unos medios para recibir mensajes desde el sistema de ordenador central 200 y unos medios para generar las señales ópticas respectivas que se transmiten por un transmisor óptico 215 a los vehículos que pasan por el punto de inicio 210.

La figura 2 también ilustra un sistema de carreteras ejemplar, que incluye una calzada de dos vías oeste/este 230, en el que los vehículos 240 pueden viajar de oeste a este en el lado norte de la carretera y de este a oeste en el lado sur de la carretera. La carretera que se muestra tiene unos arcenes 225 y una mediana 215. El sistema de carreteras incluye un cruce en el que una calzada norte/sur 235 se une a la calzada oeste/este 230 desde el sur.

Como se muestra en la figura 2, el punto de inicio 210 está localizado en el arcén 225 en el lado norte de la calzada oeste/este 230, y el transmisor óptico asociado 215 está montado en la parte superior de un mástil 220 y está dispuesto para dirigir señales ópticas en una dirección generalmente hacia el oeste en la trayectoria de los vehículos 240 que viajan al este en la calzada oeste/este 230. Más en general, se apreciará que un transmisor óptico del tipo descrito en el presente documento podría disponerse para emitir señales ópticas en cualquier dirección, o sustancialmente en todas las direcciones, con el fin de facilitar la recepción de señales ópticas por los vehículos que viajan en cualquier dirección en relación con la localización del punto de inicio. Los puntos de inicio pueden estar en

15

25

35

45

55

65 E11799261

31-07-2015

localizaciones fijas convenientes, por ejemplo en el borde de la carretera, en las intersecciones de las autopistas, montados en castilletes de señalización sobre carreteras, o vías férreas, en las gasolineras, en las fronteras regionales o nacionales, o en las estaciones de servicio de las autopistas. Como alternativa, o además, los puntos de inicio pueden ser móviles, por ejemplo empleando un equipo montado en los vehículos policiales, otros vehículos de emergencia, vehículos de transporte de mercancías o similares. Por supuesto, los puntos de inicio móviles tenderían a estar en comunicación con un sistema de ordenador central a través de las comunicaciones inalámbricas.

En el sistema de carreteras de la figura 2 se representan cinco vehículos, que actúan de diversas maneras, y fuentes de mensajes y/o destinos de mensajes, como se describirá. De los vehículos, dos (etiquetados como A y C) viajan hacia el este por la calzada oeste/este, dos (etiquetados como B y D) viajan hacia el oeste, y uno (etiquetado como E) que ha llegado desde el sur está parado en el cruce. Para los presentes fines, cada uno de los cinco vehículos tiene una OVMTU de a bordo, cuyos detalles se describirán con más detalle en lo sucesivo en el presente documento.

Como se muestra en la figura 2, el punto de inicio 210 está transmitiendo una señal SVR óptica 250 al vehículo C. La señal óptica 250 incluye una solicitud de identificación de vehículo robado (SVID) que incluye un identificador I, que identifica un vehículo robado. Como se apreciará a partir de la figura 2, momentos antes de la comunicación con el vehículo C, el punto de inicio 210 ha transmitido la misma señal SVR óptica 250 al vehículo A, cuando el vehículo A ha pasado por el punto de inicio 210. Los vehículos A y C están etiquetados como A(I) y C(I), para indicar que ambos han almacenado el identificador de vehículo robado I, que se ha recibido desde el punto de inicio 210. Con respecto al punto de inicio, que actúa como una fuente de mensajes, los vehículos A y C son destinos de mensajes.

La figura 2 también muestra al vehículo A transmitiendo, a través de una señal SVR óptica 255, una solicitud SVID que incluye el identificador I al vehículo D. Una vez más, momentos antes, el vehículo A ha transmitido la misma solicitud SVID al vehículo B. Los vehículos B y D están etiquetados como B(AI) y D(AI), para indicar que han recibido, a través del vehículo A, y almacenado el identificador de vehículo robado I. En este escenario, los vehículos B y D son destinos de mensajes con respecto al vehículo A, y el vehículo A actúa como una fuente de mensajes con respecto a los vehículos B y D.

Además, la figura 2 muestra al vehículo B transmitiendo, a través de una señal SVR óptica 260, el identificador I al vehículo E. El vehículo E está etiquetado como E(BAI) para indicar que ha recibido, a través del vehículo A y, a continuación, del B, y almacenado el identificador de vehículo robado I. En este escenario, el vehículo E es un destino de mensajes con respecto al vehículo B, y el vehículo B es una fuente de mensajes con respecto al vehículo

E.

Finalmente, la figura 2 muestra al vehículo E transmitiendo, a través de una señal SVR óptica 265, una señal de respuesta SVR que indica que su identidad coincide con la identidad I del vehículo robado. En este escenario, se han invertido los papeles y el vehículo E es una fuente de mensajes con respecto al vehículo B, y el vehículo B es un destino de mensajes con respecto al vehículo E.

En resumen, como se muestra en la figura 2, se ha identificado un vehículo robado mediante una secuencia que comprende solo cuatro señales ópticas: punto de inicio 210 → vehículo A; vehículo A → vehículo B; vehículo B → vehículo E; y vehículo E → vehículo B. En este ejemplo, cada vehículo (o, de hecho, su OVMTU respectiva) puede actuar como una fuente de mensajes o un destino de mensajes, respectivamente, dependiendo de si se envían o se reciben mensajes. Por supuesto, pueden haberse transmitido (pero no necesariamente recibido) más de cuatro señales y mensajes ópticos con el fin de lograr cuatro transmisiones recibidas con éxito.

Se apreciará que la probabilidad de identificar un vehículo robado dentro de las proximidades de un solo cruce de carreteras, como se representa en la figura 2, es relativamente baja (¡aunque no imposible!). Sin embargo, también se apreciará que la propagación de una identidad de vehículo robado I desde un punto de inicio y, a continuación, de vehículo a vehículo podría ser extremadamente rápida, especialmente en áreas metropolitanas en las que la densidad de vehículos es relativamente alta. Dada la colocación estratégica de uno o más puntos de inicio a todo lo largo de una geografía determinada (por ejemplo, un pueblo, una ciudad, un estado, un país o incluso varios países

o un continente), y el número razonable de vehículos que transportan cada uno una OVMTU, es concebible que toda una geografía pueda saturarse con una identidad I en cuestión de horas o de días. De esta manera, puede facilitarse un SVR sin la necesidad de una red de transmisores de radio, y que, por lo tanto, pueda prescindirse por completo de parte de una infraestructura SVR conocida.

El diagrama de la figura 3 ilustra con más detalle los componentes funcionales de un punto de inicio ejemplar 210 de acuerdo con una realización de la presente invención. Como se describirá a continuación en el presente documento, un punto de inicio puede recibir mensajes, así como propagarlos. Como se muestra, el punto de inicio 210 comprende un microprocesador (o procesador) 305, un circuito receptor óptico 310 accionado por un fotodiodo 312, un circuito transmisor óptico 315 que acciona un diodo emisor de luz (LED) 317, una memoria principal 320 que contiene al menos un almacén 322 para solicitudes SVID, una memoria de programa 325 para almacenar un código de programa para controlar el funcionamiento del punto de inicio 210, una interfaz de red 330 para conectar el punto

15

25

35

45

55

65 E11799261

31-07-2015

de inicio 210 a la red 205, una interfaz de gestión 335, mediante la que un operario o ingeniero de servicio puede conectarse al punto de inicio 210 con fines de actualización o mantenimiento.

Como alternativa, un operario o ingeniero de servicio puede comunicarse con el punto de inicio 210 a través de la interfaz de red, accediendo a y usando una consola de control remoto o similares de una manera conocida.

También se proporciona un reloj de tiempo real 340.

Los componentes en el punto de inicio ejemplar 210 se conectan mediante una disposición de interconexión o de BUS adecuada 307.

El procesador 305 del punto de inicio 210 puede ser un procesador integrado, que realiza las funciones de acuerdo con las instrucciones de firmware que se almacenan en y se cargan desde la memoria de programa 325. La memoria principal 320 puede ser una RAM volátil o una EEPROM no volátil, mientras que la memoria de programa puede ser una EEPROM o una ROM no volátiles. En algunas realizaciones, tanto la memoria principal 320 como la memoria de programa 325 pueden comprender una EEPROM, lo que implica de manera beneficiosa que los datos no se pierden durante un corte de energía. En algunas realizaciones, toda la funcionalidad del punto de inicio (a excepción de, tal vez, los componentes electrónicos para accionar el fotodetector y el LED) se materializa en un solo circuito integrado para aplicaciones específicas (ASIC) a medida. Por supuesto, la funcionalidad podría en cambio implementarse de cualquier manera adecuada. Por ejemplo, en esta o en cualquier otra realización, los datos recibidos pueden almacenarse en los registros de procesador además de, o en lugar de, en la memoria principal, o en cualquier otro tipo de elemento o elementos de almacenamiento.

El procesador 305 está programado para recibir, desde el sistema de ordenador central 200, solicitudes SVID, incluyendo cada una de las mismas una SVID única, y almacenar cada solicitud SVID recibida en el almacén SVID

322. A continuación, el procesador lee periódicamente la o las solicitudes SVID del almacén SVID 322 y hace que el transmisor 315 transmita solicitudes SVID asociadas al paso de los vehículos, con el fin de propagar la SVID. En lo sucesivo en el presente documento, se describirá con más detalle un protocolo de mensajería ejemplar para comunicar solicitudes SVID.

Se apreciará que una o más solicitudes SVID, asociadas con vehículos robados y aún no detectados, pueden estar "activas" en cualquier momento y almacenadas por el punto de inicio 210, y las múltiples solicitudes SVID pueden, a continuación, transmitirse una tras otra a los vehículos que pasan. En términos prácticos, esto puede significar, por supuesto, que un vehículo que pasa solo recibe una, o un subconjunto, de todas las solicitudes SVID activas que se transmiten de manera secuencial. Si este es el caso, entonces, a lo largo del tiempo, se espera que los múltiples vehículos que pasan reciban, entre los mismos, y en conjunto, todas las solicitudes SVID, con el fin de que todas las solicitudes SVID puedan propagarse de acuerdo con las realizaciones de la invención.

En esta realización ejemplar, la presencia de un vehículo no se detecta como tal y, de este modo, el tiempo entre las transmisiones consecutivas de cada solicitud SVID está dispuesto para ser relativamente corto, con el fin de maximizar la probabilidad de que todos los vehículos que pasan (o al menos algunos, pero preferentemente la mayoría de los mismos) que sean capaces de recibir las solicitudes SVID, lo hagan. Por ejemplo, cada solicitud SVID puede transmitirse diez veces por segundo, por ejemplo, cada 0,1 segundos. El tiempo entre las diferentes solicitudes SVID que se transmiten puede ser mucho más corto, por ejemplo, con un espacio de separación de 0,02 segundos, para garantizar que cada vehículo que pasa recibe un número máximo de solicitudes SVID diferentes. Sin embargo, la frecuencia de las transmisiones puede ajustarse en función de la velocidad prevista de los vehículos que pasan. Por ejemplo, el periodo entre las transmisiones puede ser mayor si el punto de inicio está localizado en un cruce en el que los vehículos reducen la velocidad. Por el contrario, el periodo entre las transmisiones puede ser más corto si el punto de inicio está localizado cerca de una autopista en la que los vehículos viajan con rapidez. En algunas realizaciones, un punto de inicio puede incluir un detector de movimiento (no mostrado), que es capaz de detectar cuándo se acerca un vehículo al punto de inicio y solo entonces desencadenar una transmisión de las solicitudes SVID.

De acuerdo con la presente realización, el LED 317 es un LED de infrarrojos de potencia relativamente alta que funciona a 940 nm, y que incluye una disposición de lente de enfoque y de reflector adecuada para garantizar que la máxima potencia óptica se enfoca y se transmite en la dirección del vehículo que se acerca. La longitud de onda óptica es similar a la empleada por los dispositivos de control remoto de infrarrojos. Sin embargo, podrían usarse otras longitudes de onda de funcionamiento, por ejemplo de 880 nm. De hecho, podría emplearse cualquier longitud de onda de funcionamiento de luz, aunque se prevé que solo deberían emplearse las longitudes de onda que son imperceptibles para los seres humanos y los animales. En otras realizaciones, las señales ópticas pueden generarse modulando la luz visible que se emite por los faros convencionales cuando se encienden. La modulación se hace lo suficientemente rápida como para ser imperceptible para los humanos y, por lo tanto, no distrae ni es indicativa de una señalización activa.

Las comunicaciones ópticas se realizan modulando datos sobre una señal portadora óptica. Los detalles de tales comunicaciones ópticas se conocen muy bien y no se describirán en el presente documento.

15

25

35

45

55

65 E11799261

31-07-2015

El diagrama de la figura 4 ilustra con más detalle los componentes funcionales de una OVMTU ejemplar 400. Como se muestra, la OVMTU 400 comprende un microprocesador (o procesador) 405, un comparador 406, una unidad de receptor óptico 410 accionada por un fotodiodo 412, una unidad de transmisor óptico 415 que acciona un diodo emisor de luz 417, una memoria principal 420, una memoria de programa 425 para almacenar un código de programa para controlar el funcionamiento de la OVMTU, un generador de códigos 430, una interfaz de gestión 435, a través de la que puede configurarse la OVMTU para su instalación en un vehículo específico, y un indicador 445. El indicador 445 puede ser cualquier tipo de alarma sonora, luz intermitente, pantalla gráfica, o similares, que sea adecuada para notificar al conductor de un vehículo que acaba de detectarse un vehículo robado.

La memoria principal 420 contiene al menos un almacén 421 para solicitudes SVID, un almacén 422 para un identificador de vehículo portador (HVID), un almacén 423 para una clave de codificación (CodKey) opcional y un almacén 424 para un registro de vehículos robados (SVREG). Un HVID es el identificador del vehículo en (o sobre) el que está montada la OVMTU. Aunque, de acuerdo con la presente realización, un almacén es habitualmente una localización en un elemento de memoria, podría ser igualmente un registro en un elemento de procesador o en cualquier otro elemento de retención de datos adecuado.

Los componentes en la OVMTU ejemplar 400 se conectan mediante una disposición de interconexión o de BUS adecuada 407.

El procesador 405 y la memoria 420, 425 pueden especificarse de manera similar a los componentes equivalentes en el punto de inicio 210. Los datos HVID y CodKey deben almacenarse, al menos, en una memoria no volátil. Por lo tanto, si la memoria principal 420 comprende una RAM volátil, los datos HVID y CodKey pueden, en cambio, almacenarse en la memoria de programa 425 o en un almacén de memoria no volátil alternativo (no mostrado). Una vez más, en algunas realizaciones, la totalidad o la mayor parte de la funcionalidad de la OVMTU está integrada en un ASIC.

En una realización práctica, una parte principal de una OVMTU 400 comprende habitualmente una carcasa sellada que contiene la mayoría de los elementos de procesamiento, una entrada de alimentación y entradas para recibir conexiones por cable desde las unidades de transmisor óptico 415 y de receptor 410. La parte principal de la OVMTU 400 puede ocultarse en cualquier localización adecuada, por ejemplo en el compartimento del motor, en el maletero (o portaequipaje), bajo el vehículo o en el compartimento de los pasajeros. Como alternativa, la OVMTU puede formar uno de los subsistemas convencionales de un vehículo, y, como tal, instalarse durante la fabricación en lugar de ser, por ejemplo, un elemento instalado a posteriori.

Mientras tanto, las unidades de transmisor óptico 415 y de receptor 410 están dispuestas de manera que el diodo óptico 412 y el LED 417 se montan dentro de una unidad de grupo de luz, por ejemplo, de los faros o las luces traseras (o ambos) de un vehículo. En algunas realizaciones, los grupos de faros y/o luces traseras de un vehículo se fabrican para incluir unidades de transmisor y de receptor ópticos que son adecuadas para la conexión a la parte principal de una OVMTU respectiva. Por supuesto, las unidades de transmisor y de receptor pueden montarse de diversas maneras diferentes y en diversos lugares diferentes. Por ejemplo, como las transmisiones ópticas no son visibles, un transmisor podría montarse dentro del compartimiento de los pasajeros de un vehículo, e irradiar de manera eficaz luz invisible en todas las direcciones. En otras realizaciones, el transmisor y/o el receptor ópticos podrían montarse sobre o en el lado posterior de un espejo retrovisor, orientados hacia fuera y hacia delante a través del parabrisas. Pueden preverse otras disposiciones alternativas.

De acuerdo con la presente realización, una OVMTU ejemplar 400 está programada para realizar al menos cuatro operaciones:

Recepción SVID: la OVMTU 400 que actúa como un destino de mensajes recibe solicitudes SVID desde puntos de inicio o desde otras OVMTU y almacena las solicitudes en el almacén SVID 421.

Comparación SVID: el comparador 406 compara los SVID recibidos con el HVID y, si se descubre que un SVID recibido coincide con el HVID de la OVMTU 400, el procesador 405 genera una transmisión de respuesta, que se envía a la fuente de la solicitud SVID, indicando que el SVID recibido coincide con su HVID.

Propagación SVID: la OVMTU 400, que actúa como una fuente de mensajes, transmite periódicamente solicitudes SVID a otras OVMTU o de vuelta a un punto de inicio.

Notificación SVID: si, en respuesta a haber enviado una solicitud SVID a otro vehículo, la OVMTU recibe una respuesta de vuelta que indica que el SVID coincide con un HVID del vehículo destinatario, la OVMTU hace que el indicador 445 indique que se ha detectado un vehículo robado.

En ocasiones, y sin haber propagado una solicitud SVID específica, una OVMTU puede recibir desde un vehículo robado un mensaje de respuesta que indica que un SVID coincide con el HVID del vehículo robado (por ejemplo, la respuesta puede haberse provocado por un mensaje SVID anterior desde una OVMTU diferente). En este caso, la

15

25

35

45

55

65 E11799261

31-07-2015

OVMTU destinataria todavía hace que el indicador 445 indique que se ha detectado un vehículo robado. De esta manera, cualquier OVMTU puede realizar una notificación SVID, independientemente de si ha recibido o transmitido previamente o no una solicitud SVID respectiva.

De acuerdo con la presente realización, como con los puntos de inicio, la OVMTU 400 no detecta como tal la presencia de otros vehículos, y la tasa de repetición de los mensajes de solicitud SVID es relativamente alta con el fin de garantizar que otros vehículos que pasan también reciban los mensajes. En realizaciones alternativas, la OVMTU puede adaptarse para ajustar la tasa de repetición de acuerdo con la velocidad del vehículo y/o detectar otros vehículos en las proximidades del vehículo con el fin de desencadenar la transmisión de las solicitudes SVID. Una manera ejemplar de detectar la velocidad del vehículo portador es conectarse a un bus de red de área de control (CAN) del vehículo portador, con el fin de detectar un valor de indicador de velocidad del vehículo portador.

Con respecto a la Comparación SVR, de acuerdo con la presente realización, una OVMTU es responsable de identificar si tiene un HVID que coincida con un SVID recibido y notificar a la fuente del SVID (o potencialmente cualquier otra OVMTU o punto de inicio que pasa) que hay una coincidencia. Al adoptar este enfoque, puede disponerse una OVMTU para generar una respuesta solo si hay una coincidencia, y no lo contrario. Esto tiene la ventaja de conservar la energía de la batería del vehículo, especialmente si el vehículo no está en funcionamiento (por ejemplo, el motor no está en marcha), de una manera que recarga la batería. En otras realizaciones, la OVMTU puede, en cambio, devolver su HVID a la fuente del SVID y dejarlo en la fuente para determinar si hay una coincidencia. En otras realizaciones más, la OVMTU puede realizar su propia comparación para determinar que hay una coincidencia y, además, confirmar la coincidencia y devolver su HVID a la fuente. En general, las realizaciones de la presente invención comprenden cualquier protocolo que facilite una fuente para realizar la Notificación SVR.

En efecto, la Notificación SVR informa al conductor del vehículo que ha originado una solicitud SVID (o que ha recibido una respuesta a una solicitud SVID requerida por otra OVMTU) que se ha detectado un vehículo robado en las proximidades del vehículo robado. A continuación, el conductor del vehículo fuente puede, por ejemplo, contactar con la policía o un centro de llamadas designado para proporcionar información, incluyendo la localización del conductor; de este modo, se indica la localización aproximada del vehículo robado. En algunas realizaciones, el indicador 445 proporciona una indicación que incluye el SVID (o cualquier otra representación del SVID u otro identificador que puede correlacionarse por el operador de la policía o del centro de llamadas con el vehículo robado), que puede comunicarse al operador de la policía o del centro de llamadas. Se apreciará que, al informar de la detección del vehículo robado, el conductor no sabe necesariamente qué coche en sus proximidades se ha robado y, por lo tanto, no se le incita a intervenir o acercarse al vehículo robado. Por supuesto, durante un corto periodo de tiempo, el vehículo robado puede comunicarse con una pluralidad de otras OVMTU, y todos los conductores de los vehículos respectivos pueden contactar con la policía o el centro de llamadas. De esta manera, la policía puede mapear el progreso del vehículo robado y calcular una localización de detección e intercepción óptima. En otras realizaciones, por ejemplo en las que se monta una OVMTU en un coche policial, la Notificación SVR puede adaptarse para incluir detalles de la marca y el modelo del vehículo robado detectado, de manera que un policía puede intervenir, acercarse y recuperar el robado vehículo. En otras realizaciones más, la OVMTU puede adaptarse para responder a una solicitud SVID, cuando hay una coincidencia, solo si el vehículo respectivo ha estado no operativo (y estacionario) durante un periodo de tiempo; por ejemplo, durante más de cinco minutos, o más de diez minutos. De esta manera, una notificación SVR se refiere habitualmente a un vehículo aparcado, y se espera que la localización presentada se mantenga con relativa precisión.

Otras realizaciones de la invención realizan una operación adicional (o alternativa) emitiendo señales ópticas de notificación de vehículos robados (OSVN). En esta operación, cuando una OVMTU determina, en respuesta a una solicitud SVID, que está en un vehículo robado, además de (o en lugar de) responder a la fuente, la OVMTU establece el registro SVREG y, mientras que se establece el registro, transmite repetidamente una señal OSVN que incluye el HVID/SVID, difundiendo de este modo de manera eficaz una señal de alerta que identifica que se ha robado el vehículo respectivo. De esta manera, la OVMTU transmite de forma proactiva señales (es decir, transmite múltiples señales sin requerir una solicitud SVID para cada una) que indican que se ha robado el vehículo respectivo. Esto es una ventaja en un escenario en el que hay múltiples solicitudes SVID activas en el sistema y no todos los vehículos son capaces de recibir todas las solicitudes SVID, pero son capaces de recibir una señal OSVN y plantear una Notificación SVR. En este caso, incluso un vehículo que no ha recibido una solicitud SVID específica es capaz de detectar una señal OSVN desde el vehículo respectivo, aumentando de este modo las probabilidades de detección y de recuperación del vehículo robado. Las OVMTU que funcionan de esta manera también se programan habitualmente para detectar mensajes OSVN de otras OVMTU, y desencadenar la Notificación SVR adecuada para el conductor, como se ha descrito anteriormente. El registro SVREG puede permanecer establecido hasta que se recupere el vehículo robado respectivo, o puede permanecer establecido durante un periodo fijo de tiempo, por ejemplo, una hora, lo que proporciona una gran oportunidad para que se detecte el vehículo sin agotar la batería del vehículo si está aparcado y no operativo.

Hasta el momento, se ha descrito una OVMTU en términos de una unidad que está instalada y montada dentro de un vehículo. En otras realizaciones, la operación funcional de una OVMTU se realiza mediante una unidad portátil e independiente, que puede unirse a contenedores, o transportarse por una persona o un animal. En algunas realizaciones, un agente de policía u otro funcionario (o, en principio, cualquier persona) que se ocupa de la

10

15

20

25

30

35

40

45

50

55

60

65 E11799261

31-07-2015

detección, y tal vez se detecte, puede transportar tales equipos. Una unidad portátil puede funcionar exactamente de la misma manera que una OVMTU, ampliando de este modo la capacidad de un sistema global para usarse en la detección de vehículos robados. Una ventaja de una unidad portátil es que puede transportarse en zonas que no tienen un alto tráfico de vehículos, tales como una zona de garaje o una calle secundaria, e incluso puede usarse para comunicar solicitudes SVID a los vehículos que están aparcados lejos de la carretera. En algunas realizaciones, una unidad portátil (o, de hecho, una unidad montada en vehículo) que se transporta por un agente de policía u otra persona asociada en parte con la detección (en lugar de detectarse), podría prescindir de la funcionalidad de Comparación SVR.

El diagrama de la figura 5a ilustra el contenido de una solicitud SVID ejemplar 500. De acuerdo con la presente realización, la solicitud 500 se genera en el sistema de ordenador central 200 y comprende: una designación SVR 505, que en esta realización indica que el mensaje es una solicitud SVID 510; un identificador de vehículo objetivo 510, que, en este ejemplo, es un SVID, por ejemplo un VIN; un código 515 asociado con el SVID, mediante el que puede comprobarse la autenticidad del SVID; un valor 520 que indica si un destinatario de la solicitud debe propagar

o no la solicitud; y un tiempo de finalización absoluto 525.

El valor de propagación 520 puede ser SÍ o NO, en el que un NO significa que la solicitud SVID no debe propagarse si el motor del vehículo asociado no está funcionando, por ejemplo, con el fin de ahorrar energía de la batería. Por otro lado, un SÍ significa que la solicitud SVR debe propagarse incluso si el motor del vehículo asociado no está funcionando. Se apreciará que el valor de propagación es un elemento opcional de información, que puede ser ventajoso en algunas realizaciones para evitar que se agote la batería de un vehículo.

El tiempo de finalización 525, que podría ser un periodo de tiempo o un tiempo relativo en lugar de un tiempo absoluto, determina durante cuánto tiempo deben los puntos de inicio y las OVMTU propagar la solicitud. Cuando un tiempo asociado con una solicitud SVID ha expirado, lo que se determina por referencia a los relojes de tiempo real, las OVMTU y los puntos de inicio se disponen para borrar la solicitud respectiva. De esta manera, se evita que el sistema global propague solicitudes después de que se haya recuperado un vehículo, o a perpetuidad. Las solicitudes que no han dado lugar a la recuperación de vehículos pueden volver a emitirse, si se desea, por el sistema de ordenador central.

El diagrama de la figura 5b ilustra el contenido de un mensaje de respuesta SVID ejemplar 550, que se transmite por una OVMTU, de acuerdo con la presente realización, si el SVID recibido en una solicitud SVID coincide con el HVID. La respuesta 550 incluye una parte de confirmación 555 que indica que el mensaje se refiere a una respuesta SVR; el HVID (por ejemplo el código VIN) 560; y un código 565 asociado con el HVID, de manera que puede comprobarse la autenticidad de la respuesta. En algunas realizaciones, el SVID y/o el HVID pueden acompañarse de un descriptor de vehículo, por ejemplo, la marca, el modelo, el año, la placa de matrícula y/o el color.

De acuerdo con las realizaciones de la invención, la autenticación de una solicitud SVID (o, de hecho, cualquier otro tipo de solicitud descrita en el presente documento) se realiza ventajosamente con el fin de identificar las solicitudes SVID erróneas o falsas, que de otro modo podrían introducirse en el sistema con malas intenciones. Aunque es más deseable una autenticación de este tipo, por ejemplo con el fin de evitar la subversión de un sistema, no es esencial, y, en algunas realizaciones, por ejemplo, las que no se ocupan de temas de SVR, puede que no sea necesaria la autenticación. Sin embargo, por si acaso, todas las realizaciones descritas con detalle en el presente documento emplean algún tipo de autenticación SVID con el fin de limitar las oportunidades para la subversión.

En algunas realizaciones SVR, el sistema de ordenador central 200 es responsable de generar y distribuir el código SVID o HVID como parte de una solicitud SVID. El código puede adoptar una de muchas formas diferentes, lo que requiere diversos tipos de operaciones de codificación o de decodificación diferentes con el fin de realizar la autenticación. Por ejemplo, un código puede ser simplemente un código hash de un tipo conocido calculado sobre un SVID o un HVID. Como se sabe bien, los códigos hash se generan habitualmente como códigos de longitud fija relativamente cortos, que resultan de una operación numérica aplicada a un SVID introducido. Aunque estos códigos no son habitualmente únicos para todos los posibles códigos SVID, se apreciará que las posibilidades de una denominada colisión de hash pueden hacerse lo suficientemente bajas, con el fin de confirmar a un destinatario que un SVID es auténtico. En tales casos, un generador de códigos 430 de una OVMTU que recibe una solicitud SVID puede aplicar el mismo algoritmo de codificación hash a un SVID que el sistema de ordenador central, y comparar el resultado con el código hash recibido con el fin de realizar la autenticación (donde una coincidencia indica la autenticación y una falta de coincidencia indica la posibilidad de una solicitud SVID introducida maliciosamente). En tales casos simples, una CodKey 423, como tal, puede no ser necesaria, aunque el algoritmo de generación de códigos hash, o al menos un elemento del mismo, puede almacenarse en la memoria no volátil, de una manera que permite que se actualice de vez en cuando, por ejemplo, a través de la interfaz de gestión 435.

En un método alternativo de autenticación, el generador de códigos 430 puede disponerse para realizar una operación de hash criptográfica, por ejemplo, el empleo de una clave de encriptación precompartida (almacenada como CodKey 423) para generar un código hash criptográfico. La misma clave y el mismo algoritmo se emplearían por el sistema de ordenador central y el destinatario para generar el código hash del SVID, con el fin de facilitar la

15

25

35

45

55

65 E11799261

31-07-2015

comparación y la autenticación. Una vez más, una coincidencia proporcionaría la autenticación y una falta de coincidencia indicaría una intención potencialmente maliciosa. En otro método más, el código puede ser una versión codificada del SVID, que puede decodificarse para revelar el SVID original. En tal caso, el generador de códigos 430 puede realizar la operación de decodificación, con el fin de que el SVID codificado pueda decodificarse y compararse con el SVID recibido y no codificado.

En un método adicional, el código SVID puede ser una firma del SVID, que se genera criptográficamente por el sistema de ordenador central usando una clave secreta de un par de claves criptográficas. Cada OVMTU puede tener entonces la clave pública (almacenada como la CodKey 423) del par y ser capaz de autenticar el certificado de una manera conocida.

En general, se conocen bien las técnicas de autenticación de datos y los expertos en la materia serían capaces de aplicar las técnicas mencionadas anteriormente, y otras técnicas, para realizar una autenticación satisfactoria, si fuera necesario.

El diagrama de flujo de las figuras 6a y 6b ejemplifica el funcionamiento de un sistema de acuerdo con una realización de la presente invención, en la que los vehículos son automóviles y los SVID son VIN.

En una primera etapa [bloque 600] se introduce un nuevo SVID en el sistema de ordenador central 200, que genera [bloque 602] una solicitud SVID 500 y comunica [bloque 604] la solicitud al punto o los puntos de inicio 210. En esta realización, la solicitud SVID incluye un código hash criptográfico, que se genera por el sistema de ordenador central

200. Teniendo en cuenta solo un punto de inicio 210 para los presentes fines (aunque, como se ha explicado, puede haber cualquier número de uno a muchos), este recibe y almacena la solicitud SVID [bloque 606]. A continuación, el procesador 305 lee periódicamente (por ejemplo, cada 0,1 segundos) la memoria SVID 322 y propaga la solicitud SVID 608 por medio de una señal óptica 250. A continuación, el procesador 305 comprueba [bloque 610] el tiempo de finalización 525 de la solicitud y, si el tiempo de finalización asociado 525 ha vencido o expirado, el procesador borra [bloque 612] la solicitud SVID de la memoria 322. A continuación, el proceso vuelve al bloque 608 para procesar y propagar todas las solicitudes SVID nuevas y restantes.

En un escenario práctico, se apreciará que es probable que haya múltiples solicitudes SVID activas (es decir, solicitudes SVID que se han recibido y no han vencido). En este caso, los puntos de inicio propagarían todas las solicitudes SVR activas en secuencia.

A continuación, se describirá el funcionamiento de una OVMTU ejemplar 400 con referencia a la figura 6b. Cada nueva solicitud SVID 500 comunicada por una fuente se recibe y se almacena [bloque 614] en la memoria de solicitudes SVID 421. Una nueva solicitud SVID 500 puede recibirse desde un punto de inicio o desde otra OVMTU. La nueva solicitud SVID 500 se autentica [bloque 616] usando el generador de códigos 430 y una clave asociada, que se almacena en la memoria CodKey 423, para realizar una operación de hash criptográfica sobre el SVID recibido 510 y comparar el resultado con el código hash recibido 515. Si el SVID recibido no es auténtico, la solicitud SVID asociada se borra de la memoria [bloque 618] y el proceso vuelve al bloque 614 para esperar la siguiente solicitud SVID nueva. Si el SVID es auténtico, entonces el SVID 510 se compara [bloque 620] por el comparador 406 con la HVID, que se almacena en la memoria HVID 422 de la OVMTU destinataria. Si no hay coincidencia [bloque 622], entonces el proceso vuelve al bloque 614 para esperar la siguiente solicitud SVID nueva. Si, por otro lado, el SVID y el HVID coinciden, la OVMTU genera una respuesta 550, que se comunica [bloque 626] en una señal óptica 265, que se envía a y es de esperar que se reciba por la fuente (o bien el punto de inicio o la otra OVMTU). Finalmente, el proceso vuelve al bloque 614 para esperar la siguiente solicitud SVID nueva. Si la fuente no recibe la respuesta (por ejemplo, puede estar fuera de alcance en el momento en el que se genera y se transmite la respuesta), entonces la detección del vehículo robado puede no producirse hasta que otra OVMTU comunica el SVID al vehículo robado. En otras realizaciones, pueden adoptarse otras acciones opcionales para aumentar las probabilidades de detección del vehículo robado, como se describirá a continuación.

En una operación paralela, la OVMTU lee periódicamente (por ejemplo, cada 0,1 segundos) las solicitudes SVID 500 de la memoria de solicitudes SVID 421 y las propaga [bloque 628] en una señal óptica 260 para que se reciban por cualquier OVMTU cercana (o punto de inicio que sea capaz de recibir señales, así como de transmitirlas) que sea capaz de recibir las solicitudes. Como parte de esta etapa, de acuerdo con la presente realización, si el motor del vehículo no está en marcha, el procesador determina para cada solicitud SVID si el valor de propagación respectivo 520 se establece en SÍ o en NO, y solo propaga las solicitudes SVR que tienen un valor SÍ. En cualquier caso, a continuación, la OVMTU determina entonces si se recibe 630 una respuesta 265. Si [bloque 630] hay una respuesta 265 (que un destinatario de la solicitud SVID es el vehículo robado), entonces [bloque 634] el SVID devuelto 560 se autentica como se ha explicado anteriormente contra el código SVID devuelto 565. Si se autentica la respuesta, entonces el procesador 405 hace que el indicador 445 emita una Notificación SVID [bloque 636]; de lo contrario se ignora la respuesta. A continuación, y si no hay respuesta, el procesador 405 comprueba, usando el reloj de tiempo real 440, si la solicitud SVID ha vencido en comparación con el tiempo de finalización 525. Si ha vencido, entonces la solicitud SVID se borra de la memoria SVID [bloque 640]. Tanto si la solicitud SVID ha vencido como si no, después de un retraso [bloque 632] de, por ejemplo, 0,1 segundos, el proceso vuelve al bloque 628 con el fin de leer y propagar la o las solicitudes SVID (o al menos alguna de las restantes).

E11799261

31-07-2015

Se apreciará que hay muchas variantes en el proceso y los sistemas descritos anteriormente, que se mantienen dentro del alcance de la presente invención.

5 De acuerdo con las realizaciones de la presente invención, los sistemas que se han descrito anteriormente, o variantes de los mismos, pueden emplearse para realizar otras operaciones, tales como la retirada del vehículo (VR). En algunas realizaciones, los sistemas respectivos se disponen para realizar solo la retirada del vehículo y no la SVR. Sin embargo, de acuerdo con una realización que va a describirse, se emplean el mismo sistema y los mismos componentes que se han descrito anteriormente para realizar las operaciones de retirada del vehículo

10 además de las operaciones SVR.

A continuación, se describirá el funcionamiento de una OVMTU ejemplar en el procesamiento de una solicitud de retirada de vehículo con referencia al diagrama de flujo de la figura 7, en el que el almacén de memoria SVID 421 se usa además como un almacén de memoria VRID.

15 En el diagrama de la figura 5c se ilustra una solicitud VRID ejemplar 570. La solicitud VR 570 se asemeja a la solicitud 500 ilustrada en la figura 5a, excepto que una designación de solicitud 575 indica "VR" en lugar de "SVR". La solicitud 570 incluye: una identidad de vehículo objetivo 580 (en este caso un VRID); un código VRID 585, para la autenticación; un valor de propagación 590; y un valor de tiempo de finalización 595.

20 Para los fines de una VR, la identidad de vehículo objetivo puede emitirse en términos de una clase de vehículo definida, por ejemplo, por la marca, el modelo y el año del coche. De esta manera, pueden retirarse todos los vehículos de un determinado lote. Como alternativa, el identificador de vehículo objetivo puede emitirse a un vehículo específico, definido por ejemplo por un VIN. Por lo tanto, de acuerdo con las realizaciones de la invención,

25 un HVID almacenado por unas OVMTU puede incluir alguno o todos los datos de identificación del vehículo asociado (por ejemplo, VIN, marca, modelo, año, color, tamaño del motor, etc.) para facilitar la identificación de grupos de uno o más vehículos por cualquier medio de identificación adecuado. De acuerdo con la presente realización VR, cada OVMTU maneja los mensajes VR de acuerdo con la lógica básica, que adopta la forma:

30 Para cada mensaje VR recibido por una OVMTU:

Si un vehículo objetivo identificado en el mensaje recibido coincide con el vehículo en el que está montada la OVMTU destinataria, entonces indicar los detalles VR al conductor;

35 Propagar el mensaje.

En mayor detalle, de acuerdo con la figura 7, una OVMTU recibe y almacena [bloque 700] una nueva solicitud VR 570 desde otra OVMTU o desde un punto de inicio. La nueva solicitud VR 570 se autentica [bloque 701], usando el generador de códigos 430 y una clave asociada, que se almacena en la memoria CodKey 423, para realizar una

40 operación de hash criptográfica sobre el VRID recibido 580 y comparar el resultado con el código hash recibido 585. Si el VRID recibido no es auténtico, la solicitud VR asociada 570 se borra de la memoria [bloque 702] y el proceso vuelve al bloque 700 para esperar la siguiente solicitud VR nueva. Si el VRID es auténtico, el VRID 580 se compara [bloque 703] por el comparador 406 con el HVID, que se almacena en la memoria HVID 422 de la OVMTU destinataria. Si no hay coincidencia [bloque 704], entonces el proceso vuelve al bloque 700 para esperar la siguiente

45 solicitud VR nueva. Si, por el contrario, el VRID y el HVID coinciden, la OVMTU hace que el indicador 445 indique [bloque 705] al conductor del vehículo portador que el vehículo portador debe llevarse a un centro de servicio. Esto está en contraste con una coincidencia de solicitud SVID, que no indica nada al conductor del vehículo portador (que es habitualmente un ladrón de coches), con el fin de no alertar al conductor de que el sistema está realizando operaciones SVR.

50 En una operación paralela, la OVMTU lee periódicamente (por ejemplo, cada 0,1 segundos) las solicitudes VRID de la memoria de solicitudes VRID 421 y las propaga [bloque 708] en una señal óptica 709 para que se reciban por cualquier OVMTU cercana capaz de recibir las solicitudes. Al igual que antes, si el motor del vehículo no está en marcha, entonces solo se propagan las solicitudes VR que tienen un valor de propagación SÍ. A continuación [bloque

55 710], el procesador 405 comprueba, usando el reloj de tiempo real 440, si la solicitud VRID ha vencido en comparación con el tiempo de finalización 590. Si ha vencido, entonces la solicitud VRID se borra de la memoria VRID [bloque 712]. A continuación, tanto si la solicitud SVID ha vencido como si no, después de un retraso [bloque 714] de, por ejemplo, 0,1 segundos, el proceso vuelve al bloque 708 con el fin de propagar la o las solicitudes SVID (o al menos las restantes).

60 Por supuesto, aunque no se ilustra (solo para facilitar la explicación y la simplicidad de los dibujos y la descripción), los dos procesos representados en las figuras 6b y 7 se realizarían, habitualmente, como un proceso combinado en las realizaciones en las que el mismo sistema realiza tanto la recuperación de vehículos robados como la retirada de vehículos.

65

10

15

20

25

30

35

40

45

50

55

60

65 E11799261

31-07-2015

En la figura 8a se ilustra un tercer tipo de mensaje de solicitud ejemplar y en la figura 8b se ilustra un mensaje de respuesta asociado. Los mensajes de solicitud y de respuesta se refieren a una consulta de estado, por ejemplo, para determinar si una OVMTU identificada (por ejemplo, como se ilustra en la figura 4) está funcionando adecuadamente. El mensaje de solicitud 800 tiene una designación de mensaje de "SOLICITUD DE ESTADO" 805, de manera que una OVMTU destinataria sepa que el mensaje es una solicitud de estado; un identificador de vehículo objetivo 810; un código identificador de vehículo objetivo 815; un valor de propagación 820; y un tiempo de finalización 825. El mensaje de respuesta 850 incluye una designación de "RESPUESTA DE ESTADO" 855, de manera que una OVMTU destinataria sepa que el mensaje es una respuesta a una consulta de estado; una CARGA ÚTIL DE RESPUESTA 860, que contiene el estado de la OVMTU que responde; un identificador de vehículo 865; y un código identificador de vehículo 870. Los códigos 815 y 870, el valor de propagación 820 y el tiempo de finalización 825 se usan como ya se ha descrito anteriormente.

De acuerdo con una realización de la invención relativa a una consulta de estado, un mensaje de solicitud 800 se origina por un sistema de ordenador central y se propaga, a través de al menos un punto de inicio, a una pluralidad de vehículos y, a continuación, de vehículo a vehículo (en general, como se ha descrito anteriormente). El mensaje de solicitud, como en una realización SVR, puede incluir un identificador de vehículo objetivo que identifica un solo vehículo, por ejemplo usando un VIN. Como alternativa, el mensaje de solicitud, como en una realización VR, puede incluir un identificador de vehículo objetivo que identifica una clase de vehículo, por ejemplo designando la marca, el modelo y el año. Como alternativa, o adicionalmente, el identificador de vehículo objetivo puede identificar una OVMTU (o bien individualmente o como una categoría, definida de una manera adecuada, por ejemplo mediante el número de serie, modelo o antigüedad de la OVMTU). Por el contrario, el mensaje de respuesta 850 identifica el vehículo o la OVMTU real que está respondiendo, con el fin de que pueda identificarse el estado contra un vehículo

o una VMTU específicos.

Cuando una OVMTU destinataria, que tiene un HVID que coincide con el identificador de vehículo objetivo 810, recibe el mensaje de solicitud de estado, se acciona una rutina de diagnóstico 426 de la OVMTU y proporciona datos de estado para incluirse en la carga útil 860 de una respuesta 850. Los datos de estado pueden significar simplemente que la OVMTU está operativa. Como alternativa, la rutina de diagnósticos 426 puede hacer que la OVMTU realice una auto-comprobación. Por ejemplo, la OVMTU puede hacer que el LED 417 transmita una ráfaga de radiación óptica que se refleje, al menos una pequeña parte de la misma, fuera de la parte interior del cristal que cubre un grupo de faro en el que está montado el LED 417 (o fuera de la parte interior de un parabrisas) y se detecte por el fotodetector 412. La cantidad de radiación óptica que se detecta puede medirse, por ejemplo, usando una disposición de conversor A-D simple, y la medición puede formar al menos una parte de la carga útil 860. Si se realiza periódicamente la misma medición (por ejemplo, en respuesta a solicitudes de estado semanales o mensuales), un cambio en la cantidad de radiación detectada (por ejemplo, el cambio puede ser una cantidad reducida de radiación detectada) puede indicar que o bien el LED 417 o el fotodetector 412 se está deteriorando y requiere atención. Esto puede dar lugar a que se emita una solicitud de retirada de vehículo del vehículo. Por supuesto, si no se detecta una radiación reflejada, entonces esto puede indicar que ha fallado la disposición de transmisor y puede generarse inmediatamente una notificación al conductor. Muchas otras formas de comprobar el estado serán evidentes para los expertos en la materia.

Después de generar el mensaje de respuesta de estado 850, la OVMTU almacena la respuesta en la memoria SVID/VRID 421 y, a continuación, propaga periódicamente el mensaje, junto con cualquier otro mensaje SVID y/o VRID que deba propagarse, a cualquier OVMTU o punto de inicio de destino que sea capaz de recibir tales mensajes. De esta manera, se propagará finalmente un mensaje de respuesta 850 de vuelta a un punto de inicio 210, que puede recibir el mensaje a través de la disposición de fotodiodo 312 y receptor óptico 310. A continuación, el punto de inicio 210 puede devolver el mensaje de estado 850 al sistema de ordenador central, por ejemplo, a través de la red 205.

En general, de acuerdo con las realizaciones de la invención, la propagación de mensajes puede ser unidireccional o bidireccional y puede iniciarse en un punto de inicio o por un vehículo y/o una VMTU. Por ejemplo, una solicitud SVID o una solicitud VR se inician habitualmente en un punto de inicio con el objetivo de propagarse al mayor número de vehículos que sea posible, sin la necesidad de devolver una respuesta a un punto de inicio. Estos son ejemplos de propagación unidireccional. Como alternativa, una consulta de estado puede ser unidireccional o bidireccional. Por ejemplo, un punto de inicio puede emitir una consulta de estado a uno o más vehículos, propagándose la consulta potencialmente a través de muchos otros vehículos al vehículo o los vehículos objetivo. Al recibir la solicitud de estado, el o cada vehículo objetivo puede generar una respuesta, que se propaga potencialmente a través de muchos otros vehículos a un punto de inicio (aunque no necesariamente el mismo punto de inicio). Este es un ejemplo de una consulta de estado bidireccional. Si se genera un mensaje de estado por un vehículo en respuesta a una condición de vehículo detectado surgiría, por ejemplo, un mensaje de estado unidireccional. En tal caso, se devolvería el mensaje a un punto de inicio, potencialmente a través de muchos otros vehículos.

Se apreciará que puede habilitarse una OVMTU y unos sistemas asociados para realizar una cualquiera o más operaciones, incluyendo (pero sin limitarse a) la monitorización de la SVR, la VR y el estado.

15

25

35

45

55

65 E11799261

31-07-2015

En las realizaciones de la invención, puede aplicarse una prioridad a diferentes solicitudes recibidas (o mensajes), en las que la prioridad puede ordenar, por ejemplo, qué solicitudes se propagan en primer lugar o qué solicitudes se propagan con mayor frecuencia. Por ejemplo, una solicitud SVR puede tener prioridad sobre una solicitud VR, y la solicitud SVR puede propagarse más a menudo que la solicitud VR. La prioridad puede establecerse por el sistema de ordenador central asignando e integrando, por ejemplo, un valor de prioridad de 1-5 en un mensaje de solicitud (donde 1 significa la prioridad más alta y 5 significa la prioridad más baja). A continuación, las OVMTU pueden adaptarse para actuar de acuerdo con la prioridad. Además, o como alternativa, puede disponerse una OVMTU para identificar y tratar diferentes solicitudes de una manera diferente, de acuerdo con un orden de prioridad predeterminado.

Las realizaciones de monitorización de estado pueden, además, emplearse para informar sobre el estado de un vehículo. Por ejemplo, en las realizaciones en las que una OVMTU está conectada a una CAN de un vehículo a motor, la OVMTU tiene acceso, potencialmente, a una gran cantidad de información sobre el rendimiento y los diagnósticos del vehículo. La OVMTU puede entonces controlarse para presentar elementos de esta información de vuelta a un ordenador central, de acuerdo con las realizaciones de la presente invención. En algunas realizaciones, la información puede presentarse en respuesta a las solicitudes de estado asociadas. En otras realizaciones, la OVMTU puede disponerse para leer y presentar la información de vuelta al sistema de ordenador central de manera pro-activa y sin necesidad de una solicitud. La información puede entonces presentarse de vuelta periódicamente (por ejemplo, cada semana o cada mes) o como resultado de sucesos desencadenantes (por ejemplo, el sobrecalentamiento o el consumo de gasolina degradada, o simplemente de manera periódica). Otra información que puede presentarse de vuelta se refiere al comportamiento del conductor, tal como el exceso de velocidad o un frenazo brusco. Dicha información puede ser útil para ajustar las primas de seguros o similares. Otro ejemplo de cuándo puede ser útil un mensaje proactivo iniciado por una OVMTU es en una situación de peligro, por ejemplo, cuando un conductor o pasajero que es víctima de un secuestro, puede activar (en secreto) un botón de pánico, para comenzar la propagación mediante la OVMTU de un mensaje de alarma, que puede detectarse por otras OVMTU.

Hasta el momento, las realizaciones de la presente invención que se han descrito emplean comunicaciones ópticas para, por ejemplo, iniciar, propagar y responder a los mensajes. Una ventaja del uso de las comunicaciones ópticas es que los componentes y los sistemas respectivos son relativamente baratos, por ejemplo, en comparación con los componentes y los sistemas de comunicaciones de radio. Esto significa que los sistemas basados en óptica pueden llegar a generalizarse más, debido a que más vehículos y más personas (tales como los guardias de tráfico) pueden estar provistos de una OVMTU con un coste relativamente bajo. Además, especialmente en relación con la SVR, una respuesta SVR que indica que se ha detectado un vehículo robado (es decir, un SVID coincide con un HVID), que se transmite, por ejemplo, usando comunicaciones ópticas de línea de visión "directas" (es decir, de punto a punto, sin una repetición de intervención u otra ayuda), proporciona un alto grado de confianza en que el vehículo robado respectivo está en las proximidades de la OVMTU destinataria. En este sentido, "en las proximidades de" un vehículo significa habitualmente que otro vehículo (o punto de inicio) está en la línea de visión óptica del primer vehículo. En una autopista o en una carretera tranquila y relativamente recta, una línea de visión puede extenderse hasta 50 metros o más, pero es probable que sea, con fines de comunicación prácticos y fiables, de aproximadamente 5-20 metros.

Si, con respecto a la SVR, se han usado, en cambio, comunicaciones de larga distancia (por ejemplo, superiores a 100 metros y/o empleando un transceptor de intervención, como mediante el uso de la tecnología de radio celular), la recepción de una respuesta SVID no proporcionaría una indicación precisa de la localización del vehículo robado, a menos que se proporcionara además una funcionalidad adicional, tal como una funcionalidad de GPS para proporcionar la información de localización precisa. Dicha funcionalidad adicional aumentaría el coste y disminuiría el coste-beneficio de un sistema de este tipo. Sin embargo, más en general, las realizaciones de la presente invención emplean otros tipos de comunicaciones inalámbricas, tales como las comunicaciones de radio de punto a punto directas. Con respecto a la monitorización de la VR y del estado, por ejemplo, puede ser ventajoso un alcance mayor y no limitarse a una línea de visión óptica de alcance relativamente corto, ya que la localización de un destinatario no es tan importante como la capacidad de un destinatario para propagar el mensaje. Algunas realizaciones de la invención emplean comunicaciones de radio directas de alcance relativamente corto, tales como, por ejemplo, las comunicaciones basadas en normas Bluetooth o Wi-Fi, o algún otro tipo de normas inalámbricas sencillas de punto a punto de corto alcance. En cualquier caso, el nivel de potencia empleado para las realizaciones de radio puede controlarse de manera que la cobertura de distancia se limite a la cobertura en las proximidades de un vehículo. Por ejemplo, el nivel de potencia puede limitarse de manera que la cobertura de distancia en un espacio libre sea de aproximadamente 100 metros, 50 metros, 20 metros, o incluso menos. Por ejemplo, en una zona edificada la cobertura se limitaría de manera natural, y estaría delimitada por los edificios a ambos lados de una carretera. De esta manera, una realización de radio directa todavía puede proporcionar información de proximidad significativa acerca de la localización del vehículo robado. Otras realizaciones de la invención emplean otras comunicaciones, tales como (y sin limitarse a) las comunicaciones de ultrasonidos o de microondas. En algunas realizaciones, pueden emplearse diferentes potencias de señal por el mismo equipo para diferentes tipos de solicitud. Por ejemplo, una solicitud SVR, que necesita información de localización relativamente precisa, puede emplear una señalización de potencia relativamente baja (distancia más corta). Por el contrario, una solicitud VR, para la que la localización es menos importante que la capacidad de recibir y propagar mensajes, puede emplear una señalización de potencia relativamente más alta (distancia más larga). Sin embargo, de acuerdo con las

E11799261

31-07-2015

realizaciones de la presente invención, se espera que las distancias cubiertas sean mucho más cortas que las que pueden lograrse usando comunicaciones de radio conocidas del tipo empleado, por ejemplo, en la telefonía móvil celular.

5 En cualquier caso, la naturaleza de un identificador de vehículo objetivo cambiará en función de la naturaleza del vehículo en o sobre el que está montado la OVMTU (u otra forma alternativa de unidad de transceptor). Por ejemplo, si el vehículo es un tren o un barco, el identificador puede ser un número de registro único. Si el vehículo es un ser humano, el identificador puede ser un nombre y/o el número de la seguridad social. Si el vehículo es un animal, el identificador puede ser un número de licencia de animales o similares.

10 Las realizaciones anteriores deben entenderse como ejemplos ilustrativos de la invención. Se prevén otras realizaciones de la invención. Debe entenderse que cualquier característica descrita en relación con una cualquiera de las realizaciones puede usarse sola o, si el contexto lo permite, en combinación con otras características descritas, y también puede usarse en combinación con una o más características de cualquier otra de las

15 realizaciones, o cualquier combinación de cualquier otra de las realizaciones. Además, también pueden emplearse equivalentes y modificaciones no descritos anteriormente sin alejarse del alcance de la invención, que se define en las reivindicaciones adjuntas.

Claims (9)

1. REIVINDICACIONES

   1. Un aparato de comunicaciones (400) para un vehículo, comprendiendo el aparato (400):

   5 un primer almacén (422) para almacenar un identificador de vehículo portador, para identificar un vehículo portador sobre o en el que está funcionando el aparato (400); un receptor (410) para recibir mensajes directamente desde fuentes de mensajes en las proximidades del vehículo portador; un segundo almacén (421) para almacenar al menos un identificador de vehículo objetivo;

   10 un transmisor (415) para transmitir mensajes directamente a destinos de mensajes en las proximidades del vehículo portador; y estando el aparato (400) adaptado para:

   recibir desde una fuente de mensajes un mensaje que contiene un identificador de vehículo objetivo y

   15 almacenar el identificador de vehículo objetivo en el segundo almacén (421); comparar un identificador de vehículo objetivo recibido con el identificador de vehículo portador con el fin de establecer si el vehículo portador es el vehículo objetivo respectivo; y en respuesta a establecer que el vehículo portador no es el vehículo objetivo respectivo, propagar el mensaje recibido a uno o más destinos de mensajes;

   20 caracterizado por que el aparato (400) está adaptado para:

   recibir desde un destino de mensajes una respuesta a un mensaje propagado y determinar, basándose en la respuesta, que el destino del mensaje respectivo es un vehículo objetivo.

   25 2. Aparato (400) de acuerdo con la reivindicación 1, que está dispuesto para propagar un mensaje que incluye un identificador de vehículo objetivo recibido solo si el identificador de vehículo objetivo recibido coincide con el identificador de vehículo portador.
2. 3. Aparato (400) de acuerdo con la reivindicación 1, que está dispuesto para propagar un mensaje que incluye un 30 identificador de vehículo objetivo recibido solo si no coinciden los identificadores.
3. 4. Aparato (400) de acuerdo con una cualquiera de las reivindicaciones anteriores, que está dispuesto, si coinciden los identificadores, para transmitir un mensaje que indica que el identificador de vehículo objetivo recibido coincide con el identificador de vehículo portador.

   35
4. 5. Aparato (400) de acuerdo con la reivindicación 4, que está dispuesto para determinar que el identificador de vehículo objetivo recibido coincide con el identificador de vehículo portador y, tras determinar una coincidencia, transmitir un mensaje a la fuente de mensajes para confirmar la coincidencia.

   40 6. Aparato (400) de acuerdo con una cualquiera de las reivindicaciones anteriores, en el que un identificador de vehículo comprende una parte de identificador y una parte de autenticación que se usa para autenticar la parte de identificador, y en el que el aparato (400) está dispuesto para autenticar un identificador de vehículo al recibir el mismo usando la parte de autenticación.

   45 7. Aparato (400) de acuerdo con una cualquiera de las reivindicaciones anteriores, que está adaptado para recibir un mensaje que indica que la fuente de mensajes respectiva es un vehículo que tiene un identificador de vehículo portador que coincide con un identificador de vehículo objetivo recibido anteriormente por la misma fuente de mensajes.

   50 8. Aparato (400) de acuerdo con la reivindicación 7, que comprende unos medios indicadores (445) y que está dispuesto para hacer que los medios indicadores (445) indiquen, a un operador del vehículo portador, que una fuente de mensajes es un vehículo objetivo.

5. 9. Aparato (400) de acuerdo con una cualquiera de las reivindicaciones anteriores, en el que el segundo almacén de 55 memoria (422) es para almacenar más de un identificador de vehículo objetivo.
6. 10. Aparato (400) de acuerdo con la reivindicación 9, que está dispuesto para leer del segundo almacén de memoria (422), y transmitir, múltiples identificadores de vehículo objetivo.

   60 11. Aparato (400) de acuerdo con una cualquiera de las reivindicaciones anteriores, en el que un mensaje recibido incluye un tiempo de expiración, y en el que el mensaje asociado no se propaga si ha transcurrido el tiempo de expiración.
7. 12. Aparato (400) de acuerdo con una cualquiera de las reivindicaciones anteriores, en el que un identificador de 65 vehículo objetivo identifica un vehículo robado.

   15
8. 13. Un sistema de comunicaciones, que comprende:

   un centro de control (200) para emitir mensajes, conteniendo cada uno al menos un identificador de vehículo objetivo;

   5 una pluralidad de aparatos (400) de acuerdo con una cualquiera de las reivindicaciones 1 a 12; y al menos un punto de inicio (210), teniendo el o cada punto de inicio unos medios para recibir mensajes desde el centro de control (200) y unos medios para propagar periódicamente mensajes que contienen al menos un identificador de vehículo objetivo a dichos aparatos (400).

   10 14. Un sistema de comunicación de acuerdo con la reivindicación 13, en el que el al menos un punto de inicio (210) comprende:

   una interfaz (330) para recibir mensajes desde el centro de control; y un transmisor inalámbrico (315) para propagar mensajes; y 15 un receptor inalámbrico (310) para recibir los mensajes propagados por uno o más de los aparatos (400).
9. 15. Un método de propagación de un mensaje a una pluralidad de vehículos que comprende:

   recibir un mensaje desde una fuente de mensajes, conteniendo el mensaje un identificador de vehículo objetivo;

   20 comparar un identificador de vehículo objetivo recibido con un identificador de vehículo portador de un vehículo destinatario con el fin de establecer si el vehículo destinatario es el vehículo objetivo respectivo; y en respuesta a establecer que el vehículo portador no es el vehículo objetivo, propagar el mensaje recibido a uno

   o más destinos de mensajes; caracterizado por

   25 recibir desde un destino de mensajes una respuesta a un mensaje propagado y determinar, basándose en la respuesta, que el destino de mensajes respectivo es un vehículo objetivo.

   16