ES2321907T3 - Arquitectura de datos de mapa para ordenador de vehiculo. - Google Patents
Arquitectura de datos de mapa para ordenador de vehiculo. Download PDFInfo
- Publication number
- ES2321907T3 ES2321907T3 ES00310805T ES00310805T ES2321907T3 ES 2321907 T3 ES2321907 T3 ES 2321907T3 ES 00310805 T ES00310805 T ES 00310805T ES 00310805 T ES00310805 T ES 00310805T ES 2321907 T3 ES2321907 T3 ES 2321907T3
- Authority
- ES
- Spain
- Prior art keywords
- data
- vehicle
- segment
- horizon
- architecture
- 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 95
- 238000013500 data storage Methods 0.000 claims description 6
- 238000003860 storage Methods 0.000 claims description 6
- 230000005540 biological transmission Effects 0.000 claims description 5
- 230000006870 function Effects 0.000 description 94
- 230000008569 process Effects 0.000 description 84
- 238000004364 calculation method Methods 0.000 description 54
- 230000007704 transition Effects 0.000 description 15
- 238000010586 diagram Methods 0.000 description 13
- 230000007246 mechanism Effects 0.000 description 11
- 230000003044 adaptive effect Effects 0.000 description 9
- 230000015572 biosynthetic process Effects 0.000 description 9
- 230000008901 benefit Effects 0.000 description 8
- 230000001419 dependent effect Effects 0.000 description 8
- 230000008859 change Effects 0.000 description 7
- 238000007726 management method Methods 0.000 description 6
- 238000012545 processing Methods 0.000 description 5
- 238000012360 testing method Methods 0.000 description 5
- 230000000717 retained effect Effects 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000012549 training Methods 0.000 description 3
- 125000004122 cyclic group Chemical group 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000007613 environmental effect Effects 0.000 description 2
- 230000010354 integration 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
- 238000011084 recovery Methods 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
- 238000000848 angular dependent Auger electron spectroscopy Methods 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 239000004020 conductor Substances 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000000694 effects Effects 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
- 238000010561 standard procedure Methods 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
Una arquitectura de datos para un vehículo de motor (108) para proporcionar datos continuamente actualizados acerca de recorridos a lo largo de carreteras por las que puede marchar el vehículo de motor desde una posición actual del vehículo de motor cuando el vehículo de motor avanza a lo largo de dichas carreteras, incluyendo la arquitectura de datos: una base de datos de mapa (130) conteniendo datos acerca de carreteras en una región geográfica; y un programa de localización de vehículo (150(2)(1)) que usa datos de sensores (120) para proporcionar una salida que indica una posición actual a lo largo de un segmento de carretera representado por datos en dicha base de datos de mapa; caracterizado porque la arquitectura de datos incluye: un programa de horizonte de datos (170) que usa la salida del programa de localización de vehículo y datos de la base de datos de mapa para determinar posibles recorridos que el vehículo de motor podría seguir desde dicha posición actual a un destino, siendo cada recorrido una secuencia correspondiente de uno o más segmentos de carretera que se representan por datos en dicha base de datos de mapa; y un depósito de datos (180) para almacenar datos que representan los recorridos determinados por el programa de horizonte de datos.
Description
Arquitectura de datos de mapa para ordenador de
vehículo.
La presente solicitud está relacionada con la
solicitud en tramitación titulada "Método y sistema para
proporcionar un horizonte electrónico en una arquitectura de
sistema avanzado de ayuda al conductor" presentada en la misma
fecha que la presente, Expediente número N0029US, cuya descripción
completa se incorpora aquí por referencia.
La presente invención se refiere a una
plataforma de arquitectura de datos de mapa que puede ser usada en
vehículos de carretera, como automóviles, camiones, buses, etc, y la
presente invención se refiere en concreto a una plataforma de
arquitectura de datos de mapa que soporta sistemas avanzados de
ayuda al conductor dispuestos en vehículos de carretera.
Los sistemas avanzados de ayuda al conductor
("ADAS") se han desarrollado con la intención de mejorar la
seguridad, comodidad, eficiencia, y satisfacción general de la
conducción. Los ejemplos de sistemas avanzados de ayuda al
conductor incluyen sistema de faros adaptativos, control de crucero
adaptativo, y control de cambio adaptativo. El sistema de faros
adaptativos regula los faros del vehículo, es decir, la anchura, el
ángulo rotacional, el ángulo de elevación y el brillo, en base a la
curva de la carretera delante del vehículo, la inclinación, el
cambio de elevación, y otros factores. El control de crucero
adaptativo mantiene y/o reanuda una velocidad establecida o
distancia segura de seguimiento con respecto a otros vehículos a
menor velocidad que la establecida en base a datos acerca de la
velocidad del vehículo, los vehículos próximos y otros obstáculos,
tipo de carretera recorrida (autovía frente a carretera local), la
curva de la carretera, la inclinación, la elevación y otros
factores. El control de cambio adaptativo regula la
desmultiplicación y el cambio de transmisiones automáticas en base
a datos del sensor acerca de la velocidad del vehículo, la velocidad
del motor, la curva de la carretera, la inclinación, elevación y
otros factores. Hay otros sistemas avanzados de ayuda al conductor
además de estos.
Estos sistemas avanzados de ayuda al conductor
utilizan varios mecanismos sensores en el vehículo para determinar
el estado corriente del vehículo y el estado corriente de la
carretera en la parte delantera del vehículo. Estos mecanismos
sensores pueden incluir sensores de radar y de orientación por
visión, como cámaras. Aunque los sensores de radar y de orientación
por visión son componentes importantes de los sistemas avanzados de
ayuda al conductor, estos componentes tienen limitaciones. La
distancia y/o la exactitud de los sensores de radar o de
orientación por visión pueden quedar afectados por determinadas
condiciones medioambientales, tales como niebla, lluvia intensa o
nieve, o carreteras cubiertas de nieve. Además, los sistemas de
radar y de orientación por visión no detectan fiablemente algunos
atributos útiles de la carretera, tales como limitaciones de
velocidad, señales de tráfico, cruces elevados, etc. Además, los
sensores de radar y de orientación por visión no pueden "ver"
a la vuelta de esquinas u otros obstáculos y por lo tanto pueden
estar limitados en tales circunstancias.
Una forma de afrontar las limitaciones de los
sistemas de radar y de orientación por visión es usar datos de
mapas digitales como un componente adicional en sistemas avanzados
de ayuda al conductor. Los datos de mapas digitales pueden ser
usados en sistemas avanzados de ayuda al conductor para proporcionar
información acerca de la carretera que hay delante. Los datos de
mapas digitales no quedan afectados por condiciones
medioambientales, tales como niebla, lluvia o nieve. Además, los
datos de mapas digitales pueden proporcionar información útil que
no puede ser proporcionada fiablemente por sistemas de orientación
por visión, tales como límites de velocidad, restricciones de
tráfico y carriles, etc. Además, los datos de mapas digitales pueden
ser usados para determinar la carretera por delante del vehículo
incluso alrededor de esquinas o más allá de obstáculos.
Consiguientemente, los datos de mapas digitales pueden ser una
adición útil en sistemas avanzados de ayuda al conductor.
Aunque los datos de mapas digitales pueden ser
usados como un componente adicional en sistemas avanzados de ayuda
al conductor, quedan problemas por resolver antes de que los datos
de mapas digitales puedan ser usados ampliamente para tales fines.
Por ejemplo, hay que manejar eficientemente la cantidad
relativamente grande de datos de mapas digitales requeridos para
sistemas avanzados de ayuda al conductor. Además, los diferentes
sistemas avanzados de ayuda al conductor requieren diferentes tipos
y cantidades de datos de mapas digitales y por lo tanto hay que
proporcionar los datos de mapas digitales que necesitan los varios
sistemas avanzados de ayuda al conductor.
US5684696 describe un sistema que permite a
vehículos autónomos seguir un recorrido deseado que planea un
recorrido continuo de retorno al recorrido deseado cuando el
vehículo se ha desviado del recorrido deseado.
Según un primer aspecto de la invención, se
facilita una arquitectura de datos según la reivindicación 1. Según
un segundo aspecto de la invención, se facilita un método según la
reivindicación 28.
Para alcanzar estos y otros objetivos, una
realización de la presente invención incluye una arquitectura de
datos para un vehículo de motor para proporcionar datos
continuamente actualizados acerca de carreteras por las que puede
marchar el vehículo de motor desde una posición actual del vehículo
de motor cuando el vehículo de motor avanza a lo largo de las
carreteras. La arquitectura de datos incorpora una base de datos de
mapa conteniendo datos acerca de carreteras en una región
geográfica y un programa de localización de vehículo que usa datos
de sensores para proporcionar una salida que indica una posición
actual a lo largo de un segmento de carretera representado por
datos en la base de datos de mapa. La arquitectura de datos también
incluye un programa de horizonte de datos que usa la salida del
programa de localización de vehículo y datos de la base de datos de
mapa para determinar uno o más recorridos que el vehículo de motor
puede recorrer al pasar de la posición corriente del vehículo a una
extensión asociada con un umbral. Los datos que representan los
recorridos determinados por el programa de horizonte de datos se
guardan en un depósito 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 geometría de la carretera,
atributos de la carretera, y objetos a lo largo de cada
recorrido.
\vskip1.000000\baselineskip
La figura 1 es un diagrama de bloques
funcionales de la arquitectura de datos de mapa 100 del sistema
avanzado de ayuda al conductor.
La figura 2 es un diagrama de bloques del
componente sensor de la arquitectura de datos de mapa 100 del
sistema avanzado de ayuda al conductor representada en la figura
1.
Las figuras 3A y 3B muestran los tipos de datos
contenidos en el componente de base de datos de mapa de la
arquitectura de datos de mapa 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 ilustración de una porción de
una red de carreteras con una ilustración de un horizonte
electrónico superpuesto encima.
La figura 7 es una ilustración de
identificadores de segmentos usados al describir recorridos en un
horizonte electrónico.
La figura 8 es una ilustración de descriptores
de recorrido en un horizonte electrónico.
La figura 9 es una ilustración de un descriptor
de recorrido para un giro en U.
La figura 10 es un diagrama de bloques que
representa componentes del depósito 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 electrónico en el depósito de datos en la figura 10.
La figura 12 es un diagrama de bloques que
representa componentes adicionales del depósito 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 realización de una aplicación de ayuda al conductor
asociada con múltiples escuchas.
La figura 16 es un diagrama de bloques que
representa cómo una aplicación de ayuda al conductor usa varias
funciones para obtener datos de horizonte electrónico.
La figura 17 es un diagrama de bloques que
representa una realización alternativa de la arquitectura de datos
de mapa de sistemas de ayuda al conductor.
\vskip1.000000\baselineskip
En esta memoria descriptiva se utiliza la
terminología y los conceptos siguientes. (No se ha previsto que la
terminología y definiciones aquí dadas sean limitativas. Se puede
utilizar otra terminología y definiciones para expresar conceptos
similares o idénticos).
(1) Segmentos y nodos. Un "segmento"
(también 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. Según una realización, los segmentos y
los nodos se representan por datos en una base de datos de mapa
usada por la arquitectura de datos de mapa del 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 pueden ser usados para modelar la curvatura de un segmento
de carretera. Los puntos de forma también pueden ser usados para
modelar pasos elevados y pasos subterráneos. Por ejemplo, cuando un
segmento de carretera cruza otro segmento de carretera a una altura
diferente (por ejemplo, un paso elevado o paso subterráneo), un
punto de forma está asociado con cada segmento de carretera en la
posición del cruce y un atributo de cada forma de punto indica una
altitud relativa o una altitud absoluta del segmento de carretera
asociado en dicha posición. Según una realización, los puntos de
forma se representan en la base de datos de mapa usada por la
arquitectura de datos de mapa del sistema de ayuda al conductor.
(3) Dirección de marcha. La "dirección
de marcha" en un segmento (la dirección permisible de marcha de
un vehículo en un segmento) se expresa en términos 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 primero 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
posición geográfica (por ejemplo, latitud, longitud, y altitud)
asociada con él.
(6) Posición de segmento. Una "posición
de segmento" es cualquier lugar en un segmento. Mientras que el
término "punto" solamente se refiere a nodos y puntos de forma
de segmentos, una posición de segmento incluye todas las posiciones
en un segmento incluyendo los nodos, todos los puntos de forma, y
todos los puntos lógicos (es decir, posiciones) entre los nodos y
los puntos de forma.
(7) Rumbos y direcciones de segmento. El
"rumbo" de un segmento en un nodo se refiere a la dirección del
segmento en dicho nodo. La dirección se mide desde el nodo hacia el
interior del segmento. Por ejemplo, el rumbo en el nodo izquierdo
es el rumbo de un vehículo en el nodo izquierdo cuando el vehículo
avanza del nodo izquierdo al derecho. El rumbo de un segmento en el
nodo izquierdo o derecho se calcula a partir del valor de rumbo en
el nodo apropiado más 180 grados.
(8) Curvatura. La "curvatura"
describe cómo una porción de un segmento se curva en un punto o una
posición 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 círculo que
corresponde a la curva del segmento en dicho punto. Según una
realización, la curvatura se representa por datos en una base de
datos de mapa usada por la arquitectura de datos de mapa del
sistema de ayuda al conductor. Según otra realización, 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 más segmentos de carretera (o porciones de los
mismos) que un vehículo podría recorrer desde una posición
actual.
(10) Objetos de carretera. Un "objeto
de carretera" se refiere a un objeto situado en o a lo largo de
una carretera, tal como una señal o un paso de peatones.
(11) Geometría de la carretera.
"Geometría de la carretera" se refiere a la forma y curvatura
de una carretera. La forma de la carretera se define por las
coordenadas geográficas de puntos a lo largo de un segmento de
carretera. ("Curvatura" se describe por separado más
adelante).
\vskip1.000000\baselineskip
La figura 1 es un diagrama de bloques
funcionales de la arquitectura de datos de mapa 100 del sistema
avanzado de ayuda al conductor. La arquitectura de datos de mapa
100 del sistema avanzado de ayuda al conductor es una combinación
de componentes de software y hardware instalados en un vehículo de
motor 108. La arquitectura de datos de mapa 100 del sistema
avanzado de ayuda al conductor proporciona acceso a datos
relacionados con mapa para uso por aplicaciones 200 del sistema
avanzado de conducción. La arquitectura de datos de mapa 100 del
sistema avanzado de ayuda al conductor incluye los componentes
siguientes.
(1) Sensores 120. Los sensores 120
proporcionan salidas que se usan mediante programación en la
arquitectura de datos de mapa 100 del sistema avanzado de ayuda al
conductor para determinar la posición del vehículo 108 en la red de
carreteras y para proporcionar otra información, tal como velocidad
y rumbo del vehículo. (Además de estos sensores 120, las
aplicaciones 200 del sistema avanzado de conducción pueden usar las
salidas de otros tipos de sensores 122. Estos otros tipos de
sensores 122 pueden incluir sensores del tipo de sistema de radar o
de visión).
(2) Una base de datos de mapa 130. La
base de datos de mapa 130 incluye información acerca de
características geográficas, tal como carreteras y puntos de
interés, en la zona geográfica en que avanza el vehículo 108 en el
que se ha instalado la arquitectura de datos de mapa 100 del sistema
avanzado de ayuda al conductor.
(3) Programa de horizonte de datos 110.
La arquitectura de datos de mapa del sistema de ayuda al conductor
100 incluye un programa de horizonte de datos 110. El programa de
horizonte de datos 110 incluye el programa que usa la base de datos
de mapa 130 y entradas de los sensores 120 para proporcionar datos
relacionados con mapa a los sistemas avanzados de ayuda al
conductor 200.
(4) Componentes de herramientas de software
150. En esta realización, 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
programación para acceder a la base de datos de mapa 130 y programas
de herramientas de software para realizar ciertas funciones
requeridas con los datos de mapa obtenidos de la base de datos de
mapa 130.
(5) Un programa de supervisión 160. El
programa de supervisión 160 es un componente de software de la
arquitectura de datos de mapa 100 del sistema avanzado de ayuda al
conductor que permite supervisar la ejecución del programa de
horizonte de datos 110.
(6) Un programa de configuración 165. El
programa de configuración 165 es un componente de software de la
arquitectura de datos de mapa 100 del sistema avanzado de ayuda al
conductor que permite la configuración 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
mapa 130 los datos relevantes acerca de la carretera que está
delante (o detrás) del vehículo.
(8) Un depósito de datos 180. El depósito
de datos 180 es un componente del programa de horizonte de datos
110. El depósito de datos 180 contiene los últimos datos relevantes
acerca de la carretera que está delante (o detrás) del vehículo
determinados 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 notifica que nuevos
datos acerca de la carretera que está delante (o detrás) del
vehículo han sido almacenados en el depósito de datos 180.
(10) Una o más aplicaciones avanzadas de
ayuda al conductor 200. Estas aplicaciones 200 usan los datos
relacionados con mapa proporcionados por el programa de horizonte
de datos 110. Estas aplicaciones 200 pueden incluir sistema de
faros adaptativos, control de crucero adaptativo, detección de
obstáculos, prevención de obstáculos, prevención de choques,
control de cambio adaptativo y otros.
(11) Una o más 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 depósito de datos 180. Una escucha de datos 300 se
puede implementar como parte de cada aplicación de ayuda al
conductor 200 o una escucha de datos se puede implementar como un
componente de software autónomo.
Cada uno de los componentes anteriores de la
arquitectura de datos de mapa 100 del sistema avanzado de ayuda al
conductor se describe con más detalle más adelante.
\vskip1.000000\baselineskip
Con referencia a las figuras 1 y 2, el programa
de horizonte de datos 110 recibe las salidas de los sensores de
posición 120. Según una realización, estos sensores 120 incluyen un
sistema GPS 120(1), un giroscopio 120(2), un sensor
de velocidad del vehículo 120(3) y un sensor de marcha hacia
delante/hacia atrás del vehículo 120(4). También se puede
incluir otros tipos de sensores 120(5). Por ejemplo, los
sensores pueden incluir sensores de navegación inerciales.
En una realización, el sistema GPS 120(1)
es un sistema fabricado por Trimble y el giroscopio 120(2) es
una unidad fabricada por Murata. También se puede usar equipo de
otros fabricantes. Los datos que indican la velocidad del vehículo
y/o la dirección hacia delante/hacia atrás del vehículo se pueden
obtener de sensores o componentes previstos para otros fines en
otro lugar en el vehículo 108. En una realización, las señales del
giroscopio y de la velocidad son recogidas cada 100 milisegundos.
El GPS y el sensor de dirección hacia delante/hacia atrás del
vehículo se han puesto a una frecuencia de una vez por segundo. En
otras realizaciones, las salidas de los sensores se pueden poner a
frecuencias diferentes.
Con referencia de nuevo a la figura 1, la base
de datos de mapa 130 incluye información acerca de carreteras,
intersecciones, puntos de interés, y posiblemente otras
características geográficas en la región geográfica en que avanza
el vehículo 108 en el que se ha instalado la arquitectura de datos
de mapa 100 del sistema avanzado de ayuda al conductor. En la
realización representada en la figura 1, la base de datos de mapa
130 está formada por una o más bases de datos componentes.
Específicamente, la base de datos de mapa 130 incluye una base de
datos primaria
130(1) y una base de datos suplementaria 130(2).
130(1) y una base de datos suplementaria 130(2).
La base de datos de mapa primaria 130(1)
puede ser similar o idéntica a una base de datos usada en sistemas
de navegación en vehículo. Según esta realización, la base de datos
de mapa primaria 130(1) soporta funciones relacionadas con
la navegación, incluyendo posición del vehículo, cálculo de ruta,
guía de ruta, y visualización del mapa. La base de datos primaria
130(1) también proporciona soporte para una porción de las
funciones del sistema avanzado de ayuda al conductor. En esta
realización, la base de datos primaria 130(1) también
proporciona una porción de las lecturas de datos proporcionadas a
las aplicaciones de ayuda al conductor 200, como se describe más
adelante.
En una realización, la base de datos de mapa
primaria 130(1) es una base de datos en el formato de
almacenamiento físico SDAL^{TM} desarrollado y publicado por
Navigation Technologies Corporation de Rosemont, Illinois. En una
realización, la base de datos primaria 130(1) está en la
versión 1.7 del formato de almacenamiento físico SDALTM. Una
realización adecuada de una base de datos de mapa primaria se
describe en la Patente de Estados Unidos número 5.968.109, cuya
descripción completa se incorpora aquí por referencia. (la materia
novedosa aquí descrita no se limita a ningún formato específico de
base de datos).
La base de datos suplementaria 130(2)
también contiene datos acerca de carreteras e intersecciones en la
región geográfica. Sin embargo, la base de datos suplementaria
130(2) incluye datos que no están necesariamente en la base
de datos de mapa primaria 130(1). La base de datos de mapa
suplementaria 130(2) puede incluir datos de mayor calidad
(es decir, más exactos) que los datos contenidos en la base de datos
primaria 130(1). Por ejemplo, con respecto a la geometría de
la carretera, los datos en la base de datos suplementaria
130(2) pueden ser más exactos con respecto a la longitud, la
latitud y/o la altitud. Además, las posiciones de inicio y fin de
túneles pueden estar especificadas más exactamente en la base de
datos suplementaria 130(2) que en la base de datos primaria
130(1). Además, los datos en la base de datos suplementaria
130(2) pueden ser más exactos con respecto a información
derivada, tal como la curvatura.
La base de datos suplementaria 130(2)
también puede incluir más tipos de datos (por ejemplo, más 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 carretera, tal como señales y pasos de peatones incluyendo sus posiciones a lo largo del segmento de carretera, tipo de objeto de señal y texto de señal. La base de datos suplementaria 130(2) también puede incluir datos que indican si una carretera está bordeada por árboles, etc.
130(2) puede incluir datos acerca de objetos de carretera, tal como señales y pasos de peatones incluyendo sus posiciones a lo largo del segmento de carretera, tipo de objeto de señal y texto de señal. La base de datos suplementaria 130(2) también puede incluir datos que indican si una carretera está bordeada por árboles, etc.
Según una realización, 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 región cubierta. Según esta alternativa, los
datos de la base de datos suplementaria 130(2) complementan
la representación de cada segmento de carretera que también se
representa en la base de datos primaria 130(1).
Según una realización alternativa, la base de
datos suplementaria 130(2) representa menos carreteras que la
base de datos primaria 130(1). En esta realización
alternativa, mientras que la base de datos primaria 130(1)
puede incluir datos que representan todas las carreteras e
intersecciones en la región cubierta, la base de datos
suplementaria
130(2) incluye datos que representan solamente una porción de todas las carreteras en la región cubierta. Por ejemplo, la base de datos suplementaria 130(2) puede incluir solamente las carreteras con los mayores volúmenes de tráfico (por ejemplo, autopistas, vías públicas principales). Los segmentos de carretera representados por la base de datos suplementaria 130(2) también pueden estar representados por datos en la base de datos primaria 130(1).
130(2) incluye datos que representan solamente una porción de todas las carreteras en la región cubierta. Por ejemplo, la base de datos suplementaria 130(2) puede incluir solamente las carreteras con los mayores volúmenes de tráfico (por ejemplo, autopistas, vías públicas principales). Los segmentos de carretera representados por la base de datos suplementaria 130(2) también pueden estar representados por datos en la base de datos primaria 130(1).
Según otra realización alternativa, en lugar de
usar dos bases de datos separadas, la arquitectura de datos de mapa
del sistema de ayuda al conductor 100 utiliza una sola base de
datos. En esta realización 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
realización de una sola base de datos, todas las carreteras pueden
estar representadas por datos que tienen el estándar de alta
exactitud de la base de datos suplementaria. Alternativamente, en la
realización de una sola base de datos, solamente algunas de las
carreteras representadas se representan por los datos de exactitud
más alta y el resto de las carreteras se representan por unos datos
de exactitud inferior.
En la realización de una sola base de datos que
contiene datos de exactitud más alta y datos de exactitud inferior,
se ha previsto unos medios para indicar si un segmento de carretera
representado se representa por datos de exactitud más alta 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
un estándar de alta exactitud especificado. 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 designación de nivel de
exactitud (por ejemplo, 0-7).
Como se ha indicado anteriormente, en algunas
realizaciones de la base de datos de mapa 130 algunas carreteras se
representan por datos que tienen un nivel de exactitud
suficientemente alto para 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 uso por aplicaciones del sistema avanzado de ayuda al
conductor. En estas realizaciones, se ha previsto unos medios por
los que los datos de exactitud más alta son integrados con los
datos de exactitud inferior (o desconocidos). Para realizar esta
integración, en la base de datos de mapa 130 se incluyen datos para
representar segmentos de transición. Un "segmento de
transición" es un segmento que está 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 de un nivel de exactitud inferior (o desconocidos). En un
segmento de transición, las coordenadas del nodo conectado al
segmento representado por datos que tienen un alto nivel de
exactitud se almacenan al nivel de exactitud más alto. Sin embargo,
las coordenadas del nodo conectado al segmento representado por
datos de un nivel de exactitud inferior (o desconocidos) se
almacenan al nivel de exactitud inferior. Por lo tanto, según esta
realización, hay tres clases de segmentos: (1) segmentos
representados por datos de alta exactitud, (2) segmentos
representados por datos de exactitud inferior (o desconocidos), y
(3) segmentos de transición que conectan (1) y (2).
Como se ha indicado anteriormente, la base de
datos de mapa 130 incluye información acerca de carreteras e
intersecciones. Según una realización, la base de datos de mapa 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 mapa 130 incluye (datos) atributos
asociados con las entidades de datos de segmento y (datos) atributos
asociados con las entidades de datos de nodo. Los atributos de nodo
se refieren a una propiedad o característica de los nodos de extremo
de un segmento. Los atributos de segmento se refieren a una
propiedad o característica asociada con el segmento en conjunto o
con un punto específico (posición) a lo largo del segmento.
Los ejemplos de atributos de nodo incluyen los
siguientes:
(1) El número de segmentos que se extienden
desde el nodo corriente. Este recuento incluye el segmento corriente
(es decir, el segmento de entrada). Todos los segmentos son
contados, tanto si son accesible como si no.
(2) El número de posibles giros que el vehículo
puede realizar en el modo especificado. (No se incluyen en este
recuento los giros en U).
Además de los anteriores, otros varios atributos
pueden estar asociados con nodos, incluyendo coordenadas
geográficas, altitud, nombre, identificación (por ejemplo, por
número de ID) de segmentos de carretera conectados, limitaciones de
giro, etc.
Como se ha indicado anteriormente, los atributos
de segmento pueden estar relacionados con una propiedad o
característica asociada con un punto específico (posición) 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 a uno de los dos nodos
de extremo de un segmento o 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 realización de la presente invención,
algunos atributos dependientes de punto están asociados con una
dirección de marcha a lo largo de un segmento. Un atributo de
"señal de stop" es un ejemplo de un atributo dependiente de
punto asociado con una dirección de marcha. Un atributo de "señal
de stop" indica la presencia de una señal de stop en un punto a
lo largo de un segmento asociado con una dirección específica de
recorrido (por ejemplo, puede no haber una señal de stop al avanzar
en la dirección contraria a lo largo del segmento).
Un atributo de "señal de stop" también es
un ejemplo de un atributo booleano. Un atributo booleano es un
atributo dependiente de punto que es verdadero o falso en el punto
específico. Una "señal de stop" se modela usando un atributo
booleano porque una señal de stop está presente o no en un punto
específico.
Otro tipo de atributo dependiente de punto es un
atributo de transición booleano. Los atributos de transición
booleanos describen propiedades o características que se aplican a
cada posición en un segmento, no solamente a los puntos de un
segmento. Un atributo de transición booleano es un atributo que
cambia de valor solamente en puntos de segmento, si es que cambia.
(los términos "antes" y "después" se refieren a un
vehículo que se aproxima a un punto y supera dicho punto). Por
ejemplo, para cualquier posición en un segmento (no solamente
cualquier punto), dada una dirección de marcha, el "paso" de
vehículos está permitido o no. Con el fin de modelar si está
permitido el "paso" de vehículos, se supone que alguna señal
relacionada (tal como "inicio de zona de no paso" y "fin de
zona de no paso") está situada en un punto de un segmento. Si
éste es el caso, se aplica uno de los siguientes a cualquier punto
del segmento.
Transición verdadero -> verdadero: Está
permitido el paso antes del punto y después del punto.
Transición verdadero -> falso: Está permitido
el paso antes del punto, pero no después del punto.
Transición falso -> verdadero: No está
permitido el paso antes del punto, pero sí después del punto.
Transición falso -> falso: No está permitido
el paso antes del punto y tampoco está permitido después del
punto.
\vskip1.000000\baselineskip
Otro tipo de atributo dependiente de punto es un
atributo de transición de rango entero. Un atributo de transición
de rango entero es un atributo que representa rangos enteros o
intervalos enteros. Un atributo de rango entero 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
cuándo se usa un atributo de transición de rango entero es para
"información de velocidad máxima". Un valor de rango entero
tal como {20 ... 29} significa que la velocidad legal máxima es
entre 20 y 29 km/h. Un valor de rango entero tal como {20 ... 20}
significa que la velocidad legal máxima es exactamente 20 km/h.
También se pueden especificar valores para diferentes horas del
día.
Algunos atributos de segmento pueden ser
idénticos para cada punto del segmento (por ejemplo, un nombre de
carretera). Tales atributos pueden ser especificados una vez para
todo el segmento.
La información de atributo dependiente de punto
puede ser almacenada en formato SDAL^{TM} 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 mapa 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.
Según una realización, 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 cómo una porción de
un segmento se curva en dicho punto. En una realización de la
presente invención, la curvatura se define para los puntos de un
segmento (es decir, puntos de forma, nodos). Dos componentes
describen la curvatura: una dirección de curvatura (curva
izquierda, curva derecha y recto) y un radio de curvatura. No se
define ningún radio de curvatura para el caso de una línea recta o
casi recta. (Un segmento en el que el radio de curvatura excede de
un valor umbral configurable puede ser considerado como una línea
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
acelerómetro) y almacenar la medición como un atributo de datos
asociado con un punto en la base de datos de mapa 130. Otra forma de
obtener datos de curvatura es calcular la curvatura usando datos de
posición. Para una secuencia de tres puntos, la curvatura en el
punto medio se puede determinar calculando el radio de un círculo
cuya circunferencia incluye las posiciones de los tres puntos. Los
datos de curvatura obtenidos por cálculo usando datos de posición se
pueden almacenar en la base de datos de mapa 130. Alternativamente,
la curvatura se puede calcular según sea necesario por una función
de software en el vehículo. Tal función de software puede estar
incluida entre las aplicaciones del sistema avanzado de ayuda al
conductor 200 usando datos de posición asociados con puntos
almacenados en la base de datos de mapa 130. Alternativamente, una
función de software que calcula la curvatura a partir de datos de
posición puede estar incluida en el programa de horizonte de datos
110.
Los componentes de herramientas de software 150
proporcionan la base sobre la que se construye el programa de
horizonte de datos 110. En la realización representada en las
figuras 1 y 4, los componentes de herramientas de software 150
incluyen una capa de acceso de datos 150(1), aplicaciones de
navegación 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 mapa 130. En una realización, la capa
de acceso de datos 150(1) es la librería SDAL^{TM} que se
puede obtener de Navigation Technologies Corporation de Rosemont,
Illinois. La capa de acceso de datos 150(1) proporciona un
conjunto de interfaces de programa de aplicación (API) en forma de
librerías de software para acceso eficiente a los atributos de mapa
en la base de datos primaria
130(1). Una realización de la capa de acceso de datos 150(1) se describe en la Solicitud pendiente número de serie 08/740.298, presentada el 25 de octubre de 1996, cuya descripción completa se incorpora aquí por referencia.
130(1). Una realización de la capa de acceso de datos 150(1) se describe en la Solicitud pendiente número de serie 08/740.298, presentada el 25 de octubre de 1996, cuya descripción completa se incorpora aquí por referencia.
Las aplicaciones de navegación 150(2)
realizan funciones similares a las usadas en sistemas de navegación
a bordo del vehículo. Según una realización, las aplicaciones de
navegación 150(2) están dispuestas en forma de rutinas de
librerías de software API. Estas rutinas de librerías de software
API realizan operaciones usadas frecuentemente en aplicaciones
relacionadas con datos de mapa. Entre las aplicaciones de navegación
150(2) se incluyen posición del vehículo 150(2)(1),
visualización de mapas 150(2)(2), cálculo de ruta
150(2)(3), geocodificación 150(2)(4), y guía de
dirección 150(2)(5). En una realización, las aplicaciones de
navegación 150(2) son el software NavTools^{TM} que se
puede obtener de Navigation Technologies Corporation de Rosemont,
Illinois. Se describen realizaciones de aplicaciones de navegación
para posición del vehículo, visualización de mapas, cálculo de ruta
y guía de dirección en las Solicitudes pendientes números de serie
09/276.377, 09/047.141, 09/047.698, 08/893.201, y 09/196.279, cuyas
descripciones completas se incorporan aquí por referencia.
La estructura de objeto 150(3)
proporciona una envuelta orientada a objeto alrededor de la capa de
acceso de datos 150(1) y las aplicaciones de navegación
150(2). La estructura de objeto 150(3) simplifica el
uso de la capa de acceso de datos 150(1) y las aplicaciones
de navegación 150(2). La estructura de objeto 150(3)
también puede facilitar el desarrollo de aplicaciones en algunas
plataformas (por ejemplo, un entorno de Microsoft Windows/NT).
En una realización, la arquitectura de datos de
mapa 100 del sistema avanzado de ayuda al conductor usa XML
(lenguaje de marcación extensible). Por ejemplo, se puede generar
archivo de registro y otra información en XML. Igualmente, parte de
la información leída por la arquitectura de datos de mapa 100 del
sistema avanzado de ayuda al conductor puede ser codificada en XML.
Una ventaja de tener un formato de archivo para múltiples fines
simplifica la manipulación y el procesado adicional de información
de entrada y salida. El uso de XML es ventajoso en un entorno de
desarrollo y prueba.
En una realización se puede usar Internet
Explorer versión 5.0 (1E5) de Microsoft u otro programa que soporte
XML como un formato nativo de archivos. 1E5 también procesa XSL
(archivos de estilo relacionado con XML). Esto permite presentar
archivos XML en formas diferentes.
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 electrónico (descrito con más detalle más
adelante). El motor de datos 170 proporciona una salida que incluye
los datos que representan el horizonte electrónico en un formato
organizado. El motor de datos 170 proporciona esta salida en una
base cíclica.
Al realizar sus funciones, el motor de datos 170
usa datos que indican la posición del vehículo (incluyendo
dirección y velocidad) como una entrada. Con referencia a la figura
5, el motor de datos 170 incluye un proceso de recepción de datos
170(1) que realiza esta función. El proceso de recepción de
datos 170(1) recibe datos que indican la posición del
vehículo a partir de la herramienta de localización del vehículo
150(2)(1). Los datos que indican la posición del vehículo
incluyen una identificación del segmento de carretera en el que se
encuentra el vehículo, la posición a lo largo del segmento de
carretera identificado en el que se encuentra el vehículo, y la
dirección que sigue el vehículo a lo largo del segmento de
carretera. El segmento de carretera en el que se encuentra el
vehículo lo determina la herramienta de localización del vehículo
150(2)(1) usando datos de la base de datos de mapa 130.
La posición a lo largo del segmento de carretera
identificado se puede disponer en varias formas diferentes. Por
ejemplo, la posición del vehículo a lo largo del segmento de
carretera puede ser proporcionada 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 posición del
vehículo a lo largo del segmento de carretera puede ser indicada por
el punto de forma al que el vehículo está más próximo.
Alternativamente, la posición del vehículo a lo largo del segmento
de carretera identificado puede ser identificada como el punto de
forma que está inmediatamente delante de la posición del vehículo.
En otra alternativa, la posición del vehículo a lo largo de un
segmento de carretera se puede disponer en porciones incrementales
de la longitud del segmento de carretera (por ejemplo, n/256 a lo
largo de un segmento de carretera).
Los datos que indican la dirección del vehículo
pueden ser suministrados al componente de recepción de datos
170(1) del motor de datos 170 por la herramienta de
localización del vehículo 150(2)(1) indicando a qué nodo del
segmento se dirige el vehículo. El componente de recepción de datos
170(1) del motor de datos 170 también obtiene la velocidad
del vehículo (por ejemplo, de los sensores 120).
La herramienta de localización del vehículo
150(2)(1) puede proporcionar una nueva salida que indica una
nueva posición del vehículo 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
período. Los intervalos también pueden ser intervalos irregulares o
pueden ser intervalos basados en algún otro factor, tal como la
distancia, o una combinación de factores, tal como el tiempo y la
distancia. Según una realización de la presente invención, el
componente de recepción de datos 170(1) recibe cada salida de
la herramienta de localización del vehículo 150(2)(1) que
indica una nueva posición del vehículo.
La herramienta de localización del vehículo
150(2)(1) puede determinar que el vehículo 108 está fuera de
la carretera. El vehículo 108 está fuera de la carretera si la
herramienta de localización del vehículo 150(2)(1) no puede
determinar una posición del vehículo a lo largo de un segmento de
carretera representado en la base de datos de mapa 130. Esto puede
tener lugar si el vehículo está realmente fuera de la carretera (por
ejemplo, no en cualquier segmento de carretera, tal como en un
aparcamiento, en el campo, o fuera de la región de cobertura de la
base de datos de mapa 130). Alternativamente, la herramienta de
localización del vehículo 150(2)(1) puede determinar que el
vehículo está fuera de la carretera si no se puede obtener
información fiable del sensor. Si la herramienta de localización
del vehículo 150(2)(1) indica que el vehículo está fuera de
la carretera, la información que indica este estado fuera de la
carretera es suministrada al proceso de recepción de datos
170(1). La determinación de un horizonte electrónico requiere
una posición válida del vehículo con el vehículo colocado en una
posición específica de un segmento específico. Si el vehículo está
fuera de la carretera, el motor de datos 170 no calcula un
horizonte electrónico.
\vskip1.000000\baselineskip
El motor de datos 170 incluye un proceso de
cálculo de horizonte electrónico 170(3). El proceso de
cálculo de horizonte electrónico 170(3) determina qué
segmentos de carretera e intersecciones deberán 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 posibles recorridos que el vehículo puede seguir desde la
posición corriente del vehículo. La extensión de cada uno de estos
posibles recorridos desde la posición corriente del vehículo se
determina por el proceso de cálculo de horizonte electrónico
170(3). El "horizonte electrónico" se refiere a la
colección de las carreteras e intersecciones que van desde la
posición corriente del vehículo a los destinos determinados por el
proceso de cálculo de horizonte electrónico 170(3). Así, el
"horizonte electrónico" representa la carretera delante (o
posiblemente detrás) del vehículo. El horizonte electrónico también
es una representación de posibles recorridos de movimiento del
vehículo desde la posición corriente del vehículo. El "horizonte
electrónico" también se refiere a la colección de datos que
representan las carreteras e intersecciones que van desde la
posición corriente del vehículo a dichos destinos, incluyendo los
atributos de la carretera, objetos de carretera, y geometría de la
carretera de los segmentos de carretera que forman el horizonte
electrónico.
Para realizar la función de determinar el
horizonte electrónico, el proceso de cálculo de horizonte
electrónico
170(3) obtiene los datos que indican la posición actual del vehículo del proceso de recepción de datos 170(1). Usando los datos que indican la posición actual del vehículo, el proceso de cálculo de horizonte electrónico 170(3) obtiene datos de la base de datos de mapa 130 que se refieren a todas las carreteras alrededor de la posición actual del vehículo. El motor de datos 170 incluye un proceso componente 170(2) que obtiene estos datos de la base de datos de mapa 130. Si la base de datos de mapa 130 incluye una base de datos primaria y una base de datos suplementaria, el proceso componente 170(2) combina los datos primarios y secundarios para uso por el motor de datos.
170(3) obtiene los datos que indican la posición actual del vehículo del proceso de recepción de datos 170(1). Usando los datos que indican la posición actual del vehículo, el proceso de cálculo de horizonte electrónico 170(3) obtiene datos de la base de datos de mapa 130 que se refieren a todas las carreteras alrededor de la posición actual del vehículo. El motor de datos 170 incluye un proceso componente 170(2) que obtiene estos datos de la base de datos de mapa 130. Si la base de datos de mapa 130 incluye una base de datos primaria y una base de datos suplementaria, el proceso componente 170(2) combina los datos primarios y secundarios para uso por el motor de datos.
Después de obtener datos que se refieren a todos
los segmentos de carretera alrededor de la posición actual del
vehículo, el motor de datos 170 determina qué segmentos de carretera
representan el horizonte electrónico. Este paso incluye determinar
las extensiones (o límites) del horizonte electrónico. Al determinar
las extensiones del horizonte electrónico, el proceso de cálculo de
horizonte electrónico 170(3) permite que los posibles
recorridos que se extienden desde la posición corriente del vehículo
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 estén provistas de todos los
datos que puedan necesitar para realizar sus funciones, dada la
velocidad y dirección del vehículo así como los requisitos
específicos de cada una de las aplicaciones de ayuda al conductor
200. Por otra parte, el proceso de cálculo de horizonte electrónico
170(3) crea un horizonte electrónico lo más pequeño posible
con el fin de reducir los recursos computacionales requeridos para
crearlo y también para reducir los recursos computacionales
requeridos por las aplicaciones de ayuda al conductor 200 al usar
los datos incluidos en el horizonte electrónico.
Las extensiones del horizonte electrónico se
determinan usando uno o más funciones de cálculo de costes, como se
explica con más detalle más adelante. Brevemente, comenzando con el
segmento en el que el vehículo se encuentra actualmente, cada
segmento de cada recorrido delantero desde la posición corriente del
vehículo es evaluado para posible inclusión en el horizonte
electrónico. El proceso de cálculo de horizonte electrónico
170(3) deja de evaluar segmentos a añadir a un recorrido
desde la posición corriente del vehículo cuando el recorrido tiene
al menos un costo umbral mínimo, si es posible. El proceso de
cálculo de horizonte electrónico 170(3) deja de calcular un
horizonte electrónico cuando se determinan todos los segmentos
incluidos en todos los recorridos de la posición corriente del
vehículo. Cuando el proceso de cálculo de horizonte electrónico
170(3) deja de calcular un horizonte electrónico, se
determinan las extensiones del horizonte electrónico.
Según una realización, el horizonte electrónico
se representa por un árbol del que salen como bifurcaciones los
posibles recorridos de movimiento desde la posición actual del
vehículo. El proceso de cálculo de horizonte electrónico
170(3) forma este árbol al determinar qué segmentos de
carretera e intersecciones incluir en el horizonte electrónico. El
árbol que forma el horizonte electrónico incluye componentes por los
que cada punto a lo largo de cada recorrido puede ser especificado
y definido dentro del contexto de toda la estructura del árbol. De
esta manera, la formación del horizonte electrónico se realiza de
manera consistente, fiable y reproducible. Esto proporciona
características, tales como un nivel de confianza, que pueden ser
usadas por los sistemas avanzados de ayuda al conductor 200.
Los componentes del horizonte electrónico se
organizan de modo que las aplicaciones de ayuda al conductor 200
puedan usar los datos que representan las carreteras situadas
alrededor del vehículo. Los componentes del horizonte electrónico
incluyen lo siguiente:
(a) Primer segmento. El segmento de
carretera en el que se encuentra el vehículo es el "primer
segmento" del árbol del horizonte electrónico.
(b) Nodo raíz. El nodo de entrada del
primer segmento del horizonte electrónico es el "nodo raíz" del
árbol del horizonte electrónico.
(c) Nodo interno. Un "nodo interno"
de un horizonte electrónico es un nodo al que están unidos al menos
dos segmentos del horizonte electrónico.
(d) Segmentos de entrada y salida. Cada
nodo interno de un horizonte electrónico tiene un "segmento de
entrada", es decir, un segmento en el que el vehículo puede
moverse potencialmente hacia dicho nodo. Un nodo interno también
tiene uno o más "segmentos de salida", es decir, segmentos en
los que un vehículo se aleja potencialmente del nodo interno
corriente.
(e) Nodo hoja. Un "nodo hoja" es un
nodo dentro de un horizonte electrónico donde no se unen segmentos
adicionales.
(f) Sub-árbol accesible. Los segmentos
del horizonte electrónico que son accesibles por recorridos
legalmente permitidos del primer segmento del horizonte electrónico
forman el "sub-árbol accesible" del horizonte electrónico.
(g) Horizonte electrónico de recorrido
simple. Un horizonte electrónico se denomina un "horizonte
electrónico de recorrido simple" si su sub-árbol accesible
consta de una lista lineal de segmentos solamente.
(h) Horizonte electrónico de segmento
único. Un horizonte electrónico de recorrido simple se denomina
un "horizonte electrónico de segmento único" si el sub-árbol
accesible del horizonte electrónico consta de un único segmento
solamente.
(i) Segmento inaccesible. Un "segmento
inaccesible" es un segmento que está conectado a un nodo incluido
en el horizonte electrónico pero en el que no se puede entrar
legalmente desde el nodo. Por ejemplo, el segmento puede ser una
calle de una sola dirección y la dirección de la limitación de una
sola dirección es tal que es ilegal conducir por el segmento del
nodo que es parte del horizonte electrónico. Alternativamente, puede
haber una prohibición de giro que en efecto no permite que un
vehículo gire en el segmento del nodo que es parte del horizonte
electrónico. Obsérvese que un segmento particular puede ser
inaccesible si el vehículo se aproxima al segmento mediante un
nodo, pero accesible si el vehículo se aproxima al segmento mediante
un nodo diferente. La formación del horizonte electrónico puede
estar configurada (por ejemplo, a través de la función de cálculo
de costes, como se describe más adelante) de modo que los segmentos
inaccesibles se incluyan en un horizonte electrónico, o
alternativamente la formación del horizonte electrónico puede estar
configurada de modo que los segmentos inaccesibles queden excluidos
de un horizonte electrónico.
\vskip1.000000\baselineskip
Ejemplo
La figura 6 ilustra un horizonte electrónico
superpuesto en una porción de la red de carreteras. En la figura 6,
el segmento inaccesible está excluido del sub-árbol del horizonte
electrónico.
El horizonte electrónico incluye unos medios por
los que cada uno de los recorridos que van desde la posición
corriente del vehículo a las extensiones del horizonte electrónico
puede ser identificado de forma única. Cada una de las partes
componentes de un horizonte electrónico puede ser identificada
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
número de índice con respecto a un nodo particular. El segmento de
entrada de un nodo tiene un índice de 0. Los segmentos de salida de
un nodo son indexados comenzando en 1. Todos los segmentos de salida
de un nodo se marcan hacia la derecha. El primer segmento (es
decir, índice = 1) es el segmento que sigue al segmento de entrada
en una dirección hacia la derecha. Es posible que no haya segmento
de salida para un nodo particular (por ejemplo, un nodo hoja). La
figura 7 ilustra la asignación de identificadores de segmento en una
intersección (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
electrónico, cada descriptor de recorrido empieza con 0. Cualquier
segmento después del primer segmento de horizonte electrónico es
identificado por su identificador de segmento con respecto a su nodo
de entrada. La figura 8 representa un ejemplo de cómo se forman los
descriptores de recorrido. La figura 8 representa el mismo horizonte
electrónico que el representado en la figura 6. Junto a cada
segmento en el horizonte electrónico está su identificador de
segmento definido con respecto al nodo de entrada a él. La figura 8
también incluye una tabla de descriptores de recorrido para cada
uno de los recorridos en el horizonte electrónico. Obsérvese que, en
algunas circunstancias, a un segmento contenido en un horizonte
electrónico se puede entrar por más de un recorrido. Si se puede
entrar en un segmento por más de un recorrido, el segmento se
incluye en cada uno de los descriptores de recorrido. Así, un
segmento puede ser incluido más de una vez en una descripción de un
horizonte electrónico. A veces hay que definir un recorrido no
válido. Tal recorrido tiene un descriptor de recorrido de -1. Los
descriptores de recorrido también pueden ser usados para describir
recorridos que implican giros en U. La figura 9 representa un
ejemplo de cómo un descriptor de recorrido puede ser usado para
describir un giro en U. En la figura 9, un vehículo que avance
desde una posición corriente del vehículo al nodo A, después al nodo
B y posteriormente vuelve al nodo A, seguiría el recorrido 0.2.0.
En cualquier recorrido, el segmento 0 es el segmento en que el
vehículo avanza hacia un nodo. Por lo tanto, para describir un giro
en U, se usa el índice de segmento 0 para indicar que el vehículo
sale del nodo en el mismo segmento en que se ha movido hacia el
nodo.
(c) Orden de recorridos. Todos los
recorridos de un horizonte electrónico definen un orden completo.
Dado que el número de recorridos es finito, hay un "primer
recorrido" y un "segundo recorrido" de un horizonte
electrónico. Dados dos descriptores de recorrido, p1 y p2, este
orden se define como sigue. Se comparan repetidas veces los índices
de segmento individuales de los dos descriptores de recorrido. En
cada iteración, se ejecutan los pasos siguientes: Primero: si los
dos primeros índices de segmento individuales son idénticos, se
sigue comparando el par siguiente de índices de segmento. Por
ejemplo, suponiendo dos descriptores de recorrido 0.4.3.1 y
0.4.2.2. El cálculo de comparación en este punto ha llegado al
segundo índice de segmento ("4" en ambos casos).
Los dos índices de segmento individuales son
diferentes. En este caso el descriptor de recorrido con el valor de
índice de segmento más pequeño se considera que es menor que el
descriptor de recorrido con el mayor de los dos valores. Por
ejemplo, supónganse dos descriptores de recorrido 0.2.3.1 y 0.2.4.2.
La comparación de los terceros índices 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 operación de comparación se detiene en
este punto.
El número de índices de segmento para ambos
recorridos se ha excedido. Los dos descriptores de recorrido son
idénticos en este caso y se detiene el cálculo de comparación de
recorrido. Un ejemplo sería dos descriptores de recorrido 0.1.2 y
el cálculo precedente ha comparado solamente el tercero de los
descriptores de segmento ("2").
El número de índices de segmento para el primer
descriptor de recorrido se ha excedido, pero hay otro índice de
segmento todavía 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 operación de
comparación de recorridos se detiene en este punto. Por ejemplo,
supónganse los descriptores de recorrido 0.2.4 y 0.2.4.1.2,
procediendo ahora la operación de comparación a comparar el cuarto
índice de segmento de cada descriptor de recorrido, pero no existe
un cuarto índice de segmento en el caso del primer descriptor de
recorrido.
La prueba siguiente supone una situación,
contraria a la situación precedente, de que el número de índices de
segmento para el segundo descriptor de recorrido excede del número
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 operación de
comparación de recorridos se detiene en este punto.
(d) Descriptor de segmento. Un descriptor
de segmento identifica de forma única un segmento con respecto a un
recorrido en el contexto de un horizonte electrónico. Un segmento es
identificado por el descriptor de recorrido del recorrido que tiene
el segmento a identificar como su último segmento. Por ejemplo, con
referencia de nuevo a la figura 8, el segmento etiquetado A puede
ser identificado como 0.2.1.
(e) Descriptor de nodo. Un "descriptor
de nodo" identifica de forma única un nodo dentro de un horizonte
electrónico. 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 raíz de un horizonte electrónico
tiene el valor especial de -1.
(f) Descriptor de punto. Un descriptor de
punto identifica de forma única cualquier punto dentro de un
horizonte electrónico. Un descriptor de punto consta de dos partes:
(1) el descriptor de segmento del segmento al que pertenece el
punto y (2) el índice 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 índice de punto propiamente dicho, por
ejemplo, "0.1:2" identifica el segmento "0.1" y el punto
2.
La creación de un horizonte electrónico es el
proceso que determina qué segmentos (e intersecciones) son parte de
un horizonte electrónico y cuáles no lo son. El primer segmento de
un horizonte electrónico es el segmento en el que el vehículo se
encuentra actualmente. Cada vez que se añade otro segmento a un
horizonte electrónico, el proceso de cálculo de horizonte
electrónico 170(3) determina si el nodo de salida de dicho
segmento se deberá expandir más, es decir, si alguno o todos los
segmentos unidos al nodo de salida del segmento también deberán ser
parte del horizonte electrónico. Para esta finalidad se usan una
función de cálculo de costes de segmento y una función de cálculo
de costes de nodo.
Las funciones de cálculo de costes indican cómo
algunos factores afectan a la creación de un horizonte electrónico.
Las funciones de cálculo de costes permiten que una aplicación de
ayuda al conductor (a través de un proceso de configuración)
especifique si algunos factores deberán afectar a la creación del
horizonte electrónico. Las funciones de cálculo de costes también
permiten que una aplicación de ayuda al conductor especifique (a
través del proceso de configuración) en qué medida cada uno de estos
factores deberá afectar a la creación del horizonte electrónico. La
lista siguiente incluye los factores que pueden ser tomados en
cuenta por las funciones de cálculo de costes.
(1) Velocidad corriente del vehículo;
(2) Tiempo de recorrido del vehículo desde la
posición corriente del vehículo;
(3) Distancia de conducción desde la posición
corriente del vehículo;
(4) Inclusión de segmentos inaccesibles;
(5) Inclusión de recorridos circulares (por
ejemplo, un recorrido que tiene el mismo segmento introducido más
de una vez);
(6) Inclusión de giros en U;
(7) Inclusión de costos de nodo (por ejemplo, el
costo de giros en intersección); e
(8) Inclusión 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
cálculo de costes.
Usando estos factores, la función de cálculo de
costes determina las extensiones de un horizonte electrónico. Por
ejemplo, las extensiones del horizonte electrónico pueden incluir
todos los segmentos dentro de una distancia absoluta, todos los
segmentos que son alcanzables a la velocidad corriente del vehículo
dentro de los n segundos siguientes, todos los segmentos a los que
se puede llegar dentro de los n segundos siguientes marchando a los
límites legales de velocidad de los segmentos correspondientes, etc.
Estos factores se pueden combinar de varias formas. Por ejemplo,
las extensiones de un horizonte electrónico pueden incluir una
distancia absoluta mínima combinada con una distancia que es una
función de la velocidad del vehículo y del tiempo.
El proceso de crear un horizonte electrónico usa
dos valores de costos umbral. El primer valor de costo umbral se
denomina el "costo umbral de creación" y el segundo costo
umbral se denomina el "costo de recorrido mínimo".
El proceso de calcular el costo durante el
proceso de creación de un horizonte electrónico opera de forma
recursiva. En primer lugar, se asocia algún costo (a través de la
función de costo de segmento) con el "costo de recorrido" del
vehículo desde la posición del vehículo (en el primer segmento del
horizonte electrónico) al nodo de salida del primer segmento del
horizonte electrónico. El proceso de creación continúa ahora de la
forma recursiva siguiente:
Para cualquier segmento unido al nodo de salida
del segmento de horizonte electrónico corriente, se añade un costo
de nodo. Este costo de nodo modela el costo asociado con el giro
desde el segmento corriente al segmento unido y se determina por la
función de costo de nodo. Entonces, se añade un costo de segmento
que refleja el costo del vehículo que avanza desde el nodo de
entrada de un segmento nuevamente unido a su nodo de salida.
En cada paso se compara el costo corriente con
un valor para el "costo umbral de creación" (o "primer
umbral"). El costo umbral de creación se usa como un umbral para
determinar cuándo se deberá parar el proceso que extiende el
recorrido desde la posición corriente del vehículo.
Una vez que el costo de un recorrido llega o
excede del costo umbral de creación, el proceso de creación se
detiene con respecto a dicho recorrido. Entonces, se aplica el mismo
proceso de creación al recorrido siguiente, y así sucesivamente
hasta que se determinan todos los recorridos que salen de la
posición corriente del vehículo y cada recorrido tiene un costo al
menos tan grande como el costo umbral de creación, si es posible.
(Obsérvese que en algunos casos puede no ser posible extender un
recorrido al costo umbral de creación. Por ejemplo, si una
carretera termina en un extremo muerto, el recorrido puede terminar
antes de que se alcance el costo umbral de creación).
Una vez creado un horizonte electrónico, el
costo asociado con cada uno de los recorridos en el horizonte
electrónico es al menos tan grande como el valor de costo umbral de
creación (si es posible).
Cuando el vehículo avanza hacia adelante y la
posición del vehículo cambia, los datos que indican la nueva
posición son recogidos por los sensores (120 en la figura 1). La
herramienta de localización del vehículo (150(2)(1) en la
figura 4) usa estos nuevos datos para determinar una nueva posición
del vehículo. Los datos que indican la nueva posición del vehículo
son enviados desde la herramienta de localización del vehículo
150(2)(1) al motor de datos (170 en la figura 5) donde los
datos son recibidos por el componente de recepción de datos
170(1) que, a su vez, pasa los datos al proceso 170(3)
que calcula el horizonte electrónico. Entonces, el proceso de
cálculo de horizonte electrónico 170(3) determina si se ha de
crear un nuevo horizonte electrónico como resultado de la nueva
posición del vehículo o si el horizonte electrónico anterior puede
ser reutilizado (paso 170(3)(5)). Como parte de la
realización de esta determinación, el componente de cálculo de
horizonte electrónico 170(3) regula los costos de todos los
recorridos en el programa de horizonte electrónico para tener en
cuenta los datos que indican la nueva posición del vehículo. Al
ajustar los costos de los recorridos, los costos de los recorridos
disminuyen porque la posición del vehículo avanza al horizonte
electrónico. En este punto, el proceso de cálculo de horizonte
electrónico 170(3) determina si algún recorrido en el
horizonte electrónico tiene un costo menor que el costo de
recorrido mínimo (es decir, el "segundo umbral"). Si todos los
recorridos en el horizonte electrónico tienen costos superiores al
costo de recorrido mínimo, no se crea un nuevo horizonte
electrónico. En cambio, se determina un nuevo horizonte electrónico
usando los recorridos que ya habían sido determinados para el
horizonte electrónico anterior (es decir, existente). Cuando se
determina de esta manera un nuevo horizonte electrónico, los
recorridos (y sus costos) son actualizados para tener en cuenta la
nueva posición del vehículo. Cuando se determina de esta manera un
nuevo horizonte electrónico, se puede eliminar uno o más segmentos
de un recorrido, o incluso un recorrido completo, del horizonte
electrónico anterior.
Cuando se reciben en el motor de datos 170 datos
que indican nuevas posiciones del vehículo, el componente de
cálculo 170(3) determina de esta manera nuevos horizontes
electrónicos hasta que cualquier costo de recorrido es menos que el
costo de recorrido mínimo. Cuando una nueva posición del vehículo
hace que cualquier costo de recorrido en un horizonte electrónico
caiga por debajo del costo de recorrido mínimo umbral, se crea un
horizonte electrónico completamente nuevo (es decir, se determinan
todos los recorridos comenzando en la posición corriente del
vehículo, de la manera descrita anteriormente, de modo que el costo
de cada recorrido sea al menos el costo umbral de creación).
La utilización de dos valores de costos umbral
tiene varias ventajas. La utilización 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 electrónico. Otra ventaja de usar dos umbrales es
que no hay que calcular con tanta frecuencia un horizonte
electrónico totalmente nuevo, reduciendo por ello los requisitos
computacionales asociados con la creación del horizonte
electrónico. Otra ventaja de usar dos umbrales es que se puede
reducir la memoria necesaria para guardar los datos asociados con
un horizonte electrónico (como se describe más adelante en conexión
con el depósito de datos 180).
Los valores del costo umbral de creación y el
costo umbral mínimo son configurables. En una realización, estos
valores son configurados por las aplicaciones de ayuda al conductor
que usan el horizonte electrónico.
Como se ha indicado anteriormente, al calcular
un horizonte electrónico, el costo asociado con la adición de cada
nodo y segmento al horizonte electrónico se determina y añade a los
costos ya acumulados para el recorrido con el fin de determinar si
la expansión del horizonte electrónico a lo largo de dicho recorrido
deberá parar. El determinar el costo de añadir un segmento a un
recorrido, la función de cálculo de horizonte electrónico
170(3) usa una función de costo de segmento 170(3)(2)
y al determinar el costo de añadir un nodo a un recorrido, la
función de cálculo de horizonte electrónico 170(3) usa una
función de costo de nodo 170(3)(3).
La función de costo de segmento 170(3)(2)
determina el costo asociado con un vehículo 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
vehículo desde la posición corriente del vehículo al nodo de salida
del primer segmento.
Según una realización, la función de costo de
segmento 170(3)(2) tiene acceso a cierta información acerca
de un segmento para el que se calcula un costo. La información
acerca del segmento se obtiene de la base de datos de mapa 130. La
función de costo de segmento 170(3)(2) puede usar algunos
datos, todos los datos, o ningún dato, dependiendo de cómo se haya
configurado la función de costo de segmento. Según una realización,
la función de costo de segmento 170(3)(2) tiene acceso a la
información 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 dirección corriente es legal ("TDI").
(La información TDI permite que la aplicación de
ayuda al conductor controle, a través de un proceso de
configuración, si se incluyen en un horizonte electrónico calles de
una dirección orientadas en contra a la dirección corriente de
marcha del vehículo).
Con respecto al primer segmento, la longitud es
la distancia desde la posición corriente del vehículo al nodo de
salida del primer segmento y el costo de recorrido estimado es el
costo de recorrido estimado desde la posición del vehículo al nodo
de salida del primer segmento.
En la función de costo de segmento
170(3)(2) se asocian factores con combinaciones de estos
elementos de datos. La función 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
("FLEN_Illegal") puede ser definido y usado como un factor de
la longitud de segmento ("L") y la dirección de marcha legal
("TDI"). Un factor de costo de longitud ilegal
("FLEN_Illegal") puede ser definido y usado como un factor de
la longitud de segmento ("L") y la dirección de marcha legal
("TDI"). Un factor de costo de marcha estimado
("FEST_Legal") puede ser definido y usado como un factor del
costo de recorrido ("SETC") y la dirección de marcha legal
("TDI"). Igualmente, un factor de costo de marcha estimado de
dirección ilegal ("FEST_Illegal") puede ser definido y usado
como un factor del costo de recorrido ("SETC") y la dirección
de marcha legal ("TDI").
Mediante la selección de valores para cada uno
de estos factores, la importancia relativa de cada uno de los
diferentes tipos de información disponible acerca de un segmento
puede ser determinada con respecto a la expansión del horizonte
electrónico. De esta manera, se puede configurar la función de costo
de segmento. Esta configuración se puede hacer en base a la entrada
de una aplicación de ayuda al conductor o, alternativamente, se
puede usar valores de configuración por defecto.
El proceso de cálculo de horizonte electrónico
170(3) también incluye una función de costo de nodo
170(3)(3). La función de costo de nodo 170(3)(3) se
usa para calcular el costo asociado con la adición de un nodo a un
recorrido al determinar un horizonte electrónico. El costo de nodo
representa el costo asociado con la transición (por ejemplo, giro a
la derecha, a la izquierda, o seguir recto) de un segmento a
otro.
Según una realización, la función de costo de
nodo 170(3)(3) tiene acceso a cierta información acerca de un
nodo para el que se calcula el costo. La información acerca del
nodo se obtiene de la base de datos de mapa 130. La función de
costo de nodo 170(3)(3) puede usar algunos datos, todos los
datos, o ningún dato, dependiendo de cómo la función de costo de
nodo 170(3)(3) ha sido configurada. Según una realización, la
función de costo de nodo 170(3)(3) tiene acceso a la
siguiente información acerca de un nodo:
(1) Si el giro a través del nodo es legal
("TL"). Un giro puede ser ilegal porque está prohibido girar
(por ejemplo, giro prohibido a la izquierda o la derecha) o el
segmento siguiente es una calle de una sola dirección en la que se
entraría en dirección contraria.
(2) El ángulo 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 corriente
para el que actualmente se está explorando una expansión
adicional.
Como con la función de costo de segmento
170(3)(2), puede haber factores asociados con estos elementos
de datos en la función de costo de nodo 170(3)(3). La
función de costo de nodo 170(3)(3) se configura seleccionando
valores para cada uno de estos factores. Por ejemplo, se aplica un
factor de ángulo de giro ("F_TA_Legal") al ángulo de giro
entre el segmento corriente y el segmento siguiente, si el giro es
legal. (Un giro es legal si ni las prohibiciones de girar ni las
limitaciones de dirección única impiden que se ejecute un giro).
Este factor puede ser usado para asociar costos más altos con
ángulos de giro más 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 añadir 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 ángulo de
giro entre el segmento corriente y el siguiente si el giro es
ilegal. Se puede añadir un factor de costo constante
("C_Illegal_Turn") si el giro es ilegal. Se puede añadir un
factor de costo constante ("Cost_SecondSegment") si el segmento
siguiente es un segmento que ya es parte del recorrido corriente y
ambos segmentos tienen la misma dirección.
La selección de valores para cada uno de los
factores en la función de costo de nodo permite asignar la
importancia relativa de cada uno de los diferentes tipos de
información disponibles acerca de un nodo con respecto a la
expansión del horizonte electrónico. De esta manera, se puede
configurar la función de costo de nodo. Esta configuración se puede
hacer en base a la entrada de una aplicación de ayuda al conductor
o, alternativamente, se puede usar valores de configuración por
defecto.
Como se ha indicado anteriormente, el costo
umbral de creación y el costo de recorrido mínimo se pueden
configurar usando la entrada de una o más de las aplicaciones de
ayuda al conductor. Estos umbrales pueden ser valores fijos o
pueden ser valores calculados. Por ejemplo, según una realización,
el costo de recorrido mínimo se puede hacer una función de la
velocidad del vehículo. Según esta realización, la velocidad
corriente del vehículo ("VSP") se puede obtener de los
sensores y actualizar de forma continua en los datos proporcionados
al proceso de cálculo de horizonte electrónico 170(3).
Un valor para un factor de costo de recorrido
mínimo ("SpeedP") se determina por una de las aplicaciones de
ayuda al conductor. Usando esta información, el costo de recorrido
mínimo ("MinCost") se calcula como sigue:
MinCost = VSP *
SpeedF
También se puede calcular el valor de costo
umbral de creación. En una realización, el valor de costo umbral de
creación ("MaxCost") se puede hacer una función del costo de
recorrido mínimo según la relación siguiente:
MaxCost =
MinCost *
MaxF,
donde MaxF es un factor aplicado al
costo de recorrido
mínimo.
Como se ha mencionado anteriormente, las
funciones de cálculo de costes se pueden configurar usando la
entrada de la aplicación de ayuda al conductor. Una forma de
configurar las funciones de cálculo de costes es asegurar que todos
los recorridos dentro del horizonte electrónico tengan una cierta
longitud mínima, que los giros en U se hayan de ignorar, y que los
segmentos inaccesibles no sean parte de un horizonte electrónico.
Esta preparación se puede lograr de la siguiente manera:
En la función de costo de segmento, FLEN_Legal
se pone a 1. Esto hace el costo idéntico a una longitud de segmento
(o en el caso del primer segmento idéntico a la distancia del
vehículo al nodo de salida del primer segmento). También en la
función de costo de segmento, FLEN_Illegal se pone a cero para
suprimir segmentos inaccesibles. También en la función de costo de
segmento, FEST_Legal y FEST_Illegal se ponen a cero. De esta forma
se ignora cualquier estimación de tiempos de recorrido. En la
función de costo de nodo, FTA_Legal y F_SDAL_EnodeCost_Legal se
pone a 0 eliminando por ello los costos de giros legales. Cost_Uturn
se pone a 100.000 para eliminar cualquier giro en U. FTA_Illegal se
pone a 0, pero C_Illegal-Turn se pone a 100.000 para
eliminar segmentos inaccesibles o giros ilegales.
Cost_SecondSegment se pone a 100.000 para eliminar que el mismo
segmento sea dos veces parte de cualquier recorrido.
Algunas aplicaciones de ayuda al conductor
requieren el procesado de todos los recorridos posibles dentro de
un horizonte electrónico (es decir, recorridos accesibles e
inaccesibles). Sin embargo, algunas aplicaciones de ayuda al
conductor usan un "recorrido primario". Un "recorrido
primario" es un recorrido específico del uno o más recorridos
posibles dentro de un horizonte electrónico. El recorrido primario
es el recorrido más probable que se espera que siga el vehículo. El
programa de horizonte de datos 110 incluye una característica por
la que un recorrido primario puede ser determinado e identificado a
una aplicación de ayuda al conductor.
Hay dos aspectos para el cálculo del recorrido
primario. Un primer aspecto es una estimación del recorrido de
marcha más probable en base a la geometría de la carretera local. Un
segundo aspecto es el uso de información de ruta, si está
disponible. Estos aspectos se explican a continuación.
El motor de datos 170 del programa de horizonte
de datos 110 incluye una función de recorrido primario
170(6). En la función de recorrido primario se incluye una función 170(6)(1) que calcula un recorrido más probable basado en la red local de carreteras ("LRNBMLP"). La función 170(6)(1) intenta estimar cómo seguirá avanzando el vehículo dentro del horizonte electrónico corriente teniendo en cuenta solamente la red viaria local. La función 170(6)(1) calcula un solo recorrido como el LRNBMLP. La función 170(6)(1) calcula el LRNBMLP como sigue. La función 170(6)(1) incluye el primer segmento de horizonte electrónico en el LRNBMLP. Entonces, la función
170(6)(1) ejecuta repetidas veces los pasos siguientes para la selección del segmento siguiente hasta que se halla un nodo hoja del horizonte electrónico.
170(6). En la función de recorrido primario se incluye una función 170(6)(1) que calcula un recorrido más probable basado en la red local de carreteras ("LRNBMLP"). La función 170(6)(1) intenta estimar cómo seguirá avanzando el vehículo dentro del horizonte electrónico corriente teniendo en cuenta solamente la red viaria local. La función 170(6)(1) calcula un solo recorrido como el LRNBMLP. La función 170(6)(1) calcula el LRNBMLP como sigue. La función 170(6)(1) incluye el primer segmento de horizonte electrónico en el LRNBMLP. Entonces, la función
170(6)(1) ejecuta repetidas veces los pasos siguientes para la selección del segmento siguiente hasta que se halla un nodo hoja del horizonte electrónico.
Si solamente está unido a un nodo un segmento
accesible, se elige dicho segmento.
Si más de un segmento accesible está unido a un
nodo, entonces se elige el segmento con la clase funcional más alta
de entre todos los segmentos accesibles. Si dos o más segmentos
accesibles tienen la misma clase funcional que es más alta que la
clase funcional de cada uno de los otros segmentos, se elige el
segmento con la clase funcional más alta con el ángulo de giro más
pequeño. Si hay dos segmentos con la clase funcional más alta y el
mismo ángulo 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 aplicación de ayuda al conductor puede optar
por tener un LRNBMLP determinado de esta manera. Alternativamente,
la aplicación de ayuda al conductor puede optar por no tener el
LRNBMLP determinado de esta manera.
Como se ha mencionado anteriormente, otro
aspecto de determinar un recorrido primario de un vehículo es usar
información de ruta. Algunos vehículos incluyen hardware y software
que puede calcular una ruta a un destino deseado. Como se ha
mencionado anteriormente en conexión con la figura 4, en una
realización de la presente invención, se incluye una herramienta de
cálculo de ruta 150(2)(3) entre las aplicaciones de
navegación 150(2). La herramienta de cálculo de ruta
150(2)(3) puede ser usada para calcular una ruta a un destino
deseado. En una realización, la herramienta de cálculo 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 vehículo vaya
del primer al último segmento de la ruta. Un
"sub-recorrido de ruta" de una ruta dentro de
un horizonte electrónico dado es el recorrido dentro del horizonte
electrónico que concuerda con algunos (o todos los) segmentos de
una ruta dada. Dada una ruta, es posible que la ruta no esté
contenida (al menos parcialmente) dentro del horizonte electrónico.
En este caso, el sub-recorrido de ruta no está
definido (y por lo tanto identificado por el descriptor de
recorrido de -1).
La función de recorrido primario 170(6)
incluye una función 170(6)(2) que intenta calcular un
recorrido basado en ruta. Un recorrido basado en ruta es la parte
de una ruta calculada que está situada dentro de un horizonte
electrónico. Las entradas a la función 170(6)(2) incluyen
datos que indican la ruta R y datos ("E") que indican el
horizonte electrónico calculado. Como un primer paso, la función
170(6)(2) determina si se puede definir un recorrido basado
en ruta para el horizonte electrónico. Para realizar este paso, la
función 170(6)(2) intenta localizar el primer segmento del
horizonte electrónico en la ruta calculada R. Si el primer segmento
del horizonte electrónico no puede ser hallado en la ruta calculada
R, el cálculo se detiene y el recorrido basado en ruta no se define
es decir, no hay recorrido basado en ruta). Sin embargo, si el
primer segmento del horizonte electrónico concuerda con uno de los
segmentos en la ruta calculada R, se define el recorrido basado en
ruta. (Obsérvese que, para que el primer segmento del horizonte
electrónico concuerde con uno de los segmentos en la ruta
calculada, la función 170(6)(2) requiere que la dirección de
recorrido a lo largo del segmento en el horizonte electrónico y la
ruta calculada sea la misma). Después de hallar el primer segmento
del horizonte electrónico en la ruta calculada, la función
170(6)(2) sigue intentando la concordancia de segmentos de
los recorridos en el horizonte electrónico E con segmentos de la
ruta calculada R. Como con el primer segmento, la función
170(6)(2) requiere que la dirección de recorrido en los
segmentos concordantes sea la misma. Este proceso de concordancia
continúa hasta que no se pueda hallar más segmentos de los
recorridos del horizonte electrónico entre los segmentos de la
ruta. Ya no se hallan concordancias porque no se contiene en E un
segmento de la ruta para el que se busca concordancia (es decir,
porque el horizonte electrónico E no se extiende más allá de algún
nodo) o se llegó al último segmento de la ruta R y, por lo tanto, no
pueden concordar segmentos adicionales de R en E.
La función de cálculo de recorrido primario
170(6) calcula un recorrido primario usando las salidas de la
función de recorrido más probable 170(6)(1) y la función
basada en ruta 170(6)(2). Si se ha definido una ruta R y la
función basada en ruta 170(6)(2) era capaz de determinar un
recorrido basado en ruta en base a 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 más probable de la red
viaria local (LRNBMLP). Una ventaja de este método es asumir que el
conductor seguirá una ruta calculada, si ha introducido información
de ruta. Sin embargo, si no se dispone de información de ruta, el
recorrido más probable de la red viaria local es la mejor
estimación que se puede facilitar.
Se hace referencia de nuevo a la figura 5.
Cuando el proceso de cálculo 170(3) ha construido un nuevo
horizonte electrónico (en contraposición a determinar un nuevo
horizonte electrónico ajustando la posición del vehículo y los
costos de recorrido del horizonte electrónico anterior), se obtiene
el contenido para la estructura de datos del nuevo horizonte
electrónico. El motor de datos 170 incluye un proceso componente
170(4) que realiza esta función. El proceso 170(4)
recibe del proceso de cálculo de horizonte electrónico 170(3)
datos que indican los recorridos (y en consecuencia qué segmentos y
nodos) se han de representar en la estructura de datos de horizonte
electrónico. Al recibir estos datos, el proceso de formación de
contenido de horizonte electrónico 170 (4) obtiene de la base de
datos de mapa 130 los datos necesarios para la formación de la
estructura de datos de horizonte electrónico. La estructura de
datos formada por el proceso de formación de contenido de horizonte
electrónico 170(4) contiene los datos relevantes acerca de
las carreteras e intersecciones en el horizonte electrónico. Esta
estructura de datos forma la salida 171 del motor de datos 170.
Los tipos de datos que el proceso de formación
de contenido de horizonte electrónico 170(4) obtiene de la
base de datos de mapa 130 se determinan mediante un proceso de
configuración. Este proceso de configuración puede ser realizado
durante una etapa de fabricación de los sistemas avanzados de ayuda
al conductor o durante un proceso de inicialización o preparación
de los sistemas avanzados de ayuda al conductor. En una realización,
el controlador de configuración 165 recibe de una o más
aplicaciones de ayuda al conductor 200 datos que indican los tipos
de datos que se deberá incluir en el horizonte electrónico. A su
vez, el controlador de configuración 165 proporciona datos al
proceso 170(4) para indicar los tipos de atributos de datos
asociados con segmentos y nodos que se deberán obtener para
inclusión en la estructura de datos de horizonte electrónico. En
base a estas entradas, el proceso de formación de contenido
170(4) obtiene los datos necesarios de la base de datos de
mapa 130 a incluir en una estructura de datos de horizonte
electrónico siempre que se cree un nuevo horizonte electrónico.
Cuando se ha obtenido una estructura de datos de
horizonte electrónico de nueva construcción y se ha almacenado en
la estructura apropiada, el contenido de la estructura es enviado
desde el motor de datos 170 al depósito de datos 180. El motor de
datos 170 incluye un proceso componente 170(8) que envía 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 electrónico. Si no se puede calcular
un horizonte electrónico, el proceso 170(4) no obtiene datos
para una estructura de datos de horizonte electrónico de la base de
datos de mapa 130. En estas circunstancias, el proceso de formación
de contenido 170(4) no envía ninguna salida o
alternativamente el proceso de formación de contenido 170(4)
proporciona un horizonte electrónico vacío, es decir, indicando que
no se ha determinado ningún horizonte electrónico para la posición
del vehículo.
Hay otra ocasión en la que se facilita un
horizonte electrónico vacío. Es posible que la herramienta de
localización del vehículo 150(2)(1) reporte que el vehículo
está marchando en dirección prohibida por una calle de una sola
dirección. En este caso, el proceso de cálculo de horizonte
electrónico 170(3) devuelve la información de estado
apropiada, estando el horizonte electrónico esencialmente vacío.
Si el proceso de cálculo 170(3) ha sido
configurado para proporcionar un recorrido primario (en lugar de un
horizonte electrónico completo), el proceso de formación de
contenido de horizonte electrónico 170(4) obtiene los datos
de la base de datos de mapa 130 necesarios para una estructura de
datos de horizonte electrónico que incluye solamente el recorrido
primario. (Alternativamente, se facilita un horizonte electrónico
incluyendo todos los recorridos junto con datos que indican por
separado el recorrido primario). Si el proceso de cálculo
170(3) ha sido configurado para proporcionar un recorrido
primario y no se puede determinar un recorrido primario, el proceso
de formación de contenido 170 (4) proporciona una salida que indica
que no se ha determinado ningún recorrido primario para la posición
del vehículo.
En la realización representada en la figura 5,
el proceso 170(4) de obtener datos para el horizonte
electrónico se representa separado del proceso 170(3) de
determinar el horizonte electrónico. En realizaciones alternativas,
estos procesos se pueden combinar de modo que se obtengan los datos
contenidos en el horizonte electrónico y el horizonte electrónico
se construye cuando se determinan los recorridos que forman el
horizonte electrónico.
Como se ha mencionado anteriormente, según una
realización de la presente invención, no se crea necesariamente un
nuevo horizonte electrónico cada vez que se obtiene una nueva
posición del vehículo. En cambio, el horizonte electrónico anterior
puede ser reutilizado si todos los costos de recorrido del horizonte
electrónico anterior todavía exceden del costo umbral mínimo
después del ajuste de una nueva posición del vehículo. En estas
circunstancias, el motor de datos 170 proporciona una salida 172
que indica un nuevo horizonte electrónico para la nueva posición
del vehículo que usa los recorridos determinados para un horizonte
electrónico anterior. El motor de datos 170 incluye un proceso de
salida de horizonte electrónico 170(7) que realiza esta
función. El proceso de salida de horizonte electrónico
170(7) proporciona esta salida 172 al depósito de datos 180,
como se explica con más detalle más adelante. Según una
realización, el proceso de salida de horizonte electrónico
170(7) proporciona una salida para cada recepción de datos
que indican una nueva posición del vehículo. Según una realización
de la presente invención, el componente 170(7) que
proporciona la salida 172 que define un horizonte electrónico está
separado del componente 170(8) que proporciona el contenido
de un horizonte electrónico. La salida 171 del proceso de salida de
contenido de horizonte electrónico 170(8) incluye todos los
atributos de datos necesarios asociados con todos los segmentos y
nodos en todos los recorridos que forman un horizonte electrónico.
La salida 172 del proceso de salida de horizonte electrónico
170(7) incluye solamente una referencia a una de las salidas 171 que contiene el contenido de datos de un horizonte electrónico y una indicación de la posición del vehículo con relación al contenido de datos referenciado.
170(7) incluye solamente una referencia a una de las salidas 171 que contiene el contenido de datos de un horizonte electrónico y una indicación de la posición del vehículo con relación al contenido de datos referenciado.
Como se ha indicado anteriormente en conexión
con la figura 1, el depósito de datos 180 es el componente del
programa de horizonte de datos 110 que contiene las últimas lecturas
de datos. Una realización del componente depósito de datos 180 se
representa en las figuras 10-12. Como se representa
en la figura 10, el depósito de datos 180 contiene tres tipos de
datos diferentes. Primero: el depósito de datos 180 contiene datos
180(1) que representan el horizonte electrónico que había
sido determinado por el motor de datos 170. Según una realización,
los datos 180(1) incluyen la información de atributos acerca
de los segmentos y nodos en el horizonte electrónico. La
información de atributos acerca de los segmentos y nodos en el
horizonte electrónico puede incluir algunos o todos los atributos
identificados en las figuras 3A y 3B. Segundo: el depósito de datos
180 contiene datos 180(2) que representan la posición del
vehículo. Los datos 180(2) que representan la posición del
vehículo son los datos determinados por la herramienta de
localización del vehículo (150(2)(1) en la figura 4). El
depósito de datos 180 puede obtener los datos 180(2) que
representan la posición del vehículo directamente de la herramienta
de localización del vehículo 150(2)(1) o los datos
180(2) que representan la posición del vehículo pueden ser
obtenidos del motor de datos 170. Tercero: el depósito de datos 180
contiene datos del sensor 180(3). Los datos del sensor
180(3) pueden ser datos en bruto del sensor obtenidos
directamente de los sensores (120 en la figura 1) o
alternativamente los datos del sensor 180(3) se pueden
obtener del motor de datos 170.
Con referencia a la figura 11, con respecto a
los datos de horizonte electrónico 180(1), el depósito de
datos 180 contiene al menos el conjunto de datos que representa el
horizonte electrónico más reciente que había sido determinado por
el motor de datos 170. En una realización, el depósito de datos 180
contiene varios conjuntos de datos que representan varios
horizontes electrónicos. Estos varios conjuntos de datos mantenidos
en el depósito de datos 180 son los conjuntos creados más
recientemente por el motor de datos 170. Por ejemplo, el depósito
de datos 180 puede mantener los diez conjuntos de datos más
recientes que representan los diez horizontes electrónicos más
recientes que habían sido determinados por el motor de datos 170
aunque también puede ser adecuado un número mayor o menor. El
número de conjuntos de datos retenidos por el depósito de datos 180
se puede configurar usando la entrada de las aplicaciones de ayuda
al conductor 200 mediante el controlador de configuración (165 en
la figura 1). A cada conjunto de datos en el depósito de datos 180
se le asigna un número de identificación o código por el que puede
ser identificado.
Según una realización representada en la figura
11, el depósito de datos 180 no mantiene necesariamente conjuntos
de datos completos para cada horizonte electrónico retenido en él.
En cambio, el depósito de datos 180 implementa un mecanismo de
manejo de depósito. Este mecanismo de manejo de depósito es similar
a mecanismos usados en programación orientada a objeto para manejar
objetos grandes. La utilización del mecanismo de manejo de depósito
reduce los requisitos de almacenamiento y manejo de múltiples
conjuntos de datos que representan múltiples horizontes
electrónicos correspondientes.
El uso de un mecanismo de manejo de depósito
para almacenamiento de horizontes electrónicos en el depósito de
datos 180 se facilita por la manera en que los horizontes
electrónicos son calculados por el motor de datos 170. Como se ha
mencionado anteriormente, según una realización, no se crea
necesariamente un nuevo horizonte electrónico cada vez que se
obtiene datos que indican una nueva posición del vehículo. En
cambio, se crea un nuevo horizonte electrónico solamente cuando un
recorrido del horizonte electrónico anterior cae por debajo de un
recorrido umbral mínimo después de tener en cuenta una nueva
posición del vehículo.
Según la realización representada en la figura
11, se definen una clase ElectronicHorizonData y una clase
ElectronicHorizon. Los objetos 181 en la clase
ElectronicHorizonData contienen toda la información (es
decir, atributos de datos) necesaria para representar un horizonte
electrónico. Adicionalmente, cada objeto
ElectronicHorizonData 181 contiene un recuento de referencia.
El recuento de referencia indica cuántos otros objetos están usando
el objeto ElectronicHorizonData 181.
Cada objeto 182 en la clase
ElectronicHorizon contiene tres elementos de información: un
indicador, una distancia delta, y un manipulador (es decir, ID). El
indicador apunta al objeto ElectronicHorizonData aplicable
181. La distancia delta en un objeto ElectronicHorizon 182 es
un valor que indica la diferencia en la posición del vehículo del
objeto ElectronicHorizon 182 con relación a la posición del
vehículo en el objeto ElectronicHorizonData referenciado
181. (A condición de que el vehículo permanezca en el mismo
segmento y se haya movido de tal manera que se puedan reutilizar los
datos de horizonte electrónico más recientemente utilizados, no se
calculan nuevos datos de horizonte electrónico).
El uso del mecanismo de manejo de depósito para
almacenamiento y uso de horizontes electrónicos tiene varias
ventajas. Los horizontes electrónicos ocuparían mucha memoria si se
almacenasen como objetos de clase ordinaria. Sin embargo, en la
realización de la figura 11, el objeto ElectronicHorizon 182
contiene solamente tres elementos de información y
consiguientemente puede ser relativamente pequeño en comparación 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 electrónico asociados, solamente se copia un
indicador 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 está usando los datos. Un objeto
ElectronicHorizonData 181 se borra cuando todos los objetos
ElectronicHorizon 181 referentes a él dejan de existir.
Se hace referencia a la figura 12. Como se ha
indicado anteriormente, el depósito de datos 180 también contiene
datos de posición del vehículo 180(2). Los datos de posición
del vehículo 180(2) contenidos en el depósito de datos 180
incluyen datos que indican la o las posiciones más recientes del
vehículo que habían sido determinadas por la herramienta de
localización del vehículo (150(2)(1) en la figura 4). El
número de posiciones del vehículo incluidas en los datos de
posición del vehículo 180(2) retenidos por el depósito de
datos 180 se puede configurar. En una realización, el número de
posiciones del vehículo representadas por los datos de posición del
vehículo 180(2) contenidos en el depósito de datos 180
corresponde al número de horizontes electrónicos incluidos en los
datos de horizonte electrónico 180 (1). Alternativamente, el número
de posiciones del vehículo representadas en los datos de posición
del vehículo 180(2) contenidos en el depósito de datos 180
puede ser mayor que el número de horizontes electrónicos incluidos
en los datos de horizonte electrónico 180(1). Los datos de
posición del vehículo 180(2) se pueden retener por separado
de los datos de horizonte electrónico 180(1) o
alternativamente los datos de posición del vehículo 180(2)
se pueden incluir con los datos de horizonte electrónico
180(1). Como se representa en la figura 12, a cada conjunto
de datos de posición del vehículo 180(2) se le puede asignar
un número de identificación o código por el que puede ser
identificado.
También como se ha indicado anteriormente, el
depósito de datos 180 contiene datos del sensor 180(3). Los
datos del sensor 180(32) contenidos en el depósito de datos
180 incluye las lecturas de sensor más recientes de los sensores
120 (en la figura 1). El número de lecturas de sensor incluidas en
el depósito de datos 180 puede ser configurado. En una realización,
el número de lecturas de sensor contenidas en el depósito de datos
180 corresponde al número de horizontes electrónicos incluidos en
los datos de horizonte electrónico 180(1) o el número de
posiciones del vehículo incluidas en los datos de posición del
vehículo 180(2). Alternativamente, el número de lecturas de
sensor contenidas en el depósito de datos 180 puede ser un número
diferente. Como se representa en la figura 12, a cada conjunto de
datos del sensor 180(3) se le puede asignar un número de
identificación o código por el que puede ser identificado.
Además de los datos de horizonte electrónico
180(1), los datos de posición del vehículo 180(2) y
los datos del sensor (3), el depósito de datos 180 también puede
contener otros tipos de datos.
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
envío de datos del depósito de datos 180 a las aplicaciones de
ayuda al conductor 200 que usan los datos. Con el fin de reducir los
requisitos de procesado, el distribuidor de datos 190 incluye un
componente 190(1) que envía mensajes 191 que indican la
disponibilidad de nuevos datos. Estos mensajes son enviados por un
bus de datos de vehículo 194 a cada proceso de ayuda al conductor
200 que usa datos almacenados en el depósito de datos 180. En una
realización en la que hay varios procesos de ayuda al conductor 200
que usan datos almacenados en el depósito 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 depósito 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
electrónico (180(1) en la figura 10), el distribuidor de
datos 190 envía mensajes acerca de la disponibilidad de nuevos
datos una vez cada ejecución cíclica del motor de datos 170. Con
respecto a los datos de posición del vehículo 180(2) y los
datos del sensor 180(3), el distribuidor de datos 190 envía
mensajes acerca de la disponibilidad de nuevos datos cuando tales
nuevos datos están disponibles.
Cada mensaje 191 identifica la disponibilidad de
nuevos datos por una ID (o indicador). Por ejemplo, con respecto a
los datos de horizonte electrónico 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 electrónico 180(1) en el depósito de
datos 180. Cada mensaje 191 también puede indicar el tipo de nuevos
datos que están disponibles, por ejemplo, horizonte electrónico,
posición del vehículo, o sensor.
(El distribuidor de datos 190 también incluye un
componente de registro 190(2). El componente de
registro
190(2) se usa en unión con componentes de registro correspondientes 302 en las escuchas 300, como se explica con más detalle más adelante).
190(2) se usa en unión con componentes de registro correspondientes 302 en las escuchas 300, como se explica con más detalle más adelante).
En la realización 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 aplicación 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
aplicación 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 aplicación 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 aplicación 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. Específicamente, 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 también identifica para el componente de registro 190(2) del distribuidor de datos 190 el tipo de datos acerca de los que la escucha 300(n) ha de ser notificada (por ejemplo, datos de horizonte electrónico, datos de posición del vehículo, o datos del sensor). En la realización de la figura 14, la escucha 300(n) se usa para notificación de datos de horizonte electrónico. Una vez que la escucha 300(n) se haya registrado con el distribuidor de datos 190, se seguirá 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 cuando los nuevos datos se depositan en el depósito de datos 180. El proceso de registro puede ser realizado una vez, por ejemplo, cuando se inicializa la aplicación de ayuda al conductor 200. El proceso de registro puede ser realizado posteriormente.
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. Específicamente, 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 también identifica para el componente de registro 190(2) del distribuidor de datos 190 el tipo de datos acerca de los que la escucha 300(n) ha de ser notificada (por ejemplo, datos de horizonte electrónico, datos de posición del vehículo, o datos del sensor). En la realización de la figura 14, la escucha 300(n) se usa para notificación de datos de horizonte electrónico. Una vez que la escucha 300(n) se haya registrado con el distribuidor de datos 190, se seguirá 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 cuando los nuevos datos se depositan en el depósito de datos 180. El proceso de registro puede ser realizado una vez, por ejemplo, cuando se inicializa la aplicación de ayuda al conductor 200. El proceso de registro puede ser realizado posteriormente.
Como se ha indicado anteriormente, después de
registrar la escucha 300(n) con el distribuidor de datos 190,
a la escucha 300(n) se le envían regularmente 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
notificación 191 incluye una identificación (es decir, ID) de un
conjunto de nuevos datos almacenados en el depósito de datos 180.
La escucha de datos 300(n) incluye un componente 306 que
guarda cada identificación 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 últimas notificaciones recibidas del distribuidor de datos
190. La cola 310 puede incluir identificaciones de varias de las más
recientes notificaciones recibidas del distribuidor de datos 190.
El tamaño de la cola es configurable.
Cuando la aplicación 200(n) está
preparada para recibir nuevos datos, la escucha de datos
300(n) obtiene los nuevos datos para la aplicación
200(n). La escucha de datos 300(n) incluye un
componente 312 que obtiene una identificación de la cola 310. El
componente 312 puede obtener la más reciente identificación añadida
a la cola 310 o, alternativamente, el componente 312 puede obtener
cualquier otra identificación de la cola 310. Después de obtener
una identificación de la cola 310, un proceso 314 en la escucha de
datos 300(n) usa la identificación para obtener los datos
asociados del depósito de datos 180. Al recibir los datos del
depósito de datos 190, un proceso 316 en la escucha de datos
300(n) envía los datos a la aplicación de ayuda al conductor
200(n).
Una aplicación de ayuda al conductor 200 puede
usar más de un tipo diferente de datos almacenados en el depósito
de datos 180. Si una aplicación de ayuda al conductor usa más de un
tipo diferente de datos almacenados en el depósito de datos 180, la
aplicación de ayuda al conductor se asocia con más de una escucha de
datos. Según una realización, una aplicación de ayuda al conductor
usa una escucha de datos separada 300 para cada uno de los
diferentes tipos de datos que usa la aplicación de ayuda al
conductor. Por ejemplo, si una aplicación de ayuda al conductor 200
usa tanto datos de horizonte electrónico como datos del sensor, la
aplicación de ayuda al conductor 200 se asocia con dos escuchas de
datos separadas 300, una para los datos de horizonte electrónico y
la otra para los datos del sensor. Cada una de las escuchas de datos
asociadas con una sola aplicación de ayuda al conductor recibe
mensajes del distribuidor de datos 190 del programa de horizonte de
datos 110 acerca de la disponibilidad de nuevos datos del tipo
asociado con la escucha. Cada una de las escuchas de datos mantiene
una cola separada de IDs con la que los respectivos tipos de datos
se pueden obtener del depósito de datos 180. La figura 15
representa una realización de una aplicación de ayuda al conductor
200(k) asociada con tres escuchas separadas
300(k)(1), 300(k)(2), y 300(k)(3), para obtener
tres diferentes tipos de datos.
En una realización descrita anteriormente se
describió una escucha de datos 300 como un objeto separado de la
aplicación de ayuda al conductor 200 asociada que usa los datos con
respecto a lo que la escucha recibió notificaciones. Según una
realización alternativa, la función de escucha se puede incorporar
al mismo objeto que procesa los datos sobre los que la escucha
recibe notificaciones. Según esta alternativa, un objeto (o
aplicación) que recibe notificaciones acerca de nuevos datos (del
distribuidor de datos) también procesa directamente los datos. Una
aplicación que recibe notificaciones acerca de los datos y procesa
los datos sobre los que recibe notificaciones, puede implementar
estas dos funciones como hilos separados.
Como se ha descrito anteriormente en conexión
con la realización en la que el proceso de escucha se implementa
como una aplicación u objeto separado, el mecanismo de notificación
de eventos usado en la escucha requiere que una llamada de
notificación por el programa de horizonte de datos vuelva
rápidamente. Una llamada de notificación deberá consumir mínimo
tiempo de procesado e indicar solamente la disponibilidad de datos
iniciar un hilo que obtenga los datos. En una realización en la que
la función de escucha se implementa como un hilo separado en la
misma aplicación u objeto que también implementa el procesado de los
datos, el mecanismo de notificación de eventos también deberá
volver rápidamente. Además, en una realización en la que la función
de escucha se implementa como un hilo separado en la misma
aplicación u objeto que también procesa los datos, se usan unos
medios para iniciar o parar el hilo que realiza la función de
escucha. Esto puede ser realizado por el programa de horizonte de
datos. Específicamente, el motor de datos 170 puede invocar el hilo
que escucha la notificación de evento dentro de la aplicación u
objeto que usa los datos. Un proceso en una aplicación que usa los
datos puede estar registrado en el motor de datos 170 de forma
similar a la descrita anteriormente en conexión con una escucha.
Una vez que el hilo de escucha ha sido registrado, el motor de datos
empieza (o para, interrumpe o reanuda) este hilo siempre que el
motor de datos arranque (se pare, interrumpa o reanude).
Con referencia de nuevo a la figura 1, el
programa de supervisión 160 es una parte de la arquitectura de datos
100. El programa de supervisión 160 permite ver la ejecución de las
funciones del programa de horizonte de datos 110. Algunas
características del programa de supervisión 160 pueden ser usadas en
un entorno de prueba y configuración. Otras características del
programa de supervisión 160 pueden ser usadas durante el uso
ordinario por un usuario final del vehículo de motor 108 en el que
se instala la arquitectura de datos de mapa 100. En una
alternativa, el programa de supervisión 160 se usa solamente en un
entorno de prueba y configuración y no en un entorno de tiempo de
ejecución (por ejemplo, durante la operación ordinaria del vehículo
por un usuario final).
En un entorno de prueba y configuración, se
puede enviar una salida del programa de supervisión 160 a un monitor
de visualización 160(1) donde se pueden ver varios aspectos
de la ejecución de las funciones del programa de horizonte de datos
110. Por ejemplo, el programa de supervisión 160 puede presentar una
imagen continua de la posición del vehículo en movimiento en un
mapa en el monitor de visualización 160(1). El monitor de
visualización 160(1) también puede mostrar una zona alrededor
de la posición actual del vehículo. Los segmentos de carretera que
son partes de recorridos en el horizonte electrónico se pueden
resaltar en el monitor de visualización 160(1). Además, el
programa de supervisión 160 puede mostrar la posición corriente del
vehículo, incluyendo un punto, rumbo, y velocidad en una imagen del
mapa en la pantalla 160(1). Si el vehículo 108 sigue una
ruta calculada por la herramienta de cálculo 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). Además, el
programa de supervisión 160 puede presentar los atributos de los
segmentos de carretera e intersecciones alrededor del vehículo.
Estos atributos incluyen los atributos representados en las figuras
3A y 3B. Los atributos asociados con el horizonte electrónico
también se pueden visualizar. El programa de supervisión 160 regula
los límites de la imagen del mapa en el monitor de visualización en
base al movimiento actual del vehículo.
Con referencia de nuevo a la figura 1, el
programa del controlador de configuración 165 es una parte de la
arquitectura de datos 100. El programa del controlador de
configuración 165 permite configurar las funciones del programa de
horizonte de datos 110. El programa del controlador de configuración
165 permite poner los parámetros, valores por defecto, etc, que
controlan la operación de la arquitectura de datos 100, incluyendo
el programa de horizonte de datos 110. Por ejemplo, el programa de
configuración 165 permite determinar el tamaño del horizonte
electrónico en la parte delantera del vehículo para el que se
determinarán lecturas de datos.
El programa de configuración 165 puede permitir
poner parámetros durante la instalación (o fabricación) del equipo
del sistema de ayuda al conductor en el vehículo. El programa de
configuración 165 también puede permitir establecer parámetros
cuando se instala nuevo equipo, por ejemplo, nuevos sensores, nuevo
hardware, más memoria. El programa de configuración 165 también
puede permitir establecer nuevos parámetros cuando se instalen
nuevos datos, por ejemplo, cuando se actualice la base de datos
130.
El programa de configuración 165 también puede
ser usado a la inicialización o durante la operación del vehículo
con el fin de cambiar las características operativas del programa de
horizonte de datos 110. El programa de configuración 165 puede
recibir entradas automáticamente 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 también pueden
proporcionar salidas que indican las extensiones necesarias para el
horizonte electrónico. La extensión del horizonte electrónico puede
ser especificada en distancia (por ejemplo, metros) o tiempo (por
ejemplo, segmentos que el vehículo puede recorrer dentro de los 10
segundos siguientes).
El programa de configuración 165 puede ser usado
para registrar una escucha de datos 300 con el fin de recibir una
difusión continua de los últimos valores de datos del distribuidor
de datos 190.
El programa de configuración 165 también puede
ser usado 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 vehículo que
se ejecutan en el bus.
Los sistemas avanzados de ayuda al conductor
ofrecen formas de mejorar la seguridad, la comodidad, la eficiencia,
y la satisfacción general de la marcha. Estos sistemas requieren
información acerca de la red de carreteras en torno al vehículo.
Parte de esta información puede ser obtenida por sensores. Sin
embargo, los sensores no obtienen fiablemente todos los tipos de
información que necesitan algunos de estos sistemas.
Consiguientemente, el uso de una base de datos de mapa además de, o
como un sucedáneo de, los sensores puede hacer que los sistemas
avanzados de ayuda al conductor operen mejor y más fiablemente.
Las realizaciones de la arquitectura de datos de
mapa descrita de los sistemas avanzados de ayuda al conductor (100
en la figura 1) proporcionan unos medios por los que una o más
aplicaciones del sistema avanzado de ayuda al conductor 200 pueden
usar datos de mapa en apoyo de la(s) función(es) que
proporcionan. La arquitectura de datos de mapa de los sistemas
avanzados de ayuda al conductor proporciona aplicaciones del sistema
avanzado de ayuda al conductor con acceso a datos acerca de la
geometría de la carretera y otros atributos cerca del vehículo. Por
ejemplo, la arquitectura de datos de mapa de los sistemas avanzados
de ayuda al conductor proporciona acceso a datos que representan
cualquier posición a lo largo de la red de carreteras cerca del
vehículo a las que se puede llegar dentro de 10 segundos de tiempo
de marcha. Esta porción de la red de carreteras corresponde al
horizonte electrónico. El horizonte electrónico es recalculado
regularmente en el tiempo y/o cuando el vehículo se desplaza a lo
largo de la red de carreteras. Una vez que se ha calculado un
horizonte electrónico, la aplicación del sistema avanzado de ayuda
al conductor puede usar los datos acerca de los recorridos del
vehículo en el horizonte electrónico.
Con referencia a la figura 16, una aplicación
avanzada de ayuda al conductor 200 puede acceder a los datos
representados por un horizonte electrónico con un manipulador del
horizonte electrónico (es decir, la ID del objeto de horizonte
electrónico 182 en el depósito de datos 180 en la figura 11). La
aplicación avanzada de ayuda al conductor 200 se basa en la escucha
(300 en la figura 14) para obtener la ID del último horizonte
electrónico (182 en la figura 11) del distribuidor de datos 190. Con
la ID del objeto de horizonte electrónico 182 se pueden obtener
algunos o todos los datos en el objeto de datos de horizonte
electrónico (181 en la figura 11). El objeto de datos de horizonte
electrónico 181 identifica todos los recorridos posibles del
vehículo (o el recorrido primario) a la extensión del horizonte
electrónico. El objeto de datos de horizonte electrónico 181
también identifica los segmentos y nodos en cada recorrido (es
decir, usando los descriptores de segmento y descriptores de nodo,
descritos anteriormente).
Según una realización de la presente invención,
las aplicaciones avanzadas de ayuda al conductor también pueden
obtener datos del sensor y datos de posición del vehículo.
Con respecto a los datos contenidos en un
horizonte electrónico, una aplicación de ayuda al conductor 200
puede usar uno de los iteradores para obtener los datos contenidos
en un horizonte electrónico de manera organizada. Un iterador es un
programa que permite la recuperación sucesiva de artículos de una
colección de artículos. Los iteradores permiten que una aplicación
avanzada de ayuda al conductor atraviese el horizonte electrónico
para recuperación de descriptores de recorrido, segmentos de
horizonte electrónico, datos acerca de puntos a lo largo de
segmentos, etc. Entre los iteradores que están disponibles para 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 electrónico y/u otra
información apropiada.
El iterador de recorrido 402 es un iterador que
genera todos los recorridos de un horizonte electrónico, un
recorrido cada vez. Los iteradores de recorrido permiten la
generación de todos los recorridos o solamente de los recorridos
que sean accesibles.
El iterador de segmento 404 devuelve una lista
de segmentos de horizonte electrónico. 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 electrónico) y
posteriormente todos los segmentos de salida del nodo (en
orientación hacia la derecha).
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
electrónico o con un recorrido de un horizonte electrónico. Cuando
se inicializa con un segmento de un horizonte electrónico, 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 electrónico, el iterador
de punto de segmento 406 devuelve el primer punto después de la
posición corriente del vehículo y posteriormente todos los puntos a
lo largo de todos los segmentos que forman el recorrido en el orden
en que tienen lugar en el recorrido. Obsérvese 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 después
el nodo de entrada del segmento de salida.
En algunas realizaciones de la base de datos de
mapa (130 en las figuras 1, 3A y 3B) algunas carreteras se
representan por datos de exactitud más alta que otras carreteras.
Algunos sistemas avanzados de ayuda al conductor 200 pueden
requerir que el vehículo se encuentre en una carretera representada
por los datos de exactitud más alta. Alternativamente, algunos
sistemas avanzados de ayuda al conductor 200 pueden requerir que
todas las carreteras situadas alrededor del vehículo (por ejemplo,
en el horizonte electrónico) sean representadas por los datos de
exactitud más alta. Así, la arquitectura 100 proporciona unos medios
por los que las aplicaciones de ayuda al conductor 200 pueden
determinar si el vehículo se encuentra en una carretera representada
por datos de exactitud más alta o si todos los segmentos de
carretera situados dentro del horizonte electrónico se representan
por datos de exactitud más alta. Si los datos de exactitud más alta
están situados en una base de datos suplementaria, tal como la base
de datos 130(2) en la figura 1, la determinación de si los
datos son datos de exactitud más alta 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
realización de base de datos única que tiene tanto datos de
exactitud más alta como datos de exactitud inferior, la
determinación de si los datos son de exactitud más alta 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 electrónico a no ser
que todos los segmentos de carretera en todos los recorridos del
horizonte electrónico se representen por datos de exactitud más
alta.
La arquitectura de interface de datos del
sistema avanzado de ayuda al conductor incluye componentes de
software y hardware que se ejecutan en una plataforma informática
adecuada. En un sistema prototipo, la arquitectura de interface 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). También son adecuadas
plataformas alternativas.
En un entorno prototipo, se pasan datos de los
sensores 120 al ordenador personal conectado mediante una conexión
en serie (RS-232).
Una realización alternativa de la arquitectura
de datos de mapa del sistema de ayuda al conductor 600 se representa
en la figura 17. Según esta alternativa, las aplicaciones de ayuda
al conductor 602 se ejecutan en microcontroladores dedicados
conectados a un bus de datos a bordo 610. En esta realización, el
bus de datos a bordo 610 es un bus CAN, aunque, en realización
alternativa, el bus a bordo del vehículo puede ser cualquier otro
tipo de bus. En la realización de la figura 17, una escucha de
datos 620 (que puede ser similar o idéntica a las escuchas de datos
300, descritas anteriormente) está adaptada para conectar con el bus
de datos a bordo 610 y comunicar lecturas de datos usando los
métodos y protocolos estándar para dicho bus.
En la realización del programa de horizonte de
datos descrito anteriormente se formó un objeto de datos de
horizonte electrónico que incluía datos que representan los
recorridos que el vehículo puede seguir a las extensiones del
horizonte electrónico. Los datos que representan los recorridos
incluían datos que representan atributos de la carretera, la
geometría de la carretera, y objetos de carretera. En la realización
descrita anteriormente, los datos que representan los recorridos se
obtuvieron de la base de datos de mapa 130 o derivaron de datos en
la base de datos de mapa (por ejemplo, la curvatura). Según una
realización alternativa, los datos de horizonte electrónico también
incluyen datos dinámicos. Los datos dinámicos incluyen datos de los
sensores, derivados de los datos del sensor, o derivados de una
combinación de datos del sensor y datos de la base de datos de
mapa. Según esta realización, los datos del sensor pueden estar
asociados con uno o varios recorridos en el horizonte electrónico.
Por ejemplo, si un sensor del sistema de radar en el vehículo
detecta un objeto situado a 100 metros por delante del vehículo,
los datos que indican este objeto detectado se incluyen en el
horizonte electrónico. Si un recorrido de horizonte electrónico
corresponde a la posición del objeto detectado, los datos que
indican el objeto detectado pueden estar asociados con el recorrido
en la posición correspondiente (por ejemplo, en un punto del
segmento en el recorrido).
Según otro aspecto, si una característica
representada por datos en la base de datos de mapa deberá ser
detectable por uno o más sensores en el vehículo, una rutina en el
programa de horizonte de datos intenta concordar la característica
representada con un objeto detectado por los sensores. Por ejemplo,
suponiendo que el horizonte electrónico incluye datos de la base de
datos de mapa que indican la presencia de un paso elevado situado
80 metros por delante del vehículo y suponiendo también que un
sensor del sistema de radar en el vehículo detecta un objeto
situado a 82 metros por delante del vehículo y atravesado en la
carretera. Según esta alternativa, una rutina en el programa de
horizonte de datos relaciona los datos de la base de datos de mapa
que indican la presencia del paso elevado y los datos del sensor de
radar que indican la presencia de un objeto atravesado en la
carretera. Según otro aspecto de esta alternativa, una rutina en el
programa de horizonte de datos puede indicar una diferencia (por
ejemplo, una \Delta) entre la posición del paso elevado como
indican los datos de la base de datos de mapa y la posición del
objeto atravesado en la carretera como indica el sensor de
radar.
En la realización del depósito de datos descrita
anteriormente se describió un mecanismo de manejo de depósito que
facilitaba el almacenamiento y el uso de los datos de horizonte
electrónico. En realizaciones alternativas, cada conjunto de datos
que representa un horizonte electrónico separado se puede considerar
como un conjunto pleno 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 electrónico
(180(1) en la figura 10) contenidos en el depósito de datos
180 pueden incluir solamente los datos de recorrido primarios.
Alternativamente, el depósito de datos 180 también puede contener
tanto datos de recorrido primarios como datos que representan todos
los datos de horizonte electrónico.
Como se ha mencionado anteriormente, en una
realización, una aplicación de ayuda al conductor utiliza una
escucha de datos separada para cada uno de los diferentes tipos de
datos que usa la aplicación de ayuda al conductor. Según una
realización alternativa, se puede usar una sola escucha de datos
para más de un tipo de datos. Según esta alternativa, una sola
escucha de datos recibe notificaciones acerca de más de un tipo de
datos y responde con peticiones de más de un tipo de datos. Por
ejemplo, según esta realización alternativa, si una aplicación de
ayuda al conductor usa tanto datos de horizonte electrónico como
datos del sensor, una sola escucha de datos puede estar asociada
con la aplicación de ayuda al conductor y ser usada para recibir
notificaciones acerca tanto de los datos de horizonte electrónico
como de los datos del sensor.
En una realización descrita anteriormente, una
escucha recibe una notificación acerca de la disponibilidad de
nuevos datos en el depósito de datos y posteriormente pide que se le
envíen nuevos datos. Según una realización alternativa, cuando una
escucha recibe una notificación acerca de la disponibilidad de
nuevos datos, puede pedir que los nuevos datos sean enviados por
difusión, multidifusión, u otros medios, a varias aplicaciones y/o
escuchas.
Según otra realización alternativa, una escucha
de datos se registra en el distribuidor de datos y a continuación
recibe automáticamente los datos en el horizonte electrónico cuando
están disponibles. Según esta alternativa, la escucha de datos no
recibe primero una notificación de la disponibilidad de nuevos datos
ni pide los nuevos datos a la recepción de la notificación. Según
esta realización alternativa, la escucha de datos puede recibir los
nuevos datos por transmisión punto a punto, difusión, multidifusión,
u otros medios.
Las realizaciones de la arquitectura de datos de
mapa del sistema avanzado de ayuda al conductor (en las figuras 1 y
17) proporcionan unos medios por los que uno o más sistemas
avanzados de ayuda al conductor pueden utilizar datos de mapa para
soportar la(s) función(es) que proporcionan. El uso de
datos de mapa por sistemas avanzados de ayuda al conductor puede
mejorar las funciones que realizan tales sistemas. La arquitectura
aquí descrita proporciona unos medios por los que más de una
aplicación de ayuda al conductor puede usar los mismos datos de
mapa. La arquitectura aquí descrita también proporciona unos medios
por los que diferentes aplicaciones de ayuda al conductor pueden
obtener diferentes tipos de datos de mapa. Además, la arquitectura
aquí descrita también proporciona unos medios por los que
diferentes aplicaciones de ayuda al conductor pueden obtener datos
de mapa a tasas diferentes.
Realizaciones de la arquitectura de datos de
mapa aquí descrita proporcionan ventajas adicionales. El software
de aplicación de ayuda al conductor se mantiene separado del
programa de horizonte de datos, proporcionando por ello
versatilidad, compatibilidad y fiabilidad. Además, dado que el
programa de horizonte de datos implementa una interface fácil de
usar, es relativamente fácil que diferentes tipos de aplicaciones de
ayuda al conductor utilizan el programa de horizonte de datos.
Se ha previsto que la descripción detallada
anterior se considere ilustrativa más bien que limitativa y se
entiende que se ha previsto que las reivindicaciones siguientes
incluyendo todos los equivalentes definan el alcance de la
invención.
Claims (33)
1. Una arquitectura de datos para un vehículo de
motor (108) para proporcionar datos continuamente actualizados
acerca de recorridos a lo largo de carreteras por las que puede
marchar el vehículo de motor desde una posición actual del vehículo
de motor cuando el vehículo de motor avanza a lo largo de dichas
carreteras, incluyendo la arquitectura de datos:
una base de datos de mapa (130) conteniendo
datos acerca de carreteras en una región geográfica; y
un programa de localización de vehículo
(150(2)(1)) que usa datos de sensores (120) para proporcionar
una salida que indica una posición actual a lo largo de un segmento
de carretera representado por datos en dicha base de datos de
mapa;
caracterizado porque la arquitectura de
datos incluye:
un programa de horizonte de datos (170) que usa
la salida del programa de localización de vehículo y datos de la
base de datos de mapa para determinar posibles recorridos que el
vehículo de motor podría seguir desde dicha posición actual a un
destino, siendo cada recorrido una secuencia correspondiente de uno
o más segmentos de carretera que se representan por datos en dicha
base de datos de mapa; y
un depósito de datos (180) para almacenar datos
que representan los recorridos determinados por el programa de
horizonte de datos.
2. La arquitectura de datos de la reivindicación
1, donde dichos datos almacenados en dicho depósito de datos
incluyen:
un objeto de datos de horizonte electrónico
conteniendo atributos de datos que representan segmentos de
carretera que forman los recorridos; y
una pluralidad de objetos de horizonte
electrónico, donde cada objeto de horizonte electrónico incluye:
una referencia a dicho objeto de datos de
horizonte electrónico, y
datos que indican una distancia que una posición
de vehículo asociada con el objeto de horizonte electrónico
representado se desplaza de la posición de vehículo asociada con el
objeto de datos de horizonte electrónico referen-
ciado.
ciado.
3. La arquitectura de datos de la reivindicación
2, donde dichos atributos de datos que representan segmentos de
carretera contenidos en dicho objeto de datos de horizonte
electrónico incluyen datos que indican la geometría de la
carretera, datos que indican atributos de la carretera, y datos que
representan objetos de carretera.
4. La arquitectura de datos de la reivindicación
1, incluyendo además:
un distribuidor de datos en respuesta al
almacenamiento de datos que representan los recorridos en dicho
depósito de datos, donde dicho distribuidor de datos envía mensajes
que indican la disponibilidad de nuevos datos cada vez que se
guardan nuevos datos en dicho depósito de datos.
5. La arquitectura de datos de la reivindicación
4, incluyendo además:
un programa de escucha, donde dicho programa de
escucha recibe dichos mensajes de dicho distribuidor de datos.
6. La arquitectura de datos de la reivindicación
5, donde dicho programa de escucha está asociado con una aplicación
de ayuda al conductor que usa los datos almacenados en dicho
depósito de datos que representan los recorri-
dos.
dos.
7. La arquitectura de datos de la reivindicación
5, donde dicho programa de escucha suministra una salida a un bus
en vehículo al que está conectada una aplicación de ayuda al
conductor que usa los datos almacenados en dicho depósito de
datos.
8. La arquitectura de datos de la reivindicación
7, donde dicho bus en vehículo incluye un bus CAN.
9. La arquitectura de datos de la reivindicación
5, donde dicho programa de escucha incluye una cola conteniendo
dichos mensajes recibidos muy recientemente por él.
10. La arquitectura de datos de la
reivindicación 4, donde dicho distribuidor de datos envía mensajes
cada vez que se determina una nueva posición del vehículo.
11. La arquitectura de datos de la
reivindicación 4, incluyendo además:
un programa de escucha que se registra en el
distribuidor de datos para recibir dichos mensajes de él.
12. La arquitectura de datos de la
reivindicación 11, donde dicho programa de escucha recibe mensajes
acerca de un tipo de datos solamente.
13. La arquitectura de datos de la
reivindicación 11, donde dicho programa de escucha recibe mensajes
acerca de más de un tipo de datos.
14. La arquitectura de datos de la
reivindicación 1, incluyendo además:
un distribuidor de datos en respuesta al
almacenamiento de datos que representan los recorridos en dicho
depósito de datos, donde dicho distribuidor de datos envía dichos
datos cada vez que se guardan nuevos datos en dicho depósito de
datos.
15. La arquitectura de datos de la
reivindicación 1, incluyendo además:
un distribuidor de datos en respuesta al
almacenamiento de datos que representan los recorridos en dicho
depósito de datos, donde dicho distribuidor de datos envía dichos
datos mediante al menos una transmisión de punto a punto,
transmisión multidifusión, y transmisión difundida.
16. La arquitectura de datos de la
reivindicación 1, donde dicho depósito de datos también guarda datos
que representan posiciones anteriores del vehículo de motor.
17. La arquitectura de datos de la
reivindicación 16, incluyendo además:
un distribuidor de datos sensible al
almacenamiento de datos que representan los recorridos en dicho
depósito de datos y datos que representan una nueva posición del
vehículo, donde dicho distribuidor de datos envía mensajes que
indican la disponibilidad de nuevos datos cada vez que se guardan
nuevos datos en dicho depósito de datos.
18. La arquitectura de datos de la
reivindicación 1, donde dicho depósito de datos también guarda datos
del sensor.
19. La arquitectura de datos de la
reivindicación 18, incluyendo además:
un distribuidor de datos sensible al
almacenamiento de datos que representan los recorridos y dichos
datos del sensor en dicho depósito de datos, donde dicho
distribuidor de datos envía mensajes que indican la disponibilidad
de nuevos datos cada vez que se guardan nuevos datos en dicho
depósito de datos.
20. La arquitectura de datos de la
reivindicación 1, donde dicha base de datos de mapa está situada en
dicho vehículo de motor.
21. La arquitectura de datos de la
reivindicación 1, donde dicho depósito de datos también guarda datos
que representan un recorrido primario.
22. La arquitectura de datos de la
reivindicación 21 donde dicho recorrido primario es un recorrido
basado en ruta.
23. La arquitectura de datos de la
reivindicación 21 donde dicho recorrido primario es un recorrido más
probable basado en la red local de carreteras.
24. La arquitectura de datos de la
reivindicación 1, incluyendo además:
un programa de evaluación de recorridos que
indica un recorrido más probable en base solamente a la red viaria
local.
25. La arquitectura de datos de la
reivindicación 1, donde dichos datos acerca de carreteras incluyen
datos acerca de objetos de carretera incluyendo señales de
carretera y pasos de peatones.
26. La arquitectura de datos de la
reivindicación 1, incluyendo además:
una rutina en dicho programa de horizonte de
datos que calcula la curvatura de la carretera usando coordenadas
de puntos a lo largo de carreteras.
27. La arquitectura de datos de la
reivindicación 1, donde dicho programa de horizonte de datos guarda
temporalmente datos que representan segmentos de carretera situados
alrededor del vehículo de motor en dicho depósito de datos; e
\newpage
incluyendo además una escucha de datos asociada
con una aplicación que proporciona características de ayuda al
conductor, donde
dicha escucha de datos recibe notificaciones de
dicho programa de horizonte de datos acerca de datos nuevamente
almacenados y obtiene dichos datos de dicho programa de horizonte de
datos, según sea necesario.
28. Un método de proporcionar datos que
representan posibles recorridos que un vehículo (108) podría tomar
a lo largo de carreteras desde una posición actual del vehículo a
una posición a lo largo de una carretera, incluyendo el método:
determinar una posición del vehículo;
caracterizado porque el método
incluye:
determinar todos los recorridos a lo largo de
segmentos de carretera que el vehículo puede seguir desde dicha
posición actual a un destino asociado con un umbral;
almacenar datos que representan dichos
recorridos; y
hacer dichos datos almacenados accesibles a
aplicaciones (200) que usan los datos para proporcionar ayuda a un
conductor de dicho vehículo durante el recorrido.
29. El método de la reivindicación 28, donde
dicho paso de almacenamiento incluye:
almacenar un primer objeto que incluye atributos
de datos que representan dichos recorridos; y
almacenar un segundo objeto que incluye la
distancia que una posición de vehículo asociada con dicho segundo
objeto difiere de una posición de vehículo asociada con dicho primer
objeto.
30. El método de la reivindicación 28,
incluyendo además:
después del paso de almacenar datos que
representan dichos recorridos, proporcionar una notificación a
dichas aplicaciones que usan los datos de que nuevos datos están
disponibles.
31. El método de la reivindicación 30,
incluyendo además:
después del paso de proporcionar una
notificación, enviar los datos que representan dichos recorridos a
una aplicación que responde a dicha notificación.
32. El método de la reivindicación 28,
incluyendo además:
poner los datos almacenados asociados con varias
posiciones del vehículo muy recientemente determinadas a
disposición de dichas aplicaciones que usan los datos.
33. El método de la reivindicación 28, donde
dichos datos almacenados son accesibles para aplicaciones que usan
los datos por un bus CAN.
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 |
|---|---|
| ES2321907T3 true ES2321907T3 (es) | 2009-06-15 |
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 Before (1)
| 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 |
Country Status (5)
| Country | Link |
|---|---|
| EP (2) | EP2042833B1 (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) |
| US9291471B2 (en) | 2009-12-01 | 2016-03-22 | Mitsubishi Electric Corporation | In-vehicle information processing device and driving assist device |
| 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) |
| US11176845B2 (en) | 2012-12-11 | 2021-11-16 | Abalta Technologies, Inc. | Adaptive analysis of driver behavior |
| US9569984B2 (en) | 2012-12-11 | 2017-02-14 | Abalta Technologies, Inc. | Recording, monitoring, and analyzing 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. |
| 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 |
| EP3130891B1 (en) | 2015-08-11 | 2018-01-03 | Continental Automotive GmbH | Method for updating a server database containing precision road information |
| 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 EP EP08019227.1A patent/EP2042833B1/en not_active Expired - Lifetime
- 2000-12-05 ES ES08019227.1T patent/ES2569936T3/es not_active Expired - Lifetime
- 2000-12-05 AT AT00310805T patent/ATE423962T1/de not_active IP Right Cessation
- 2000-12-05 DE DE60041624T patent/DE60041624D1/de not_active Expired - Lifetime
- 2000-12-05 ES ES00310805T patent/ES2321907T3/es not_active Expired - Lifetime
- 2000-12-05 EP EP00310805A patent/EP1111338B1/en not_active Expired - Lifetime
- 2000-12-20 JP JP2000387379A patent/JP2001229494A/ja not_active Withdrawn
Also Published As
| Publication number | Publication date |
|---|---|
| DE60041624D1 (de) | 2009-04-09 |
| ES2569936T3 (es) | 2016-05-13 |
| EP1111338A3 (en) | 2004-07-07 |
| EP1111338B1 (en) | 2009-02-25 |
| JP2001229494A (ja) | 2001-08-24 |
| EP2042833B1 (en) | 2016-02-17 |
| EP1111338A2 (en) | 2001-06-27 |
| EP2042833A1 (en) | 2009-04-01 |
| ATE423962T1 (de) | 2009-03-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2321907T3 (es) | Arquitectura de datos de mapa para ordenador de vehiculo. | |
| 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 | |
| US8892356B1 (en) | Method and system for representing traffic signals in a road network database | |
| US7463974B2 (en) | Systems, methods, and programs for determining whether a vehicle is on-road or off-road | |
| US5731978A (en) | Method and apparatus for enhancing vehicle navigation through recognition of geographical region types | |
| US8213682B2 (en) | Feature information collecting apparatuses, methods, and programs | |
| JP4559551B2 (ja) | フィードバックを用いた地理データベースの更新、拡張、並びに改良のためのシステム及び方法 | |
| US20070021912A1 (en) | Current position information management systems, methods, and programs | |
| EP3919861B1 (en) | Method, apparatus, and computer program product for generating and communicating low bandwidth map version agnostic routes | |
| EP1498694B1 (en) | Vehicle driver assistance system | |
| JP2004109130A (ja) | 地理的データベースにおいて道路を合理化表示する方法 | |
| US20090043488A1 (en) | Navigation system, server, method, and program | |
| White | Emerging requirements for digital maps for in-vehicle pathfinding and other traveller assistance | |
| US12607469B2 (en) | Method, apparatus, and computer program product for estimating a time-of-arrival at a destination | |
| US20200240801A1 (en) | Systems, methods, and computer program product for route validation | |
| EP3922948B1 (en) | Method, apparatus, and computer program product for generating and communicating low bandwidth map version agnostic routes | |
| EP1674827A1 (en) | System for detecting a lane change of a vehicle | |
| JPH09113297A (ja) | 経路計算方法及びこの方法を使用するナビゲーション装置 |