ES3024372T3

ES3024372T3 - Electronic horizon for adas function

Info

Publication number: ES3024372T3
Application number: ES21184886T
Authority: ES
Inventors: Jörg Schüttemeyer; Johannes Stille; Jens Landvogt
Original assignee: Here Global BV
Current assignee: Here Global BV
Priority date: 2021-07-09
Filing date: 2021-07-09
Publication date: 2025-06-04
Anticipated expiration: 2041-07-09
Also published as: US20240318972A1; EP4116676A1; EP4367478A1; EP4116676C0; EP4116676B1; WO2023280993A1; US12601605B2

Abstract

Se describe, entre otros, un método realizado al menos por un dispositivo móvil (110, 400) o una parte del mismo, comprendiendo el método: proporcionar una indicación de una trayectoria del dispositivo móvil (110, 400) a un servidor remoto (121, 500); obtener (136), desde un servidor remoto (121, 500), un horizonte electrónico que comprende datos de horizonte electrónico para una o más funciones ADAS del dispositivo móvil (110, 400), en donde el horizonte electrónico ha sido construido a partir de datos de mapa por el servidor (121, 500) específicamente para permitir que el dispositivo móvil (110, 400) proporcione o para soportar el dispositivo móvil (110, 400) en proporcionar una o más funciones ADAS, en donde el horizonte electrónico cubre una o más rutas potenciales (204, 205, 303a, 303b) predichas para ser tomadas por el dispositivo móvil (110, 400) basándose en la indicación de la trayectoria; y soportar o realizar al menos una de las una o más funciones ADAS basándose al menos parcialmente en el horizonte electrónico. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Horizonte electrónico para función de ADAS

Campo de la divulgación

La presente divulgación se refiere al concepto de horizontes electrónicos y a la provisión de sistemas de asistencia al conductor (ADAS) avanzados, tales como una asistencia de velocidad inteligente (ISA).

Antecedentes

Un ejemplo de una función de ADAS es una asistencia de velocidad inteligente (ISA), que puede considerarse una característica de seguridad avanzada que evita que los vehículos superen el límite de velocidad establecido, ayudando a reducir las colisiones en las carreteras. Por lo tanto, en este momento, la regulación exige que cada vehículo vendido, por ejemplo, en la Unión Europea requerirá una ISA, que tendrá que instalarse en todos los vehículos nuevos vendidos a partir de mayo de 2022. Por lo tanto, por razones de coste, será necesario implementar las funciones de ADAS tales como una ISA con necesidades de recursos mínimas, de tal modo que las mismas puedan implementarse en cada vehículo de una forma económica. En consecuencia, los fabricantes de vehículos (OEM) y otros proveedores de automoción requieren componentes de hardware rentables, que a menudo terminan con capacidades de procesamiento y almacenamiento de datos muy limitadas.

En la actualidad, aunque los límites de velocidad (y otras señales de tráfico) cambian de forma comparativamente frecuente debido a muchos factores diferentes, sigue siendo necesario asegurarse de que los vehículos obtienen la información de una forma fiable. Por lo tanto, para funciones de ADAS como la ISA, la fuente primaria de información es y sigue siendo el sistema de cámara del vehículo. Sin embargo, habitualmente se requiere una fusión de datos con datos de mapa (que contienen información de límite de velocidad, entre otros atributos) para asegurar el nivel de calidad necesario para ISA.

En los datos de mapa, que se emplean para este fin, los límites de velocidad y otras señales en postes adyacentes a las carreteras se registran habitualmente como objetos de mapa, con sus ubicaciones almacenadas en formato de punto de coordenadas (WGS-84) o en relación con el enlace de carretera (por ejemplo, con un ID de enlace y un desplazamiento a lo largo de ese enlace). Los sistemas de ADAS pueden basarse entonces en información de mapa que proporciona el límite de velocidad relevante para la sección de la carretera en donde se ubica actualmente el vehículo.

Una solución sería requerir que los vehículos respectivos tengan acceso a un mapa de referencia local, incluido en muchos casos como parte de, por ejemplo, los sistemas de navegación. Para vehículos que tienen acceso a un mapa de este tipo a bordo, los datos requeridos para la función de ADAS respectiva pueden recuperarse entonces del mapa a bordo - suponiendo que los datos permanecen actualizados regularmente. Sería necesario insertar las actualizaciones del mapa por aire (es decir, a través de una conexión de datos inalámbrica) o a través de tarjetas de USB/SD. La información en relación con las funciones de ADAS, tal como el límite de velocidad y otras características que pueden ayudar en la detección del límite de velocidad, se actualiza entonces como parte de una actualización de región o tesela de mapa. Sin embargo, el almacenamiento de una base de datos de mapas completa y la recuperación de la información de interés (por ejemplo, la información de límite de velocidad y posiblemente información de ubicación auxiliar para ayudar a la detección de límite de velocidad basada en cámara en el vehículo para una ISA) requiere un almacenamiento y procesamiento local significativo de recursos, lo que puede no ser una opción para cada tipo de vehículo, debido a que los fabricantes pueden aspirar a conservar la arquitectura de su vehículo.

Para vehículos sin un mapa a bordo, sería necesario recuperar tales datos de mapa a través de una conexión en línea, por ejemplo, después de proporcionar la posición del vehículo a un servidor. Por ejemplo, podría proporcionarse una tesela de mapa o una capa de mapa individual en respuesta, o bien mediante una actualización de mapa o difusión en continuo, que contiene la información requerida (por ejemplo, ubicación de límites de velocidad) para la porción en teselas respectiva del mapa. Sin embargo, en primer lugar, transferir y extraer los datos relevantes a partir de los datos de mapa aún puede requerir recursos significativos, debido a que una tesela generalmente abarca un área de aproximadamente 1 - 4 km2, que puede ser altamente compleja e incluir muchas características que aumentan el tamaño de datos de la tesela, particularmente en escenarios urbanos. Por lo tanto, una tesela contendría habitualmente características tanto relevantes como no relevantes para soportar una ISA. Incluso si se proporcionara una capa de mapa de teselas objetivo con características de soporte de ISA, la tesela a menudo contendría características de carreteras no relevantes para la trayectoria del vehículo. En segundo lugar, como las conexiones de datos pueden no estar siempre disponibles, puede que ni siquiera sea posible alcanzar y consultar el servidor remoto en busca de datos de mapa respectivos para extraer entonces la información de interés, tal como límite de velocidad y otra información de señales en postes.

El documento US 2021/0064041 A1 divulga un dispositivo de provisión de trayectoria que permite la conducción autónoma. El documento US 2011/0054716 A1 divulga un horizonte de ADAS para vehículos.

En ciertos aspectos, la presente divulgación aborda, por lo tanto, entre otras cosas, el problema de cómo proporcionar información requerida para ciertas funciones de ADAS (tal como información de límite de velocidad para una función de ISA) a vehículos con recursos de procesamiento limitados y - en particular - sin una base de datos de mapas local. En ciertos aspectos, la presente divulgación también aborda el problema de cobertura de red limitada y transferencia de red limitada para proporcionar información requerida para funciones de ADAS a través de una conexión en línea. En ciertos aspectos, la presente divulgación también proporciona una protección de datos mejorada.

Sumario de algunas realizaciones ilustrativas

De acuerdo con un primer aspecto, se divulga un método, realizado por un dispositivo móvil o una parte del mismo, como se define en la reivindicación 1.

El dispositivo móvil que realiza el método del primer aspecto puede ser, por ejemplo, un vehículo, un coche, una moto o similar. Sin embargo, el dispositivo móvil o la parte del mismo también puede ser un sistema de navegación integrado en un vehículo. Además, el dispositivo móvil también puede ser un teléfono inteligente, por ejemplo. Como se explicará con más detalle a continuación, una parte del dispositivo móvil puede ser, por ejemplo, un componente de software y/o hardware de las entidades mencionadas anteriormente, tal como un componente funcional, un componente de cliente, un módulo, una circuitería, un chip, un microprocesador o similar.

De acuerdo con un segundo aspecto, se divulga un método, realizado por un servidor o una parte del mismo, como se define en la reivindicación 13.

El al menos un servidor que realiza el método de acuerdo con el segundo aspecto puede ser, por ejemplo, o comprender un servidor de un proveedor o distribuidor de mapas. El al menos un servidor también puede materializarse por múltiples servidores o una arquitectura distribuida y puede ser, por ejemplo, o comprender un servidor distribuido, un servidor perimetral de red o un servidor en la nube. El servidor también puede comprender una base de datos (por ejemplo, una base de datos de mapas) o estar en comunicación con una base de datos (por ejemplo, externa) o un servidor de base de datos. Como se explicará con más detalle a continuación, una parte del servidor puede ser, por ejemplo, un componente de software y/o hardware del mismo, tal como un componente funcional, un componente de servidor, un módulo, una circuitería, un chip, un microprocesador o similar.

El dispositivo móvil o parte del mismo que realiza el método del primer aspecto y el al menos un servidor que realiza el método del segundo aspecto pueden trabajar conjuntamente para realizar realizaciones de los métodos del primer y/o el segundo aspectos.

De acuerdo con cada uno del primer y el segundo aspecto de la invención, también se divulga un producto de programa informático, haciendo el producto de programa informático, cuando es ejecutado por un procesador, que un aparato realice y/o controle las acciones del método de acuerdo con el aspecto respectivo de la presente invención.

El producto de programa informático puede almacenarse en un medio de almacenamiento legible por ordenador, en particular, un medio tangible y/o no transitorio. El medio de almacenamiento legible por ordenador podría ser, por ejemplo, un disco o una memoria o similar. El producto de programa informático podría almacenarse en el medio de almacenamiento legible por ordenador en forma de instrucciones que codifican el medio de almacenamiento legible por ordenador. El medio de almacenamiento legible por ordenador puede tener por objeto tomar parte en el funcionamiento de un dispositivo, como una memoria interna o externa, por ejemplo, una memoria de solo lectura (ROM) o un disco duro de un ordenador, o puede tener por objeto la distribución del programa, como un disco óptico.

De acuerdo con cada uno del primer y el segundo aspecto ilustrativo de la invención, se divulga un aparato (es decir, un dispositivo móvil o una parte del mismo/un servidor o una parte del mismo), configurado para realizar y/o controlar o que comprende medios respectivos para realizar y/o controlar el método de acuerdo con el aspecto ilustrativo respectivo de la presente invención.

En general, los medios del aparato respectivo de cualquier aspecto pueden implementarse en hardware y/o software. Estos pueden comprender, por ejemplo, al menos un procesador para ejecutar código de programa informático para realizar las funciones requeridas, al menos una memoria que almacena el código de programa, o ambos. Como alternativa, estos podrían comprender, por ejemplo, circuitería que se diseña para implementar las funciones requeridas, por ejemplo, implementadas en un conjunto de chips o un chip, como un circuito integrado. En general, los medios pueden comprender, por ejemplo, uno o más medios de procesamiento o procesadores.

Más específicamente, de acuerdo con cada uno del primer y el segundo aspecto ilustrativo de la invención, se divulga un aparato (es decir, un dispositivo móvil o una parte del mismo/un servidor o una parte del mismo) respectivo, que comprende al menos un procesador y al menos una memoria que incluye código de programa informático, configurados la al menos una memoria y el código de programa informático para, con el al menos un procesador, hacer que un aparato al menos realice y/o controle el método de acuerdo con el aspecto ilustrativo respectivo de la presente invención.

El aparato descrito anteriormente puede ser un módulo o un componente para un dispositivo, por ejemplo, un chip. El aparato divulgado de acuerdo con cualquier aspecto de la invención puede comprender solo los componentes divulgados, por ejemplo, medios, procesador, memoria, o puede comprender además uno o más componentes adicionales.

De acuerdo con cualquiera del primer y el segundo aspecto ilustrativo de la invención, también se divulga un sistema que comprende múltiples aparatos (por ejemplo, un dispositivo móvil y un vehículo en el caso del primer aspecto ilustrativo o múltiples servidores en el caso del segundo aspecto ilustrativo, por ejemplo), en donde dichos aparatos están configurados para cooperar para realizar el método de acuerdo con el aspecto ilustrativo respectivo de la invención o uno de dichos aparatos está configurado para realizar el método de acuerdo con el aspecto ilustrativo respectivo de la invención solo.

En particular, de acuerdo con un aspecto ilustrativo adicional, también se divulga un sistema que comprende un dispositivo móvil o una parte del mismo y un servidor o una parte del mismo que realizan conjuntamente el método de acuerdo con el primer y/o el segundo aspecto ilustrativo. En particular, el dispositivo móvil o una parte del mismo puede configurarse para realizar el método de acuerdo con el primer aspecto ilustrativo y el servidor o una parte del mismo puede configurarse para realizar el método de acuerdo con el segundo aspecto ilustrativo.

En lo sucesivo, se describirán con detalle adicional características ilustrativas y realizaciones ilustrativas de todos los aspectos de la presente invención.

Que el dispositivo móvil y el servidor estén ubicados remotamente entre sí, puede entenderse que significa que los mismos se comunican en particular al menos en parte a través de una red de comunicaciones inalámbricas, tal como un sistema de comunicación celular (por ejemplo, un sistema de comunicación que utiliza GSM, WCDMA, LTE, 5G y/o cualquier tecnología de generación futura) y/o un sistema de comunicación no celular (por ejemplo, una red de área local inalámbrica). En general, un sistema de comunicación celular puede caracterizarse, por ejemplo, por un pavimento básicamente sin discontinuidades de un área geográfica (habitualmente del orden de al menos cientos o miles de kilómetros cuadrados) con células en las que se proporciona cobertura por nodos respectivos del sistema de comunicación que son operados por el mismo operador, cuya red puede soportar, por ejemplo, el traspaso de comunicación entre células. En consecuencia, un sistema de comunicación no celular puede caracterizarse como un sistema de comunicación que no tiene todas estas propiedades. Con más detalle, ejemplos de un sistema o red de comunicación celular son un sistema o red de comunicación de segunda generación (2g , por ejemplo, el Sistema Global para Comunicación Móvil (GSM), el Sistema de Radio por Paquetes General (GPRS), las Tasas de Datos Mejoradas para la Evolución de GSM (EDGE) o los Datos Conmutados por Circuitos de Alta Velocidad (HSCSD)), de tercera generación (3G, por ejemplo, el Sistema Universal de Telecomunicaciones Móviles, UMTS, WCDMA, TD-SCDMA o CDMA-2000), de cuarta generación (4G, por ejemplo, el Sistema de Evolución a Largo Plazo, el sistema de LTE, el sistema de LTE Avanzada (LTE-A) o el sistema de WiMAX de 802.16m del IEEE), de quinta generación (5G) o más reciente. Ejemplos adicionales de un sistema o red de comunicación no celular son un sistema de WLAN (por ejemplo, uno de WiFi o de 802.11 del IEEE), un sistema de WiMAX (por ejemplo, uno de 802.16 del IEEE), un sistema de acceso a Internet por satélite, un sistema (de LE) de Bluetooth, un sistema de ZigBee, un sistema de identificación de radiofrecuencia (RFID), una red de radiodifusión tal como, por ejemplo, un sistema de radiodifusión de vídeo digital (DVB), radiodifusión de audio digital (DAB) o modulado en frecuencia (FM)/modulado en amplitud (AM), un sistema de comunicación de campo cercano (NFC), etc.

Una función de sistema de asistencia al conductor avanzado (ADAS) puede entenderse generalmente como una tecnología electrónica para ayudar a un conductor a, por ejemplo, conducir y/o aparcar. Para esto, un ADAS puede hacer uso de una interfaz hombre-máquina. Un ADAS puede usar sensores (por ejemplo, cámaras), para detectar obstáculos cercanos o errores del conductor, y responder en consecuencia. Una función de ADAS puede, por ejemplo, alertar al conductor de problemas, implementar salvaguardas y/o tomar el control del vehículo si es necesario.

Por ejemplo, una función de ADAS puede proporcionar asistencia de límite de velocidad, automatizar la iluminación, el control de crucero adaptativo, ayudar a evitar colisiones, incorporar navegación por satélite y advertencias de tráfico, alertar a los conductores acerca de posibles obstáculos, ayudar en la salida de carril y el centrado de carril, proporcionar asistencia de navegación a través de teléfonos inteligentes, por nombrar unos pocos ejemplos.

Con respecto al ejemplo de una asistencia de velocidad inteligente, esta función puede usar, por ejemplo, información acerca de la carretera u objetos de arcén para determinar una velocidad permitida o adecuada, como se explicará con detalle adicional a continuación. En cualquier caso, la función de ISA se entiende solo como un ejemplo de una posible función de ADAS para la presente invención.

Un horizonte electrónico puede referirse, por ejemplo, a una representación parcial de una red de tráfico o de carreteras. Por ejemplo, un horizonte electrónico puede comprender, por ejemplo, datos acerca de uno o más enlaces o segmentos de carretera, intersecciones, objetos de arcén, geometría de carretera y/o atributos de carreteras u objetos de carretera. La representación de la red de tráfico puede conducir al exterior desde una posición actual del dispositivo móvil, por ejemplo, hasta cierto punto limitado (por ejemplo, predicho dependiendo de las circunstancias específicas). Por lo tanto, el horizonte electrónico puede representar la red de tráfico (por ejemplo, carretera(s), atributos, etc.) por delante (o posiblemente por detrás) del dispositivo móvil. En ese sentido, el horizonte electrónico puede ser una representación de trayectorias potenciales que van a ser tomadas por el dispositivo móvil desde su posición actual en un futuro próximo. Por lo tanto, puede entenderse que el horizonte electrónico se refiere a una colección de datos que representa una red de tráfico parcial que conduce lejos de la posición actual del dispositivo móvil en un grado limitado y que forma de ese modo el horizonte electrónico.

Por lo tanto, el horizonte electrónico comprende datos derivados de datos de mapa acerca de una porción de la red de tráfico por delante, que pueden usarse entonces por una aplicación de ADAS respectiva para implementar la funcionalidad de ADAS correspondiente con respecto al dispositivo móvil.

La indicación de una trayectoria proporcionada por el dispositivo móvil puede comprender, por ejemplo, o consistir en una o más ubicaciones (por ejemplo, pares de coordenadas), un rumbo (por ejemplo, un vector) y/o la velocidad (por ejemplo, actual). Puede ser ventajoso proporcionar las últimas N ubicaciones del dispositivo móvil, como se describirá con más detalle a continuación.

Como el horizonte electrónico cubre una o más trayectorias potenciales que se predice que van a ser tomadas por el dispositivo móvil, la construcción del horizonte electrónico implica predecir la trayectoria o trayectorias que es probable que el dispositivo móvil recorra en el futuro inmediato. Esto asegura que los datos necesarios se transmiten al dispositivo móvil para permitir la implementación de la función de ADAS respectiva por el dispositivo móvil a medida que se desplaza. Cuando se determina una porción adecuada del tráfico o red de carreteras por delante para su inclusión cuando se construye en el horizonte electrónico, el servidor puede equilibrar la provisión de datos suficientes para asegurar que la funcionalidad de ADAS pueda implementarse adecuadamente por el dispositivo móvil mientras se evita sobrecargar el dispositivo móvil y sus aplicaciones de ADAS.

En primer lugar, en este sentido, la determinación del tamaño o extensión del horizonte electrónico que va a ser construido por el servidor puede estar centrada en el tamaño de los datos. Esto puede permitir, en particular, mantener una utilización de memoria caché óptima (por ejemplo, entregando trayectorias de longitudes que cruzan potencialmente múltiples teselas). En consecuencia, las solicitudes para obtener un horizonte electrónico en el dispositivo móvil pueden hacerse a intervalos irregulares, intervalos irregulares que pueden proporcionar en particular una mejor protección de privacidad. Esto contrasta con un enfoque, en el que la extensión de cada horizonte electrónico obtenido se basa y, en particular, se limita al borde de una tesela respectiva (lo que significa que tiene que haber al menos una solicitud por tesela), solicitudes que pueden permitir sacar conclusiones acerca de la identidad, lo que puede ser un problema de protección de privacidad. El enfoque descrito, por otro lado, puede funcionar ventajosamente sobre la base de una trayectoria en lugar de una tesela. La trayectoria puede ajustarse a escala (es decir, acortarse o prolongarse) dinámicamente, dependiendo de diversos factores tales como velocidad, memoria caché disponible, conectividad esperada, estrategia para minimizar el coste de transferencia de datos, etc. (como se describirá con más detalle a continuación).

En segundo lugar, las solicitudes pueden gestionarse sin mantener el estado en el lado de servidor, lo que 1) simplifica la implementación, 2) ahorra recursos y 3) baja el riesgo de privacidad de almacenar datos de ubicación.

En tercer lugar, el tamaño de cabida útil del horizonte electrónico puede ajustarse para encajar en un número fijo de paquetes de datos de célula (idealmente, solo en uno), de tal modo que hay menos tara de comunicación cuando se proporcionan los datos de horizonte electrónico. Por ejemplo, TCP tiene un tamaño de cabida útil máximo de 64 kb, lo que podría abarcar varias teselas (particularmente en una autopista lejos de los centros de población). La extensión del horizonte electrónico puede estar sujeta a consideraciones adicionales como se explicará con más detalle a continuación.

Además, debido a que el horizonte electrónico cubre una o más trayectorias potenciales que se predice que van a tomarse, puede obtenerse un horizonte electrónico que se extiende más allá de lo que actualmente necesitan las aplicaciones de ADAS respectivas, por lo que pueden entregarse datos a las aplicaciones de ADAS durante algún tiempo desde un único conjunto de datos de horizonte electrónico desde el servidor. Esto se aplica tanto cuando una aplicación de ADAS necesita información únicamente para la ubicación actual, o cuando ella misma necesita un horizonte electrónico (en el último caso, el horizonte electrónico proporcionado a las aplicaciones de ADAS puede estar menos extendido que el obtenido del servidor). Además, no es necesario entregar el horizonte electrónico de forma incremental, actualizándolo continuamente con datos adicionales relevantes en la posición actual, en su lugar puede hacerse un envío único (aunque repetidamente) de un horizonte electrónico completo (con más datos de los necesarios en este momento).

El horizonte electrónico se ha construido a partir de datos de mapa por el servidor específicamente para posibilitar que el dispositivo móvil proporcione la(s) función(es) de ADAS respectiva(s) o al menos para soportar el dispositivo móvil para proporcionar la(s) función(es) de ADAS respectiva(s). Por lo tanto, puede considerarse que el horizonte electrónico se construye específicamente para una cierta situación o circunstancias (por ejemplo, basándose en una cierta posición del dispositivo móvil, ciertas trayectorias potenciales que se predice que van a ser tomadas por el dispositivo móvil y/o cierta(s) función(es) de ADAS que va(n) a proporcionarse). Por lo tanto, puede considerarse que un horizonte electrónico depende de la posición actual del dispositivo móvil, la trayectoria o trayectorias que se predice que van a ser tomadas por el dispositivo móvil y/o la(s) función(es) de ADAS que va(n) a ser soportada(s) por el horizonte electrónico.

Además, en contraste con los datos de mapa digital originales (por ejemplo, teselas de mapa completas o ciertas capas de una tesela de mapa) tal como se almacenan en una base de datos de mapas, un horizonte electrónico es construido o derivado por el servidor a partir de estos datos de mapa. En otras palabras, los datos del horizonte electrónico ya se han extraído de estos datos de mapa, de tal modo que solo pueden incluirse, en el horizonte electrónico, datos específicamente relevantes o requeridos para la(s) función(es) de ADAS respectiva(s). Por lo tanto, el horizonte electrónico puede comprender menos datos que, por ejemplo, el mapa original con la misma extensión geográfica.

Para proporcionar un ejemplo de un formato o estructura de datos para un horizonte electrónico se hace referencia a la especificación de ADASIS (tal como la versión 1, la versión 2 o la versión 3 de ADASIS). Sin embargo, la implementación específica y la estructura de datos del horizonte electrónico no están limitadas por la presente divulgación.

Para construir el horizonte electrónico de tal modo que cubra una o más trayectorias potenciales que se predice que van a ser tomadas por el dispositivo móvil, puede ser necesario considerar más que únicamente una posición actual (tal como una posición de coche actual c Cp , el rumbo y la velocidad del dispositivo móvil, la hora local, etc.). Por ejemplo, puede considerarse un cierto número de las últimas estimaciones de posición, como se explicará con más detalle a continuación. Adicionalmente o como alternativa, puede considerarse otra información tal como expectativas basándose en trayectorias tomadas previamente de entidades móviles en la misma posición.

En este sentido, el método de acuerdo con el primer y/o el segundo aspecto puede comprender además la etapa de predecir una o más trayectorias potenciales, que es probable que sean tomadas por el dispositivo móvil de tal modo que los datos de horizonte electrónico pueden cubrir entonces las una o más trayectorias potenciales. Por ejemplo, pueden considerarse solo trayectorias que se toman con una probabilidad por encima de un umbral (por ejemplo, predefinido o calculado dinámicamente). Por ejemplo, el horizonte electrónico puede cubrir la trayectoria y las subtrayectorias más probables, por ejemplo, siempre que las mismas estén por encima del umbral. Por ejemplo, solo pueden usarse trayectorias potenciales hasta una distancia máxima (por ejemplo, predeterminada), radio y/o tiempo de viaje esperado desde una posición actual del dispositivo móvil para el horizonte electrónico.

Aunque un ADAS realizado por el dispositivo móvil puede basarse únicamente en los datos a partir del horizonte electrónico, una función de ADAS habitualmente considera datos adicionales, tales como entradas de sensor desde el dispositivo móvil, como se explicará con más detalle a continuación. En consecuencia, la(s) función(es) de ADAS puede(n) basarse al menos parcialmente en el horizonte electrónico.

Los aspectos ilustrativos pueden tener, en particular, la ventaja de que, en comparación con, por ejemplo, la provisión habitual de datos de mapa, solo es necesario proporcionar una cantidad reducida de datos, debido a que el horizonte electrónico se ha construido en línea en un servidor a partir de datos de mapa específicamente para proporcionar las una o más funciones de ADAS en primer lugar. Esto ahorra recursos de almacenamiento y procesamiento (y, por lo tanto, hardware costoso) en el dispositivo móvil. Adicionalmente, como el horizonte electrónico no comprende solo datos de horizonte electrónico que cubren una posición actual del dispositivo móvil, sino también una o más trayectorias potenciales que se predice que van a ser tomadas por el dispositivo móvil, pueden salvarse retransmisiones repetidas de datos y brechas de conectividad. Esto último puede facilitarse en particular considerando mapas de conectividad, como se explicará con más detalle a continuación.

De acuerdo con una realización de cualquiera de los aspectos ilustrativos, el horizonte electrónico se obtiene obteniendo repetidamente un horizonte electrónico de sustitución que comprende datos de horizonte electrónico de sustitución. La provisión y obtención del horizonte electrónico puede considerarse como un servicio en línea. El horizonte electrónico de sustitución puede ser proporcionado por el servidor y obtenido por el dispositivo móvil sobre la marcha. Por ejemplo, puede comprobarse si el dispositivo móvil está cerca de una frontera del horizonte electrónico (es decir, cerca de posiciones geográficas que ya no están cubiertas por el horizonte electrónico), lo que puede ser determinado, por ejemplo, por el dispositivo móvil y/o por el servidor. Por ejemplo, esto puede lograrse comprobando las estimaciones de posición del dispositivo móvil y, por ejemplo, comparando tal cosa con una cobertura del horizonte electrónico utilizado actualmente en el dispositivo móvil y/o comprobando el tiempo que ha transcurrido desde una (por ejemplo, la última) posición determinada del dispositivo móvil y comparándolo con un tiempo estimado hasta que se espera que el dispositivo móvil alcance la frontera del horizonte electrónico desde allí. En caso de que, por ejemplo, el dispositivo móvil determine que está cerca de una frontera del horizonte electrónico, puede solicitar un horizonte electrónico nuevo o de sustitución. En caso de que, por ejemplo, el servidor determine que el dispositivo móvil debería estar cerca de una frontera del horizonte electrónico, puede insertar un horizonte electrónico nuevo o de sustitución en el dispositivo móvil. Como ya se ha mencionado anteriormente, en contraste con un protocolo de horizonte electrónico que mantiene de forma incremental un horizonte electrónico almacenado en el lado del cliente (es decir, en el dispositivo móvil) enviando muchas actualizaciones pequeñas, el enfoque descrito es diferente, debido a que se envía un nuevo horizonte de sustitución desde de vez en cuando, que sustituye completamente el horizonte electrónico almacenado en el cliente (actualización no incremental). Ventajosamente, no es necesario almacenar el estado actual del cliente (como es necesario con otras implementaciones de horizonte electrónico basadas en servidor). En su lugar, solo se requiere la posición para la que el dispositivo móvil necesita un horizonte electrónico.

De acuerdo con una realización de cualquiera de los aspectos ilustrativos, el horizonte electrónico solo comprende datos de horizonte electrónico requeridos y/o útiles específicamente para las una o más funciones de ADAS. Por ejemplo, el horizonte electrónico puede no comprender datos de horizonte electrónico que solo pueden ser útiles para otras funciones de ADAS. Por ejemplo, los datos de horizonte electrónico pueden no comprender datos de horizonte electrónico que sean no esenciales, requeridos y/o no útiles para las una o más funciones de ADAS. Por ejemplo, el horizonte electrónico comprende datos de horizonte electrónico solo para una, dos o tres funciones de ADAS diferentes.

En un ejemplo, todos los datos de horizonte electrónico del horizonte electrónico pueden ser requeridos y/o ser útiles para una función de ADAS. Por ejemplo, el horizonte electrónico puede ser proporcionado por un servidor específicamente dedicado para proporcionar un horizonte electrónico construido para esta función de ADAS. Por ejemplo, en caso de que los datos de horizonte electrónico deban habilitar o soportar una función de asistencia de velocidad inteligente de un dispositivo móvil, el horizonte electrónico puede ser proporcionado por un servidor de límite de velocidad en línea (SLO). Sin embargo, la construcción del horizonte electrónico por el servidor también puede comprender las etapas de identificar una o más funciones de ADAS que deberán ser soportadas por el horizonte electrónico y entonces construir el horizonte electrónico basándose en estas una o más funciones de ADAS identificadas.

De acuerdo con una realización de cualquiera de los aspectos ilustrativos, los datos de horizonte electrónico comprenden información de geometría de carretera reducida. La información de geometría de carretera reducida puede referirse en particular a información de geometría de carretera reducida en comparación con información de geometría de carretera que está comprendida por los datos de mapa a partir de los que se construye el horizonte electrónico. Por ejemplo, los datos de horizonte electrónico pueden no comprender una representación precisa de la geometría de carretera. Por ejemplo, los datos de horizonte electrónico pueden, en particular, no comprender una o más de la siguiente información de geometría de carretera: información de latitud/longitud de cada punto, una representación de spline, una representación de clotoide y/o una representación basada en curva de una carretera o segmento de carretera. Por ejemplo, los datos de horizonte electrónico pueden comprender solo segmentos o enlaces de carretera lineales con información acerca de la longitud de los enlaces o segmentos individuales pero sin ninguna geometría de carretera para los segmentos o enlaces de carretera individuales. Por ejemplo, con respecto a una función de asistencia de velocidad inteligente, los datos de horizonte electrónico pueden comprender, sin embargo, información de límite de velocidad para los enlaces o segmentos de carretera individuales.

Aunque una geometría de carretera reducida puede hacer que una puesta en coincidencia de la posición del dispositivo móvil con respecto al horizonte electrónico sea más difícil o menos precisa, aún puede reducir la potencia de procesamiento requerida, en particular en caso de que la geometría de carretera reducida se compense o se equilibre considerando otra información en su lugar, tal como datos obtenidos de un sensor del dispositivo móvil, como se explicará con más detalle a continuación.

El método de acuerdo con el primer aspecto ilustrativo puede comprender además:

- construir, basándose en el horizonte electrónico obtenido, un horizonte electrónico interno para distribuir los datos de horizonte electrónico obtenidos con el horizonte electrónico dentro del dispositivo móvil.

Por ejemplo, puede construirse un horizonte electrónico interno (o local) que comprenda un subconjunto de los datos de horizonte electrónico comprendidos por el horizonte electrónico obtenido (que, por lo tanto, puede considerarse como un horizonte electrónico "externo", "basado en la nube" o "remoto"). El horizonte electrónico interno o local solo se usa para distribuir datos (desde el horizonte electrónico obtenido) interna o localmente en el dispositivo móvil. Esto puede facilitar adicionalmente la distribución del horizonte electrónico obtenido a los componentes o módulos respectivos en el dispositivo móvil. Por ejemplo, en un ejemplo, el dispositivo móvil puede comprender un componente de cliente para recibir el horizonte electrónico y para construir un horizonte electrónico interno para reenviar los datos de horizonte electrónico a partir del horizonte electrónico recibido (o una parte del mismo) a componentes adicionales en el dispositivo móvil, por ejemplo, a un componente de fusión, que puede obtener adicionalmente datos de sensor del dispositivo móvil y considerar esas dos fuentes de datos para proporcionar la función de ADAS. El reenvío o la provisión del horizonte electrónico interno puede hacerse de múltiples formas, por ejemplo, proporcionar una API de propiedad exclusiva dentro del dispositivo móvil (por ejemplo, la ECU) o distribuir el mismo a través de un protocolo convencional como ADASISv2.

En consecuencia, el método de acuerdo con el primer aspecto ilustrativo puede comprender además:

- obtener datos de sensor desde uno o más sensores del dispositivo móvil, en donde dicha ejecución al menos una de las una o más funciones de ADAS se basa adicionalmente al menos parcialmente en los datos de sensor obtenidos.

Los sensores usados para realizar la función de ADAS pueden depender de la función de ADAS específica que va a realizarse. Por ejemplo, un sensor del dispositivo móvil puede ser una cámara. Una cámara puede ser útil para realizar una función de ISA, debido a que la cámara puede detectar señales de arcén (directa o indirectamente) que proporcionan información acerca del límite de velocidad actualmente válido a observar. Sin embargo, pueden usarse otros sensores tales como un acelerómetro, un giroscopio, un odómetro o diversos otros sensores habitualmente usados e implementados en vehículos, dependiendo del caso de uso o función de ADAS específico que va a implementarse. Por ejemplo, los datos de sensor obtenidos y los datos de horizonte electrónico (por ejemplo, por medio del horizonte electrónico obtenido o como un horizonte electrónico interno construido localmente) pueden proporcionarse a un componente de fusión del dispositivo móvil, que entonces puede fusionar o combinar los datos de horizonte electrónico y los datos de sensor para proporcionar la función de ADAS (o datos requeridos para la misma).

De acuerdo con una realización de cualquiera de los aspectos ilustrativos, las una o más funciones de ADAS comprenden una o más de:

- una función de asistencia de velocidad inteligente;

- una función de advertencia de peligro;

- una función de indicación de vehículo de emergencia; y/o

- una función de detección de señales de tráfico.

Como ya se ha mencionado, una función de asistencia de velocidad inteligente (ISA) puede usar, por ejemplo, información acerca de la carretera u objetos de arcén para determinar una velocidad permitida o adecuada. Por ejemplo, puede obtenerse información a partir del conocimiento de la posición del dispositivo móvil (con respecto al horizonte electrónico), teniendo en cuenta los límites de velocidad conocidos para la posición, y/o interpretando características de carretera tales como señales (obteniendo los datos respectivos, por ejemplo, a partir del sensor). En general, una ISA puede 1) informar al conductor acerca del límite de velocidad actual, 2) alertar al conductor en caso de exceso de velocidad, y/o 3) ayudar al conductor/coche a permanecer por debajo del límite de velocidad ajustando activamente la velocidad del vehículo (en particular, las acciones 2) y 3) son opcionales, mientras que 1 es habitualmente un implementación obligatoria). En otras palabras, una ISA puede alertar a un conductor (ISA pasivo, por ejemplo, a través de la visualización de avisos visuales y/o auditivos, tales como advertencias visuales y/o auditivas, y/o avisos táctiles, tales como una vibración del volante o del pedal del acelerador) o adaptar activamente la velocidad (ISA activa), por ejemplo, reduciendo la entrada del acelerador y/o aplicando los frenos (aunque la conducción puede invalidar, no obstante, cualquiera de tales adaptaciones). Tales alertas y/o adaptaciones pueden tener lugar, por ejemplo, cuando un vehículo ha entrado en una nueva zona de velocidad, cuando están en vigor diferentes límites de velocidad de acuerdo con la hora del día o las condiciones y/o cuando se superan los límites de velocidad. Adicionalmente o como alternativa, una ISA puede proporcionar información acerca de peligros de conducción (por ejemplo, áreas de alto movimiento de peatones, cruces de ferrocarril, escuelas, hospitales, etc.) y límites impuestos por, por ejemplo, radares o cámaras de velocidad. El método de acuerdo con el primer aspecto puede comprender, en particular, una etapa de método respectiva de, por ejemplo, alertar al conductor y/o adaptar la velocidad del dispositivo móvil. En cualquier caso, en general, el fin de una ISA es ayudar al conductor a mantener una velocidad segura.

Una función de advertencia de peligro puede indicar diferentes peligros en particular temporales y/o locales al conductor y/o participar activamente en una funcionalidad de conducción del vehículo. Son ejemplos de tales peligros un accidente, una inundación, un atasco de tráfico, un cierre de carretera, por ejemplo.

Otro ejemplo de una función de ADAS puede ser una función de indicación de vehículo de emergencia, que puede indicar al conductor que un vehículo de emergencia se está acercando y/o participar activamente en una funcionalidad de conducción del vehículo, de tal modo que se pueda formar un pasillo para un vehículo de emergencia.

Una función de detección o reconocimiento de señales de tráfico (TSR), como otro ejemplo, puede reconocer señales de tráfico comunes, tales como una señal de "alto" o una señal de "girar más adelante", a través de técnicas de procesamiento de imágenes (por ejemplo, basándose en la forma o el color de la señal). Debido al uso de tecnología basada en cámaras, diversos factores (mala iluminación, condiciones climáticas, obstrucción parcial de la señal) pueden hacer que el TSR óptico sea menos preciso. Una detección de señales de tráfico también puede formar parte de la función de ISA (por ejemplo, como una entrada a un componente de fusión para fusionar los datos con los datos de horizonte electrónico).

Las funciones de ADAS anteriores (pero también las funciones de ADAS en general) pueden basarse, además del horizonte electrónico, entre otras cosas, en datos proporcionados por comunicación de vehículo a vehículo (V2V), comunicación de vehículo a infraestructura (V2I) y/o comunicación de vehículo a todo (V2X). Los sistemas de V2V permiten que los vehículos intercambien información entre sí acerca de su posición actual y los peligros próximos (lo que puede ser ventajoso en particular para la función de advertencia de peligro o la función de aproximación de vehículo de emergencia). Los sistemas de V2I tienen lugar cuando el vehículo intercambia información con elementos de infraestructura cercanos, tales como señales de tráfico (lo que puede ser ventajoso, en particular, para el reconocimiento de señales de tráfico o la asistencia de velocidad inteligente). Los sistemas V2X tienen lugar cuando el vehículo supervisa su entorno y toma información acerca de posibles obstáculos o peatones en su trayectoria.

De acuerdo con una realización de cualquiera de los aspectos ilustrativos, una o más de la siguiente información está comprendida por o es derivable de los datos de horizonte electrónico:

- un código de país;

- un tipo de una carretera;

- un rumbo de carretera;

- un lado de conducción;

- una distancia a una siguiente intersección;

- un número de carriles en la dirección de conducción;

- un número de carriles opuestos a la dirección de conducción; y/o

- una indicación de una zona de área urbana.

La información anterior es particularmente útil si el horizonte electrónico se ha construido al menos para la función de ADAS de una asistencia de velocidad inteligente.

Más específicamente, una información de código de país puede ser importante debido a que esta proporciona características de señales de tráfico esperadas para realizar una detección, debido a que, por ejemplo, las señales de límite de velocidad difieren ligeramente entre países. Asimismo, un código de país puede proporcionar información para límites de velocidad implícitos (por ejemplo, una señal de entrada o salida de ciudad puede implicar ciertos límites de velocidad).

La información acerca de un tipo de carretera puede referirse a la categoría de carretera (por ejemplo, autopista, autovía, carretera local, etc.), lo que también puede proporcionar una indicación del tamaño y la posición esperados para los límites de señal en poste, especialmente en conexión con el código de país y/o límites de velocidad implícitos que se aplican a la carretera.

La información acerca de un lado de conducción (es decir, un atributo de conducción por la derecha o izquierda) proporciona una indicación de que el dispositivo móvil espera señales relevantes (por ejemplo, límite de velocidad) en un lado u otro. Por ejemplo, en caso de conducción por la derecha, el dispositivo móvil puede buscar o detectar solo señales en el lado derecho y viceversa. Sin embargo, esta información también puede implicarse a partir de o ser derivable del código de país, por ejemplo.

La información acerca de una distancia a una intersección puede proporcionar información adicional acerca de dónde (a lo largo de la carretera) o cuándo esperar o buscar señales (por ejemplo, límites de velocidad), mientras que la información acerca del número de carriles en y/u opuestos a la dirección de conducción puede ayudar en una estimación de una distancia lateral (es decir, transversal a la carretera) desde el vehículo hasta la señal (por ejemplo, de límite de velocidad).

Una indicación de un área urbana puede permitir derivar configuraciones o restricciones adicionales que considerar, por ejemplo, para la detección de señales de tráfico, y que puede requerir un algoritmo de detección para operar, por ejemplo, de una forma o modo diferente, por ejemplo, empleando una segmentación diferente de las imágenes capturadas que, por ejemplo, en comparación con la carretera abierta.

Cualquiera de la información anterior puede ser usada por el vehículo (por ejemplo, un componente de fusión) para soportar la adquisición y/o evaluación de datos por sensores de vehículo (tales como una cámara).

El método de acuerdo con el primer aspecto ilustrativo puede comprender además uno o más de:

- comprobar si es necesario actualizar o sustituir el horizonte electrónico;

- enviar y/o recibir una solicitud de información que va a usarse para al menos una de las una o más funciones de ADAS;

- identificar una posición del dispositivo móvil con respecto al horizonte electrónico; y/o

- determinar y/o proporcionar información que va a usarse para al menos una de las una o más funciones de ADAS basándose en el horizonte electrónico.

De acuerdo con una realización de los aspectos ilustrativos, la indicación de la trayectoria comprende una o más estimaciones de posición, información de rumbo y/o información de velocidad del dispositivo móvil, y/o la indicación de la trayectoria se proporciona en respuesta a determinar que es necesario actualizar el horizonte electrónico.

En una realización, el método puede comprender además:

- determinar que es necesario actualizar o sustituir el horizonte electrónico en caso de que una extensión restante del horizonte electrónico sea menor que o igual a una extensión mínima;

- obtener un horizonte electrónico actualizado o de sustitución con una extensión deseada.

Por ejemplo, el dispositivo móvil (o la parte del mismo) puede comprobar repetidamente si es necesario actualizar el horizonte electrónico. Para esto, el dispositivo móvil puede determinar su posición geográfica (por ejemplo, por medio de posicionamiento por satélite y/o sensores, tales como odómetro, giroscopio, acelerómetro, etc.) y comparar identificar esta posición en o con respecto al horizonte electrónico. Como resultado de esta comprobación, puede determinarse que se requiere una actualización. Por ejemplo, en caso de que la posición esté cerca (por ejemplo, por debajo de un umbral predefinido) de una frontera del horizonte electrónico, el dispositivo móvil puede determinar que se requiere una actualización y puede solicitar una actualización del horizonte electrónico. En un ejemplo, puede decidirse si es necesario actualizar el horizonte electrónico definiendo una primera, o mínima, extensión o ampliación de horizonte electrónico (en particular, por delante del vehículo, por ejemplo, en unidades de distancia o tiempo) y una segunda, o deseada, extensión o ampliación de horizonte electrónico (en unidades de distancia o tiempo) y aplicando el siguiente esquema: Si la extensión restante real (por ejemplo, la distancia o el tiempo desde la posición actual hasta la frontera del horizonte electrónico) se vuelve menor que o igual a una extensión mínima predefinida, se determina que es necesario actualizar o sustituir el horizonte electrónico, y el nuevo horizonte electrónico se crea entonces (al menos) con la extensión deseada y se proporciona como una actualización (incremental) o un horizonte electrónico de sustitución. La extensión también puede ser mayor, por ejemplo, debido a que es posible que sea necesario evitar las brechas de conectividad como se describe con más detalle a continuación. Como resultado, habitualmente hay bastante tiempo hasta que - debido a que el vehículo se mueve hacia delante - la extensión restante del horizonte electrónico alcanza la extensión mínima y se obtienen nuevos datos de horizonte electrónico. En general, este enfoque funciona tanto con actualizaciones incrementales (que entonces proporcionan grandes incrementos a intervalos largos, de forma bastante diferente del caso con los protocolos convencionales como ADASIS que proporcionan pequeños incrementos frecuentes) o con las actualizaciones de sustitución o autónomas completas descritas previamente (que son mucho más fáciles de implementar y manejar debido a que el servidor no necesita conocer el estado del cliente). Aunque la comprobación y decisión de si es necesario actualizar el horizonte electrónico puede ser hecha por el dispositivo móvil, generalmente también es posible que el dispositivo móvil proporcione estimaciones de posición al servidor y el servidor entonces realiza la comprobación descrita anteriormente.

Adicionalmente o como alternativa, puede haber una puesta en coincidencia fallida (es decir, el dispositivo móvil puede no ser capaz de hacer coincidir su posición con ninguna característica del horizonte electrónico actual), lo que también puede ser una razón para solicitar un nuevo horizonte electrónico. Sin embargo, también son posibles otros sucesos o circunstancias que pueden exigir una actualización del horizonte electrónico.

Por ejemplo, en respuesta a determinar que es necesario actualizar el horizonte electrónico, el dispositivo móvil puede proporcionar, al servidor, una o más estimaciones de posición del dispositivo móvil. Por ejemplo, el dispositivo móvil puede proporcionar las últimas n estimaciones de posición (por ejemplo, las últimas 1, 2, 3, 4 o 5 estimaciones de posición), que pueden comprender, por ejemplo, información de latitud y longitud. En caso de que se proporcione más de una estimación de posición, esto puede permitir que el servidor determine también un rumbo y/o velocidad del dispositivo móvil. Adicionalmente o como alternativa, la(s) estimación(es) de posición también puede(n) comprender directamente información de velocidad y/o una información de rumbo.

Como queda claro a partir de lo anterior, la información de posicionamiento del dispositivo móvil puede ser útil para dos fines diferentes. Por un lado, la información de posicionamiento puede usarse como (o junto con otra información, tal como información de rumbo y/o velocidad como parte de) la información de trayectoria para enviarse al servidor (por ejemplo, cuando la posición es o está a punto de estar fuera del horizonte electrónico). En el servidor, puede hacerse una puesta en coincidencia de mapa y puede construirse un horizonte electrónico, como se describe. Por otra parte, puede realizarse información de posicionamiento (por ejemplo, regularmente) en el dispositivo móvil basándose en el horizonte electrónico ya obtenido.

Como ya se ha mencionado, el dispositivo móvil puede comprender, por ejemplo, un componente de cliente y un componente de fusión. El componente de fusión puede requerir, por ejemplo, que se use información para al menos una de las una o más funciones de ADAS y, por lo tanto, puede enviar una solicitud correspondiente al componente de cliente, que a su vez recibe la solicitud (por ejemplo, el componente de fusión puede enviar una solicitud de información de límite de velocidad al componente de cliente). Como alternativa, el componente de cliente puede proporcionar activamente esta información al componente de fusión (o en general dentro del dispositivo móvil), por ejemplo, a través del horizonte electrónico local o interno.

Para proporcionar la información solicitada (por ejemplo, al componente de fusión), el dispositivo móvil (por ejemplo, un componente de cliente) puede identificar una posición del dispositivo móvil con respecto al horizonte electrónico (es decir, una coincidencia de mapa basada en horizonte electrónico).

El dispositivo móvil puede determinar y/o proporcionar información que va a usarse para al menos una de las una o más funciones de ADAS basándose en el horizonte electrónico. Por ejemplo, basándose en la posición identificada del dispositivo móvil con respecto al horizonte electrónico, el dispositivo móvil (por ejemplo, el componente de cliente) puede determinar y entonces proporcionar información del horizonte electrónico relevante para la función de ADAS relevante (por ejemplo, al componente de fusión). La distribución o provisión de la información que se utilizará para la(s) función(es) de ADAS puede, en un ejemplo, como ya se ha mencionado, usar un horizonte electrónico interno que se construye (por ejemplo, por el componente de cliente) basándose en el horizonte electrónico obtenido y entonces este el horizonte electrónico interno se transmite internamente dentro del dispositivo móvil (por ejemplo, al componente de fusión).

De acuerdo con cualquiera de los aspectos, una extensión del horizonte electrónico tiene en cuenta una disponibilidad esperada de una conectividad de red entre el dispositivo móvil y el servidor. En consecuencia, el servidor determina una extensión del horizonte electrónico basándose al menos en parte en una disponibilidad esperada de una conectividad de red entre el dispositivo móvil y el servidor, en donde dicha construcción de dicho horizonte electrónico se basa entonces al menos en parte en dicha extensión determinada. Para esto puede usarse información de cobertura de red o conectividad (tal como un mapa de conectividad). Como se ha descrito, una extensión puede entenderse como una extensión geográfica cubierta por los datos de horizonte electrónico. Por ejemplo, teniendo en cuenta una disponibilidad de una conectividad de red entre el dispositivo móvil y el servidor, la extensión (geográfica) del horizonte electrónico puede elegirse de tal modo que la frontera del horizonte electrónico no está ubicada en un área con una brecha de conectividad. La conectividad o brecha de red puede ser específica para un cierto proveedor de servicio usado por el dispositivo móvil para una conexión al servidor (por ejemplo, un proveedor específico elegido por un fabricante de coches). Por lo tanto, el proveedor de servicio de red puede considerarse como un parámetro y, en particular, también proporcionarse al servidor para su consideración cuando se construye el horizonte electrónico. En general, puede entenderse que una brecha de conectividad es un área sin conectividad, o de conectividad baja y/o lenta (por ejemplo, recepción y/o ancho de banda por debajo de un umbral). Como se ha explicado, el horizonte electrónico cubre una o más trayectorias potenciales que se predice que van a ser tomadas por el dispositivo móvil. Por ejemplo, estas trayectorias predichas pueden elegirse de tal forma (por ejemplo, suficientemente largas) como para evitar brechas de conectividad cuando el dispositivo móvil requiere un horizonte electrónico actualizado. Por ejemplo, este aspecto puede ser tenido en cuenta por el servidor cuando se construye el horizonte electrónico respectivo. Por ejemplo, puede usarse información de cobertura de red para determinar si existe el riesgo de que un horizonte electrónico actualizado necesite actualizarse en una brecha de conectividad. Por ejemplo, puede evitarse que al menos la trayectoria más probable (MPP) cubierta por el horizonte electrónico termine en un área de una brecha de conectividad. Adicionalmente o como alternativa, este aspecto también puede ser considerado por el dispositivo móvil cuando se solicita un horizonte electrónico (por ejemplo, en caso de que se permita que el dispositivo móvil indique una extensión deseada del horizonte electrónico con la solicitud).

El método de acuerdo con el primer aspecto ilustrativo, para identificar una posición del dispositivo móvil con respecto al horizonte electrónico, puede comprender además uno o más de:

- determinar una distancia recorrida por el dispositivo móvil desde una posición para la que se proporcionó una indicación de una trayectoria del dispositivo móvil al servidor; y/o

- detectar información de rumbo o información de cambio de rumbo del dispositivo móvil.

Como se ha mencionado anteriormente, los datos de horizonte electrónico pueden comprender, en particular, información de geometría de carretera reducida. Para facilitar la identificación de una posición del dispositivo móvil con respecto al horizonte electrónico, puede utilizarse información adicional de sensores del dispositivo móvil. Por ejemplo, puede determinarse una distancia recorrida por el dispositivo móvil desde una posición para la que se proporcionó una indicación de una trayectoria del dispositivo móvil al servidor (por ejemplo, por medio de un odómetro y/o información de rotación de rueda) y entonces usarse para identificar una posición del dispositivo móvil con respecto al horizonte electrónico. La indicación de una trayectoria puede comprender, en particular, una estimación de posición que indica una posición respectiva, como ya se ha mencionado. Por ejemplo, puede determinarse información de rumbo o información de cambio de rumbo del dispositivo móvil (por ejemplo, por medio de un giroscopio y/o un acelerómetro) y entonces usarse para identificar una posición del dispositivo móvil con respecto al horizonte electrónico. Por ejemplo, la información de rumbo o cambio de rumbo medida del dispositivo móvil puede compararse con información de rumbo o cambio de rumbo (esperado) en el horizonte electrónico. La comparación entre información (de cambio) de rumbo en el horizonte electrónico y la información (de cambio) de rumbo registrada por el/los sensor(es) ayuda adicionalmente a determinar una posición del dispositivo móvil en el horizonte electrónico.

Como ya se ha mencionado, la indicación de la trayectoria puede comprender en particular una o más estimaciones de posición del dispositivo móvil.

Además, el método de acuerdo con el segundo aspecto ilustrativo puede comprender además uno o más de:

- obtener los datos de mapa desde una base de datos de mapas; y/o

- identificar una posición del dispositivo móvil con respecto a los datos de mapa.

Como ya se ha mencionado, el dispositivo móvil puede proporcionar, al servidor, una o más estimaciones de posición del dispositivo móvil (por ejemplo, en respuesta a determinar que es necesario actualizar el horizonte electrónico). En consecuencia, estas estimaciones de posición son obtenidas entonces por el servidor. Para obtener los datos para construir el horizonte electrónico, el servidor puede obtener en primer lugar datos de mapa relevantes a partir de una base de datos de mapas (por ejemplo, basándose en las estimaciones de posición obtenidas). El servidor puede entonces identificar una posición del dispositivo móvil con respecto a los datos de mapa (es decir, una coincidencia de mapa basada en mapa). El servidor puede predecir entonces trayectorias potenciales que pueden ser tomadas por el dispositivo móvil y construir el horizonte electrónico que no solo incluye información con respecto a la posición actual del dispositivo móvil sino también con respecto a trayectorias potenciales que se predice que van a ser tomadas por el dispositivo móvil. Como se ha descrito anteriormente, el horizonte electrónico está diseñado específicamente para posibilitar que un dispositivo móvil proporcione o soporte el dispositivo móvil para proporcionar las una o más funciones de ADAS.

En una realización alternativa, el servidor puede, en lugar de obtener las una o más estimaciones de posición del dispositivo móvil directamente desde el dispositivo móvil, obtener las estimaciones de posición de una entidad adicional, tal como un servidor de un fabricante de vehículos, que ha recibido la solicitud o estimaciones de posición desde los vehículos respectivos y reenvía las solicitudes (por ejemplo, anonimizadas) al servidor. El servidor devuelve entonces el horizonte electrónico construido directamente o a través del servidor del fabricante o incluso a través de otro dispositivo al vehículo.

Ha de entenderse que la presentación de la invención en esta sección es meramente a modo de ejemplo y no limitante.

Otras características de la invención serán evidentes a partir de la siguiente descripción detallada considerada en conjunto con las figuras adjuntas. Ha de entenderse, sin embargo, que los dibujos se diseñan solamente para fines de ilustración y no como una definición de los límites de la invención, para los que debería hacerse referencia a las reivindicaciones adjuntas. Debería entenderse adicionalmente que los dibujos no están dibujados a escala y que meramente pretenden ilustrar conceptualmente las estructuras y procedimientos descritos en el presente documento.

Breve descripción de las figuras

La figura 1 muestra un diagrama de mensaje ilustrativo que ilustra la comunicación interna en un vehículo y la comunicación entre el vehículo y un servidor en la nube;

las figuras 2a-c muestran diagramas esquemáticos de redes de carreteras ilustrativas para ilustrar la cobertura de un horizonte electrónico;

la figura 3a,b muestra diagramas esquemáticos de mapas de cobertura ilustrativos de una red de comunicación para ilustrar diferentes extensiones de horizontes electrónicos;

la figura 4 muestra un diagrama de bloques de una realización ilustrativa de un dispositivo móvil de acuerdo con la invención;

la figura 5 muestra un diagrama de bloques de una realización ilustrativa de un servidor de acuerdo con la invención; y

la figura 6 muestra una ilustración esquemática de ejemplos de medios de almacenamiento tangibles y no transitorios de acuerdo con la invención.

Descripción detallada de las figuras

Los aspectos de la presente divulgación se describirán a continuación con referencia a realizaciones ilustrativas. Aunque la siguiente descripción se refiere a una asistencia de velocidad inteligente como un ejemplo de una función de ADAS, el siguiente ejemplo no se limita a la asistencia de límite de velocidad inteligente sino que puede usarse igualmente en combinación con otras funciones de ADAS.

Pasando a continuación a la figura 1, se muestra un diagrama de mensaje 100 de ejemplo que ilustra la comunicación interna dentro de un vehículo 110 (como un ejemplo de un dispositivo móvil) y la comunicación entre el vehículo 110 y un servidor en la nube 120 (como un ejemplo de un servidor). El vehículo 110 y el servidor en la nube 120 forman un sistema 110, 120.

El vehículo 110 comprende un cliente en línea de límite de velocidad, el cliente de SLO 111, un componente de posicionamiento 112 y un componente de fusión (de sensores) 113 para combinar datos de sensor con información desde el horizonte electrónico. El servidor en la nube 120 comprende un servidor en línea de límite de velocidad, el servidor de SLO 121 y una base de datos de mapas 122.

Los diagramas de bloques de ejemplo del vehículo 110 y el servidor 120 también se describirán adicionalmente a continuación con referencia a las figuras 4 y 5.

En lugar de confiar en un mapa almacenado localmente para comprender los alrededores del vehículo 110 y proporcionar la ubicación de los diferentes límites de velocidad, los aspectos ilustrativos de la presente divulgación proponen ahora una construcción en línea de un horizonte electrónico (E<h>) que puede proporcionarse al vehículo 110 a través de una conexión de datos inalámbrica, incluso si no se proporciona conectividad de red para el 100 % de las carreteras por las que se conduce, como resultará evidente a partir de la siguiente descripción.

Aunque el vehículo 110 no tiene un mapa almacenado localmente, este está en línea y conectado a Internet. Por lo tanto, el cliente de vehículo 111 (también denominado como cliente de SLO) desea conocer un límite de velocidad legal para una posición actual a partir de un servicio en línea. Para esto, el componente de posicionamiento 112 (por ejemplo, basado en posicionamiento por satélite, tal como posicionamiento de GNSS, posicionamiento basado en red celular/no celular, por ejemplo, basado en WiFi o redes móviles, o similares) determina regularmente una posición actual del vehículo 110 y lo proporciona al cliente de SLO 111, acción 130. El cliente de SLO 111 puede comprobar si la posición ya está cubierta por un horizonte electrónico almacenado localmente y/o si el vehículo 110 se acerca (por ejemplo, por debajo de un umbral predefinido, por ejemplo, en metros) al final de un último segmento de carretera cubierto por los datos de horizonte electrónico actual, acción 131. Si el cliente de SLO 111 determina que es necesario extender o actualizar el horizonte electrónico, el cliente de SLO 111 a su vez envía al menos una posición de vehículo actual opcionalmente en combinación con el rumbo (por ejemplo, en grados), una información de velocidad de desplazamiento estimada del vehículo 110 potencialmente junto con una indicación de tiempo para la medición, a un servidor de extremo trasero 121 de un servicio en la nube 120, acción 132. Por ejemplo, un vector (por ejemplo, que comprende un único par de coordenadas y rumbo) ya puede proporcionar una base para una predicción y podría ser suficiente particularmente en un área con poca densidad de carreteras. Sin embargo, añadir velocidad puede mejorar la predicción (por ejemplo, una velocidad más alta podría asociarse con una probabilidad inferior de giro). Aun así, debido a que una única posición a menudo no es suficiente para decidir de forma singular acerca de la posición/dirección o la ruta de viaje esperada del vehículo en la red de carreteras, el cliente de SLO puede retener algún número n de las posiciones más recientes (por ejemplo, n = 5) para describir una trayectoria que habitualmente permite una conclusión sobre estos factores.

En general, el posicionamiento y/o la comprobación de la posición descritos anteriormente pueden realizarse en función del tiempo (por ejemplo, cada minuto, cada 30 segundos, cada 5 segundos o similar) o en función de la distancia (por ejemplo, cada 100 m, cada 20 m, cada kilómetros). Mientras que para un dispositivo móvil en reposo un enfoque basado en la distancia es ventajoso para proporcionar datos significativos, para un dispositivo móvil en movimiento también es razonable un enfoque basado en el tiempo o mixto.

El servidor de extremo trasero 121 (también denominado como servidor en línea de límite de velocidad, servidor de SLO) obtiene datos de mapa desde la base de datos de mapas 122, acción 133, y realiza una puesta en coincidencia de mapa basada en mapa de las posiciones de vehículo obtenidas, acción 134. El servidor de SLO 121 construye en última instancia un horizonte electrónico, que cubre trayectorias probables que se predice que van a ser tomadas por el vehículo 110, es decir, generalmente una cierta área delante del vehículo, como se explicará con más detalle a continuación y con referencia a la figura 2.

En otras palabras, el horizonte electrónico se calcula por medio de un servicio en la nube 120, que tiene las ventajas de potentes recursos de procesamiento, un mapa actualizado, así como conectividad permanente a otros servicios que pueden entregar atributos de mapa requeridos para información relevante para el límite de velocidad, por ejemplo, información acerca de límites de velocidad dinámicos/variables en, por ejemplo, pórticos y señales electrónicas, etc. Además, el servicio en la nube 120 también puede tener acceso a información de tráfico y otra información relacionada con la red de carreteras para la determinación del horizonte electrónico.

El área geográfica cubierta por el horizonte electrónico puede adaptarse (hacerse crecer/contraerse), por ejemplo, basándose en una configuración, por ejemplo, una longitud preestablecida de la trayectoria más probable (MPP), un grado preestablecido de trayectorias laterales o subtrayectorias y/o áreas de cobertura de datos/células conocidas.

El servidor de SLO 121 responde transmitiendo el horizonte electrónico construido al cliente de SLO 111 del vehículo 110 y el cliente de SLO 111 recibe y almacena el horizonte electrónico localmente, acción 136.

El horizonte electrónico puede incluir, en particular, la Trayectoria Más Probable y ciertas subtrayectorias potenciales, cada una con límites de velocidad en los desplazamientos de enlace respectivos. Sin embargo, el horizonte electrónico puede incluir ciertas referencias a la geometría de la carretera en las intersecciones, información acerca de las longitudes (pero no la geometría) de los enlaces o segmentos de carretera y potencialmente cualquier información adicional requerida para la función de ADAS respectiva, por ejemplo, información requerida por el componente de fusión de sensores 113 (por ejemplo, detalles específicos de país/región tales como lado de conducción o código de país).

Con el mecanismo anterior, está disponible un horizonte electrónico para un área amplia delante del vehículo 110 que puede proporcionarse al componente de fusión 113 para combinar los datos con, por ejemplo, datos de la cámara u otros sensores.

Como se ha mencionado, el cliente de SLO 111 realiza regularmente una puesta en coincidencia de la posición del vehículo y el horizonte electrónico, de tal modo que el cliente de SLO 111 siempre es consciente de dónde se ubica el vehículo y solicitará una extensión del horizonte electrónico si el vehículo alcanza la frontera o el borde del horizonte electrónico hasta cierto punto, o antes de que lo haga.

Hay múltiples formas de proporcionar estos datos a unidades de procesamiento posteriores (normalmente el componente de fusión 113) dentro del vehículo 110. Por ejemplo, a petición del componente de fusión 113, acción 138, el cliente de SLO 111 proporciona información de límite de velocidad y cualquier información requerida adicionalmente al componente de fusión 113. En un ejemplo, los datos pueden proporcionarse como mensajes ADASIS convencionales, acción 140. En este caso, el cliente de SLO 111 funcionaría y aparecería como un proveedor de horizonte electrónico para los componentes adicionales del vehículo, limitando los datos a los mensajes requeridos para la fusión. Se observa, sin embargo, que los datos que se proporcionan en el formato de ADASIS dentro del vehículo 110 pueden ser solo un subconjunto del horizonte electrónico almacenado en memoria caché recuperado desde el servidor de SLO 121. Para esto, el horizonte electrónico recibido, después de ser recibido, reconstruido (es decir, descodificado) y almacenado por el cliente de SLO 111, acciones 136, 137, el horizonte electrónico puede distribuirse (por ejemplo, como un horizonte electrónico interno o local) dentro del vehículo, acción 140

En cualquier caso, como se ha esbozado anteriormente, el vehículo puede basarse ventajosamente en un servicio en línea para recuperar los datos de límite de velocidad relevantes en el vehículo.

Adicionalmente, se observa que en comparación con un sistema que solicita datos de límite de velocidad en línea a petición, el enfoque descrito puede tratar ventajosamente indisponibilidades de red hasta un cierto grado (como se describirá con más detalle a continuación). Incluso en regiones o países en donde la cobertura de la red móvil es muy buena, las áreas de indisponibilidad (llamadas zonas grises) ocurrirán bastante a menudo durante un corto período de tiempo.

Otra ventaja del enfoque descrito es la necesidad de solo una potencia de procesamiento, un almacenamiento y una memoria caché mínimos. Esto permitirá a los fabricantes de vehículos quedarse idealmente con una arquitectura existente para vehículos sin navegación y ahorrar esfuerzo para rediseñar la arquitectura del vehículo para cumplir con, por ejemplo, la regulación de ISA.

Además, el enfoque descrito tiene la ventaja de, no obstante, ser flexible para proporcionar atributos adicionales/secundarios al vehículo - dependiendo de la información requerida del algoritmo de fusión, o función de ADAS, respectivo que va a implementarse.

En lo sucesivo, el uso de un horizonte electrónico, debido a que puede emplearse en aspectos ilustrativos de la presente divulgación se explica a continuación con más detalle.

En general, un horizonte electrónico puede entenderse como un conjunto de datos que proporciona representaciones de carretera digitales como una entrada al sistema de ADAS de un vehículo.

El horizonte electrónico puede proporcionar una colección de elementos de información de carretera (como se ha descrito anteriormente) para carreteras en las proximidades del vehículo. Una implementación habitual podría representar carreteras y trayectorias como una secuencia de segmentos de carretera, teniendo cada uno un conjunto de atributos. El horizonte electrónico puede comprender una trayectoria más probable que se espera que recorra el vehículo, por ejemplo, basándose en las estimaciones de posición del vehículo notificadas previamente. El horizonte electrónico puede incluir además subtrayectorias, es decir, otras carreteras en donde es probable que se desplace el vehículo.

Pasando a continuación a las figuras 2a-c, la figura 2a muestra una red de carreteras 200 e ilustra una posición actual 201 del vehículo junto con un rumbo 202. Por razones de comparación, la figura 2b muestra un ejemplo, en donde el horizonte electrónico comprendería simplemente todos los enlaces o segmentos de carretera 203 en un área alrededor de la posición del vehículo. Ventajosamente, como se muestra a continuación en la figura 2c, los aspectos ilustrativos de la presente divulgación sugieren seleccionar para el horizonte electrónico ciertos enlaces y segmentos de carretera (más probablemente la trayectoria 204 y las subtrayectorias 205) que se predice que van a ser tomadas por el vehículo. Habitualmente, estos segmentos de carretera 204, 205 seleccionados o enlaces están aproximadamente en la dirección de desplazamiento del vehículo. Segmentos y enlaces, por ejemplo, en un sentido opuesto (o que requiera un giro de más de, por ejemplo, 160°).

En cualquier caso, para proporcionar un conjunto de datos liviano y reducido, se requiere definir un límite geográfico desde la posición de vehículo actual 201 hasta en donde se deberá calcular el horizonte electrónico. En un ejemplo, la extensión del horizonte electrónico puede definirse por un parámetro que puede fijarse para cubrir (por ejemplo, como máximo) hasta x metros o km desde la posición de vehículo actual 201. Adicionalmente o como alternativa, la extensión puede depender del tipo de carretera, del número de posibilidades para desviarse y/o de la probabilidad de usar o alcanzar una carretera.

Para aquellos segmentos de carretera incluidos en el horizonte electrónico, los atributos se proporcionan según sea necesario por la función de ADAS correspondiente. Para el ejemplo de una aplicación de asistencia de velocidad inteligente, el propio límite de velocidad será habitualmente el atributo más importante, pero atributos adicionales pueden ser usados por la función de asistencia de velocidad inteligente. Los atributos generalmente consisten en un valor y una definición del tramo de carretera al que son aplicables.

Con un mapa perfecto, siempre actualizado, la información proporcionada por el horizonte electrónico reflejaría la realidad sobre el terreno completamente y sería suficiente para producir información, por ejemplo, para advertir al conductor acerca del límite de velocidad actual (por ejemplo, por medios visuales, auditivos o hápticos), y/o para un sistema de control de velocidad en el vehículo que evita el exceso de velocidad.

Sin embargo, se espera que no toda la información de límite de velocidad sea completamente precisa en el mapa, por ejemplo, debido a señales temporales o debido a los límites de velocidad variables y cambiantes. Por lo tanto, se recomienda que un vehículo en la carretera también realice la detección de los límites de velocidad en postes usando al menos una cámara montada en el vehículo.

La propia cámara puede requerir, o no, información adicional para realizar una detección de señales de tráfico con alta calidad. En cualquier caso, los datos a partir de la cámara se agregan y combinan entonces con la información desde el horizonte electrónico (habiéndose derivado de los datos de mapa externos) en el componente de fusión 113. El componente de fusión - y potencialmente el propio sistema de cámara - requiere, sin embargo, soporte del horizonte electrónico para límites de velocidad con el fin de alcanzar un nivel aceptable de precisión de tal modo que atributos adicionales/secundarios puedan soportar el algoritmo de fusión. Estos atributos pueden proporcionarse basándose en las necesidades individuales de un fabricante de coches.

Algunos de los atributos secundarios importantes son el código de país y el tipo de carretera. El código de país es importante debido a que este proporciona características de señales de tráfico esperadas para realizar una detección, debido a que, por ejemplo, las señales de límite de velocidad difieren ligeramente entre países. Este también proporciona información para límites de velocidad implícitos - por lo que una señal de salida de la ciudad puede correlacionarse directamente con el límite de velocidad implícito correcto El tipo de carretera se refiere a la categoría de carretera (autopista, autovía, carretera local, etc.), lo que proporciona una indicación del tamaño y la posición esperados para los límites de señal en poste en relación con el código de país, así como del límite de velocidad implícito que se aplica a la carretera.

Otros atributos potencialmente útiles para la cámara/sistema de fusión son indicaciones de: Carretera de conducción a la izquierda o conducción a la derecha, Distancia a la siguiente intersección, Número de carriles en la dirección de conducción, Número de carriles en el sentido opuesto y/o zona de área urbana. El atributo de conducción por la derecha/izquierda (aunque lo más probablemente es derivable del código de país) puede proporcionar una indicación de si buscar señales de límite de velocidad en un lado o en el otro. Las distancias a las intersecciones proporcionan sugerencias acerca de dónde buscar señales de límites de velocidad en postes, mientras que el número de carriles en/opuestos ayuda en la dirección de conducción en la estimación de una distancia lateral desde el vehículo hasta la señal de límite de velocidad. Las áreas urbanas pueden tener otras restricciones para la detección, que pueden requerir que el vehículo (por ejemplo, un algoritmo de fusión de cámara) opere en un modo diferente cuando se detecta un área urbana basándose en este atributo, por ejemplo realizar una segmentación diferente de las imágenes capturadas que en la carretera abierta.

En lo sucesivo, se describirá con más detalle el horizonte electrónico basado en la nube materializado por el servidor de SLO 121 de la nube 120.

Como ya se ha mencionado, implementar la construcción del horizonte electrónico basándose en un mapa de carreteras digital almacenado localmente dentro del vehículo, habitualmente en un sistema de navegación, pero posiblemente también en una unidad separada, requiere recursos significativos para almacenar y evaluar el mapa y para actualizar el mapa.

En caso de que el mapa se almacene en algún lugar remoto del vehículo, habitualmente solo puede accederse al mismo a través de un servicio de Internet y los datos de mapa necesitarían ser recuperados por el vehículo según sea necesario. Con mapas comunes, la unidad de almacenamiento más pequeña que puede descargarse individualmente es una tesela de una cierta capa de mapa. Incluso esta unidad más pequeña contendrá, sin embargo, mucha más información de la que el vehículo realmente necesita acerca de la carretera actual para realizar una cierta función de ADAS, consumiendo así recursos significativos tanto para la transferencia de datos como para el procesamiento de los datos de mapa para extraer la información relevante.

Los aspectos ilustrativos de la presente divulgación optimizan en primer lugar este enfoque mediante el uso de un servicio fuera del vehículo (es decir, accesible a través de Internet) que puede proporcionar al vehículo la información exacta que se necesita actualmente dependiendo de la posición actual del vehículo y la(s )función(es) de ADAS respectiva(s) que va(n) a implementarse. Esto reduce la necesidad de ancho de banda de red, para almacenamiento dentro del vehículo, y para potencia de procesamiento en el lado del vehículo, debido a que los datos pueden venir básicamente ya preparados en la forma en la que se necesitan dentro del vehículo.

Aunque aún puede considerarse que esta solución tiene dos desventajas, en concreto, que se basa completamente en la conectividad de red y no puede proporcionar datos en situaciones en las que la conectividad a Internet no está disponible y que necesita repetir con frecuencia la transferencia de datos esencialmente idénticos si el vehículo está desplazándose a lo largo de una carretera en donde las características de la carretera no cambian, el concepto de aspectos ilustrativos de la presente divulgación puede resolver estos dos problemas usando un servicio proporcionado por el servidor de SLO 121 de la nube 120. Más específicamente, el servidor de SLO 121 transfiere al vehículo no solo información relevante en la ubicación actual del vehículo, sino un conjunto de datos de horizonte electrónico que proporciona información acerca de la carretera por la que viaja el vehículo a cierta distancia por delante y, opcionalmente, así como por carreteras laterales a las que podría girar el vehículo. El software dentro del vehículo, es decir, el cliente de SLO 111 extrae entonces de este conjunto de datos (ya reducido) de nuevo solo los datos que actualmente son relevantes para la asistencia de velocidad inteligente u otras funciones de ADAS. Se observa que la expresión horizonte electrónico deberá entenderse en un significado genérico, que no se refiere a una norma o implementación específica.

En su lugar, una implementación de este concepto puede usar una estructura de horizonte electrónico de propiedad exclusiva que puede optimizarse para el fin descrito.

Como se hace evidente a partir de lo anterior, esto puede optimizar la cantidad de datos que se van a transferir desde el servidor de SLO 121 al cliente de SLO 111 en el vehículo 110 mediante el uso de una representación compacta que proporciona valores de atributo junto con una definición del segmento de carretera al que son aplicables (en lugar de necesitar reenviar el mismo valor de atributo cada vez que el vehículo necesita el valor).

En lo sucesivo, se describe con más detalle cómo se analizará con más detalle la cuestión de las brechas de conectividad.

El enfoque descrito anteriormente también puede posibilitar que el vehículo haga frente a las brechas en la conectividad de la red, debido a que una vez que se han descargado los datos del servidor de SLO 121, el vehículo 110 no necesita conectarse al servicio de nuevo hasta que no alcance el final de un último segmento de carretera cubierto por los datos de horizonte electrónico disponibles actualmente en el vehículo.

El riesgo de estar en una brecha de conectividad justo cuando se necesitan nuevos datos puede mitigarse solicitando nuevos datos desde el servidor de SLO 121 mucho antes de alcanzar la frontera del horizonte electrónico disponible actualmente, por lo que hay suficiente tiempo para reintentar y una probabilidad suficientemente alta de establecer una conexión de red al menos una vez hasta alcanzar la frontera del horizonte electrónico disponible actualmente.

Este enfoque puede refinarse adicionalmente si la información acerca de la conectividad de red a lo largo de la carretera está disponible en el vehículo 110 o el servidor de SLO 121. Por ejemplo, la extensión (geográfica) de los datos de horizonte electrónico proporcionados por el servidor de SLO 121 puede adaptarse para que sea lo suficientemente grande para salvar brechas de conectividad eventuales, por ejemplo, ajustando la extensión del horizonte electrónico basándose en zonas de cobertura de red de datos.

Las figuras 3a,b muestran diagramas esquemáticos de mapas de cobertura 300a, 300b ilustrativos de una red de comunicación para ilustrar este enfoque para diferentes extensiones de horizontes electrónicos. En las células 301a se proporciona suficiente conectividad de red, mientras que en la célula 302a no se proporciona cobertura. Usando esta información, la extensión geográfica del horizonte electrónico puede calcularse dependiendo de la ubicación del vehículo 304a dentro del área de cobertura de datos. Por ejemplo, cuando se espera que un vehículo conduzca a través del área 302a sin ninguna cobertura de red, la extensión geográfica del horizonte electrónico puede aumentarse para no terminar en esta área 302a. En su lugar, el/los enlace(s) de carretera 303a incluido(s) en el horizonte electrónico termina(n) en las áreas 301a adyacentes, en donde la cobertura de red estará disponible de nuevo. Como resultado, el horizonte electrónico une el área 302a y continúa proporcionando la funcionalidad de ADAS respectiva (por ejemplo, información de límite de velocidad) incluso en esta área 302a. Sin embargo, si se detecta basándose en la información de conectividad que la posición 304b del vehículo está en o hacia un área 301b en donde hay buena conectividad de red, el número o extensión de los enlaces de carretera 303b y, por lo tanto, la extensión del horizonte electrónico puede reducirse para optimizar el tamaño de cabida útil de datos de horizonte electrónico. Obsérvese que, aunque la figura 3a, b muestra una representación hexagonal regular por simplicidad, las áreas de cobertura pueden adoptar, por supuesto, diferentes formas irregulares y tamaños irregulares.

Mientras que en la realización descrita anteriormente, el servicio en la nube 120 recibe la solicitud de creación de horizonte electrónico (acción 132) directamente desde el vehículo 110, la solicitud también puede proceder de otras entidades en realizaciones alternativas. Por ejemplo, un OEM de vehículo puede recibir las solicitudes de su flota de vehículos y reenviarlas al servidor de SLO 121 en la nube 120. Esta configuración puede permitir cambiar los requisitos de anonimización al OEM, es decir, el servidor de SLO 121 podría responder a las solicitudes con ID de sesión de comunicación con una relación desconocida a un vehículo específico. El servidor de SLO usa de nuevo las n estimaciones de posición recientes para crear un horizonte electrónico, que contiene los atributos analizados en la sección previa. El horizonte electrónico se proporciona entonces al vehículo (por ejemplo, directamente o como alternativa a través del OEM).

En una realización ventajosa adicional, las memorias intermedias de protocolo pueden usarse para la comunicación de servidor de cliente descrita anteriormente y para la codificación de una estructura de datos de horizonte electrónico para optimizar el volumen de datos. En un ejemplo, la estructura de datos de horizonte electrónico puede contener una lista de segmentos o trayectorias de carretera, en donde cada segmento o trayectoria tiene una lista de atributos, por ejemplo, con tipo de atributo, valor y/o rango de desplazamiento a lo largo del segmento o trayectoria al que se aplica el atributo, y opcionalmente una lista de intersecciones que contienen, cada una, una lista de trayectorias laterales (haciendo de esto una estructura de datos recursiva) con sus rumbos o ángulos de giro.

Como se ha mencionado, no es necesario que los datos de horizonte electrónico contengan la información de geometría de carretera completa (por ejemplo, latitud y longitud de los puntos de forma a lo largo de la carretera, o posiblemente una representación basada en spline, clotoide u otra curva), debido a que este enfoque requiere una cantidad significativa de datos volumen de transferencia para los datos de geometría, así como un algoritmo de puesta en coincidencia de mapa complejo que consume potencia de procesamiento. No obstante, para poder identificar la posición del vehículo con respecto al horizonte electrónico, pueden emplearse uno o más de los siguientes enfoques:

• Los datos de horizonte electrónico pueden contener ya información acerca de la ubicación del vehículo que corresponde a la estimación de posición más reciente proporcionada en la solicitud. Esta información puede proporcionarse como un desplazamiento en la trayectoria más probable.

• El vehículo puede medir la distancia recorrida desde esa estimación de posición, por ejemplo, usando información de rotación de rueda.

• El cliente de SLO 111 puede usar esta información de distancia para actualizar su posición en la carretera representada por el horizonte electrónico, habitualmente simplemente sumando la distancia recorrida al desplazamiento en la trayectoria más probable.

• Preferiblemente, el cliente de SLO 111, sin embargo, debería ser capaz de detectar giros, por ejemplo, para detectar situaciones en las que el vehículo se sale de la trayectoria más probable o, en general, de cualquier carretera. Para esto, el cliente de SLO 111 puede supervisar el rumbo del vehículo (contenido en las estimaciones de posición, desde un GNSS o desde una fusión con otros sensores) y/o cambios de rumbo (según son medidos, por ejemplo, por un giroscopio, una brújula y/o patrones de movimiento del volante). Confiar específicamente en un giroscopio o una brújula puede ser menos susceptible de errores que confiar en ángulos de dirección, debido a que estos probablemente eliminarán por filtrado movimientos rápidos que evitan baches, adelantamientos, etc., que pueden recogerse cuando solo se supervisa el volante/columna de dirección. Para esto, los datos de horizonte electrónico contienen o bien rumbos para las carreteras que entran y salen de una intersección, o bien directamente ángulos de giro. Si el cliente de SLO 111 halla que el vehículo está cerca (por ejemplo, por debajo de un umbral de distancia) de una intersección (usando su posición actual en los datos de horizonte electrónico y comparándolos con los puntos de inicio de las subtrayectorias o con información de intersección explícita en los datos de horizonte electrónico), entonces el cliente de SLO 111 compara la información de rumbo o cambio de rumbo del vehículo con la información de rumbo o ángulo de giro de los datos de horizonte electrónico para decidir si el vehículo se ha desviado de la carretera previa y, de ser así, por qué subtrayectoria podría estar conduciendo ahora.

• Como alternativa o adicionalmente, el cliente de SLO 111 puede usar la información de rumbo o cambio de rumbo a partir del vehículo también cuando no se está cerca de una intersección, por ejemplo, para hallar si el vehículo ha cambiado de sentido o ha girado a un camino de acceso o sitio de estacionamiento. Los datos de horizonte electrónico pueden proporcionar información adicional acerca del rumbo de la carretera o el cambio de rumbo de la carretera en ubicaciones en donde la carretera gira abruptamente, de tal modo que el cliente de SLO 111 no confunda, por ejemplo, seguir una curva pronunciada en la carretera con girar fuera de la carretera (por ejemplo, confundir una curva cerrada con un cambio de sentido).

Los aspectos y realizaciones ilustrativos de la presente divulgación pueden tener, por lo tanto, las siguientes ventajas:

Solución liviana - no se requiere ningún mapa en el vehículo, requisitos de hardware bajos

Cubrir indisponibilidades de red hasta cierto punto

Optimizar datos transferidos por aire al vehículo

Flexibilidad con respecto a atributos adicionales necesarios para el algoritmo de fusión

Disponibilidad de los datos más recientes en el lado del servidor, incluyendo, por ejemplo, límites de velocidad dinámicos

Pasando a continuación a la figura 4 que muestra un diagrama de bloques con componentes relevantes de un dispositivo móvil 400, tal como el vehículo 110 descrito anteriormente. Sin embargo, el diagrama de bloques de la figura 4 también puede ser representativo de otro dispositivo móvil tal como un teléfono inteligente, un ordenador de tipo tableta, un ordenador ultraportátil, un sistema de navegación o similares.

El dispositivo móvil 400 comprende un procesador 401. El procesador 401 puede representar un único procesador o dos o más procesadores, que están, por ejemplo, al menos parcialmente acoplados, por ejemplo a través de un bus. El procesador 401 ejecuta un código de programa almacenado en la memoria de programa 402 (por ejemplo, el código de programa que hace que el dispositivo móvil 400 realice una o más de las realizaciones de un método de acuerdo con la presente divulgación o partes del mismo, cuando se ejecuta en el procesador 401), e interacciona con una memoria principal 403. La memoria de programa 402 también puede contener un sistema operativo para el procesador 401. Algunas o todas las memorias 402 y 403 también pueden incluirse en el procesador 401.

Una o ambas de una memoria principal y una memoria de programa de un procesador (por ejemplo, la memoria de programa 402 y la memoria principal 403) podrían conectarse de forma fija al procesador (por ejemplo, el procesador 401) o al menos ser parcialmente extraíbles del procesador, por ejemplo, en forma de una tarjeta o lápiz de memoria.

Una memoria de programa (por ejemplo, la memoria de programa 402) puede ser, por ejemplo, una memoria no volátil. Esta puede ser, por ejemplo, una memoria FLASH (o una parte de la misma), cualquiera de una ROM, PROM, EPROM, MRAM o una FeRAM (o una parte de la misma) o un disco duro (o una parte del mismo), por nombrar solo unos pocos ejemplos. Por ejemplo, una memoria de programa puede comprender, por ejemplo, una primera sección de memoria que está instalada de forma fija, y una segunda sección de memoria que es extraíble, por ejemplo, en forma de una tarjeta de memoria SD extraíble.

Una memoria principal (por ejemplo, la memoria principal 403) puede ser, por ejemplo, una memoria volátil. Esta puede ser, por ejemplo, una memoria DRAM, por dar un ejemplo no limitante. Esta puede usarse, por ejemplo, como una memoria de trabajo para el procesador 401 cuando se ejecuta un sistema operativo y/o programas.

Cualquiera de las memorias 402, 403 puede usarse para almacenar (al menos temporalmente) datos de horizonte electrónico, como se ha descrito anteriormente.

El procesador 401 controla adicionalmente una interfaz de radio 404 configurada para recibir y/o emitir datos y/o información. Por ejemplo, la interfaz de radio 404 puede configurarse para recibir señales de radio desde un nodo de radio. La interfaz de radio 404 está configurada para recibir señales de radio que se transmiten por nodos de radio de, por ejemplo, una red de WiFi (WLAN) y/o cualquier otro sistema de comunicaciones de radio. Por ejemplo, la interfaz de radio 404 puede comprender una interfaz de radio de WLAN que incluye al menos un receptor de WLAN (RX). El receptor de WLAN también puede ser una parte de un transceptor de WLAN. El receptor de WLAN puede ayudar a determinar una posición del dispositivo móvil.

Además, el procesador 401 controla una interfaz de comunicación 405 que está configurada, por ejemplo, para comunicarse de acuerdo con un sistema de comunicación celular como un sistema de comunicación celular de 2G/3G/4G/5G o de una generación futura. El dispositivo móvil 400 puede usar la interfaz de comunicación 405 para comunicarse con un servidor, por ejemplo, con el servidor de SLO 121 representado en la figura 1. En consecuencia, el dispositivo móvil 400 puede obtener un horizonte electrónico a través de la interfaz de comunicación 405, como se ha descrito anteriormente.

Además, el procesador 401 puede controlar un sensor de posicionamiento de GNSS 406 (por ejemplo, un sensor de GPS o cualquier otra técnica de posicionamiento de GNSS). El sensor de posicionamiento de GNSS puede configurarse para recibir señales de satélite de un sistema de GNSS (por ejemplo, señales de satélite de GPS) y para determinar una posición del dispositivo móvil 400 basándose al menos parcialmente en señales de satélite del sistema de GNSS que pueden recibirse en esta posición.

Además, el procesador 401 puede controlar medios opcionales adicionales y, en particular, sensores para realizar funciones de ADAS. Por ejemplo, el dispositivo móvil puede comprender, en particular, uno o más de una cámara 407 (que puede proporcionar datos al componente de fusión 113 o que puede obtener información del cliente de SLO 111 para soportar el funcionamiento de la cámara 407), un sensor de movimiento 408, tal como un acelerómetro o un giroscopio, y/o un odómetro 409, que puede usarse para determinar una posición del dispositivo móvil.

Los componentes 402 a 409 del dispositivo móvil 400 pueden conectarse, por ejemplo, con el procesador 401 por medio de uno o más buses en serie y/o en paralelo.

Ha de entenderse que el dispositivo móvil 400, dependiendo del tipo de dispositivo, puede comprender varios otros componentes, tales como una interfaz de usuario (por ejemplo, una pantalla táctil, un teclado, un panel táctil, una pantalla, etc.) para nombrar sino un ejemplo.

Pasando a continuación a la figura 5, se muestra un diagrama de bloques de una realización ilustrativa de un servidor 500, tal como el servidor de SLO 121 de la figura 1.

Por ejemplo, el servidor 500 puede usarse para la construcción en línea de horizontes electrónicos para proporcionar horizontes electrónicos respectivos a los vehículos, como se ha descrito con detalle anteriormente.

El servidor 500 comprende un procesador 501. El procesador 501 puede representar un único procesador o dos o más procesadores, que están, por ejemplo, al menos parcialmente acoplados, por ejemplo a través de un bus. El procesador 501 ejecuta un código de programa almacenado en la memoria de programa 502 (por ejemplo, el código de programa que hace que el servidor 500 realice una o más de las realizaciones de un método de acuerdo con la presente divulgación o partes del mismo), e interacciona con una memoria principal 503.

La memoria de programa 502 también puede comprender un sistema operativo para el procesador 501. Algunas o todas las memorias 502 y 503 también pueden incluirse en el procesador 501. Puede usarse cualquier memoria para almacenar datos de mapa y para almacenar horizontes electrónicos construidos. Como se ilustra en la figura 1, el servidor 500 también puede comprender una base de datos de mapas o tener acceso a un servidor de base de datos de mapas, para obtener datos de mapa respectivos.

Además, el procesador 501 controla una interfaz de comunicación 504 que está configurada, por ejemplo, para comunicarse de acuerdo con un sistema de comunicación celular como un sistema de comunicación celular de 2G/3G/4G/5G o de una generación futura. La interfaz de comunicación 504 del servidor 500 puede proporcionarse para comunicarse entre el dispositivo móvil 400 y el servidor 500 (por ejemplo, el vehículo 110 y el servidor de SLO 120 de la figura 1).

El servidor 500 puede comprender además una interfaz de usuario 505 (por ejemplo, una pantalla táctil, un teclado, un panel táctil, una pantalla, etc.).

Los componentes 502 a 505 del servidor 500 pueden conectarse, por ejemplo, con el procesador 501 por medio de uno o más buses en serie y/o en paralelo.

Ha de entenderse que el servidor 500 puede comprender diversos otros componentes.

La figura 6 es una ilustración esquemática de ejemplos de medios de almacenamiento legibles por ordenador tangibles y no transitorios de acuerdo con la presente invención que pueden usarse, por ejemplo, para implementar la memoria 402 de la figura 4 o la memoria 502 de la figura 5. Para este fin, la figura 6 visualiza una memoria flash 600, que puede soldarse o unirse, por ejemplo, a una placa de circuito impreso, una unidad de estado sólido 601 que comprende una pluralidad de chips de memoria (por ejemplo, chips de memoria flash), una unidad de disco duro magnético 602, una tarjeta digital segura (SD) 603, un lápiz de memoria de bus serie universal (USB) 604, un medio de almacenamiento óptico 605 (tal como, por ejemplo, un CD-ROM o DVD) y un medio de almacenamiento magnético 606.

Cualquier conexión presentada en las realizaciones descritas ha de entenderse en el sentido de que los componentes implicados se acoplan operativamente. Por lo tanto, las conexiones pueden ser directas o indirectas con cualquier número o combinación de elementos intermedios, y puede haber meramente una relación funcional entre los componentes.

Además, como se usa en este texto, el término 'circuitería' se refiere a cualquiera de los siguientes:

(a) implementaciones de circuito solo de hardware (tales como implementaciones en solo circuitería analógica y/o digital)

(b) combinaciones de circuitos y software (y/o firmware), tales como: (i) a una combinación de procesador(es) o (ii) a secciones de procesador(es)/software (incluyendo procesador(es) de señales digitales), software y memoria o memorias que funcionan conjuntamente para hacer que un aparato, tal como un teléfono móvil, realice diversas funciones), y

(c) a circuitos, tales como un(os) microprocesador(es) o una sección de un(os) microprocesador(es), que requieren software o firmware para su funcionamiento, incluso si el software o firmware no está presente físicamente.

Esta definición de 'circuitería' es aplicable a todos los usos de este término en este texto, incluyendo en cualquier reivindicación. Como un ejemplo adicional, como se usa en este texto, el término 'circuitería' también cubre una implementación de meramente un procesador (o múltiples procesadores) o una sección de un procesador y su software y/o firmware adjunto. El término 'circuitería' también cubre, por ejemplo, un circuito integrado de banda base o circuito integrado de procesador de aplicaciones para un teléfono móvil.

Cualquiera de los procesadores mencionados en este texto, en particular, pero sin limitación, los procesadores 401 y 501 de las figuras 4 y 5, podría ser un procesador de cualquier tipo adecuado. Cualquier procesador puede comprender, pero sin limitación, uno o más microprocesadores, uno o más procesadores con procesador(es) de señales digitales adjunto(s), uno o más procesadores sin procesador(es) de señales digitales adjunto(s), uno o más chips de ordenador de propósito especial, una o más matrices de puertas programables en campo (FPGA), uno o más controladores, uno o más circuitos integrados específicos de la aplicación (ASIC) o uno o más ordenadores. La estructura/hardware pertinente se ha programado de tal forma para que lleve a cabo la función descrita.

Además, cualquiera de las acciones o etapas descritas o ilustradas en el presente documento puede implementarse usando instrucciones ejecutables en un procesador de propósito general o de propósito especial y almacenadas en un medio de almacenamiento legible por ordenador (por ejemplo, disco, memoria o similar) para ser ejecutadas por un procesador de este tipo. Debería entenderse que las referencias a 'medio de almacenamiento legible por ordenador' abarcan circuitos especializados tales como FPGA, ASIC, dispositivos de procesamiento de señales y otros dispositivos.

Además, cualquiera de las acciones descritas o ilustradas en el presente documento puede implementarse usando instrucciones ejecutables en un procesador de propósito general o de propósito especial y almacenadas en un medio de almacenamiento legible por ordenador (por ejemplo, disco, memoria o similar) para ser ejecutadas por un procesador de este tipo. Debería entenderse que las referencias a 'medio de almacenamiento legible por ordenador' abarcan circuitos especializados tales como FPGA, ASIC, dispositivos de procesamiento de señales y otros dispositivos.

Puede entenderse que la expresión "A o B o C, o una combinación de los mismos" o "al menos uno de A, B y C" no es exhaustiva y que incluye al menos los siguientes: (i) A, o (ii) B, o (iii) C, o (iv) A y B, o (v) A y C, o (vi) B y C, o (vii) A y B y C.

Claims

REIVINDICACIONES

1. Un método realizado por un dispositivo móvil (110, 400) o una parte del mismo, comprendiendo el método:

- proporcionar una indicación de una trayectoria del dispositivo móvil (100, 400) a un servidor remoto (121, 500); - obtener (136), desde el servidor remoto (121, 500), un horizonte electrónico que comprende datos de horizonte electrónico, basándose en la indicación de la trayectoria;

- realizar una o más funciones de ADAS basándose al menos parcialmente en el horizonte electrónico obtenido;caracterizado porcomprender además el método:

- determinar una extensión deseada del horizonte electrónico basándose al menos en parte en una disponibilidad esperada de una conectividad de red entre el dispositivo móvil (110, 400) y el servidor remoto (121, 500) y - proporcionar una solicitud para el horizonte electrónico, en donde la extensión deseada del horizonte electrónico solicitado se indica con la solicitud;

en donde el horizonte electrónico obtenido se basa adicionalmente en la solicitud.

2. El método de acuerdo con la reivindicación 1, en donde el horizonte electrónico se obtiene obteniendo repetidamente un horizonte electrónico de sustitución que comprende datos de horizonte electrónico de sustitución.

3. El método de acuerdo con las reivindicaciones 1 o 2, en donde el horizonte electrónico solo comprende datos de horizonte electrónico requeridos y/o útiles específicamente para las una o más funciones de ADAS.

4. El método de acuerdo con cualquiera de las reivindicaciones 1 a 3, en donde los datos de horizonte electrónico comprenden información de geometría de carretera reducida.

5. El método de acuerdo con cualquiera de las reivindicaciones 1 a 4, en donde el método comprende además: - construir, basándose en el horizonte electrónico obtenido, un horizonte electrónico interno para distribuir los datos de horizonte electrónico obtenidos con el horizonte electrónico dentro del dispositivo móvil (110, 400).

6. El método de acuerdo con cualquiera de las reivindicaciones 1 a 5, en donde el método comprende además - obtener datos de sensor desde uno o más sensores del dispositivo móvil, en donde dicha ejecución al menos una de las una o más funciones de ADAS se basa adicionalmente al menos parcialmente en los datos de sensor obtenidos.

7. El método de acuerdo con cualquiera de las reivindicaciones 1 a 6, en donde las una o más funciones de ADAS comprenden una o más de:

- una función de asistencia de velocidad inteligente;

- una función de advertencia de peligro;

- una función de indicación de vehículo de emergencia; y/o

- una función de detección de señales de tráfico.

8. El método de acuerdo con cualquiera de las reivindicaciones 1 a 7, en donde una o más de la siguiente información está comprendida por o es derivable de los datos de horizonte electrónico:

- un código de país;

- un tipo de una carretera;

- un rumbo de carretera;

- un lado de conducción;

- una distancia a una siguiente intersección;

- un número de carriles en la dirección de conducción;

- un número de carriles opuestos a la dirección de conducción; y/o

- una indicación de una zona de área urbana.

9. El método de acuerdo con cualquiera de las reivindicaciones 1 a 8, en donde el método comprende además uno o más de:

- comprobar (131) si es necesario actualizar o sustituir el horizonte electrónico;

- identificar (139) una posición del dispositivo móvil (110, 400) con respecto al horizonte electrónico.

10. El método de acuerdo con cualquiera de las reivindicaciones 1 a 9, en donde la indicación de la trayectoria comprende una o más estimaciones de posición, información de rumbo y/o información de velocidad del dispositivo móvil (110, 400) y/o en donde la indicación de la trayectoria se proporciona en respuesta a determinar que es necesario actualizar el horizonte electrónico.

11. El método de acuerdo con cualquiera de las reivindicaciones 1 a 10, en donde el método comprende además:

12. El método de acuerdo con la reivindicación 9, en donde, para identificar una posición del dispositivo móvil (110, 400) con respecto al horizonte electrónico, el método comprende además uno o más de:

- determinar una distancia recorrida por el dispositivo móvil (110, 400) desde una posición para la que se proporcionó una indicación de una trayectoria del dispositivo móvil (110, 400) al servidor (121, 500); y/o

- detectar información de rumbo o información de cambio de rumbo del dispositivo móvil (110, 400).

13. Un método realizado por un servidor (121, 500) o una parte del mismo, comprendiendo el método:

- obtener, desde un dispositivo móvil (110, 400) remoto, una indicación de una trayectoria del dispositivo móvil (110, 400),

- construir (135) un horizonte electrónico a partir de datos de mapa específicamente para posibilitar que el dispositivo móvil (110, 400) proporcione una o más funciones de ADAS, en donde el horizonte electrónico comprende datos de horizonte electrónico para las una o más funciones de ADAS del dispositivo móvil (110, 400), en donde los datos de horizonte electrónico cubren una o más trayectorias (204, 205, 303a, 303b) potenciales que se predice que van a ser tomadas por el dispositivo móvil (110, 400) basándose en la indicación de la trayectoria; y

- proporcionar (136), al dispositivo móvil (110, 400), el horizonte electrónicocaracterizado porcomprender además el método:

- determinar una extensión del horizonte electrónico basándose al menos en parte en una disponibilidad esperada de una conectividad de red entre el dispositivo móvil (110, 400) y el servidor (121), en donde dicha construcción de dicho horizonte electrónico se basa al menos en parte en dicha extensión determinada.

14. El método de la reivindicación 13, en donde la indicación de la trayectoria comprende una o más estimaciones de posición del dispositivo móvil (110, 400).

15. El método de las reivindicaciones 13 o 14, en donde el método comprende además uno o más de:

- obtener (133) los datos de mapa desde una base de datos de mapas (122); y/o

- identificar (134) una posición del dispositivo móvil (110, 400) con respecto a los datos de mapa.

16. Un dispositivo móvil (110, 400) o una parte del mismo que comprende medios para realizar el método de acuerdo con cualquiera de las reivindicaciones 1 a 12.

17. Un servidor (121, 500) o una parte del mismo que comprende medios para realizar el método de acuerdo con cualquiera de las reivindicaciones 13 a 15.

18. Un sistema (110, 120) que comprende un dispositivo móvil o una parte del mismo y un servidor o una parte del mismo que realizan conjuntamente un método que comprende:

- proporcionar, por el dispositivo móvil (110, 400), al servidor (121, 500), una indicación de una trayectoria del dispositivo móvil (110, 400);

- obtener, por el servidor (121, 500), desde el dispositivo móvil (110, 400), la indicación de una trayectoria del dispositivo móvil (110, 400),

- construir (135), por el servidor, un horizonte electrónico a partir de datos de mapa específicamente para posibilitar que el dispositivo móvil (110, 400) proporcione una o más funciones de ADAS, en donde el horizonte electrónico comprende datos de horizonte electrónico para las una o más funciones de ADAS del dispositivo móvil (110, 400), en donde los datos de horizonte electrónico cubren una o más trayectorias (204, 205, 303a, 303b) potenciales que se predice que van a ser tomadas por el dispositivo móvil (110, 400) basándose en la indicación de la trayectoria; - proporcionar (136), por el servidor (121, 500), al dispositivo móvil (110, 400), el horizonte electrónico;

- obtener (136), por el dispositivo móvil (110, 400), desde el servidor (121, 500), el horizonte electrónico; y - realizar, por el dispositivo móvil (110, 400), al menos una de las una o más funciones de ADAS basándose al menos parcialmente en el horizonte electrónicocaracterizado por que:

- la extensión del horizonte electrónico es determinada por el servidor (121, 500) basándose al menos en parte en la disponibilidad esperada de una conectividad de red entre el dispositivo móvil (110, 400) y el servidor (121, 500), y/o

- la extensión del horizonte electrónico es determinada por el dispositivo móvil (110, 400) basándose al menos en parte en la disponibilidad esperada de una conectividad de red entre el dispositivo móvil (110, 400) y el servidor remoto (121, 500).

19. Producto de programa informático, haciendo el producto de programa informático, cuando es ejecutado por un procesador de un aparato, que dicho aparato realice un método de acuerdo con cualquiera de las reivindicaciones 1 a 15.

20. Medio de almacenamiento legible por ordenador que comprende un producto de programa informático de acuerdo con la reivindicación 19.