ES2569936T3 - Plataforma de arquitectura de datos de mapas para sistemas avanzados de ayuda al conductor - Google Patents
Plataforma de arquitectura de datos de mapas para sistemas avanzados de ayuda al conductor Download PDFInfo
- Publication number
- ES2569936T3 ES2569936T3 ES08019227.1T ES08019227T ES2569936T3 ES 2569936 T3 ES2569936 T3 ES 2569936T3 ES 08019227 T ES08019227 T ES 08019227T ES 2569936 T3 ES2569936 T3 ES 2569936T3
- Authority
- ES
- Spain
- Prior art keywords
- data
- electronic horizon
- segment
- vehicle
- driver assistance
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 claims description 104
- 238000004590 computer program Methods 0.000 claims description 2
- 230000006870 function Effects 0.000 description 96
- 230000008569 process Effects 0.000 description 83
- 238000004364 calculation method Methods 0.000 description 55
- 230000007704 transition Effects 0.000 description 15
- 238000010586 diagram Methods 0.000 description 13
- 230000015572 biosynthetic process Effects 0.000 description 12
- 230000007246 mechanism Effects 0.000 description 11
- 230000003044 adaptive effect Effects 0.000 description 9
- 230000008901 benefit Effects 0.000 description 8
- 230000001419 dependent effect Effects 0.000 description 8
- 238000007726 management method Methods 0.000 description 6
- 238000012800 visualization Methods 0.000 description 6
- 238000012545 processing Methods 0.000 description 5
- 238000003860 storage Methods 0.000 description 5
- 238000012360 testing method Methods 0.000 description 5
- 230000008859 change Effects 0.000 description 4
- 230000000717 retained effect Effects 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000007613 environmental effect Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 230000004807 localization Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 230000002265 prevention Effects 0.000 description 2
- 102100034112 Alkyldihydroxyacetonephosphate synthase, peroxisomal Human genes 0.000 description 1
- 101000799143 Homo sapiens Alkyldihydroxyacetonephosphate synthase, peroxisomal Proteins 0.000 description 1
- 230000009418 agronomic effect Effects 0.000 description 1
- 238000000848 angular dependent Auger electron spectroscopy Methods 0.000 description 1
- 239000004020 conductor Substances 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 238000013506 data mapping Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000001788 irregular Effects 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 239000000047 product Substances 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
- G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
- G01C21/38—Electronic maps specially adapted for navigation; Updating thereof
- G01C21/3885—Transmission of map data to client devices; Reception of map data by client devices
- G01C21/3896—Transmission of map data from central databases
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/16—Anti-collision systems
- G08G1/166—Anti-collision systems for active traffic, e.g. moving vehicles, pedestrians, bikes
Landscapes
- Engineering & Computer Science (AREA)
- Radar, Positioning & Navigation (AREA)
- Remote Sensing (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Automation & Control Theory (AREA)
- Navigation (AREA)
- Traffic Control Systems (AREA)
- Instructional Devices (AREA)
Abstract
Un metodo de obtencion de datos de horizonte electronico (181) para su uso por aplicaciones (200) que usan los datos de horizonte electronico para proporcionar ayuda a un conductor de un vehiculo mientras se conduce, caracterizado por que el metodo comprende: recibir mensajes que incluyen una identificacion (182) de datos de horizonte electronico (181), en donde los datos de horizonte electronico (181) incluyen datos que representan todos los recorridos a lo largo de segmentos de carretera por los que puede marchar el vehiculo de motor desde la posicion actual del vehiculo hasta una extension asociada con un umbral; y obtener los datos de horizonte electronico (181) usando la identificacion (182) cuando una aplicacion de ayuda al conductor (200) esta preparada para recibir nuevos datos de horizonte electronico (181).
Description
5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Plataforma de arquitectura de datos de mapas para sistemas avanzados de ayuda al conductor Referencia a solicitud relacionada
La presente solicitud esta relacionada con la solicitud en tramitacion junto con la presente titulada "METHOD AND SYSTEM FOR PROVIDING AN ELECTRONIC HORIZON IN AN ADVANCED DRIVER ASSISTANCE SYSTEM ARCHITECTURE' (Metodo y sistema para proporcionar un horizonte electronico en una arquitectura de sistema avanzado de ayuda al conductor) presentada en la misma fecha que la presente, expediente del mandatario n.° N0029US, cuya descripcion completa se incorpora en el presente documento por referencia.
Antecedentes de la invencion
La presente invencion se refiere a una plataforma de arquitectura de datos de mapas que se puede usar en vehiculos de carretera, como automoviles, camiones, buses, y asi sucesivamente, y la presente invencion se refiere en concreto a una plataforma de arquitectura de datos de mapas que soporta sistemas avanzados de ayuda al conductor provistos en vehiculos de carretera.
Los sistemas avanzados de ayuda al conductor ("ADAS", Advanced driver assistance system) se han desarrollado con la intencion de mejorar la seguridad, la comodidad, la eficiencia y la satisfaccion general de la conduccion. Los ejemplos de sistemas avanzados de ayuda al conductor incluyen orientacion de faros adaptativa, control de crucero adaptativo y control de cambio adaptativo. La orientacion de faros adaptativa ajusta los faros del vehiculo, es decir, la anchura, el angulo rotacional, el angulo de elevacion y el brillo, sobre la base de la curvatura de la carretera delante del vehiculo, la inclinacion, el cambio de elevacion y otros factores. El control de crucero adaptativo mantiene y/o reanuda una velocidad establecida o la distancia segura de seguimiento con respecto a otros vehiculos a menor velocidad que la establecida sobre la base de datos acerca de la velocidad del vehiculo, los vehiculos proximos y otros obstaculos, tipo de carretera recorrida (autovia frente a carretera local), la curvatura de la carretera, la inclinacion, la elevacion y otros factores. El control de cambio adaptativo ajusta la desmultiplicacion y el cambio de transmisiones automaticas sobre la base de datos de sensor acerca de la velocidad del vehiculo, la velocidad del motor, la curvatura de la carretera, la inclinacion, la elevacion y otros factores. Hay otros sistemas avanzados de ayuda al conductor ademas de estos.
Estos sistemas avanzados de ayuda al conductor usan varios mecanismos sensores en el vehiculo para determinar el estado actual del vehiculo y el estado actual de la carretera en la parte delantera del vehiculo. Estos mecanismos sensores pueden incluir sensores de radar y de orientacion por vision, como camaras. Aunque los sensores de radar y de orientacion por vision son componentes importantes de los sistemas avanzados de ayuda al conductor, estos componentes tienen limitaciones. El alcance y/o la exactitud de los sensores de radar o de orientacion por vision pueden quedar afectados por determinadas condiciones ambientales, tales como niebla, lluvia intensa o nieve, o carreteras cubiertas de nieve. Ademas, los sistemas de radar y de orientacion por vision no detectan fiablemente algunos atributos utiles de la carretera, tales como limitaciones de velocidad, senales de trafico, cruces elevados, etc. Ademas, los sensores de radar y de orientacion por vision no pueden "ver" a la vuelta de esquinas u otros obstaculos y, por lo tanto, pueden estar limitados en tales circunstancias.
Una forma de afrontar las limitaciones de los sistemas de radar y de orientacion por vision es usar datos de mapas digitales como un componente adicional en sistemas avanzados de ayuda al conductor. Los datos de mapas digitales se pueden usar en sistemas avanzados de ayuda al conductor para proporcionar information acerca de la carretera que hay delante. Los datos de mapas digitales no quedan afectados por condiciones ambientales, tales como niebla, lluvia o nieve. Ademas, los datos de mapas digitales pueden proporcionar informacion util que no se puede proporcionar fiablemente por sistemas de orientacion por vision, tales como limites de velocidad, restricciones de trafico y de carril, etc. Ademas, los datos de mapas digitales se pueden usar para determinar la carretera por delante del vehiculo incluso a la vuelta de esquinas o mas alla de obstaculos. Por consiguiente, los datos de mapas digitales pueden ser una adicion util en sistemas avanzados de ayuda al conductor.
Aunque los datos de mapas digitales se pueden usar como un componente adicional en sistemas avanzados de ayuda al conductor, quedan problemas por afrontar antes de que los datos de mapas digitales se puedan usar de forma generalizada para tales fines. Por ejemplo, existe una necesidad de manejar eficientemente la cantidad relativamente grande de datos de mapas digitales requeridos para sistemas avanzados de ayuda al conductor. Ademas, diferentes sistemas avanzados de ayuda al conductor requieren diferentes tipos y cantidades de datos de mapas digitales y, por lo tanto, existe una necesidad de proporcionar los datos de mapas digitales que necesitan los varios sistemas avanzados de ayuda al conductor.
El documento US 5.751.576 describe una visualization animada de mapas que transporta informacion a partir de cualquiera de los mapas basicos o de aplicacion de un sistema agronomico controlado por ordenador, asi como caracteristicas geologicas o ambientales, estructuras fisicas, senales de sensor, informacion de estatus y otros datos, a una representation bi- o tridimensional que se proyecta usando una visualizacion de cabeza erguida (HUD,
5
10
15
20
25
30
35
40
45
50
55
60
65
heads-up display) superpuesta sobre el entorno y el terreno en el mundo real visibles para el operario a traves del parabrisas del vehiculo de aplicacion de producto.
El documento US 5.576.964 describe un metodo y sistema para relacionar un sensor pasivo con un entorno geografico, en el que el sensor pasivo detecta una imagen del entorno geografico.
Resumen de la invencion
De acuerdo con un primer aspecto de la invencion, se facilita un metodo de acuerdo con la reivindicacion 1.
De acuerdo con un segundo aspecto de la invencion, se facilita un sistema de ayuda al conductor de acuerdo con la reivindicacion 14.
De acuerdo con un tercer aspecto de la invencion, se facilita un programa informatico de acuerdo con la reivindicacion 15.
Para abordar estos y otros objetivos, unas realizaciones de la presente invencion comprenden una arquitectura de datos para un vehiculo de motor para proporcionar datos continuamente actualizados acerca de carreteras por las que puede marchar el vehiculo de motor desde una posicion actual del vehiculo de motor cuando el vehiculo de motor marcha a lo largo de las carreteras. La arquitectura de datos incorpora una base de datos de mapas que contiene datos acerca de carreteras en una region geografica y un programa de localizacion de vehiculos que usa datos procedentes de sensores para proporcionar una salida que indica una posicion actual a lo largo de un segmento de carretera representado por datos en la base de datos de mapas. La arquitectura de datos tambien incluye un programa de horizonte de datos que usa la salida del programa de localizacion de vehiculos y datos procedentes de la base de datos de mapas para determinar uno o mas recorridos que el vehiculo de motor puede recorrer al pasar de la posicion actual del vehiculo hasta una extension asociada con un umbral. Los datos que representan los recorridos determinados por el programa de horizonte de datos se guardan en un deposito de datos del que los sistemas de ayuda al conductor pueden obtener los datos. Los datos que representan los recorridos incluyen datos acerca de la geometria de la carretera, atributos de la carretera y objetos a lo largo de cada recorrido.
Breve descripcion de los dibujos
La figura 1 es un diagrama de bloques funcionales de la arquitectura de datos de mapas de sistema avanzado de ayuda al conductor 100.
La figura 2 es un diagrama de bloques del componente sensor de la arquitectura de datos de mapas de sistema avanzado de ayuda al conductor 100 representada en la figura 1.
Las figuras 3A y 3B muestran los tipos de datos contenidos en el componente de base de datos de mapas de la arquitectura de datos de mapas de sistemas avanzados de ayuda al conductor.
La figura 4 es un diagrama de bloques de los componentes de las herramientas de software representadas en la figura 1.
La figura 5 es un diagrama de bloques de los componentes del motor de datos representado en la figura 1.
La figura 6 es una ilustracion de una porcion de una red de carreteras con una ilustracion de un horizonte electronico superpuesto sobre la misma.
La figura 7 es una ilustracion de identificadores de segmentos usados al describir recorridos en un horizonte electronico.
La figura 8 es una ilustracion de descriptores de recorrido en un horizonte electronico.
La figura 9 es una ilustracion de un descriptor de recorrido para un giro en U.
La figura 10 es un diagrama de bloques que representa componentes del deposito de datos en la figura 1.
La figura 11 es un diagrama de bloques que representa componentes usados para el almacenamiento de datos de horizonte electronico en el deposito de datos en la figura 10.
La figura 12 es un diagrama de bloques que representa componentes adicionales del deposito de datos en la figura 10.
La figura 13 es un diagrama de bloques que representa componentes del distribuidor de datos en la figura 1.
La figura 14 es un diagrama de bloques que representa componentes de la escucha de datos en la figura 1. La
figura 15 es un diagrama de bloques que representa una realizacion de una aplicacion de ayuda al conductor
asociada con multiples escuchas.
La figura 16 es un diagrama de bloques que representa como una aplicacion de ayuda al conductor usa varias funciones para obtener datos de horizonte electronico.
La figura 17 es un diagrama de bloques que representa una realizacion alternativa de la arquitectura de datos de mapas de sistemas de ayuda al conductor.
Descripcion detallada de la descripcion de las realizaciones actualmente preferidas
I. Terminologia
5
10
15
20
25
30
35
40
45
50
55
60
65
En la presente memoria descriptiva se usa la terminologia y los conceptos siguientes (no se ha previsto que la terminologia y definiciones dadas en el presente documento sean limitativas. Se pueden usar otra terminologia y definiciones para expresar conceptos similares o identicos).
(1) Segmentos y nodos. Un "segmento" (tambien denominado un "segmento de carretera") es un tramo de una carretera. Cada segmento tiene dos puntos de extremo. Un "nodo" es uno de los puntos de extremo de un segmento. Un segmento tiene un nodo izquierdo y un nodo derecho. El nodo izquierdo es el nodo con el menor valor de longitud. Si los valores de longitud de ambos nodos son los mismos, el nodo izquierdo es el nodo con la menor latitud. De acuerdo con una realizacion, los segmentos y los nodos se representan por datos en una base de datos de mapas usada por la arquitectura de datos de mapas de sistema de ayuda al conductor.
(2) Puntos de forma. "Puntos de forma" son puntos intermedios en un segmento entre sus puntos de extremo. Los puntos de forma se usan para varios fines. Los puntos de forma se pueden usar para modelar la curvatura de un segmento de carretera. Los puntos de forma tambien se pueden usar para modelar pasos elevados y pasos subterraneos. Por ejemplo, cuando un segmento de carretera cruza otro segmento de carretera a una altura diferente (por ejemplo, un paso elevado o paso subterraneo), un punto de forma esta asociado con cada segmento de carretera en la posicion del cruce y un atributo de cada punto de forma indica una altitud relativa o una altitud absoluta del segmento de carretera asociado en dicha posicion. De acuerdo con una realizacion, los puntos de forma se representan en la base de datos de mapas usada por la arquitectura de datos de mapas de sistema de ayuda al conductor.
(3) Sentido de marcha. El "sentido de marcha" en un segmento (el sentido permisible de marcha de un vehiculo en un segmento) se expresa en terminos de "avance del nodo izquierdo al nodo derecho" o "del nodo derecho al nodo izquierdo".
(4) Nodo de entrada y nodo de salida. El nodo encontrado en primer lugar en el contexto de marcha en un segmento se denomina el "nodo de entrada", el otro nodo se denomina el "nodo de salida".
(5) Punto. Un "punto" se refiere a un nodo o un punto de forma de un segmento. Un punto tiene una posicion geografica (por ejemplo, latitud, longitud y altitud) asociada con el mismo.
(6) Posicion de segmento. Una "posicion de segmento" es cualquier lugar en un segmento. Mientras que el termino "punto" solamente se refiere a nodos y puntos de forma de segmentos, una posicion de segmento incluye todas las posiciones en un segmento incluyendo los nodos, todos los puntos de forma y todos los puntos logicos (es decir, posiciones) entre los nodos y los puntos de forma.
(7) Orientaciones y rumbos de segmento. La "orientacion" de un segmento en un nodo se refiere a la direccion del segmento en dicho nodo. La direccion se mide desde el nodo hacia el interior del segmento. Por ejemplo, la orientacion en el nodo izquierdo es el rumbo de un vehiculo en el nodo izquierdo cuando el vehiculo avanza del nodo izquierdo al derecho. El rumbo de un segmento en el nodo izquierdo o derecho se calcula a partir del valor de orientacion en el nodo apropiado mas 180 grados.
(8) Curvatura. La "curvatura" describe como una porcion de un segmento se curva en un punto o una posicion de segmento. Hay formas diferentes de calcular y de representar la curvatura. Una forma de representar la curvatura en un punto de un segmento es por el radio de un circulo que corresponde a la curva del segmento en dicho punto. De acuerdo con una realizacion, la curvatura se representa por datos en una base de datos de mapas usada por la arquitectura de datos de mapas de sistema de ayuda al conductor. De acuerdo con otra realizacion, la curvatura se puede calcular usando datos que indican las coordenadas de puntos sucesivos a lo largo de un segmento de carretera.
(9) Recorrido. Un "recorrido" es una secuencia de uno o mas segmentos de carretera (o porciones de los mismos) por encima de los cuales un vehiculo podria marchar desde una posicion actual.
(10) Objetos de la carretera. Un "objeto de la carretera" se refiere a un objeto situado en o a lo largo de una carretera, tal como una senal o un paso de peatones.
(11) Geometria de la carretera. "Geometria de la carretera" se refiere a la forma y curvatura de una carretera. La forma de la carretera se define por las coordenadas geograficas de puntos a lo largo de un segmento de carretera ("curvatura" se describe por separado en lo sucesivo).
II. Arquitectura de datos de mapas de sistemas avanzados de ayuda al conductor
A. Vision general
La figura 1 es un diagrama de bloques funcionales de la arquitectura de datos de mapas de sistema avanzado de ayuda al conductor 100. La arquitectura de datos de mapas de sistema avanzado de ayuda al conductor 100 es una combinacion de componentes de software y hardware instalados en un vehiculo de motor 108. La arquitectura de datos de mapas de sistema avanzado de ayuda al conductor 100 proporciona acceso a datos relacionados con mapas para su uso por aplicaciones de sistema avanzado de conduccion 200. La arquitectura de datos de mapas de sistema avanzado de ayuda al conductor 100 incluye los componentes siguientes.
(1) Sensores 120. Los sensores 120 proporcionan salidas que se usan mediante programacion en la arquitectura de datos de mapas de sistema avanzado de ayuda al conductor 100 para determinar la posicion del vehiculo 108 en la red de carreteras y para proporcionar otra informacion, tal como velocidad y rumbo del vehiculo (ademas de estos sensores 120, las aplicaciones de sistema avanzado de conduccion 200 pueden usar las salidas procedentes de otros tipos de sensores 122. Estos otros tipos de sensores 122 pueden incluir tipos de sensores
5
10
15
20
25
30
35
40
45
50
55
60
65
de sistema por vision o radar).
(2) Una base de datos de mapas 130. La base de datos de mapas 130 incluye informacion acerca de caracteristicas geograficas, tal como carreteras y puntos de interes, en la zona geografica en la que avanza el vehiculo 108 en el que esta instalada la arquitectura de datos de mapas de sistema avanzado de ayuda al conductor 100.
(3) Programa de horizonte de datos 110. La arquitectura de datos de mapas de sistema de ayuda al conductor 100 incluye un programa de horizonte de datos 110. El programa de horizonte de datos 110 incluye la programacion que usa la base de datos de mapas 130 y entradas procedentes de los sensores 120 para proporcionar datos relacionados con mapas a los sistemas avanzados de ayuda al conductor 200.
(4) Componentes de herramientas de software 150. En la presente realizacion, los componentes de herramientas de software 150 son una parte del programa de horizonte de datos 110. Los componentes de herramientas de software 150 incluyen programacion para acceder a la base de datos de mapas 130 y programas de herramientas de software para realizar ciertas funciones requeridas con los datos de mapas obtenidos de la base de datos de mapas 130.
(5) Un programa de supervision 160. El programa de supervision 160 es un componente de software de la arquitectura de datos de mapas de sistema avanzado de ayuda al conductor 100 que permite supervisar la ejecucion del programa de horizonte de datos 110.
(6) Un programa de configuracion 165. El programa de configuracion 165 es un componente de software de la arquitectura de datos de mapas de sistema avanzado de ayuda al conductor 100 que permite la configuracion del programa de horizonte de datos 110.
(7) Un motor de datos 170. El motor de datos 170 es un componente del programa de horizonte de datos 110. El motor de datos 170 determina y obtiene de la base de datos de mapas 130 los datos relevantes acerca de la carretera que esta delante (o detras) del vehiculo.
(8) Un deposito de datos 180. El deposito de datos 180 es un componente del programa de horizonte de datos 110. El deposito de datos 180 contiene los ultimos datos relevantes acerca de la carretera que esta delante (o detras) del vehiculo segun es determinado por el motor de datos 170.
(9) Un distribuidor de datos 190. El distribuidor de datos 190 es un componente del programa de horizonte de datos 110. El distribuidor de datos 190 proporciona una notificacion acerca de que nuevos datos acerca de la carretera que esta delante (o detras) del vehiculo se han almacenado en el deposito de datos 180.
(10) Una o mas aplicaciones avanzadas de ayuda al conductor 200. Estas aplicaciones 200 usan los datos relacionados con mapas proporcionados por el programa de horizonte de datos 110. Estas aplicaciones 200 pueden incluir orientacion de faros adaptativa, control de crucero adaptativo, detection de obstaculos, prevention de obstaculos, prevencion de choques, control de cambio adaptativo y otros.
(11) Una o mas escuchas de datos 300. Una escucha de datos 300 es un componente de software usado para obtener datos del programa de horizonte de datos 110. Una escucha de datos 300 recibe las notificaciones del distribuidor de datos 190 y obtiene datos del deposito de datos 180. Una escucha de datos 300 se puede implementar como parte de cada aplicacion de ayuda al conductor 200 o una escucha de datos se puede implementar como un componente de software autonomo.
Cada uno de los componentes anteriores de la arquitectura de datos de mapas de sistema avanzado de ayuda al conductor 100 se describe con mas detalle en lo sucesivo.
B. Los sensores de position 120
Con referencia a las figuras 1 y 2, el programa de horizonte de datos 110 recibe las salidas procedentes de los sensores de posicion 120. De acuerdo con una realizacion, estos sensores 120 incluyen un sistema GPS 120(1), un giroscopio 120(2), un sensor de velocidad de vehiculo 120(3) y un sensor de marcha hacia delante/hacia atras del vehiculo 120(4). Tambien se puede incluir otros tipos de sensores 120(5). Por ejemplo, los sensores pueden incluir sensores de navegacion inercial.
En una realizacion, el sistema GPS 120(1) es un sistema fabricado por Trimble y el giroscopio 120(2) es una unidad fabricada por Murata. Tambien se puede usar equipo de otros fabricantes. Datos que indican la velocidad del vehiculo y/o la direction hacia delante/hacia atras del vehiculo se pueden obtener de sensores o componentes previstos para otros fines en otro lugar en el vehiculo 108. En una realizacion, las senales del giroscopio y de la velocidad son recogidas cada 100 milisegundos. El GPS y el sensor de direccion hacia delante/hacia atras del vehiculo se proporcionan a una frecuencia de una vez por segundo. En otras realizaciones, las salidas procedentes
5
10
15
20
25
30
35
40
45
50
55
60
65
de los sensores se pueden proporcionar a frecuencias diferentes.
C. La base o bases de datos 130
(1) Organizacion de bases de datos de mapas
Con referencia de nuevo a la figura 1, la base de datos de mapas 130 incluye informacion acerca de carreteras, intersecciones, puntos de interes y, posiblemente, otras caracteristicas geograficas en la region geografica en la que avanza el vehiculo 108 en el que se ha instalado la arquitectura de datos de mapas 100 del sistema avanzado de ayuda a conductor. En la realizacion representada en la figura 1, la base de datos de mapas 130 esta formada por una o mas bases de datos de componentes. Especificamente, la base de datos de mapas 130 incluye una base de datos primaria 130(1) y una base de datos suplementaria 130(2).
La base de datos de mapas primaria 130(1) puede ser similar o identica a una base de datos usada en sistemas de navegacion en vehiculo. De acuerdo con la presente realizacion, la base de datos de mapas primaria 130(1) soporta funciones relacionadas con la navegacion, incluyendo posicion del vehiculo, calculo de ruta, guia de ruta y visualizacion de mapas. La base de datos primaria 130(1) tambien proporciona soporte para una porcion de las funciones de sistema avanzado de ayuda al conductor. En la presente realizacion, la base de datos primaria 130(1) tambien proporciona una porcion de las lecturas de datos proporcionadas a las aplicaciones de ayuda al conductor 200, como se describe en lo sucesivo.
En una realizacion, la base de datos de mapas primaria 130(1) es una base de datos en el formato de almacenamiento fisico SDAL™ desarrollado y publicado por Navigation Technologies Corporation de Rosemont, Illinois. En una realizacion, la base de datos primaria 130(1) esta en la version 1.7 del formato de almacenamiento fisico SDAL™ Una realizacion adecuada de una base de datos de mapas primaria se describe en la Patente de Estados Unidos con n.° 5.968.109, cuya descripcion completa se incorpora en el presente documento por referencia (la materia objeto novedosa descrita en el presente documento no se limita a formato especifico alguno de base de datos).
La base de datos suplementaria 130(2) tambien contiene datos acerca de carreteras e intersecciones en la region geografica. Sin embargo, la base de datos suplementaria 130(2) incluye datos que no se proporcionan necesariamente en la base de datos de mapas primaria 130(1). La base de datos de mapas suplementaria 130(2) puede incluir datos de mayor calidad (es decir, mas exactos) que los datos que estan contenidos en la base de datos primaria 130(1). Por ejemplo, con respecto a la geometria de la carretera, los datos en la base de datos suplementaria 130(2) pueden ser mas exactos con respecto a la longitud, la latitud y/o la altitud. Ademas, las posiciones de inicio y de fin de tuneles se pueden especificar mas exactamente en la base de datos suplementaria 130(2) que en la base de datos primaria 130(1). Ademas, los datos en la base de datos suplementaria 130(2) pueden ser mas exactos con respecto a informacion derivada, tal como la curvatura.
La base de datos suplementaria 130(2) tambien puede incluir mas tipos de datos (por ejemplo, mas tipos de atributos) que los datos contenidos en la base de datos primaria 130(1). Por ejemplo, la base de datos suplementaria 130(2) puede incluir datos acerca de objetos de la carretera, tal como senales y pasos de peatones incluyendo sus posiciones a lo largo del segmento de carretera, tipo de objeto de senal y texto de senal. La base de datos suplementaria 130(2) tambien puede incluir datos que indican si una carretera esta bordeada por arboles, etc.
De acuerdo con una realizacion, la base de datos primaria 130(1) y la base de datos suplementaria 130(2) incluyen datos que representan todas las carreteras e intersecciones en la region cubierta. De acuerdo con esta alternativa, los datos en la base de datos suplementaria 130(2) suplementan la representacion de cada segmento de carretera que tambien se representa en la base de datos primaria 130(1).
De acuerdo con una realizacion alternativa, la base de datos suplementaria 130(2) representa menos carreteras que la base de datos primaria 130(1). En la presente realizacion alternativa, mientras que la base de datos primaria 130(1) puede incluir datos que representan todas las carreteras e intersecciones en la region cubierta, la base de datos suplementaria 130(2) incluye datos que representan solamente una porcion de todas las carreteras en la region cubierta. Por ejemplo la base de datos suplementaria 130(2) puede incluir solamente las carreteras con los mayores volumenes de trafico (por ejemplo, autopistas, vias publicas principales). Los segmentos de carretera representados por la base de datos suplementaria 130(2) tambien pueden estar representados por datos en la base de datos primaria 130(1).
De acuerdo con otra realizacion alternativa, en lugar de usar dos bases de datos separadas, la arquitectura de datos de mapas de sistema de ayuda al conductor 100 usa una sola base de datos. En la presente realizacion de una sola base de datos los datos de menor exactitud contenidos en la base de datos primaria 130(1) se combinan con los datos de mayor exactitud contenidos en la base de datos suplementaria 130(2). En la realizacion de una sola base de datos, todas las carreteras pueden estar representadas por datos que tienen la norma de alta exactitud de la base de datos suplementaria. Alternativamente, en la realizacion de una sola base de datos, solamente algunas de las carreteras representadas se representan por los datos de exactitud superior y el resto de las carreteras se
5
10
15
20
25
30
35
40
45
50
55
60
65
representan por unos datos de exactitud inferior.
En la realizacion de una sola base de datos que contiene datos de exactitud superior y datos de exactitud inferior, se ha previsto unos medios para indicar si un segmento de carretera representado se representa por datos de exactitud superior o por datos de exactitud inferior. Un atributo de datos (por ejemplo, un bit de datos de alta exactitud) puede estar asociado con cada entidad de datos que representa un segmento de carretera para indicar si los datos que representan los segmentos son conformes a una norma de alta exactitud especificada. En otras alternativas, las carreteras pueden estar representadas por datos de diferentes niveles de exactitud. Cada uno de estos diferentes niveles de exactitud puede ser indicado por una designacion de nivel de exactitud (por ejemplo, 0-7).
(2) Integration de datos de diferentes niveles de exactitud
Como se ha indicado anteriormente, en algunas realizaciones de la base de datos de mapas 130 algunas carreteras se representan por datos que tienen un nivel de exactitud suficientemente alto para su uso por aplicaciones del sistema avanzado de ayuda al conductor y otras carreteras se representan por datos que tienen un nivel de exactitud que no es suficientemente alto para su uso por aplicaciones del sistema avanzado de ayuda al conductor. En estas realizaciones, se ha previsto unos medios por los que unos datos de exactitud superior se integran con unos datos de exactitud inferior (o desconocida). Para realizar esta integration, en la base de datos de mapas 130 se incluyen datos para representar segmentos de transition. Un "segmento de transition" es un segmento que esta conectado en un extremo a otro segmento representado por datos que tienen un alto nivel de exactitud y en su otro extremo a otro segmento representado por datos que tienen un nivel de exactitud inferior (o desconocido). En un segmento de transicion, las coordenadas del nodo conectado al segmento representado por datos que tienen un alto nivel de exactitud se almacenan al nivel de exactitud superior. Sin embargo, las coordenadas del nodo conectado al segmento representado por datos de un nivel de exactitud inferior (o desconocido) se almacenan al nivel de exactitud inferior. Por lo tanto, de acuerdo con la presente realizacion, hay tres clases de segmentos: (1) segmentos representados por datos de alta exactitud, (2) segmentos representados por datos de exactitud inferior (o desconocida), y (3) segmentos de transicion que conectan (1) y (2).
(3) Tipos de atributos de datos incluidos en la base de datos de mapas
Como se ha indicado anteriormente, la base de datos de mapas 130 incluye information acerca de carreteras e intersecciones. De acuerdo con una realizacion, la base de datos de mapas 130 representa cada segmento de carretera con una entidad de datos de segmento separada. Cada nodo en el punto de extremo de un segmento de carretera se representa por una entidad de datos de nodo separada. La base de datos de mapas 130 incluye atributos (de datos) asociados con las entidades de datos de segmento y atributos (de datos) asociados con las entidades de datos de nodo. Los atributos de nodo se refieren a una propiedad o caracteristica de los nodos de extremo de un segmento. Los atributos de segmento se refieren a una propiedad o caracteristica asociada con el segmento en conjunto o con un punto (position) especifico a lo largo del segmento.
Los ejemplos de atributos de nodo incluyen los siguientes:
(1) El numero de segmentos que se extienden desde el nodo actual. Este recuento incluye el segmento actual (es decir, el segmento de entrada). Todos los segmentos son contados, tanto si son accesibles como si no.
(2) El numero de posibles giros que el vehiculo puede realizar en el modo especificado (no se incluyen en este recuento los giros en U).
Ademas de los anteriores, varios otros atributos pueden estar asociados con nodos, incluyendo coordenadas geograficas, altitud, nombre, identification (por ejemplo, por numero de ID) de segmentos de carretera conectados con los mismos, limitaciones de giro, etc.
Como se ha indicado anteriormente, los atributos de segmento pueden estar relacionados con una propiedad o caracteristica asociada con un punto (posicion) especifico a lo largo del segmento. Estos atributos de un segmento se denominan "atributos dependientes de punto". Este tipo de atributo de segmento describe una propiedad relacionada con un "punto" en un segmento (donde un "punto" se refiere o bien a uno de los dos nodos de extremo de un segmento o bien a un punto de forma en el segmento).
Se usa un atributo dependiente de punto para representar una propiedad del segmento de carretera en el punto, como pendiente, peralte, etc.
En una realizacion de la presente invention, algunos atributos dependientes de punto estan asociados con un sentido de marcha a lo largo de un segmento. Un atributo de "senal de stop" es un ejemplo de un atributo dependiente de punto asociado con un sentido de marcha. Un atributo de "senal de stop" indica la presencia de una senal de stop en un punto a lo largo de un segmento asociado con un sentido especifico de recorrido (por ejemplo, puede no haber una senal de stop al avanzar en el sentido contrario a lo largo del segmento).
5
10
15
20
25
30
35
40
45
50
55
60
65
Un atributo de "senal de stop" tambien es un ejemplo de un atributo booleano. Un atributo booleano es un atributo dependiente de punto que es verdadero o falso en el punto espedfico. Una "senal de stop" se modela usando un atributo booleano porque una senal de stop esta presente o no en un punto espedfico.
Otro tipo de atributo dependiente de punto es un atributo de transition booleano. Los atributos de transition booleanos describen propiedades o caracteristicas que se aplican a cada position en un segmento, no solamente a los puntos de un segmento. Un atributo de transicion booleano es un atributo que cambia de valor solamente en puntos de segmento, si es que cambia (los terminos "antes" y "despues" se refieren a un vehiculo que se aproxima a un punto y supera dicho punto). Por ejemplo, para cualquier posicion en un segmento (no solamente cualquier punto), dado un sentido de marcha, el "paso" de vehiculos esta permitido o no. Con el fin de modelar si esta permitido el "paso" de vehiculos, se supone que alguna senal relacionada (tal como "inicio de zona de no paso" y "fin de zona de no paso") esta situada en un punto de un segmento. Si es este el caso, se aplica uno de los siguientes a cualquier punto del segmento.
Transicion verdadero -> verdadero: Esta permitido el paso antes del punto y despues del punto.
Transicion verdadero -> falso: Esta permitido el paso antes del punto, pero no despues del punto.
Transicion falso -> verdadero: No esta permitido el paso antes del punto, pero si despues del punto.
Transicion falso -> falso: No esta permitido el paso antes del punto y tampoco esta permitido
despues del punto.
Otro tipo de atributo dependiente de punto es un atributo de transicion de rango de numeros enteros. Un atributo de transicion de rango de numeros enteros es un atributo que representa rangos de numeros enteros o intervalos de numeros enteros. Un atributo de rango de numeros enteros tiene un valor fijo entre cualesquiera dos puntos consecutivos de un segmento, pero puede cambiar su valor en cualquier punto a un intervalo diferente. Un valor se define antes de un punto y en el punto. Un ejemplo de cuando se usa un atributo de transicion de rango de numeros enteros es para "information de velocidad maxima". Un valor de rango de numeros enteros tal como {20 ... 29} significa que la velocidad legal maxima es entre 20 y 29 km/h. Un valor de rango de numeros enteros tal como {20 ... 20} significa que la velocidad legal maxima es exactamente 20 km/h. Tambien se pueden especificar valores para diferentes instantes del dia.
Algunos atributos de segmento pueden ser identicos para cada punto del segmento (por ejemplo, un nombre de carretera). Tales atributos pueden ser especificados una vez para todo el segmento.
La informacion de atributo dependiente de punto puede ser almacenada en formato SDAL™ o en otras tablas de base de datos.
Las figuras 3A y 3B muestran algunos de los tipos de datos incluidos en la base de datos de mapas 130. La columna de la tabla etiquetada "Fuente" en las figuras 3A y 3B indica si el elemento de datos se halla en la base de datos primaria 130(1), la base de datos suplementaria 130(2), o ambas.
(4) Curvatura
De acuerdo con una realization, entre los atributos de segmento hay un atributo que representa la curvatura. "Curvatura" es una propiedad de un punto a lo largo de una longitud de un segmento. La curvatura describe como una portion de un segmento se curva en dicho punto. En una realizacion de la presente invention, la curvatura se define para los puntos de un segmento (es decir, puntos de forma, nodos). Dos componentes describen la curvatura: un sentido de curvatura (curva a la izquierda, curva a la derecha y recta) y un radio de curvatura. No se define radio de curvatura alguno para el caso de una linea recta o casi recta (un segmento en el que el radio de curvatura supera un valor umbral configurable puede ser considerado como una linea recta).
Los datos de curvatura se pueden obtener de varias formas diferentes. Una forma de obtener datos de curvatura es medirla directamente usando equipo sensor (por ejemplo, un acelerometro) y almacenar la medicion como un atributo de datos asociado con un punto en la base de datos de mapas 130. Otra forma de obtener datos de curvatura es calcular la curvatura usando datos de posicion. Para una secuencia de tres puntos, la curvatura en el punto medio se puede determinar calculando el radio de un drculo cuya circunferencia incluye las posiciones de los tres puntos. Los datos de curvatura obtenidos por calculo usando datos de posicion se pueden almacenar en la base de datos de mapas 130. Alternativamente, la curvatura se puede calcular segun sea necesario por una funcion de software en el vehiculo. Tal funcion de software puede estar incluida entre las aplicaciones del sistema avanzado de ayuda al conductor 200 usando datos de posicion asociados con puntos almacenados en la base de datos de mapas 130. Alternativamente, una funcion de software que calcula la curvatura a partir de datos de posicion puede estar incluida en el programa de horizonte de datos 110.
D. Componentes de herramientas de software 150
Los componentes de herramientas de software 150 proporcionan la base sobre la que se construye el programa de horizonte de datos 110. En la realizacion representada en las figuras 1 y 4, los componentes de herramientas de
5
10
15
20
25
30
35
40
45
50
55
60
65
software 150 incluyen una capa de acceso de datos 150(1), aplicaciones de navegacion 150(2), y una estructura de objeto 150(3).
La capa de acceso de datos 150(1) permite acceder a la base de datos de mapas 130. En una realization, la capa de acceso de datos 150(1) es la libreria SDAL™ facilitada por Navigation Technologies Corporation de Rosemont, Illinois. La capa de acceso de datos 150(1) proporciona un conjunto de interfaces de programacion de aplicaciones (API, application programming interface) en forma de librerias de software para un acceso eficiente a los atributos de mapa en la base de datos primaria 130(1). Una realizacion de la capa de acceso de datos 150(1) se describe en la solicitud pendiente junto con la presente con n.° de serie 08/740.298, presentada el 25 de octubre de 1996, cuya description completa se incorpora en el presente documento por referencia.
Las aplicaciones de navegacion 150(2) realizan funciones similares a las usadas en sistemas de navegacion a bordo del vehiculo. De acuerdo con una realizacion, las aplicaciones de navegacion 150(2) estan dispuestas en forma de rutinas de librerias de software de API. Estas rutinas de librerias de software de API realizan operaciones usadas frecuentemente en aplicaciones relacionadas con datos de mapas. Entre las aplicaciones de navegacion 150(2) se incluyen position del vehiculo 150(2)(1), visualization de mapas 150(2)(2), calculo de ruta 150(2)(3), geocodificacion 150(2)(4), y guia de direction 150(2)(5). En una realizacion, las aplicaciones de navegacion 150(2) son el software NavTools™ facilitado por Navigation Technologies Corporation de Rosemont, Illinois. Se describen realizaciones de aplicaciones de navegacion para posicion del vehiculo, visualizacion de mapas, calculo de ruta y guia de direccion en las solicitudes pendientes junto con la presente con n.° de serie 09/276.377, 09/047.141, 09/047.698, 08/893.201, y 09/196.279, cuyas descripciones completas se incorporan en el presente documento por referencia.
La estructura de objeto 150(3) proporciona un contenedor orientada a objetos alrededor de la capa de acceso de datos 150(1) y las aplicaciones de navegacion 150(2). La estructura de objeto 150(3) simplifica el uso de la capa de acceso de datos 150(1) y las aplicaciones de navegacion 150(2). La estructura de objeto 150(3) tambien puede facilitar el desarrollo de aplicaciones en algunas plataformas (por ejemplo, un entorno de Microsoft Windows/NT).
XML en la arquitectura de datos del sistema avanzado de ayuda al conductor
En una realizacion, la arquitectura de datos de mapas de sistema avanzado de ayuda al conductor 100 usa XML (eXtensive Markup Language, lenguaje de marcacion extensible). Por ejemplo, se puede generar information de archivo de registro y de otro tipo en XML. Igualmente, parte de la informacion leida por la arquitectura de datos de mapas de sistema avanzado de ayuda al conductor 100 se puede codificar en XML. Una ventaja de tener un formato de archivo para multiples fines simplifica la manipulation y el procesamiento adicional de informacion de entrada y de salida. El uso de XML es ventajoso en un entorno de desarrollo y prueba.
En una realizacion se puede usar Internet Explorer version 5.0 (IE5) de Microsoft u otro programa que soporte XML como un formato nativo de archivo. IE5 tambien procesa XSL (archivos de estilo relacionado con XML). Esto permite presentar archivos XML de diferentes formas.
E. El motor de datos 170
(1) Vision general
Con referencia a las figuras 1 y 5, el programa de horizonte de datos 110 incluye un motor de datos 170. El motor de datos 170 es el componente del programa de horizonte de datos 110 que calcula un horizonte electronico (descrito con mas detalle en lo sucesivo). El motor de datos 170 proporciona una salida que incluye los datos que representan el horizonte electronico en un formato organizado. El motor de datos 170 proporciona esta salida de una forma ciclica.
(2) Entradas al motor de datos
Al realizar sus funciones, el motor de datos 170 usa datos que indican la posicion del vehiculo (incluyendo direccion y velocidad) como una entrada. Con referencia a la figura 5, el motor de datos 170 incluye un proceso de reception de datos 170(1) que realiza esta funcion. El proceso de recepcion de datos 170(1) recibe datos que indican la posicion del vehiculo a partir de la herramienta de localization de vehiculo 150(2)(1). Los datos que indican la posicion del vehiculo incluyen una identification del segmento de carretera en el que se encuentra el vehiculo, la posicion a lo largo del segmento de carretera identificado en el que se encuentra el vehiculo, y el sentido que sigue el vehiculo a lo largo del segmento de carretera. El segmento de carretera en el que se encuentra el vehiculo es determinado por la herramienta de localizacion de vehiculo 150(2)(1) usando datos procedentes de la base de datos de mapas 130.
La posicion a lo largo del segmento de carretera identificado se puede proporcionar en varias formas diferentes. Por ejemplo, la posicion del vehiculo a lo largo del segmento de carretera se puede proporcionar como una distancia desde un extremo (por ejemplo, n metros desde el punto de extremo izquierdo). En otra alternativa, si el segmento de carretera incluye puntos de forma situados entre sus puntos de extremo, la posicion del vehiculo a lo largo del
5
10
15
20
25
30
35
40
45
50
55
60
65
segmento de carretera puede ser indicada por el punto de forma al que el vehiculo esta mas proximo. Alternativamente, la posicion del vehnculo a lo largo del segmento de carretera identificado se puede identificar como el punto de forma que esta inmediatamente delante de la posicion del vehiculo. En otra alternativa, la posicion del vehiculo a lo largo de un segmento de carretera se puede proporcionar en porciones incrementales de la longitud del segmento de carretera (por ejemplo, n/256-avos a lo largo de un segmento de carretera).
Los datos que indican la direccion del vehiculo pueden ser suministrados al componente de recepcion de datos 170(1) del motor de datos 170 por la herramienta de localizacion de vehiculo 150(2)(1) indicando a que nodo del segmento se dirige el vehiculo. El componente de recepcion de datos 170(1) del motor de datos 170 tambien obtiene la velocidad del vehiculo (por ejemplo, de los sensores 120).
La herramienta de localizacion de vehiculo 150(2)(1) puede proporcionar una nueva salida que indica una nueva posicion del vehiculo a intervalos regulares. Estos intervalos pueden ser una vez por segundo, 10 veces por segundo, 100 veces por segundo, una vez cada 2 segundos, o cualquier otro periodo. Los intervalos tambien pueden ser intervalos irregulares o pueden ser intervalos basados en algun otro factor, tal como la distancia, o una combinacion de factores, tal como el tiempo y la distancia. De acuerdo con una realizacion de la presente invencion, el componente de recepcion de datos 170(1) recibe cada salida de la herramienta de localizacion de vehiculo 150(2)(1) que indica una nueva posicion del vehiculo.
La herramienta de localizacion de vehiculo 150(2)(1) puede determinar que el vehiculo 108 esta fuera de la carretera. El vehiculo 108 esta fuera de la carretera si la herramienta de localizacion de vehiculo 150(2)(1) no puede determinar una posicion del vehiculo a lo largo de un segmento de carretera representado en la base de datos de mapas 130. Esto puede tener lugar si el vehiculo esta realmente fuera de la carretera (por ejemplo, no en algun segmento de carretera, tal como en un aparcamiento, en el campo, o fuera de la region de cobertura de la base de datos de mapas 130). Alternativamente, la herramienta de localizacion de vehiculo 150(2)(1) puede determinar que el vehiculo esta fuera de la carretera si no se puede obtener information fiable del sensor. Si la herramienta de localizacion de vehiculo 150(2)(1) indica que el vehiculo esta fuera de la carretera, la informacion que indica este estado fuera de la carretera se suministra al proceso de recepcion de datos 170(1). La determination de un horizonte electronico requiere una posicion valida del vehiculo con el vehiculo colocado en una posicion especifica de un segmento especifico. Si el vehiculo esta fuera de la carretera, el motor de datos 170 no calcula un horizonte electronico.
(3) Calculo del horizonte electronico
El motor de datos 170 incluye un proceso de calculo de horizonte electronico 170(3). El proceso de calculo de horizonte electronico 170(3) determina que segmentos de carretera e intersecciones deberan ser representados en la salida del motor de datos 170. Estos segmentos e intersecciones representados en la salida del motor de datos 170 son los recorridos potenciales que el vehiculo puede seguir desde la posicion actual del vehiculo. La extension de cada uno de estos recorridos potenciales desde la posicion actual del vehiculo se determina por el proceso de calculo de horizonte electronico 170(3). El "horizonte electronico" se refiere a la coleccion de las carreteras e intersecciones que van desde la posicion actual del vehiculo a los destinos determinados por el proceso de calculo de horizonte electronico 170(3). Asi, el "horizonte electronico" representa la carretera delante (o posiblemente detras) del vehiculo. El horizonte electronico tambien es una representation de recorridos potenciales de movimiento del vehiculo desde la posicion actual del vehiculo. El "horizonte electronico" tambien se refiere a la coleccion de datos que representan las carreteras e intersecciones que van desde la posicion actual del vehiculo a dichos destinos, incluyendo los atributos de la carretera, objetos de la carretera y geometria de la carretera de los segmentos de carretera que forman el horizonte electronico.
Para realizar la funcion de determinar el horizonte electronico, el proceso de calculo de horizonte electronico 170(3) obtiene los datos que indican la posicion actual del vehiculo del proceso de recepcion de datos 170(1). Usando los datos que indican la posicion actual del vehiculo, el proceso de calculo de horizonte electronico 170(3) obtiene datos procedentes de la base de datos de mapas 130 que se refieren a todas las carreteras alrededor de la posicion actual del vehiculo. El motor de datos 170 incluye un proceso de componentes 170(2) que obtiene estos datos procedentes de la base de datos de mapas 130. Si la base de datos de mapas 130 incluye una base de datos primaria y una base de datos suplementaria, el proceso de componentes 170(2) combina los datos primarios y secundarios para su uso por el motor de datos.
Despues de obtener datos que se refieren a todos los segmentos de carretera alrededor de la posicion actual del vehiculo, el motor de datos 170 determina que segmentos de carretera representan el horizonte electronico. Esta etapa incluye determinar las extensiones (o limites) del horizonte electronico. Al determinar las extensiones del horizonte electronico, el proceso de calculo de horizonte electronico 170(3) permite que los recorridos potenciales que se extienden desde la posicion actual del vehiculo sean suficientemente grandes para que las aplicaciones de ayuda al conductor 200 (en la figura 1) que usan los datos enviados por el programa de horizonte de datos 110 esten provistas de todos los datos que estas puedan necesitar para realizar sus funciones, dada la velocidad y direccion del vehiculo asi como los requisitos especificos de cada una de las aplicaciones de ayuda al conductor 200. Por otra parte, el proceso de calculo de horizonte electronico 170(3) crea un horizonte electronico lo mas
5
10
15
20
25
30
35
40
45
50
55
60
65
pequeno posible con el fin de reducir los recursos computacionales requeridos para crearlo y tambien para reducir los recursos computacionales requeridos por las aplicaciones de ayuda al conductor 200 al usar los datos incluidos en el horizonte electronico.
Las extensiones del horizonte electronico se determinan usando uno o mas funciones de calculo de costos, como se explica con mas detalle en lo sucesivo. Brevemente, comenzando con el segmento en el que el vehiculo se encuentra actualmente, se evalua la posible inclusion en el horizonte electronico de cada segmento de cada recorrido delantero que parte de la posicion actual del vehiculo. El proceso de calculo de horizonte electronico 170(3) deja de evaluar segmentos a anadir a un recorrido desde la posicion actual del vehiculo cuando el recorrido tiene al menos un costo umbral minimo, si es posible. El proceso de calculo de horizonte electronico 170(3) deja de calcular un horizonte electronico cuando se determinan todos los segmentos incluidos en todos los recorridos de la posicion actual del vehiculo. Cuando el proceso de calculo de horizonte electronico 170(3) deja de calcular un horizonte electronico, se determinan las extensiones del horizonte electronico.
De acuerdo con una realizacion, el horizonte electronico se representa por un arbol del que salen como bifurcaciones los recorridos potenciales de movimiento desde la posicion actual del vehiculo. El proceso de calculo de horizonte electronico 170(3) forma este arbol al determinar que segmentos de carretera e intersecciones incluir en el horizonte electronico. El arbol que forma el horizonte electronico incluye componentes por los que cada punto a lo largo de cada recorrido se puede especificar y definir dentro del contexto de toda la estructura del arbol. De esta manera, la formacion del horizonte electronico se realiza de una manera consistente, fiable y reproducible. Esto proporciona caracteristicas, tales como un nivel de confianza, que pueden ser usadas por los sistemas avanzados de ayuda al conductor 200.
(4) Terminologia del horizonte electronico
Los componentes del horizonte electronico se organizan de modo que las aplicaciones de ayuda al conductor 200 puedan usar los datos que representan las carreteras situadas alrededor del vehiculo. Los componentes del horizonte electronico incluyen lo siguiente:
(a) Primer segmento. El segmento de carretera en el que se encuentra el vehiculo es el "primer segmento" del arbol de horizonte electronico.
(b) Nodo raiz. El nodo de entrada del primer segmento del horizonte electronico es el "nodo raiz" del arbol de horizonte electronico.
(c) Nodo interno. Un "nodo interno" de un horizonte electronico es un nodo al que estan unidos al menos dos segmentos del horizonte electronico.
(d) Segmentos de entrada y de salida. Cada nodo interno de un horizonte electronico tiene un "segmento de entrada", es decir, un segmento en el que el vehiculo se puede mover potencialmente hacia dicho nodo. Un nodo interno tambien tiene uno o mas "segmentos de salida", es decir, segmentos en los que un vehiculo se aleja potencialmente del nodo interno actual.
(e) Nodo hoja. Un "nodo hoja" es un nodo dentro de un horizonte electronico donde no se unen segmentos adicionales.
(f) Sub-arbol accesible. Los segmentos del horizonte electronico que son accesibles por recorridos legalmente permitidos del primer segmento del horizonte electronico forman el "sub-arbol accesible" del horizonte electronico.
(g) Horizonte electronico de recorrido simple. Un horizonte electronico se denomina un "horizonte electronico de recorrido simple" si el sub-arbol accesible del mismo consiste solamente en una lista lineal de segmentos.
(h) Horizonte electronico de segmento unico. Un horizonte electronico de recorrido simple se denomina un "horizonte electronico de segmento unico" si el sub-arbol accesible del horizonte electronico consiste solamente en un unico segmento.
(i) Segmento inaccesible. Un "segmento inaccesible" es un segmento que esta conectado a un nodo incluido en el horizonte electronico pero en el que no se puede entrar legalmente desde el nodo. Por ejemplo, el segmento puede ser una calle de sentido unico y el sentido de la limitacion de un sentido unico es tal que es ilegal conducir por el segmento procedente del nodo que es parte del horizonte electronico. Alternativamente, puede haber en efecto una prohibicion de giro que no permite que un vehiculo gire en el segmento procedente del nodo que es parte del horizonte electronico. Observese que un segmento particular puede ser inaccesible si el vehiculo se aproxima al segmento por medio de un nodo, pero accesible si el vehiculo se aproxima al segmento por medio de un nodo diferente. La formacion del horizonte electronico puede estar configurada (por ejemplo, a traves de la funcion de calculo de costos, como se describe en lo sucesivo) de modo que los segmentos inaccesibles se incluyan en un horizonte electronico o, alternativamente, la formacion del horizonte electronico puede estar configurada de modo que los segmentos inaccesibles queden excluidos de un horizonte electronico.
Ejemplo
La figura 6 ilustra un horizonte electronico superpuesto en una porcion de la red de carreteras. En la figura 6, el segmento inaccesible esta excluido del sub-arbol de horizonte electronico.
5
10
15
20
25
30
35
40
45
50
55
60
65
(5) Identificacion de componentes del horizonte electronico
El horizonte electronico incluye unos medios por los que cada uno de los recorridos que van desde la posicion actual del vehiculo a las extensiones del horizonte electronico se puede identificar de forma unica. Cada una de las partes componentes de un horizonte electronico se puede identificar usando identificadores de segmento, identificadores de recorrido, descriptores de segmento, descriptores de nodo y descriptores de punto.
(a) Identificadores de segmento. Un "identificador de segmento" identifica un segmento con un numero de indice con respecto a un nodo particular. El segmento de entrada de un nodo tiene un indice de 0. Los segmentos de salida de un nodo son indexados comenzando en 1. Todos los segmentos de salida de un nodo se marcan en el sentido de las agujas del reloj. El primer segmento (es decir, indice = 1) es el segmento que sigue al segmento de entrada en el sentido de las agujas del reloj. Es posible que no haya segmento de salida para un nodo particular (por ejemplo, un nodo hoja). La figura 7 ilustra la asignacion de identificadores de segmento en una interseccion (es decir, un nodo).
(b) Descriptores de recorrido. Un "descriptor de recorrido" describe un recorrido por una lista de los identificadores de segmento de dicho recorrido. Dado que cada recorrido incluye el primer segmento de un horizonte electronico, cada descriptor de recorrido empieza con 0. Cualquier segmento despues del primer segmento de horizonte electronico es identificado por su identificador de segmento con respecto a su nodo de entrada. La figura 8 representa un ejemplo de como se forman los descriptores de recorrido. La figura 8 representa el mismo horizonte electronico que el representado en la figura 6. Junto a cada segmento en el horizonte electronico esta su identificador de segmento definido con respecto al nodo de entrada al mismo. La figura 8 tambien incluye una tabla de descriptores de recorrido para cada uno de los recorridos en el horizonte electronico.
Observese que, en algunas circunstancias, a un segmento contenido en un horizonte electronico se puede entrar por mas de un recorrido. Si se puede entrar en un segmento por mas de un recorrido, el segmento se incluye en cada uno de los descriptores de recorrido. Asi, un segmento puede ser incluido mas de una vez en una descripcion de un horizonte electronico.
A veces hay que definir un recorrido no valido. Tal recorrido tiene un descriptor de recorrido de -1.
Los descriptores de recorrido tambien se pueden usar para describir recorridos que implican giros en U. La figura 9 representa un ejemplo de como un descriptor de recorrido se puede usar para describir un giro en U. En la figura 9, un vehiculo que avance desde una posicion actual del vehiculo al nodo A, despues al nodo B y posteriormente vuelva al nodo A, seguiria el recorrido 0.2.0. En cualquier recorrido, el segmento 0 es el segmento en el que el vehiculo avanza hacia un nodo. Por lo tanto, para describir un giro en U, se usa el indice de segmento 0 para indicar que el vehiculo sale del nodo en el mismo segmento en el que se ha movido hacia el nodo.
(c) Orden de recorridos. Todos los recorridos de un horizonte electronico definen un orden completo. Dado que el numero de recorridos es finito, hay un "primer recorrido" y un "segundo recorrido" de un horizonte electronico. Dados dos descriptores de recorrido, pi y p2, este orden se define como sigue. Se comparan repetidas veces los indices de segmento individuales de los dos descriptores de recorrido. En cada iteracion, se ejecutan las siguientes etapas:
En primer lugar, si los dos primeros indices de segmento individuales son identicos, se sigue comparando el par siguiente de indices de segmento. Por ejemplo, suponiendo dos descriptores de recorrido 0.4.3.1 y 0.4.2.2. El calculo de comparacion en este punto ha llegado al segundo indice de segmento ("4" en ambos casos).
Los dos indices de segmento individuales son diferentes. En este caso el descriptor de recorrido con el valor de indice de segmento mas pequeno se considera que es menor que el descriptor de recorrido con el mayor de los dos valores. Por ejemplo, suponganse dos descriptores de recorrido 0.2.3.1 y 0.2.4.2. La comparacion de los terceros indices de segmento "3" y "4" de ambos descriptores de recorrido da lugar a que el primer descriptor de recorrido sea declarado menor que el segundo descriptor de recorrido. La operacion de comparacion se detiene en este punto.
Se ha superado el numero de indices de segmento para ambos recorridos. Los dos descriptores de recorrido son identicos en este caso y se detiene el calculo de comparacion de recorrido. Un ejemplo seria dos descriptores de recorrido 0.1.2 y el calculo anterior ha comparado solamente el tercero de los descriptores de segmento ("2").
Se ha superado el numero de indices de segmento para el primer descriptor de recorrido, pero hay otro indice de segmento todavia disponible para el segundo descriptor de recorrido. En este caso, el primer descriptor de recorrido se considera que es menor que el segundo descriptor de recorrido y la operacion de comparacion de recorridos se detiene en este punto. Por ejemplo, suponganse los descriptores de recorrido 0.2.4 y 0.2.4.1.2, procediendo ahora la operacion de comparacion a comparar el cuarto indice de segmento de cada descriptor de recorrido, pero no existe un cuarto indice de segmento en el caso del primer descriptor de recorrido.
5
10
15
20
25
30
35
40
45
50
55
60
65
La prueba siguiente supone una situacion, contraria a la situacion anterior, de que el numero de indices de segmento para el segundo descriptor de recorrido supera el numero de descriptores de segmento para el primer descriptor de recorrido. En este caso, el primer descriptor de recorrido se considera que es mayor que el segundo descriptor de recorrido. La operacion de comparacion de recorridos se detiene en este punto.
(d) Descriptor de segmento. Un descriptor de segmento identifica de forma unica un segmento con respecto a un recorrido en el contexto de un horizonte electronico. Un segmento es identificado por el descriptor de recorrido del recorrido que tiene el segmento a identificar como su ultimo segmento. Por ejemplo, con referencia de nuevo a la figura 8, el segmento etiquetado A se puede identificar como 0.2.1.
(e) Descriptor de nodo. Un "descriptor de nodo" identifica de forma unica un nodo dentro de un horizonte electronico. Un descriptor de nodo es el descriptor de recorrido del recorrido que termina en el nodo a identificar. En la figura 8, el descriptor de nodo del nodo etiquetado C es, por lo tanto, 0.2.2. El descriptor de nodo para el nodo raiz de un horizonte electronico tiene el valor especial de -1.
(f) Descriptor de punto. Un descriptor de punto identifica de forma unica cualquier punto dentro de un horizonte electronico. Un descriptor de punto consiste en dos partes: (1) el descriptor de segmento del segmento al que pertenece el punto y (2) el indice de punto del punto a identificar. Para poder distinguir entre descriptores de punto y otros descriptores, se usan dos puntos para separar la parte de descriptor de segmento de un descriptor de punto del indice de punto propiamente dicho, por ejemplo, "0.1:2" identifica el segmento "0.1" y el punto 2.
(6) Funciones de calculo de costos
(a) Vision general
La creacion de un horizonte electronico es el proceso que determina que segmentos (e intersecciones) son parte de un horizonte electronico y cuales no lo son. El primer segmento de un horizonte electronico es el segmento en el que el vehiculo se encuentra actualmente. Cada vez que se anade otro segmento a un horizonte electronico, el proceso de calculo de horizonte electronico 170(3) determina si el nodo de salida de dicho segmento se deberia expandir mas, es decir, si alguno o todos los segmentos unidos al nodo de salida del segmento tambien deberian ser parte del horizonte electronico. Para este fin se usan una funcion de calculo de costos de segmento y una funcion de calculo de costos de nodo.
Las funciones de calculo de costos indican como algunos factores afectan a la creacion de un horizonte electronico. Las funciones de calculo de costos permiten que una aplicacion de ayuda al conductor (a traves de un proceso de configuracion) especifique si algunos factores deberan afectar a la creacion del horizonte electronico. Las funciones de calculo de costos tambien permiten que una aplicacion de ayuda al conductor especifique (a traves del proceso de configuracion) en que medida cada uno de estos factores debera afectar a la creacion del horizonte electronico. La lista siguiente incluye los factores que pueden ser tomados en cuenta por las funciones de calculo de costos.
(1) Velocidad actual del vehiculo;
(2) Tiempo de recorrido del vehiculo desde la posicion actual del vehiculo;
(3) Distancia de conduccion desde la posicion actual del vehiculo;
(4) Inclusion de segmentos inaccesibles;
(5) Inclusion de recorridos circulares (por ejemplo, un recorrido que tiene el mismo segmento introducido mas de una vez);
(6) Inclusion de giros en U;
(7) Inclusion de costos de nodo (por ejemplo, el costo de giros en interseccion); e
(8) Inclusion de costos estimados del recorrido de segmentos.
La lista anterior no es exclusiva y puede haber otros factores que pueden ser considerados por las funciones de calculo de costos.
Usando estos factores, la funcion de calculo de costos determina las extensiones de un horizonte electronico. Por ejemplo, las extensiones del horizonte electronico pueden incluir todos los segmentos dentro de una distancia absoluta, todos los segmentos que son alcanzables a la velocidad actual del vehiculo dentro de los n segundos siguientes, todos los segmentos a los que se puede llegar dentro de los n segundos siguientes marchando a los limites legales de velocidad de los segmentos correspondientes, etc. Estos factores se pueden combinar de varias formas. Por ejemplo, las extensiones de un horizonte electronico pueden incluir una distancia absoluta minima combinada con una distancia que es una funcion de la velocidad del vehiculo y del tiempo.
(b) El proceso de calcular valores de costo
El proceso de crear un horizonte electronico usa dos valores de costo umbral. El primer valor de costo umbral se denomina el "costo umbral de creacion" y el segundo costo umbral se denomina el "costo de recorrido minimo".
El proceso de calcular el costo durante el proceso de creacion de un horizonte electronico opera de forma recursiva. En primer lugar, se asocia algun costo (a traves de la funcion de costo de segmento) con el "costo de recorrido" del
5
10
15
20
25
30
35
40
45
50
55
60
65
vehiculo desde la posicion del vehiculo (en el primer segmento del horizonte electronico) al nodo de salida del primer segmento del horizonte electronico. El proceso de creacion continua ahora de la forma recursiva siguiente:
Para cualquier segmento unido al nodo de salida del segmento de horizonte electronico actual, se anade un costo de nodo. Este costo de nodo modela el costo asociado con el giro desde el segmento actual al segmento unido y se determina por la funcion de costo de nodo. Entonces, se anade un costo de segmento que refleja el costo del vehiculo que avanza desde el nodo de entrada de un segmento recien unido a su nodo de salida.
En cada etapa se compara el costo actual con un valor para el "costo umbral de creacion" (o "primer umbral"). El costo umbral de creacion se usa como un umbral para determinar cuando se debera parar el proceso que extiende el recorrido desde la posicion actual del vehiculo.
Una vez que el costo de un recorrido llega a o supera el costo umbral de creacion, el proceso de creacion se detiene para dicho recorrido. Entonces, se aplica el mismo proceso de creacion al recorrido siguiente, y asi sucesivamente hasta que se determinan todos los recorridos que salen de la posicion actual del vehiculo y cada recorrido tiene un costo al menos tan grande como el costo umbral de creacion, si es posible (observese que en algunos casos puede no ser posible extender un recorrido al costo umbral de creacion. Por ejemplo, si una carretera termina en una calle sin salida, el recorrido puede terminar antes de que se alcance el costo umbral de creacion).
Una vez creado un horizonte electronico, el costo asociado con cada uno de los recorridos en el horizonte electronico es al menos tan grande como el valor de costo umbral de creacion (si es posible).
Cuando el vehiculo avanza hacia delante y la posicion del vehiculo cambia, los datos que indican la nueva posicion son recogidos por los sensores (120 en la figura 1). La herramienta de localizacion de vehiculo (150(2)(1) en la figura 4) usa estos nuevos datos para determinar una nueva posicion del vehiculo. Los datos que indican la nueva posicion del vehiculo son enviados desde la herramienta de localizacion de vehiculo 150(2)(1) al motor de datos (170 en la figura 5) donde los datos son recibidos por el componente de recepcion de datos 170(1) que, a su vez, pasa los datos al proceso 170(3) que calcula el horizonte electronico. Entonces, el proceso de calculo de horizonte electronico 170(3) determina si se ha de crear un nuevo horizonte electronico como resultado de la nueva posicion del vehiculo o si el horizonte electronico anterior se puede reutilizar (etapa 170(3)(5)). Como parte de la realizacion de esta determinacion, el componente de calculo de horizonte electronico 170(3) ajusta los costos de todos los recorridos en el programa de horizonte electronico para tener en cuenta los datos que indican la nueva posicion del vehiculo. Al ajustar los costos de los recorridos, los costos de los recorridos disminuyen porque la posicion del vehiculo avanza al horizonte electronico. En este punto, el proceso de calculo de horizonte electronico 170(3) determina si algun recorrido en el horizonte electronico tiene un costo menor que el costo de recorrido minimo (es decir, el "segundo umbral"). Si todos los recorridos en el horizonte electronico tienen costos superiores al costo de recorrido minimo, no se crea un nuevo horizonte electronico. En su lugar, se determina un nuevo horizonte electronico usando los recorridos que ya se habian determinado para el horizonte electronico anterior (es decir, existente). Cuando se determina de esta manera un nuevo horizonte electronico, los recorridos (y sus costos) son actualizados para tener en cuenta la nueva posicion del vehiculo. Cuando se determina de esta manera un nuevo horizonte electronico, se pueden eliminar del horizonte electronico anterior uno o mas segmentos de un recorrido, o incluso un recorrido completo.
Cuando se reciben en el motor de datos 170 datos que indican nuevas posiciones del vehiculo, el componente de calculo 170(3) determina de esta manera nuevos horizontes electronicos hasta que cualquier costo de recorrido sea menor que el costo de recorrido minimo. Cuando una nueva posicion del vehiculo hace que cualquier costo de recorrido en un horizonte electronico caiga por debajo del costo de recorrido minimo umbral, se crea un horizonte electronico completamente nuevo (es decir, se determinan todos los recorridos comenzando en la posicion actual del vehiculo, de la manera descrita anteriormente, de modo que el costo de cada recorrido sea al menos el costo umbral de creacion).
El uso de dos valores de costo umbral tiene varias ventajas. El uso de dos valores de costo umbral permite un margen de seguridad. Este margen de seguridad es configurable por las aplicaciones de ayuda al conductor 200 que usan el horizonte electronico. Otra ventaja de usar dos umbrales es que no hay que calcular con tanta frecuencia un horizonte electronico totalmente nuevo, reduciendo de ese modo los requisitos computacionales asociados con la creacion del horizonte electronico. Otra ventaja de usar dos umbrales es que se puede reducir la memoria necesaria para guardar los datos asociados con un horizonte electronico (como se describe en lo sucesivo en conexion con el deposito de datos 180).
Los valores del costo umbral de creacion y el costo umbral minimo son configurables. En una realizacion, estos valores son configurados por las aplicaciones de ayuda al conductor que usan el horizonte electronico.
(c) Calculo de los costos de recorrido al calcular el horizonte electronico
Como se ha indicado anteriormente, al calcular un horizonte electronico, el costo asociado con la adicion de cada nodo y segmento al horizonte electronico se determina y se anade a los costos ya acumulados para el recorrido con
5
10
15
20
25
30
35
40
45
50
55
60
65
el fin de determinar si debera parar la expansion del horizonte electronico a lo largo de dicho recorrido. Al determinar el costo de anadir un segmento a un recorrido, la funcion de calculo de horizonte electronico 170(3) usa una funcion de costo de segmento 170(3)(2) y al determinar el costo de anadir un nodo a un recorrido, la funcion de calculo de horizonte electronico 170(3) usa una funcion de costo de nodo 170(3)(3).
(d) La funcion de costo de segmentos
La funcion de costo de segmento 170(3)(2) determina el costo asociado con un vehiculo que avanza desde el nodo de entrada al nodo de salida de un segmento. En el caso del primer segmento, el costo se limita al costo de recorrido del vehiculo desde la posicion actual del vehiculo al nodo de salida del primer segmento.
De acuerdo con una realizacion, la funcion de costo de segmento 170(3)(2) tiene acceso a cierta informacion acerca de un segmento para el que se calcula un costo. La informacion acerca del segmento se obtiene de la base de datos de mapas 130. La funcion de costo de segmento 170(3)(2) puede usar algunos datos, todos los datos o ningun dato, dependiendo de como se haya configurado la funcion de costo de segmento. De acuerdo con una realizacion, la funcion de costo de segmento 170(3)(2) tiene acceso a la informacion siguiente acerca de un segmento:
(1) La longitud ("L") del segmento,
(2) Un costo estimado del recorrido ("SETC"), y
(3) Si el recorrido a lo largo del segmento en la direccion actual es legal ("TDI") (la informacion de TDI permite que la aplicacion de ayuda al conductor controle, a traves de un proceso de configuracion, si se incluyen en un horizonte electronico calles de sentido unico orientadas en el sentido contrario al sentido actual de marcha del vehiculo).
Con respecto al primer segmento, la longitud es la distancia desde la posicion actual del vehiculo al nodo de salida del primer segmento y el costo de recorrido estimado es el costo de recorrido estimado desde la posicion del vehiculo al nodo de salida del primer segmento.
En la funcion de costo de segmento 170(3)(2) se asocian factores con combinaciones de estos elementos de datos. La funcion de costo de segmento 170(3)(2) se configura seleccionando valores para cada uno de estos factores. Por ejemplo, un factor de costo de longitud legal ("FLENJllegal") se puede definir y usar como un factor de la longitud de segmento ("L") y el sentido de marcha legal ("TDI"). Un factor de costo de longitud ilegal ("FLENJllegal") se puede definir y usar como un factor de la longitud de segmento ("L") y el sentido de marcha legal ("TDI"). Un factor de costo de marcha estimado ("FEST_Legal") se puede definir y usar como un factor del costo de recorrido ("SETC") y el sentido de marcha legal ("TDI"). Igualmente, un factor de costo de marcha estimado de sentido ilegal ("FESTJllegal") se puede definir y usar como un factor del costo de recorrido ("SETC") y el sentido de marcha legal ("TDI").
Mediante la seleccion de valores para cada uno de estos factores, la importancia relativa de cada uno de los diferentes tipos de informacion disponible acerca de un segmento puede ser determinada con respecto a la expansion del horizonte electronico. De esta manera, se puede configurar la funcion de costo de segmento. Esta configuracion se puede hacer sobre la base de la entrada procedente de una aplicacion de ayuda al conductor o, alternativamente, se pueden usar valores de configuracion por defecto.
(e) La funcion de costo de nodo
El proceso de calculo de horizonte electronico 170(3) tambien incluye una funcion de costo de nodo 170(3)(3). La funcion de costo de nodo 170(3)(3) se usa para calcular el costo asociado con la adicion de un nodo a un recorrido al determinar un horizonte electronico. El costo de nodo representa el costo asociado con la transicion (por ejemplo, giro a la derecha, a la izquierda, o seguir recto) de un segmento a otro.
De acuerdo con una realizacion, la funcion de costo de nodo 170(3)(3) tiene acceso a cierta informacion acerca de un nodo para el que se calcula el costo. La informacion acerca del nodo se obtiene de la base de datos de mapas 130. La funcion de costo de nodo 170(3)(3) puede usar algunos datos, todos los datos o ningun dato, dependiendo de como se ha configurado la funcion de costo de nodo 170(3)(3). De acuerdo con una realizacion, la funcion de costo de nodo 170(3)(3) tiene acceso a la siguiente informacion acerca de un nodo:
(1) Si el giro a traves del nodo es legal ("TL"). Un giro puede ser ilegal porque esta prohibido girar (por ejemplo, giro prohibido a la izquierda o la derecha) o el segmento siguiente es una calle de sentido unico en la que se entraria en el sentido contrario.
(2) El angulo de giro del segmento de entrada al segmento siguiente ("TA"). El valor se puede expresar en grados.
(3) Un costo de nodo estimado ("EnodeCost").
(4) Un valor ("SecondSegment") que indica si el segundo segmento ya es parte del recorrido actual para el que actualmente se esta explorando una expansion adicional.
5
10
15
20
25
30
35
40
45
50
55
60
65
Como con la funcion de costo de segmento 170(3)(2), puede haber factores asociados con estos elementos de datos en la funcion de costo de nodo 170(3)(3). La funcion de costo de nodo 170(3)(3) se configura seleccionando valores para cada uno de estos factores. Por ejemplo, se aplica un factor de angulo de giro ("F_TA_Legal") al angulo de giro entre el segmento actual y el segmento siguiente, si el giro es legal (un giro es legal si ni las prohibiciones de girar ni las limitaciones de sentido unico impiden que se ejecute un giro). Este factor se puede usar para asociar costos mas altos con angulos de giro mas pronunciados y viceversa. Se puede aplicar un factor de costo de nodo ("F_SDAL_EnodeCost_Legal") al costo de nodo ("EnodeCost") de la base de datos 130. Se puede anadir un costo constante ("Cost_UTurn") en el caso de que el giro sea legal y el giro sea un giro en U. Eligiendo un valor apropiadamente alto, los giros en U se pueden suprimir completamente. Se puede aplicar un factor de giro ilegal ("F_TA_Illegal") al angulo de giro entre el segmento actual y el siguiente si el giro es ilegal. Se puede anadir un factor de costo constante ("C_Illegal_Turn") si el giro es ilegal. Se puede anadir un factor de costo constante ("Cost_SecondSegment") si el segmento siguiente es un segmento que ya es parte del recorrido actual y ambos segmentos tienen el mismo sentido.
La selection de valores para cada uno de los factores en la funcion de costo de nodo permite asignar la importancia relativa de cada uno de los diferentes tipos de information disponibles acerca de un nodo con respecto a la expansion del horizonte electronico. De esta manera, se puede configurar la funcion de costo de nodo. Esta configuration se puede hacer sobre la base de la entrada de una aplicacion de ayuda al conductor o, alternativamente, se pueden usar valores de configuracion por defecto.
(f) Configuracion de las funciones de calculo de costos
Como se ha indicado anteriormente, el costo umbral de creation y el costo de recorrido minimo se pueden configurar usando la entrada de una o mas de las aplicaciones de ayuda al conductor. Estos umbrales pueden ser valores fijos o pueden ser valores calculados. Por ejemplo, de acuerdo con una realization, el costo de recorrido minimo se puede hacer una funcion de la velocidad del vehiculo. De acuerdo con la presente realizacion, la velocidad actual del vehiculo ("VSP") se puede obtener de los sensores y actualizar de forma continua en los datos proporcionados al proceso de calculo de horizonte electronico 170(3).
Un valor para un factor de costo de recorrido minimo ("SpeedP") se determina por una de las aplicaciones de ayuda al conductor. Usando esta informacion, el costo de recorrido minimo ("MinCost") se calcula como sigue:
MinCost = VSP * SpeedF
Tambien se puede calcular el valor de costo umbral de creacion. En una realizacion, el valor de costo umbral de creacion ("MaxCost") se puede hacer una funcion del costo de recorrido minimo de acuerdo con la relation siguiente:
MaxCost = MinCost * MaxF,
donde MaxF es un factor aplicado al costo de recorrido minimo.
Como se ha mencionado anteriormente, las funciones de calculo de costos se pueden configurar usando una entrada de la aplicacion de ayuda al conductor. Una forma de configurar las funciones de calculo de costos es asegurar que todos los recorridos dentro del horizonte electronico tengan una cierta longitud minima, que se han de ignorar los giros en U, y que los segmentos inaccesibles no se hagan parte de un horizonte electronico. Esta preparation se puede lograr de la siguiente manera:
En la funcion de costo de segmento, FLEN_Legal se ajusta a 1. Esto hace el costo identico a una longitud de segmento (o en el caso del primer segmento identico a la distancia del vehiculo al nodo de salida del primer segmento). Tambien en la funcion de costo de segmento, FLENJllegal se ajusta a cero para suprimir segmentos inaccesibles. Tambien en la funcion de costo de segmento, FEST_Legal y FESTJllegal se ajustan a cero. De esta forma se ignora cualquier estimation de tiempos de recorrido. En la funcion de costo de nodo, tanto FTA_Legal como F_SDAL_EnodeCost_Legal se ajustan a 0 eliminando de ese modo los costos de giros legales. Cost_Uturn se ajusta a 100.000 para eliminar todo giro en U. FTAJllegal se ajusta a 0, pero C_Illegal_Turn se ajusta a 100.000 para eliminar segmentos inaccesibles o giros ilegales. Cost_SecondSegment se ajusta a 100.000 para eliminar que el mismo segmento sea dos veces parte de cualquier recorrido.
(7) Recorrido primario
(a) Vision general
Algunas aplicaciones de ayuda al conductor requieren el procesamiento de todos los recorridos posibles dentro de un horizonte electronico (es decir, recorridos accesibles e inaccesibles). Sin embargo, algunas aplicaciones de ayuda al conductor usan un "recorrido primario". Un "recorrido primario" es un recorrido especifico del uno o mas recorridos posibles dentro de un horizonte electronico. El recorrido primario es el recorrido mas probable que se
5
10
15
20
25
30
35
40
45
50
55
60
65
espera que siga el vehiculo. El programa de horizonte de datos 110 incluye una caracteristica por la que un recorrido primario puede ser determinado e identificado para una aplicacion de ayuda al conductor.
Hay dos aspectos para el calculo del recorrido primario. Un primer aspecto es una estimation del recorrido de marcha mas probable sobre la base de la geometria de la carretera local. Un segundo aspecto es el uso de information de ruta, si esta disponible. Estos aspectos se analizan a continuation.
(b) Recorrido mas probable
El motor de datos 170 del programa de horizonte de datos 110 incluye una funcion de recorrido primario 170(6). En la funcion de recorrido primario se incluye una funcion 170(6)(1) que calcula un recorrido mas probable basado en la red local de carreteras ("LRNBMLP", local-road-network-based most likely path). La funcion 170(6)(1) intenta estimar como seguira avanzando el vehiculo dentro del horizonte electronico actual teniendo en cuenta solamente la red local de carreteras. La funcion 170(6)(1) calcula un solo recorrido como el LRNBMLP. La funcion 170(6)(1) calcula el LRNBMLP como sigue. La funcion 170(6)(1) incluye el primer segmento de horizonte electronico en el LRNBMLP. Entonces, la funcion 170(6)(1) ejecuta repetidas veces las siguientes etapas para la selection del segmento siguiente hasta que se halla un nodo hoja del horizonte electronico.
Si solamente un segmento accesible esta unido a un nodo, se elige dicho segmento.
Si mas de un segmento accesible esta unido a un nodo, entonces se elige el segmento con la clase funcional mas alta de entre todos los segmentos accesibles. Si dos o mas segmentos accesibles tienen la misma clase funcional que es mas alta que la clase funcional de cada uno de los otros segmentos, se elige el segmento con la clase funcional mas alta con el angulo de giro mas pequeno. Si hay dos segmentos con la clase funcional mas alta y el mismo angulo de giro (por ejemplo, siendo uno un giro a la izquierda y siendo el otro un giro a la derecha), se elige el giro a la derecha sobre el giro a la izquierda.
Una aplicacion de ayuda al conductor puede optar por tener un LRNBMLP determinado de esta manera. Alternativamente, la aplicacion de ayuda al conductor puede optar por no tener el LRNBMLP determinado de esta manera.
(c) Recorrido basado en ruta
Como se ha mencionado anteriormente, otro aspecto de determinar un recorrido primario de un vehiculo es usar informacion de ruta. Algunos vehiculos incluyen hardware y software que pueden calcular una ruta a un destino deseado. Como se ha mencionado anteriormente en conexion con la figura 4, en una realization de la presente invention, se incluye una herramienta de calculo de ruta 150(2)(3) entre las aplicaciones de navegacion 150(2). La herramienta de calculo de ruta 150(2)(3) se puede usar para calcular una ruta a un destino deseado. En una realizacion, la herramienta de calculo de ruta 150(2)(3) proporciona una salida en forma de ruta de datos ("R"). La ruta de datos es una lista de segmentos consecutivos y dirigidos que describen una forma legal de que un vehiculo vaya del primer al ultimo segmento de la ruta. Un "sub-recorrido de ruta" de una ruta dentro de un horizonte electronico dado es el recorrido dentro del horizonte electronico que concuerda con algunos (o todos los) segmentos de una ruta dada. Dada una ruta, es posible que la ruta no este contenida (al menos parcialmente) dentro del horizonte electronico. En este caso, el sub-recorrido de ruta no esta definido (y, por lo tanto, esta identificado por el descriptor de recorrido de -1).
La funcion de recorrido primario 170(6) incluye una funcion 170(6)(2) que intenta calcular un recorrido basado en ruta. Un recorrido basado en ruta es la parte de una ruta calculada que esta situada dentro de un horizonte electronico. Las entradas a la funcion 170(6)(2) incluyen datos que indican la ruta R y datos ("E") que indican el horizonte electronico calculado. Como una primera etapa, la funcion 170(6)(2) determina si se puede definir un recorrido basado en ruta para el horizonte electronico. Para realizar esta etapa, la funcion 170(6)(2) intenta localizar el primer segmento del horizonte electronico en la ruta calculada R. Si el primer segmento del horizonte electronico no se puede hallar en la ruta calculada R, el calculo se detiene y el recorrido basado en ruta no esta definido es decir, no hay recorrido basado en ruta). Sin embargo, si el primer segmento del horizonte electronico concuerda con uno de los segmentos en la ruta calculada R, el recorrido basado en ruta esta definido (observese que, para que el primer segmento del horizonte electronico concuerde con uno de los segmentos en la ruta calculada, la funcion 170(6)(2) requiere que el sentido de recorrido a lo largo del segmento tanto en el horizonte electronico como en la ruta calculada sean el mismo). Despues de hallar el primer segmento del horizonte electronico en la ruta calculada, la funcion 170(6)(2) sigue intentando la concordancia de segmentos de los recorridos en el horizonte electronico E con segmentos de la ruta calculada R. Como con el primer segmento, la funcion 170(6)(2) requiere que el sentido de recorrido en los segmentos concordantes sea el mismo. Este proceso de concordancia continua hasta que no se pueda hallar mas segmentos de los recorridos del horizonte electronico entre los segmentos de la ruta. Ya no se hallan concordancias porque no esta contenido en E un segmento a partir de la ruta para el que se busca una concordancia (es decir, porque el horizonte electronico E no se extiende mas alla de algun nodo) o se llego al ultimo segmento de la ruta R y, por lo tanto, no se pueden poner en concordancia segmentos adicionales de R en E.
5
10
15
20
25
30
35
40
45
50
55
60
65
(d) Calcular el recorrido primario
La funcion de calculo de recorrido primario 170(6) calcula un recorrido primario usando las salidas procedentes de la funcion de recorrido mas probable 170(6)(1) y la funcion basada en ruta 170(6)(2). Si se ha definido una ruta R y la funcion basada en ruta 170(6)(2) fue capaz de determinar un recorrido basado en ruta sobre la base de R, entonces se selecciona dicho recorrido basado en ruta de R como el recorrido primario. Sin embargo, si no se ha definido una ruta o no fue posible calcular un recorrido basado en ruta, se usa el recorrido mas probable de la red local de carreteras (LRNBMLP). Una ventaja de este metodo es suponer que el conductor seguira una ruta calculada, si ha introducido informacion de ruta. Sin embargo, si no se dispone de informacion de ruta, el recorrido mas probable de la red local de carreteras es la mejor estimation que se puede facilitar.
(8) Determination del contenido del horizonte electronico de nueva construction
Se hace referencia de nuevo a la figura 5. Cuando el proceso de calculo 170(3) ha construido un nuevo horizonte electronico (en contraposition a determinar un nuevo horizonte electronico ajustando la position del vehiculo y los costos de recorrido del horizonte electronico anterior), se obtiene el contenido para la estructura de datos del nuevo horizonte electronico. El motor de datos 170 incluye un proceso de componentes 170(4) que realiza esta funcion. El proceso 170(4) recibe del proceso de calculo de horizonte electronico 170(3) datos que indican los recorridos (y, en consecuencia, que segmentos y nodos) se han de representar en la estructura de datos de horizonte electronico. Al recibir estos datos, el proceso de formation de contenido de horizonte electronico 170(4) obtiene de la base de datos de mapas 130 los datos necesarios para la formacion de la estructura de datos de horizonte electronico. La estructura de datos formada por el proceso de formacion de contenido de horizonte electronico 170(4) contiene los datos relevantes acerca de las carreteras e intersecciones en el horizonte electronico. Esta estructura de datos forma la salida 171 del motor de datos 170.
Los tipos de datos que el proceso de formacion de contenido de horizonte electronico 170(4) obtiene de la base de datos de mapas 130 se determinan mediante un proceso de configuration. Este proceso de configuration se puede realizar durante una etapa de fabrication de los sistemas avanzados de ayuda al conductor o durante un proceso de initialization o preparation de los sistemas avanzados de ayuda al conductor. En una realization, el controlador de configuracion 165 recibe de una o mas aplicaciones de ayuda al conductor 200 datos que indican los tipos de datos que se debera incluir en el horizonte electronico. A su vez, el controlador de configuracion 165 proporciona datos al proceso 170(4) para indicar los tipos de atributos de datos asociados con segmentos y nodos que se deberan obtener para inclusion en la estructura de datos de horizonte electronico. Sobre la base de estas entradas, el proceso de formacion de contenido 170(4) obtiene los datos necesarios de la base de datos de mapas 130 a incluir en una estructura de datos de horizonte electronico siempre que se cree un nuevo horizonte electronico.
Cuando se ha obtenido una estructura de datos de horizonte electronico de nueva construccion y se ha almacenado en la estructura apropiada, el contenido de la estructura se envia desde el motor de datos 170 al deposito de datos 180. El motor de datos 170 incluye un proceso de componentes 170(8) que proporciona esta salida 171.
Como se ha mencionado anteriormente, en algunas circunstancias (por ejemplo, un estado fuera de la carretera), no se puede calcular un horizonte electronico. Si no se puede calcular un horizonte electronico, el proceso 170(4) no obtiene datos para una estructura de datos de horizonte electronico de la base de datos de mapas 130. En estas circunstancias, el proceso de formacion de contenido 170(4) no proporciona salida alguna o, alternativamente, el proceso de formacion de contenido 170(4) proporciona un horizonte electronico vacio, es decir, que indica que no se ha determinado horizonte electronico alguno para la posicion del vehiculo.
Hay otra ocasion en la que se facilita un horizonte electronico vacio. Es posible que la herramienta de localization de vehiculo 150(2)(1) notifique que el vehiculo esta marchando en direction prohibida por una calle de sentido unico. En este caso, el proceso de calculo de horizonte electronico 170(3) devuelve la informacion de estado apropiada, estando el horizonte electronico esencialmente vacio.
Si el proceso de calculo 170(3) se ha configurado para proporcionar un recorrido primario (en lugar de un horizonte electronico completo), el proceso de formacion de contenido de horizonte electronico 170(4) obtiene los datos procedentes de la base de datos de mapas 130 necesarios para una estructura de datos de horizonte electronico que incluye solamente el recorrido primario (alternativamente, se facilita un horizonte electronico incluyendo todos los recorridos junto con datos que indican por separado el recorrido primario). Si el proceso de calculo 170(3) se ha configurado para proporcionar un recorrido primario y no se puede determinar un recorrido primario, el proceso de formacion de contenido 170(4) proporciona una salida que indica que no se ha determinado recorrido primario alguno para la posicion del vehiculo.
En la realizacion representada en la figura 5, el proceso 170(4) de obtencion de datos para el horizonte electronico se representa separado del proceso 170(3) de determinacion del horizonte electronico. En realizaciones alternativas, estos procesos se pueden combinar de modo que se obtengan los datos contenidos en el horizonte electronico y el horizonte electronico se construye cuando se determinan los recorridos que forman el horizonte electronico.
5
10
15
20
25
30
35
40
45
50
55
60
65
(8) Provision del horizonte electronico
Como se ha mencionado anteriormente, de acuerdo con una realizacion de la presente invencion, no se crea necesariamente un nuevo horizonte electronico cada vez que se obtiene una nueva posicion del vehiculo. En su lugar, el horizonte electronico anterior se puede reutilizar si todos los costos de recorrido del horizonte electronico anterior todavia superan el costo umbral minimo despues del ajuste de una nueva posicion del vehiculo. En estas circunstancias, el motor de datos 170 proporciona una salida 172 que indica un nuevo horizonte electronico para la nueva posicion del vehiculo que usa los recorridos determinados para un horizonte electronico anterior. El motor de datos 170 incluye un proceso de salida de horizonte electronico 170(7) que realiza esta funcion. El proceso de salida de horizonte electronico 170(7) proporciona esta salida 172 al deposito de datos 180, como se explica con mas detalle en lo sucesivo. De acuerdo con una realizacion, el proceso de salida de horizonte electronico 170(7) proporciona una salida para cada recepcion de datos que indican una nueva posicion del vehiculo. De acuerdo con una realizacion de la presente invencion, el componente 170(7) que proporciona la salida 172 que define un horizonte electronico esta separado del componente 170(8) que proporciona el contenido de un horizonte electronico. La salida 171 del proceso de salida de contenido de horizonte electronico 170(8) incluye todos los atributos de datos necesarios asociados con todos los segmentos y nodos en todos los recorridos que forman un horizonte electronico. La salida 172 del proceso de salida de horizonte electronico 170(7) incluye solamente una referencia a una de las salidas 171 que contiene el contenido de datos de un horizonte electronico y una indicacion de la posicion del vehiculo en relacion con el contenido de datos referenciado.
F. El deposito de datos 180
Como se ha indicado anteriormente en conexion con la figura 1, el deposito de datos 180 es el componente del programa de horizonte de datos 110 que contiene las ultimas lecturas de datos. Una realizacion del componente deposito de datos 180 se representa en las figuras 10-12. Como se representa en la figura 10, el deposito de datos 180 contiene tres tipos de datos diferentes. En primer lugar, el deposito de datos 180 contiene datos 180(1) que representan el horizonte electronico que habia sido determinado por el motor de datos 170. De acuerdo con una realizacion, los datos 180(1) incluyen la informacion de atributos acerca de los segmentos y nodos en el horizonte electronico. La informacion de atributos acerca de los segmentos y nodos en el horizonte electronico puede incluir algunos o todos los atributos identificados en las figuras 3A y 3B. En segundo lugar, el deposito de datos 180 contiene datos 180(2) que representan la posicion del vehiculo. Los datos 180(2) que representan la posicion del vehiculo son los datos determinados por la herramienta de localizacion de vehiculo (150(2)(1) en la figura 4). El deposito de datos 180 puede obtener los datos 180(2) que representan la posicion del vehiculo directamente de la herramienta de localizacion de vehiculo 150(2)(1) o los datos 180(2) que representan la posicion del vehiculo pueden ser obtenidos del motor de datos 170. En tercer lugar, el deposito de datos 180 contiene datos de sensor 180(3). Los datos de sensor 180(3) pueden ser datos en bruto del sensor obtenidos directamente de los sensores (120 en la figura 1) o, alternativamente, los datos de sensor 180(3) se pueden obtener del motor de datos 170.
Con referencia a la figura 11, con respecto a los datos de horizonte electronico 180(1), el deposito de datos 180 contiene al menos el conjunto de datos que representa el horizonte electronico mas reciente que habia sido determinado por el motor de datos 170. En una realizacion, el deposito de datos 180 contiene varios conjuntos de datos que representan varios horizontes electronicos. Estos varios conjuntos de datos mantenidos en el deposito de datos 180 son los conjuntos creados mas recientemente por el motor de datos 170. Por ejemplo, el deposito de datos 180 puede mantener los diez conjuntos de datos mas recientes que representan los diez horizontes electronicos mas recientes que habian sido determinados por el motor de datos 170 aunque tambien puede ser adecuado un numero mayor o menor que diez. El numero de conjuntos de datos retenidos por el deposito de datos 180 se puede configurar usando la entrada de las aplicaciones de ayuda al conductor 200 mediante el controlador de configuracion (165 en la figura 1). A cada conjunto de datos en el deposito de datos 180 se le asigna un numero de identificacion o codigo por el que se puede identificar este.
De acuerdo con una realizacion representada en la figura 11, el deposito de datos 180 no mantiene necesariamente conjuntos de datos completos para cada horizonte electronico retenido en el mismo. En su lugar, el deposito de datos 180 implementa un mecanismo de manejo de deposito. Este mecanismo de manejo de deposito es similar a mecanismos usados en programacion orientada a objetos para manejar objetos grandes. El uso del mecanismo de manejo de deposito reduce los requisitos de almacenamiento y manejo de multiples conjuntos de datos que representan multiples horizontes electronicos correspondientes.
El uso de un mecanismo de manejo de deposito para almacenamiento de horizontes electronicos en el deposito de datos 180 se facilita por la manera en la que los horizontes electronicos son calculados por el motor de datos 170. Como se ha mencionado anteriormente, de acuerdo con una realizacion, no se crea necesariamente un nuevo horizonte electronico cada vez que se obtienen datos que indican una nueva posicion del vehiculo. En su lugar, se crea un nuevo horizonte electronico solamente cuando un recorrido del horizonte electronico anterior cae por debajo de un recorrido umbral minimo despues de tener en cuenta una nueva posicion del vehiculo.
De acuerdo con la realizacion representada en la figura 11, se definen una clase ElectronicHorizonData y una clase ElectronicHorizon. Los objetos 181 en la clase ElectronicHorizonData contienen toda la informacion (es decir,
5
10
15
20
25
30
35
40
45
50
55
60
65
atributos de datos) necesaria para representar un horizonte electronico. Adicionalmente, cada objeto ElectronicHorizonData 181 contiene un recuento de referencia. El recuento de referencia indica cuantos otros objetos estan usando el objeto ElectronicHorizonData 181.
Cada objeto 182 en la clase ElectronicHorizon contiene tres elementos de informacion: un puntero, una distancia delta y un manipulador (es decir, ID). El puntero apunta al objeto ElectronicHorizonData aplicable 181. La distancia delta en un objeto ElectronicHorizon 182 es un valor que indica la diferencia en la posicion del vehiculo del objeto ElectronicHorizon 182 en relacion con la posicion del vehiculo en el objeto ElectronicHorizonData 181 referenciado (a condicion de que el vehiculo permanezca en el mismo segmento y se haya movido de tal manera que se puedan reutilizar los datos de horizonte electronico mas recientemente usados, no se calculan nuevos datos de horizonte electronico).
El uso del mecanismo de manejo de deposito para almacenamiento y uso de horizontes electronicos tiene varias ventajas. Los horizontes electronicos ocuparian mucha memoria si se almacenasen como objetos de clase ordinaria. Sin embargo, en la realization de la figura 11, el objeto ElectronicHorizon 182 contiene solamente tres elementos de informacion y, por consiguiente, puede ser relativamente pequeno en comparacion con el objeto ElectronicHorizonData 181. Copiar un objeto ElectronicHorizon 182 implica copiar los datos contenidos en el objeto ElectronicHorizon 182, pero en lo que respecta a los datos de horizonte electronico asociados, solamente se copia un puntero al objeto ElectronicHorizonData respectivo 181. Cuando se copia el objeto ElectronicHorizon 182, el recuento de referencia en el objeto ElectronicHorizonData aplicable ElectronicHorizonData 181 se incrementa indicando que el objeto ElectronicHorizon 182 esta usando los datos. Un objeto ElectronicHorizonData 181 se borra cuando todos los objetos ElectronicHorizon 181 referentes al mismo dejan de existir.
Se hace referencia a la figura 12. Como se ha indicado anteriormente, el deposito de datos 180 tambien contiene datos de posicion de vehiculo 180(2). Los datos de posicion de vehiculo 180(2) contenidos en el deposito de datos 180 incluyen datos que indican la una o mas posiciones mas recientes del vehiculo que habian sido determinadas por la herramienta de localization de vehiculo (150(2)(1) en la figura 4). El numero de posiciones del vehiculo incluidas en los datos de posicion de vehiculo 180(2) retenidos por el deposito de datos 180 se puede configurar. En una realizacion, el numero de posiciones del vehiculo representadas por los datos de posicion de vehiculo 180(2) contenidos en el deposito de datos 180 corresponde al numero de horizontes electronicos incluidos en los datos de horizonte electronico 180(1). Alternativamente, el numero de posiciones del vehiculo representadas en los datos de posicion de vehiculo 180(2) contenidos en el deposito de datos 180 puede ser mayor que el numero de horizontes electronicos incluidos en los datos de horizonte electronico 180(1). Los datos de posicion de vehiculo 180(2) se pueden retener por separado de los datos de horizonte electronico 180(1) o, alternativamente, los datos de posicion de vehiculo 180(2) se pueden incluir con los datos de horizonte electronico 180(1). Como se representa en la figura 12, a cada conjunto de datos de posicion de vehiculo 180(2) se le puede asignar un numero de identification o codigo por el que se puede identificar este.
Tambien como se ha indicado anteriormente, el deposito de datos 180 contiene datos de sensor 180(3). Los datos de sensor 180(32) contenidos en el deposito de datos 180 incluye las lecturas de sensor mas recientes de los sensores 120 (en la figura 1). El numero de lecturas de sensor incluidas en el deposito de datos 180 se puede configurar. En una realizacion, el numero de lecturas de sensor contenidas en el deposito de datos 180 corresponde al numero de horizontes electronicos incluidos en los datos de horizonte electronico 180(1) o el numero de posiciones del vehiculo incluidas en los datos de posicion de vehiculo 180(2). Alternativamente, el numero de lecturas de sensor contenidas en el deposito de datos 180 puede ser un numero diferente. Como se representa en la figura 12, a cada conjunto de datos de sensor 180(3) se le puede asignar un numero de identificacion o codigo por el que se puede identificar este.
Ademas de los datos de horizonte electronico 180(1), los datos de posicion de vehiculo 180(2) y los datos de sensor (3), el deposito de datos 180 tambien puede contener otros tipos de datos.
G. El distribuidor de datos 190
La figura 13 representa los componentes del distribuidor de datos 190. El distribuidor de datos 190 es el componente del programa de horizonte de datos 110 que inicia el envio de datos del deposito de datos 180 a las aplicaciones de ayuda al conductor 200 que usan los datos. Con el fin de reducir los requisitos de procesamiento, el distribuidor de datos 190 incluye un componente 190(1) que envia mensajes 191 que indican la disponibilidad de nuevos datos. Estos mensajes son enviados por un bus de datos de vehiculo 194 a cada proceso de ayuda al conductor 200 que usa datos almacenados en el deposito de datos 180. En una realizacion en la que hay varios procesos de ayuda al conductor 200 que usan datos almacenados en el deposito de datos 180, los mensajes 191 del distribuidor de datos 190 son enviados por el bus de datos 194 a cada proceso 200 que usa los datos. Cada proceso de ayuda al conductor 200 que usa datos almacenados en el deposito de datos 180 se registra en el distribuidor de datos 190 para recibir los mensajes acerca de la disponibilidad de nuevos datos.
Con respecto a los datos de horizonte electronico (180(1) en la figura 10), el distribuidor de datos 190 envia mensajes acerca de la disponibilidad de nuevos datos una vez cada ejecucion dclica del motor de datos 170. Con
5
10
15
20
25
30
35
40
45
50
55
60
65
respecto a los datos de posicion de vetnculo 180(2) y los datos de sensor 180(3), el distribuidor de datos 190 env^a mensajes acerca de la disponibilidad de nuevos datos cuando tales nuevos datos pasan a estar disponibles.
Cada mensaje 191 identifica la disponibilidad de nuevos datos por una ID (o puntero). Por ejemplo, con respecto a los datos de horizonte electronico 180(1), el mensaje 191 enviado por el distribuidor de datos 190 a las aplicaciones de ayuda al conductor 200 que usan los datos incluye la ID asociada con los datos de horizonte electronico 180(1) en el deposito de datos 180. Cada mensaje 191 tambien puede indicar el tipo de nuevos datos que estan disponibles, por ejemplo, horizonte electronico, posicion del vehiculo o sensor.
(El distribuidor de datos 190 tambien incluye un componente de registro 190(2). El componente de registro 190(2) se usa en union con componentes de registro correspondientes 302 en las escuchas 300, como se explica con mas detalle en lo sucesivo).
H. La escucha de datos 300
En la realizacion representada en la figura 1, cada una de las aplicaciones de ayuda al conductor 200 que usan los datos recogidos por el programa de horizonte de datos 110, usa una escucha de datos 300. Una escucha de datos 300 es un conjunto de funciones asociadas con una aplicacion de ayuda al conductor 200 que usa los datos recogidos por el programa de horizonte de datos 110. Una escucha de datos 300 proporciona unos medios por los que una aplicacion de ayuda al conductor 200 conecta con el programa de horizonte de datos 110. La escucha de datos 300 incluye procesos por los que cada aplicacion de ayuda al conductor 200 que usa datos almacenados por el programa de horizonte de datos 110 puede obtener los datos que requiere.
La figura 14 representa componentes de una escucha de datos 300(n). La escucha de datos 300(n) se representa asociada con una aplicacion de ayuda al conductor 200(n). Como se representa en la figura 14, la escucha de datos 300(n) incluye un componente de registro 302. El componente de registro 302 registra la escucha particular 300(n) con el programa de horizonte de datos 110. Especificamente, el componente de registro 302 registra con el componente de registro 190(2) del distribuidor de datos 190. Como parte del proceso de registro, el componente de registro 302 transmite un mensaje al distribuidor de datos 190 indicando que la escucha (de la que el componente 302 es una parte) ha de ser notificada acerca de la disponibilidad de nuevos datos. Como parte del proceso de registro, el componente de registro 302 tambien identifica para el componente de registro 190(2) del distribuidor de datos 190 el tipo de datos acerca de los cuales la escucha 300(n) ha de ser notificada (por ejemplo, datos de horizonte electronico, datos de posicion de vehiculo, o datos de sensor). En la realizacion de la figura 14, la escucha 300(n) se usa para notificacion de datos de horizonte electronico. Una vez que la escucha 300(n) se haya registrado con el distribuidor de datos 190, se seguiran enviando a la escucha 300(n) notificaciones del distribuidor de datos 190 acerca de la disponibilidad de nuevos datos del tipo especificado durante el registro a medida que se depositen nuevos datos en el deposito de datos 180. El proceso de registro se puede realizar una vez, por ejemplo, cuando se inicializa la aplicacion de ayuda al conductor 200. El proceso de registro se puede realizar posteriormente.
Como se ha indicado anteriormente, despues de registrar la escucha 300(n) con el distribuidor de datos 190, se envian regularmente a la escucha 300(n) unas notificaciones 191 acerca de la disponibilidad de nuevos datos. La escucha de datos 300(n) incluye un componente 304 que recibe estas notificaciones 191. Como se ha mencionado anteriormente, cada notificacion 191 incluye una identificacion (es decir, ID) de un conjunto de nuevos datos almacenados en el deposito de datos 180. La escucha de datos 300(n) incluye un componente 306 que guarda cada identificacion en una cola 310. La cola 310 se incluye como parte de la escucha de datos 300(n). Las identificaciones almacenadas en la cola 310 incluyen al menos las de las ultimas notificaciones recibidas del distribuidor de datos 190. La cola 310 puede incluir identificaciones de varias de las mas recientes notificaciones recibidas del distribuidor de datos 190. El tamano de la cola es configurable.
Cuando la aplicacion 200(n) esta preparada para recibir nuevos datos, la escucha de datos 300(n) obtiene los nuevos datos para la aplicacion 200(n). La escucha de datos 300(n) incluye un componente 312 que obtiene una identificacion de la cola 310. El componente 312 puede obtener la mas reciente identificacion anadida a la cola 310 o, alternativamente, el componente 312 puede obtener cualquier otra identificacion de la cola 310. Despues de obtener una identificacion de la cola 310, un proceso 314 en la escucha de datos 300(n) usa la identificacion para obtener los datos asociados del deposito de datos 180. Al recibir los datos del deposito de datos 190, un proceso 316 en la escucha de datos 300(n) proporciona los datos a la aplicacion de ayuda al conductor 200(n).
Una aplicacion de ayuda al conductor 200 puede usar mas de uno de los diferentes tipos de datos almacenados en el deposito de datos 180. Si una aplicacion de ayuda al conductor usa mas de un tipo diferente de datos almacenados en el deposito de datos 180, la aplicacion de ayuda al conductor se asocia con mas de una escucha de datos. De acuerdo con una realizacion, una aplicacion de ayuda al conductor usa una escucha de datos separada 300 para cada uno de los diferentes tipos de datos que usa la aplicacion de ayuda al conductor. Por ejemplo, si una aplicacion de ayuda al conductor 200 usa tanto datos de horizonte electronico como datos de sensor, la aplicacion de ayuda al conductor 200 se asocia con dos escuchas de datos separadas 300, una para los datos de horizonte electronico y la otra para los datos de sensor. Cada una de las escuchas de datos asociadas con una sola aplicacion de ayuda al conductor recibe mensajes del distribuidor de datos 190 del programa de horizonte de datos 110 acerca
5
10
15
20
25
30
35
40
45
50
55
60
65
de la disponibilidad de nuevos datos del tipo asociado con la escucha. Cada una de las escuchas de datos mantiene una cola separada de ID con la que los respectivos tipos de datos se pueden obtener del deposito de datos 180. La figura 15 representa una realizacion de una aplicacion de ayuda al conductor 200(k) asociada con tres escuchas separadas 300(k)(1), 300(k)(2) y 300(k)(3), para obtener tres tipos diferentes de datos.
I. Realizacion alternativa para la escucha
En una realizacion descrita anteriormente, se describio una escucha de datos 300 como un objeto separado de la aplicacion de ayuda al conductor 200 asociada con la misma que usa los datos para los cuales la escucha estaba recibiendo notificaciones. De acuerdo con una realizacion alternativa, la funcion de escucha se puede incorporar al mismo objeto que procesa los datos acerca de los cuales la escucha recibe notificaciones. De acuerdo con esta alternativa, un objeto (o aplicacion) que recibe notificaciones acerca de nuevos datos (del distribuidor de datos) tambien procesa directamente los datos. Una aplicacion que tanto recibe notificaciones acerca de los datos como procesa los datos acerca de los cuales recibe notificaciones, puede implementar estas dos funciones como subprocesos separados.
Como se ha descrito anteriormente en conexion con la realizacion en la que el proceso de escucha se implementa como una aplicacion u objeto separado, el mecanismo de notificacion de eventos usado en la escucha requiere que una llamada de notificacion por el programa de horizonte de datos vuelva rapidamente. Una llamada de notificacion debera consumir un tiempo de procesamiento minimo y solamente indicar la disponibilidad de datos o iniciar un subproceso que obtenga los datos. En una realizacion en la que la funcion de escucha se implementa como un subproceso separado en la misma aplicacion u objeto que tambien implementa el procesamiento de los datos, el mecanismo de notificacion de eventos tambien deberia volver rapidamente. Ademas, en una realizacion en la que la funcion de escucha se implementa como un subproceso separado en la misma aplicacion u objeto que tambien procesa los datos, se usan unos medios para iniciar o parar el subproceso que realiza la funcion de escucha. Esto puede ser realizado por el programa de horizonte de datos. Especificamente, el motor de datos 170 puede invocar el subproceso que escucha la notificacion de evento dentro de la aplicacion u objeto que usa los datos. Un proceso en una aplicacion que usa los datos se puede registrar en el motor de datos 170 de forma similar a la descrita anteriormente en conexion con una escucha. Una vez que se ha registrado el subproceso de escucha, el motor de datos empieza (o para, interrumpe o reanuda) este subproceso siempre que el motor de datos se arranca (se para, se interrumpe o se reanuda).
J. El programa de supervision 160
Con referencia de nuevo a la figura 1, el programa de supervision 160 es una parte de la arquitectura de datos 100. El programa de supervision 160 permite ver la ejecucion de las funciones del programa de horizonte de datos 110. Algunas caracteristicas del programa de supervision 160 se pueden usar en un entorno de prueba y configuration. Otras caracteristicas del programa de supervision 160 se pueden usar durante el uso ordinario por un usuario final del vehiculo de motor 108 en el que se instala la arquitectura de datos de mapas 100. En una alternativa, el programa de supervision 160 se usa solamente en un entorno de prueba y configuracion y no en un entorno de tiempo de ejecucion (por ejemplo, durante la operation ordinaria del vehiculo por un usuario final).
En un entorno de prueba y configuracion, se puede enviar una salida del programa de supervision 160 a un monitor de visualization 160(1) donde se pueden ver varios aspectos de la ejecucion de las funciones del programa de horizonte de datos 110. Por ejemplo, el programa de supervision 160 puede presentar una imagen continua de la position del vehiculo en movimiento en un mapa en el monitor de visualizacion 160(1). El monitor de visualizacion 160(1) tambien puede mostrar una zona alrededor de la posicion actual del vehiculo. Los segmentos de carretera que son partes de recorridos en el horizonte electronico se pueden resaltar en el monitor de visualizacion 160(1). Ademas, el programa de supervision 160 puede mostrar la posicion actual del vehiculo, incluyendo un punto, rumbo y velocidad en una imagen del mapa en la pantalla 160(1). Si el vehiculo 108 sigue una ruta calculada por la herramienta de calculo de ruta (150(2)(3) en la figura 4), la ruta calculada se puede resaltar en la imagen del mapa en la pantalla 160(1). Ademas, el programa de supervision 160 puede presentar los atributos de los segmentos de carretera e intersecciones alrededor del vehiculo. Estos atributos incluyen los atributos representados en las figuras 3A y 3B. Los atributos asociados con el horizonte electronico tambien se pueden visualizar. El programa de supervision 160 ajusta los limites de la imagen del mapa en el monitor de visualizacion sobre la base del movimiento actual del vehiculo.
K. El programa de configuracion 165
Con referencia de nuevo a la figura 1, el programa del controlador de configuracion 165 es una parte de la arquitectura de datos 100. El programa del controlador de configuracion 165 permite configurar las funciones del programa de horizonte de datos 110. El programa del controlador de configuracion 165 permite poner los parametros, valores por defecto, etc., que controlan la operacion de la arquitectura de datos 100, incluyendo el programa de horizonte de datos 110. Por ejemplo, el programa de configuracion 165 permite determinar el tamano del horizonte electronico en la parte delantera del vehiculo para el que se determinaran lecturas de datos.
5
10
15
20
25
30
35
40
45
50
55
60
65
El programa de configuracion 165 puede permitir poner parametros durante la instalacion (o fabrication) del equipo del sistema de ayuda al conductor en el vehiculo. El programa de configuracion 165 tambien puede permitir establecer parametros cuando se instala nuevo equipo, por ejemplo, nuevos sensores, nuevo hardware, mas memoria. El programa de configuracion 165 tambien puede permitir establecer nuevos parametros cuando se instalan nuevos datos, por ejemplo, cuando se actualiza la base de datos 130.
El programa de configuracion 165 tambien se puede usar a la initialization o durante la operation del vehiculo con el fin de cambiar las caracteristicas operativas del programa de horizonte de datos 110. El programa de configuracion 165 puede recibir entradas automaticamente de las aplicaciones de ayuda al conductor 200. Las aplicaciones de ayuda al conductor 200 suministran salidas que indican los tipos de datos que necesitan. Las aplicaciones de ayuda al conductor 200 tambien pueden proporcionar salidas que indican las extensiones necesarias para el horizonte electronico. La extension del horizonte electronico se puede especificar en distancia (por ejemplo, metros) o tiempo (por ejemplo, segmentos que el vehiculo puede recorrer dentro de los 10 segundos siguientes).
El programa de configuracion 165 se puede usar para registrar una escucha de datos 300 con el fin de recibir una difusion continua de los ultimos valores de datos del distribuidor de datos 190.
El programa de configuracion 165 tambien se puede usar para conectar la escucha de datos 300 a una arquitectura de bus de datos a bordo para transferir lecturas de datos a las aplicaciones avanzadas de ayuda al conductor 200 del vehiculo que se ejecutan en el bus.
L. Uso de la arquitectura de datos de mapas de sistema avanzado de ayuda al conductor
(1) Vision general
Los sistemas avanzados de ayuda al conductor ofrecen formas de mejorar la seguridad, la comodidad, la eficiencia, y la satisfaction general de la marcha. Estos sistemas requieren information acerca de la red de carreteras en torno al vehiculo. Parte de esta informacion puede ser obtenida por sensores. Sin embargo, los sensores no obtienen fiablemente todos los tipos de informacion que necesitan algunos de estos sistemas. Por consiguiente, el uso de una base de datos de mapas ademas de, o como un sucedaneo de, los sensores puede hacer que los sistemas avanzados de ayuda al conductor operen mejor y mas fiablemente.
Las realizaciones de la arquitectura de datos de mapas descrita de los sistemas avanzados de ayuda al conductor (100 en la figura 1) proporcionan unos medios por los que una o mas aplicaciones del sistema avanzado de ayuda al conductor 200 pueden usar datos de mapas en apoyo de la funcion o funciones provistas de ese modo. La arquitectura de datos de mapas de los sistemas avanzados de ayuda al conductor proporciona aplicaciones del sistema avanzado de ayuda al conductor con acceso a datos acerca de la geometria de la carretera y otros atributos cerca del vehiculo. Por ejemplo, la arquitectura de datos de mapas de los sistemas avanzados de ayuda al conductor proporciona acceso a datos que representan cualquier position a lo largo de la red de carreteras cerca del vehiculo a las que se puede llegar dentro de 10 segundos de tiempo de marcha. Esta portion de la red de carreteras corresponde al horizonte electronico. El horizonte electronico se vuelve a calcular regularmente en el tiempo y/o a medida que el vehiculo se desplaza a lo largo de la red de carreteras. Una vez que se ha calculado un horizonte electronico, la aplicacion del sistema avanzado de ayuda al conductor puede usar los datos acerca de los recorridos del vehiculo en el horizonte electronico.
Con referencia a la figura 16, una aplicacion avanzada de ayuda al conductor 200 puede acceder a los datos representados por un horizonte electronico con un manipulador del horizonte electronico (es decir, la ID del objeto de horizonte electronico 182 en el deposito de datos 180 en la figura 11). La aplicacion avanzada de ayuda al conductor 200 se basa en la escucha (300 en la figura 14) para obtener la ID del ultimo horizonte electronico (182 en la figura 11) del distribuidor de datos 190. Con la ID del objeto de horizonte electronico 182 se pueden obtener algunos o todos los datos en el objeto de datos de horizonte electronico (181 en la figura 11). El objeto de datos de horizonte electronico 181 identifica todos los recorridos posibles del vehiculo (o el recorrido primario) a la extension del horizonte electronico. El objeto de datos de horizonte electronico 181 tambien identifica los segmentos y nodos en cada recorrido (es decir, usando los descriptores de segmento y descriptores de nodo, descritos anteriormente).
De acuerdo con una realization de la presente invention, las aplicaciones avanzadas de ayuda al conductor tambien pueden obtener datos de sensor y datos de posicion de vehiculo.
(2) Iteradores
Con respecto a los datos contenidos en un horizonte electronico, una aplicacion de ayuda al conductor 200 puede usar uno de los iteradores para obtener los datos contenidos en un horizonte electronico de manera organizada. Un aterrador es un programa que permite la recuperation sucesiva de articulos de una coleccion de articulos. Los iteradores permiten que una aplicacion avanzada de ayuda al conductor atraviese el horizonte electronico para recuperacion de descriptores de recorrido, segmentos de horizonte electronico, datos acerca de puntos a lo largo de
5
10
15
20
25
30
35
40
45
50
55
60
65
segmentos, etc. Entre los iteradores que estan disponibles para su uso por las aplicaciones de ayuda al conductor se incluyen un iterador de recorrido 402, un iterador de segmento 404 y un iterador de punto de segmento 406. Para usar alguno de los iteradores, las aplicaciones avanzadas de ayuda al conductor inicializan el iterador con la ID apropiada del horizonte electronico y/u otra information apropiada.
(a) Iterador de recorrido
El iterador de recorrido 402 es un iterador que genera todos los recorridos de un horizonte electronico, un recorrido cada vez. Los iteradores de recorrido permiten la generation de todos los recorridos o solamente de los recorridos que sean accesibles.
(b) Iterador de segmento
El iterador de segmento 404 devuelve una lista de segmentos de horizonte electronico. Dado un nodo, el iterador de segmento 404 devuelve primero el segmento de entrada de dicho nodo (en el contexto de un recorrido en el horizonte electronico) y posteriormente todos los segmentos de salida del nodo (en una orientation en el sentido de las agujas del reloj).
(c) Iterador de punto de segmento
El iterador de punto de segmento 406 es un iterador que devuelve puntos de segmento. Un iterador de punto de segmento 406 puede ser inicializado con un segmento de un horizonte electronico o con un recorrido de un horizonte electronico. Cuando se inicializa con un segmento de un horizonte electronico, el iterador de punto de segmento 406 devuelve todos los puntos del segmento comenzando con el nodo de entrada del segmento. Cuando se inicializa con un recorrido de un horizonte electronico, el iterador de punto de segmento 406 devuelve el primer punto despues de la position actual del vehiculo y posteriormente todos los puntos a lo largo de todos los segmentos que forman el recorrido en el orden en el que tienen lugar en el recorrido. Observese que para un nodo intermedio de un recorrido, el iterador de punto de segmento 406 devuelve primero el nodo de salida del segmento entrante y despues el nodo de entrada del segmento de salida.
(3) Determination de la exactitud de datos
En algunas realizaciones de la base de datos de mapas (130 en las figuras 1, 3A y 3B) algunas carreteras se representan por datos de exactitud superior que otras carreteras. Algunos sistemas avanzados de ayuda al conductor 200 pueden requerir que el vehiculo se encuentre en una carretera representada por los datos de exactitud superior. Alternativamente, algunos sistemas avanzados de ayuda al conductor 200 pueden requerir que todas las carreteras situadas alrededor del vehiculo (por ejemplo, en el horizonte electronico) sean representadas por los datos de exactitud superior. Asi, la arquitectura 100 proporciona unos medios por los que las aplicaciones de ayuda al conductor 200 pueden determinar si el vehiculo se encuentra en una carretera representada por datos de exactitud superior o si todos los segmentos de carretera situados dentro del horizonte electronico se representan por datos de exactitud superior. Si los datos de exactitud superior estan situados en una base de datos suplementaria, tal como la base de datos 130(2) en la figura 1, la determinacion de si los datos son datos de exactitud superior se puede hacer identificando la fuente de los datos (por ejemplo, la base de datos suplementaria 130(2) o la base de datos primaria 130(1)). En una realization de base de datos unica que tiene tanto datos de exactitud superior como datos de exactitud inferior, la determinacion de si los datos son de exactitud superior se puede hacer por referencia a un atributo de datos apropiado (tal como el atributo nivel de exactitud, descrito anteriormente). En algunas realizaciones, el programa de horizonte de datos 110 puede estar configurado para no proporcionar un horizonte electronico a no ser que todos los segmentos de carretera en todos los recorridos del horizonte electronico se representen por datos de exactitud superior.
M. Implementation
La arquitectura de interfaz de datos del sistema avanzado de ayuda al conductor incluye componentes de software y hardware que se ejecutan en una plataforma informatica adecuada. En un sistema prototipo, la arquitectura de interfaz de datos del sistema avanzado de ayuda al conductor se ejecuta en un entorno Microsoft Windows o Microsoft NT incluyendo un ordenador personal en red (Pentium II o superior). Tambien son adecuadas plataformas alternativas.
En un entorno prototipico, se pasan datos de los sensores 120 al ordenador personal conectado mediante una conexion en serie (RS-232).
III. Realizaciones alternativas
A. Arquitectura alternativa de bus a bordo
5
10
15
20
25
30
35
40
45
50
55
60
65
Una realizacion alternativa de la arquitectura de datos de mapas de sistema de ayuda al conductor 600 se representa en la figura 17. De acuerdo con esta alternativa, las aplicaciones de ayuda al conductor 602 se ejecutan en microcontroladores dedicados conectados a un bus de datos a bordo 610. En la presente realizacion, el bus de datos a bordo 610 es un bus CAN, aunque, en realizacion alternativa, el bus a bordo del vehiculo puede ser cualquier otro tipo de bus. En la realizacion de la figura 17, una escucha de datos 620 (que puede ser similar o identica a las escuchas de datos 300, descritas anteriormente) esta adaptada para conectar con el bus de datos a bordo 610 y comunicar lecturas de datos usando los metodos y protocolos convencionales para dicho bus.
B. Horizonte electronico combinado con datos de sensor
En la realizacion del programa de horizonte de datos descrito anteriormente se formo un objeto de datos de horizonte electronico que incluia datos que representan los recorridos que el vehiculo puede seguir a las extensiones del horizonte electronico. Los datos que representan los recorridos incluian datos que representan atributos de la carretera, la geometria de la carretera y objetos de la carretera. En la realizacion descrita anteriormente, los datos que representan los recorridos se obtuvieron de la base de datos de mapas 130 o derivaron de datos en la base de datos de mapas (por ejemplo, la curvatura). De acuerdo con una realizacion alternativa, los datos de horizonte electronico tambien incluyen datos dinamicos. Los datos dinamicos incluyen datos procedentes de los sensores, derivados de los datos de sensor, o derivados de una combination de datos de sensor y datos procedentes de la base de datos de mapas. De acuerdo con la presente realizacion, los datos de sensor pueden estar asociados con uno o varios recorridos en el horizonte electronico. Por ejemplo, si un sensor del sistema de radar en el vehiculo detecta un objeto situado a 100 metros por delante del vehiculo, los datos que indican este objeto detectado se incluyen en el horizonte electronico. Si un recorrido de horizonte electronico corresponde a la position del objeto detectado, los datos que indican el objeto detectado pueden estar asociados con el recorrido en la posicion correspondiente (por ejemplo, en un punto del segmento en el recorrido).
De acuerdo con otro aspecto, si una caracteristica representada por datos en la base de datos de mapas debera ser detectable por uno o mas sensores en el vehiculo, una rutina en el programa de horizonte de datos intenta poner en concordancia la caracteristica representada con un objeto detectado por los sensores. Por ejemplo, suponiendo que el horizonte electronico incluye datos procedentes de la base de datos de mapas que indican la presencia de un paso elevado situado 80 metros por delante del vehiculo y suponiendo tambien que un sensor del sistema de radar en el vehiculo detecta un objeto situado a 82 metros por delante del vehiculo y que se extiende atravesado en la carretera. De acuerdo con esta alternativa, una rutina en el programa de horizonte de datos relaciona los datos procedentes de la base de datos de mapas que indican la presencia del paso elevado y los datos de sensor de radar que indican la presencia de un objeto que se extiende atravesado en la carretera. De acuerdo con otro aspecto de esta alternativa, una rutina en el programa de horizonte de datos puede indicar una diferencia (por ejemplo, una A) entre la posicion del paso elevado como indican los datos procedentes de la base de datos de mapas y la posicion del objeto que se extiende atravesado en la carretera como indica el sensor de radar.
C. Otras alternativas
En la realizacion del deposito de datos descrita anteriormente se describio un mecanismo de manejo de deposito que facilitaba el almacenamiento y el uso de los datos de horizonte electronico. En realizaciones alternativas, cada conjunto de datos que representa un horizonte electronico separado se puede considerar como un conjunto completo de datos (es decir, todos los atributos para cada recorrido).
Como se ha mencionado anteriormente, el motor de datos 170 (en la figura 5) puede estar configurado para determinar un recorrido primario. Si un recorrido primario ha sido determinado por el motor de datos 170, los datos de horizonte electronico (180(1) en la figura 10) contenidos en el deposito de datos 180 pueden incluir solamente los datos de recorrido primarios. Alternativamente, el deposito de datos 180 tambien puede contener tanto datos de recorrido primarios como datos que representan todos los datos de horizonte electronico.
Como se ha mencionado anteriormente, en una realizacion, una aplicacion de ayuda al conductor usa una escucha de datos separada para cada uno de los diferentes tipos de datos que usa la aplicacion de ayuda al conductor. De acuerdo con una realizacion alternativa, se puede usar una sola escucha de datos para mas de un tipo de datos. De acuerdo con esta alternativa, una sola escucha de datos recibe notificaciones acerca de mas de un tipo de datos y responde con peticiones de mas de un tipo de datos. Por ejemplo, de acuerdo con la presente realizacion alternativa, si una aplicacion de ayuda al conductor usa tanto datos de horizonte electronico como datos de sensor, una sola escucha de datos puede estar asociada con la aplicacion de ayuda al conductor y ser usada para recibir notificaciones acerca tanto de los datos de horizonte electronico como de los datos de sensor.
En una realizacion descrita anteriormente, una escucha recibe una notification acerca de la disponibilidad de nuevos datos en el deposito de datos y posteriormente pide que se le envien nuevos datos. De acuerdo con una realizacion alternativa, cuando una escucha recibe una notificacion acerca de la disponibilidad de nuevos datos, puede pedir que los nuevos datos sean enviados por difusion, multidifusion u otros medios, a varias aplicaciones y/o escuchas.
De acuerdo con otra realizacion alternativa, una escucha de datos se registra en el distribuidor de datos y, a continuacion, recibe automaticamente los datos en el horizonte electronico cuando estos pasan a estar disponibles. De acuerdo con esta alternativa, la escucha de datos no recibe primero una notificacion de la disponibilidad de nuevos datos ni pide los nuevos datos a la recepcion de la notificacion. De acuerdo con la presente realizacion 5 alternativa, la escucha de datos puede recibir los nuevos datos por transmision punto a punto, difusion, multidifusion, u otros medios.
IV. Ventajas
10 Las realizaciones de la arquitectura de datos de mapas de sistema avanzado de ayuda al conductor (en las figuras 1 y 17) proporcionan unos medios por los que uno o mas sistemas avanzados de ayuda al conductor pueden usar datos de mapas para soportar la funcion o funciones provistas de ese modo. El uso de datos de mapas por sistemas avanzados de ayuda al conductor puede mejorar las funciones que realizan tales sistemas. La arquitectura descrita en el presente documento proporciona unos medios por los que mas de una aplicacion de ayuda al conductor puede
15 usar los mismos datos de mapas. La arquitectura descrita en el presente documento tambien proporciona unos medios por los que diferentes aplicaciones de ayuda al conductor pueden obtener diferentes tipos de datos de mapas. Ademas, la arquitectura descrita en el presente documento tambien proporciona unos medios por los que diferentes aplicaciones de ayuda al conductor pueden obtener datos de mapas a tasas diferentes.
20 Realizaciones de la arquitectura de datos de mapas descrita en el presente documento proporcionan ventajas adicionales. El software de aplicacion de ayuda al conductor se mantiene separado del programa de horizonte de datos, proporcionando de ese modo versatilidad, compatibilidad y fiabilidad. Ademas, dado que el programa de horizonte de datos implementa una interfaz facil de usar, es relativamente facil el uso del programa de horizonte de datos por parte de diferentes tipos de aplicaciones de ayuda al conductor.
25
Se ha previsto que la descripcion detallada anterior se considere ilustrativa en lugar de limitativa y que se entienda que se ha previsto que las reivindicaciones siguientes, incluyendo todos los equivalentes, definan el alcance de la invention.
Claims (15)
- 510152025303540455055REIVINDICACIONES1. Un metodo de obtencion de datos de horizonte electronico (181) para su uso por aplicaciones (200) que usan los datos de horizonte electronico para proporcionar ayuda a un conductor de un vehiculo mientras se conduce, caracterizado por que el metodo comprende:recibir mensajes que incluyen una identificacion (182) de datos de horizonte electronico (181), en donde los datos de horizonte electronico (181) incluyen datos que representan todos los recorridos a lo largo de segmentos de carretera por los que puede marchar el vehiculo de motor desde la posicion actual del vehiculo hasta una extension asociada con un umbral; yobtener los datos de horizonte electronico (181) usando la identificacion (182) cuando una aplicacion de ayuda al conductor (200) esta preparada para recibir nuevos datos de horizonte electronico (181).
- 2. El metodo de la reivindicacion 1, en el que los mensajes son difundidos por un distribuidor de datos (110).
- 3. El metodo de la reivindicacion 2, que ademas comprende registrarse en el distribuidor de datos (110) para recibir los mensajes.
- 4. El metodo de una cualquiera de las reivindicaciones anteriores, que ademas comprende almacenar la identificacion (182) antes de la obtencion de los datos de horizonte electronico (181).
- 5. El metodo de una cualquiera de las reivindicaciones anteriores, en el que los datos de horizonte electronico (181) se obtienen de un deposito de datos (180).
- 6. El metodo de la reivindicacion 5, en el que los datos de horizonte electronico (181) se obtienen del deposito de datos (180) por medio de un bus CAN.
- 7. El metodo de una cualquiera de las reivindicaciones anteriores, que ademas comprende obtener datos de sensor (180(3)).
- 8. El metodo de una cualquiera de las reivindicaciones anteriores, que ademas comprende obtener datos de posicion de vehiculo (180(2)).
- 9. El metodo de una cualquiera de las reivindicaciones anteriores, que ademas comprende usar un iterador para obtener los datos de horizonte electronico (181).
- 10. El metodo de la reivindicacion 9, en el que el iterador es uno de:un iterador de recorrido (402); un iterador de segmento (404); y un iterador de punto de segmento (406).
- 11. El metodo de una cualquiera de las reivindicaciones anteriores, que ademas comprende determinar el nivel de exactitud de los datos de horizonte electronico (181).
- 12. El metodo de una cualquiera de las reivindicaciones anteriores, que ademas comprende la aplicacion de ayuda al conductor (200) para configurar el umbral.
- 13. El metodo de una cualquiera de las reivindicaciones anteriores, que ademas comprende indicar mediante la aplicacion de ayuda al conductor (200) un tipo de datos que se van a incluir en los datos de horizonte electronico (181).
- 14. Un sistema de ayuda al conductor que comprende unos medios configurados para llevar a cabo un metodo de acuerdo con una cualquiera de las reivindicaciones anteriores.
- 15. Un programa informatico el cual, al ser ejecutado por un ordenador, esta configurado para llevar a cabo un metodo de acuerdo con una cualquiera de las reivindicaciones 1 a 13.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US46651799A | 1999-12-20 | 1999-12-20 | |
| US466517 | 1999-12-20 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2569936T3 true ES2569936T3 (es) | 2016-05-13 |
Family
ID=23852073
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES08019227.1T Expired - Lifetime ES2569936T3 (es) | 1999-12-20 | 2000-12-05 | Plataforma de arquitectura de datos de mapas para sistemas avanzados de ayuda al conductor |
| ES00310805T Expired - Lifetime ES2321907T3 (es) | 1999-12-20 | 2000-12-05 | Arquitectura de datos de mapa para ordenador de vehiculo. |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES00310805T Expired - Lifetime ES2321907T3 (es) | 1999-12-20 | 2000-12-05 | Arquitectura de datos de mapa para ordenador de vehiculo. |
Country Status (5)
| Country | Link |
|---|---|
| EP (2) | EP1111338B1 (es) |
| JP (1) | JP2001229494A (es) |
| AT (1) | ATE423962T1 (es) |
| DE (1) | DE60041624D1 (es) |
| ES (2) | ES2569936T3 (es) |
Families Citing this family (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6829690B1 (en) * | 2000-05-23 | 2004-12-07 | Navteq North America, Llc | Method and system for accessing spatially organized geographic data in blocks |
| DE10303791A1 (de) * | 2003-01-31 | 2004-08-12 | Robert Bosch Gmbh | System und Verfahren zur Bereitstellung ortsabhängiger Daten für prädiktive Informations- und Assistenzsysteme in einem Fahrzeug |
| DE102004014050A1 (de) * | 2004-03-23 | 2005-10-13 | Daimlerchrysler Ag | Verfahren zur Verwaltung digitaler Karten |
| DE102009024153A1 (de) | 2009-06-05 | 2010-12-09 | Daimler Ag | Verfahren zur sukzessiven Prognostizierung eines mit einem Kraftfahrzeug zurückzulegenden wahrscheinlichsten Streckenabschnitts |
| US9566982B2 (en) | 2009-06-16 | 2017-02-14 | Tomtom North America, Inc. | Methods and systems for generating a horizon for use in an advanced driver assistance system (ADAS) |
| WO2011068070A1 (ja) * | 2009-12-01 | 2011-06-09 | 三菱電機株式会社 | 車載情報処理装置および走行支援装置 |
| DE102010007260A1 (de) | 2010-02-09 | 2011-08-11 | Continental Automotive GmbH, 30165 | Prädiktiver eHorizon |
| CN102096082A (zh) * | 2010-11-22 | 2011-06-15 | 东莞市泰斗微电子科技有限公司 | 一种用于卫星导航装置的地图加载方法 |
| US9542241B2 (en) | 2011-07-12 | 2017-01-10 | Harman International Industries, Incorporated | Navigation application interface |
| ITTO20111243A1 (it) * | 2011-12-30 | 2013-07-01 | Magneti Marelli Spa | Sistema e procedimento per la stima del percorso stradale piu'probabile per un veicolo in marcia |
| GB201219742D0 (en) * | 2012-11-02 | 2012-12-12 | Tom Tom Int Bv | Methods and systems for generating a horizon for use in an advanced driver assistance system (adas) |
| US9569984B2 (en) | 2012-12-11 | 2017-02-14 | Abalta Technologies, Inc. | Recording, monitoring, and analyzing driver behavior |
| US11176845B2 (en) | 2012-12-11 | 2021-11-16 | Abalta Technologies, Inc. | Adaptive analysis of driver behavior |
| JP2015161717A (ja) * | 2014-02-26 | 2015-09-07 | 株式会社デンソー | 地図データのデータ構造 |
| CN106033644A (zh) * | 2015-03-20 | 2016-10-19 | 深圳市赛格导航科技股份有限公司 | 一种行车区域限制方法及系统 |
| EP3073224B1 (en) | 2015-03-27 | 2019-05-08 | Panasonic Automotive & Industrial Systems Europe GmbH | Sensor data fusion based on digital map information |
| ITUB20151802A1 (it) * | 2015-07-01 | 2017-01-01 | Magneti Marelli Spa | Sistema a bordo veicolo e procedimento perfezionati per il rilevamento di oggetti in un ambiente circostante un veicolo. |
| EP3130891B1 (en) | 2015-08-11 | 2018-01-03 | Continental Automotive GmbH | Method for updating a server database containing precision road information |
| EP3131020B1 (en) | 2015-08-11 | 2017-12-13 | Continental Automotive GmbH | System and method of a two-step object data processing by a vehicle and a server database for generating, updating and delivering a precision road property database |
| US10466704B2 (en) | 2017-06-22 | 2019-11-05 | GM Global Technology Operations LLC | Autonomous vehicle localization |
| US10899348B2 (en) | 2017-12-20 | 2021-01-26 | Here Global B.V. | Method, apparatus and computer program product for associating map objects with road links |
| DE102018217454A1 (de) | 2018-10-11 | 2020-04-16 | Continental Automotive Gmbh | Verfahren und Backendvorrichtung zur prädiktiven Ladesteuerung für einen elektrischen Energiespeicher eines Kraftfahrzeugs |
| US11635301B2 (en) | 2018-11-02 | 2023-04-25 | Lg Electronics Inc. | Electronic device for vehicle, and method and system for operating electronic device for vehicle |
| CN109974720B (zh) * | 2018-11-27 | 2023-04-07 | 财团法人车辆研究测试中心 | 动态地图数据分类装置及其方法 |
| CN112015832B (zh) * | 2019-05-28 | 2024-06-21 | 阿里巴巴集团控股有限公司 | 路网预测树可视化方法、装置、电子设备及存储介质 |
| US11692845B2 (en) * | 2019-05-30 | 2023-07-04 | Speedgauge, Inc. | Predictive annotation of relevant road information based on vehicle location and identity |
| CN114332174B (zh) * | 2021-12-15 | 2025-06-03 | 腾讯科技（深圳）有限公司 | 轨迹图像对齐方法、装置、计算机设备以及存储介质 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5646843A (en) * | 1990-02-05 | 1997-07-08 | Caterpillar Inc. | Apparatus and method for surface based vehicle control system |
| JPH06111188A (ja) * | 1991-03-27 | 1994-04-22 | Clarion Co Ltd | ナビゲーション装置における走行経路一致方法 |
| US5576964A (en) | 1992-11-30 | 1996-11-19 | Texas Instruments Incorporated | System and method for relating a passive sensor to a geographic environment |
| US5751576A (en) | 1995-12-18 | 1998-05-12 | Ag-Chem Equipment Co., Inc. | Animated map display method for computer-controlled agricultural product application equipment |
| US6199013B1 (en) * | 1997-07-15 | 2001-03-06 | Navigation Technologies Corp. | Maneuver generation program and method |
| JPH11325935A (ja) * | 1998-05-11 | 1999-11-26 | Xanavi Informatics Corp | 経路探索装置 |
| DE19821163A1 (de) * | 1998-05-12 | 1999-11-18 | Volkswagen Ag | Fahrer-Assistenzsystem und Verfahren zu dessen Betrieb |
| JP3976889B2 (ja) * | 1998-05-25 | 2007-09-19 | 三菱電機株式会社 | ナビゲーション装置 |
-
2000
- 2000-12-05 ES ES08019227.1T patent/ES2569936T3/es not_active Expired - Lifetime
- 2000-12-05 EP EP00310805A patent/EP1111338B1/en not_active Expired - Lifetime
- 2000-12-05 EP EP08019227.1A patent/EP2042833B1/en not_active Expired - Lifetime
- 2000-12-05 DE DE60041624T patent/DE60041624D1/de not_active Expired - Lifetime
- 2000-12-05 AT AT00310805T patent/ATE423962T1/de not_active IP Right Cessation
- 2000-12-05 ES ES00310805T patent/ES2321907T3/es not_active Expired - Lifetime
- 2000-12-20 JP JP2000387379A patent/JP2001229494A/ja not_active Withdrawn
Also Published As
| Publication number | Publication date |
|---|---|
| EP1111338A2 (en) | 2001-06-27 |
| EP1111338A3 (en) | 2004-07-07 |
| ES2321907T3 (es) | 2009-06-15 |
| EP2042833B1 (en) | 2016-02-17 |
| ATE423962T1 (de) | 2009-03-15 |
| EP1111338B1 (en) | 2009-02-25 |
| JP2001229494A (ja) | 2001-08-24 |
| DE60041624D1 (de) | 2009-04-09 |
| EP2042833A1 (en) | 2009-04-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2569936T3 (es) | Plataforma de arquitectura de datos de mapas para sistemas avanzados de ayuda al conductor | |
| US6405128B1 (en) | Method and system for providing an electronic horizon in an advanced driver assistance system architecture | |
| US9341485B1 (en) | Method and apparatus for representing road intersections | |
| CA2245986C (en) | Method and apparatus for displaying current vehicle position | |
| US5731978A (en) | Method and apparatus for enhancing vehicle navigation through recognition of geographical region types | |
| EP0689034B1 (en) | Method for identifying highway access ramps for route calculation in a vehicle navigation system | |
| US7477988B2 (en) | Dual road geometry representation for position and curvature-heading | |
| US7734410B2 (en) | Navigation system | |
| JP3413087B2 (ja) | 車両ナビゲーションシステムにより近接ルートを案内する方法及び装置 | |
| US7463974B2 (en) | Systems, methods, and programs for determining whether a vehicle is on-road or off-road | |
| US6144919A (en) | Method and apparatus for using non-digitized cities for route calculation | |
| EP1039266A2 (en) | Position determining program and method | |
| EP0840269A1 (en) | Method and apparatus for use in a vehicle navigation system | |
| CN111307167A (zh) | 用于通过区域的路线生成的方法和系统 | |
| US20090043488A1 (en) | Navigation system, server, method, and program | |
| US20200240801A1 (en) | Systems, methods, and computer program product for route validation |