FR3132588A1 - Procédé d’élaboration d’un horizon artificiel - Google Patents

Abstract

L’invention concerne un procédé d’élaboration d’un horizon artificiel pour un véhicule automobile, comprenant des étapes de : - réception de données d’entrée relatives au véhicule automobile et à son environnement, - détermination de différents trajets, et - génération de messages caractérisant ledit horizon artificiel, dont des messages longs de caractérisation d’évènements, chaque message long comportant plusieurs champs, dont au moins un premier champ relatif à un type d’attribut caractérisant l’évènement et un second champ indiquant la valeur de cet attribut. Selon l’invention, le premier champ peut prendre au moins deux valeurs distinctes associées à un nombre correspondant de catégories d’évènements temporaires, lesdits catégories étant dissociées en fonction de leurs vitesses et/ou de leurs positions relatives au véhicule automobile. Figure pour l’abrégé : Fig.1

Description

Procédé d’élaboration d’un horizon artificiel Domaine technique de l'invention

La présente invention concerne de manière générale les systèmes d’interfaçage permettant aux véhicules automobiles d’appréhender leurs environnements extérieurs. Elle concerne ici la génération d’horizons artificiels, c’est-à-dire le traitement de données permettant au véhicule de construire une carte de son environnement.

L’invention porte ainsi plus spécifiquement sur un procédé d’élaboration d’un horizon artificiel pour un véhicule automobile, comprenant des étapes de :
- réception de données d’entrée relatives au véhicule automobile et à son environnement,
- détermination de différents trajets empruntables par le véhicule automobile, et
- génération de messages caractérisant ledit horizon artificiel.

Ici, plusieurs types de messages peuvent être élaborés, dont :
- des messages de positionnement du véhicule automobile,
- des messages de positionnement de chaque trajet,
- des messages de caractérisation de chaque trajet,
- des messages courts et longs de caractérisation d’évènements se trouvant sur chaque trajet, chacun des messages longs comportant plusieurs champs, dont au moins un premier champ relatif à un type d’attribut caractérisant l’évènement et un second champ indiquant la valeur de cet attribut.

L’invention concerne aussi un véhicule automobile comprenant des clients logiciels (parmi lesquels une interface homme-machine et/ou un système de navigation et/ou des systèmes d’aide à la conduite) et une interface principale qui est programmée pour mettre en œuvre un procédé d’élaboration tel que précité, afin de fournir à chaque client une partie au moins de l’horizon artificiel élaboré.

Etat de la technique

De nombreux véhicules sont aujourd’hui équipés de systèmes d’assistance à la conduite embarqués, qui permettent d’assister le conducteur lors de sa conduite, que ce soit lors de situations de conduite dangereuse ou simplement pour améliorer le confort de conduite.

On connaît par exemple les systèmes embarqués suivants : le système de navigation qui aide le conducteur à suivre un itinéraire pour se rendre d’un point de départ à un point d’arrivée, le système d’aide à la conduite dit « ADAS » (acronyme anglais pour « Advanced Driver Assistance Système »), ou encore l’Interface Homme-Machine (IHM) qui affiche ou émet des alertes lors de la conduite.

Pour fonctionner efficacement, les systèmes embarqués doivent sonder et analyser l’environnement plus ou moins lointain du véhicule. A cet effet, le véhicule est équipé de capteurs physiques qui récoltent des informations sur ce qui entoure le véhicule.

Pour améliorer encore la connaissance de son environnement, le véhicule peut aussi être équipé de la technologie V2X grâce à laquelle il reçoit des messages en provenance d’émetteurs situés à distance de lui, par exemple de la part d’autres véhicules (technologie dite V2V), d’infrastructures routières (technologie dite V2I), du réseau (technologie dite V2N) ou encore d’autres usagers de la route tels que les piétons (technologie dite V2P).

Les messages reçus de la part de ces émetteurs contiennent des informations diverses telles que : la position absolue (en coordonnées GPS) de l’émetteur, la fiabilité de cette position, la vitesse de déplacement de l’émetteur, l’accélération de l’émetteur et/ou sa direction de déplacement, ou encore les dangers que l’émetteur a rencontrés ou créés lors de son déplacement (route glissante, virage dangereux, accident, encombrement du trafic…).

On estime ainsi qu’avec le déploiement de la technologie V2X dans de plus en plus de véhicules et le développement de la 5G, la quantité d’informations qui viendra à être reçue par seconde dans un véhicule sera telle qu’il deviendra nécessaire de sélectionner les plus utiles, au risque, sinon, de ralentir le fonctionnement des systèmes embarqués dans le véhicule voire de les saturer.

Dans ce cadre, plusieurs constructeurs de véhicules se sont associés pour créer un protocole nommé ADASIS (de l’anglais « Advanced Driver Assistance Systems Interface Specification »). Ce protocole, et notamment sa version V2, est conçu pour décrire la géométrie de la route à l’avant du véhicule et caractériser son environnement par un nombre élevé mais limité de paramètres. On dit alors de ce protocole qu’il permet de créer un horizon artificiel. Selon ce protocole, l’environnement est décrit non pas par portions de route, mais plutôt par trajets empruntables par le véhicule automobile. Il est ainsi défini un trajet principal sur lequel se trouve le véhicule, et des trajets secondaires qui prennent naissance sur le trajet principal ou sur d’autres trajets secondaires.

Ce protocole est alors conçu de manière à ce que le fournisseur d’horizon artificiel (qui fonctionne selon ce protocole) puisse envoyer aux systèmes embarqués (appelés « clients ») six types de messages.

Ces types de messages sont les suivants :
- des messages de position relatifs à la position du véhicule,
- des messages de bout (en anglais « Stub ») relatifs à la position du point où le trajet concerné prend naissance,
- des messages de segment caractérisant les attributs principaux d’une partie particulière du trajet concerné,
- des messages de profil courts caractérisant les évènements situés sur chaque trajet qui peuvent être exprimés en 10 bits,
- des messages de profil longs caractérisant les évènements situés sur chaque trajet qui peuvent être exprimés en 32 bits,
- des messages de métadonnées.

Ce protocole permet de fournir aux clients des données sur l’environnement qui sont précises et facilement exploitables, et dont le nombre varie d’un client à l’autre. Typiquement, la plupart des clients (par exemple le système de régulation automatique de vitesse) n’a besoin de données relatives qu’au trajet principal. D’autres clients ont en revanche besoin de davantage de données, en particulier des données relatives aux évènements présents sur les trajets secondaire (pour vérifier par exemple si un véhicule prioritaire arrive sur l’un de ces trajets secondaires).

Mais même avec ce protocole, le nombre de données à traiter par les calculateurs du véhicule reste très important, si bien que le problème de ralentissement ou de saturation demeure.

En outre, ce protocole est conçu pour ne transmettre que des données relatives à des évènements permanents (panneau, croisement…), si bien qu’il fournit des informations limitées.

Présentation de l'invention

Afin de remédier aux inconvénients précités de l’état de la technique, la présente invention propose de compléter le protocole ADASIS (version 2) précité pour ajouter une couche dynamique supplémentaire afin de transmettre des informations relatives à des « évènements » temporaires (objets ou situations circonstancielles) qui sont pertinentes pour les clients, en distinguant les évènements selon leur nature.

Plus particulièrement, on propose selon l’invention un procédé d’élaboration d’un horizon artificiel tel que défini dans l’introduction, dans lequel le premier champ d’un message long peut prendre au moins deux valeurs distinctes respectivement associées à un nombre correspondant de catégories prédéfinies d’évènements temporaires (c’est-à-dire passagers, non permanents), lesdites catégories étant distinguées en fonction de la vitesse de l’évènement temporaire et/ou de la position de l’évènement temporaire relativement au véhicule automobile.

Ainsi, l’invention propose de tirer parti des messages longs du protocole ADASIS afin de transmettre des données codées de manière particulière. En particulier, le premier champ (relatif au type d’attribut) peut prendre une première valeur pour indiquer que le second champ (valeur de l’attribut) comportera des données relatives à des évènements temporaires dynamiques, ou une seconde valeur pour indiquer que le champ comportera des données relatives à des évènements temporaires statiques ou pseudo-statiques (c’est-à-dire considérés comme statiques bien qu’ils ne le soient pas exactement). Le second champ pourra alors lui-même être codé pour recevoir non pas simplement une valeur, mais une juxtaposition de données caractérisant plusieurs aspects de l’évènement temporaire (sa vitesse, sa position sur les voies de circulation…).

De cette façon, il est possible de fournir de manière efficace aux clients les seules informations qui leurs sont utiles, en exploitant les données qui décrivent les informations cartographiques et en ajoutant des attributs pour indiquer la présence d'objets particuliers.

L’intérêt de distinguer les évènements dynamiques des évènements statiques est que pour caractériser ces deux types d’évènements, on n’emploie pas les mêmes attributs. Par conséquent, seuls les attributs pertinents seront codés dans chaque message, puisque chaque message sera associé à une catégorie seulement d’évènements.

On notera par ailleurs que la façon employée pour caractériser ces évènements sera telle qu’il ne sera pas nécessaire (contrairement à ce qui est fait en général selon le protocole ADASIS) d’envoyer un message de terminaison lorsqu’un évènement sera mis à jour (par exemple sa position). A titre d’exemple, en utilisant l’identifiant de l’évènement, on pourra directement transmettre la version mise à jour de l’évènement, sans avoir besoin d’effacer la version précédente. Ceci permettra de réduire le nombre de messages envoyés.

Comme cela sera bien expliqué dans la suite de cet exposé, cette implémentation évitera en outre de transmettre plusieurs fois le même genre d’information, afin de ne pas surcharger les calculateurs.

D’autres caractéristiques avantageuses et non limitatives du procédé d’élaboration conforme à l’invention, prises individuellement ou selon toutes les combinaisons techniquement possibles, sont les suivantes :
- une catégorie d’événements correspond à des évènements dynamiques, une catégorie d’événements correspond à des évènements statiques ou pseudo-statiques vis-à-vis du véhicule automobile, et une catégorie d’évènement correspond à des feux de circulation ;
- un évènement est considéré comme dynamique lorsque sa vitesse est supérieure à un premier seuil et/ou lorsque sa distance au véhicule automobile est supérieure à un second seuil ;
- le premier seuil et/ou le second seuil est une fonction de la vitesse du véhicule automobile et/ou de la vitesse de l'événement et/ou de l'environnement ;
- lorsque la vitesse et/ou la distance au véhicule automobile d’un évènement varie dans le temps, la valeur du premier champ peut changer ;
- l’un au moins de évènements suivants est considéré comme dynamique :
¤ un véhicule d'urgence en intervention,
¤ un véhicule dont un système de freinage d'urgence est activé,
¤ un véhicule dont un système de retenue réversible des occupants est activé,
¤ une personne ou un animal sur le trajet,
¤ des travaux routiers mobiles sur le trajet,
¤ un véhicule roulant à contresens,
¤ des travaux mobiles de sauvetage et de récupération en cours,
¤ un véhicule au moins un tiers plus lent que la vitesse maximum autorisée,
¤ un véhicule générant un risque de collision,
¤ un véhicule violant le code de la route,
¤ une situation dangereuse ;
- l’un au moins de évènements suivants est considéré comme statique :
¤ un accident,
¤ des travaux routiers,
¤ une portion de trajet impraticable,
¤ des conditions météorologiques défavorables,
¤ une zone d’aquaplaning,
¤ une zone dangereuse,
¤ une zone de travaux de sauvetage et de récupération en cours,
¤ un véhicule à l’arrêt,
¤ une fin de file d’embouteillage dangereuse ;
- chaque message long associé à une catégorie d’évènement temporaire comporte deux champs permettant d’identifier de deux façons distinctes chaque évènement ;
- les données d’entrée sont au moins en partie issues d’un message de notification d’évènement décentralisé et/ou d’un message d’avertissement coopératif émis par un véhicule tiers.

L’invention concerne aussi un véhicule automobile comprenant des clients logiciels (parmi lesquels une interface homme-machine et/ou un système de navigation et/ou des systèmes d’aide à la conduite) et une interface principale qui est programmée pour mettre en œuvre un procédé d’élaboration tel que précité, afin de fournir à chaque client une partie au moins de l’horizon artificiel élaboré.

D’autres caractéristiques préférentielles du procédé d’élaboration conforme à l’invention sont les suivantes :
- seuls les évènements qui sont situés sur un trajet principal (également appelé trajet le plus probable au sens du protocole ADASIS), à une distance du véhicule inférieure à un seuil, sont considérés dans les messages émis vers les clients (ce qui permettra de réduire la quantité d’informations envoyées, et donc la bande passante nécessaire à cet envoi) ;
- ce seuil est inférieur à la distance sur laquelle le client reçoit des informations sur la cartographie ;
- les données d’entrée fournies au véhicule automobile par les véhicules environnants sont également fournies au client via les messages de taille longue, sans même que ne soit détecté une éventuelle situation dangereuse ;
Evènements dynamiques :
- un événement dynamique est identifié grâce au champ d'index de trajet de l'interface standard ADASIS ainsi que grâce au champ « ID »,
- 6 bits sont utilisés afin de discriminer les événements dynamiques dans l'index de trajet et une valeur particulière est utilisée pour indiquer que toutes les valeurs possibles du champ ID sont utilisées ;
- les valeurs du champ ID sont sélectionnées dans un ordre croissant ;
- les valeurs du champ ID permettent de suivre les événements dynamiques tant qu'ils appartiennent à un même segment de route et permettent de mettre à jour sa position sans mettre fin à l'événement ;
- il est prévu d’envoyer un message spécifique lorsque l'événement dynamique n'appartient plus à l'index de trajet initialement identifié, libérant ainsi la valeur du champ ID correspondante ;
- une valeur spécifique est utilisée afin d'indiquer que plus de 63 objets sont présents dans l'index de trajet ;
- dans un tel cas dit de débordement, lorsqu'un nouvel événement dynamique doit être livré au client, la décision sur quel événement prioriser est prise en fonction de la distance entre l’évènement et le véhicule ;
- ainsi, si le nouvel évènement est plus éloigné du véhicule que l'ensemble des évènements déjà transmis, alors le nouvel évènement est rejeté, sinon l’évènement le plus éloigné est rejeté et le nouvel évènement est utilisé en utilisant la valeur du champ ID ainsi libéré ;
- des attributs spécifiques qui décrivent la cause et la sous-cause de l'événement dynamique sont décrits sur 7 bits ;
- un attribut spécifique qui représente l'âge de l'événement dynamique est décrit sur 10 bits ;
- cet attribut représente le temps avec une précision de 10 ms couvrant 10 secondes ;
- un attribut spécifique qui représente la voie est décrit sur 4 bits ;
- cet attribut spécifique indique sur quelle voie l'événement dynamique est situé (numéro de voie, ou bande d'arrêt d'urgence) ;
- un attribut spécifique qui représente la direction est décrit sur 2 bits ;
- cet attribut indique si l'événement dynamique avance ou recule ;
- un attribut spécifique qui est appelé « valeur » représente la vitesse de l'événement dynamique, il est décrit sur 5 bits ;
- un attribut qui indique la cause et la sous-cause est décrit en 9 bits, dont 5 bits pour la cause ;
Evènements statiques (ou pseudo-statiques) :
- un événement statique est identifié grâce au champ d'index de trajet de l'interface standard ADASIS ainsi que grâce au champ « ID » ;
- 7 bits sont utilisés afin de discriminer les événements statiques dans l'index de trajet et une valeur particulière est réservée pour indiquer que toutes les valeurs du champ ID sont utilisées.
- les valeur du champ ID sont sélectionnés dans un ordre croissant ;
- ces valeurs permettent de suivre les événements statiques tant qu'ils appartiennent au même segment de trajet et permettent de mettre à jour leurs positions sans mettre fin à l'événement ;
- il est prévu de supprimer un message spécifique lorsque l'événement statique n'appartient plus à l'index de trajet initialement identifié, libérant ainsi la valeur du champ ID correspondante ;
- une valeur spécifique est utilisée afin d'indiquer que plus de 127 objets sont présents dans l'index spécifique et qu'une situation de débordement se produit ;
- le cas de débordement est traité de la même façon que pour les évènements dynamiques ;
- un attribut appelé « valeur » est utilisé pour indiquer la durée de l'événement statique ;
- la valeur 0 est utilisée pour indiquer que l'événement n'a pas de longueur tandis que les valeurs de 1 à 62 sont utilisées pour indiquer la longueur de l'événement statique ;
- la longueur n'est pas codée uniformément et la précision est dégradée pour des longueurs croissantes ;
- les longueurs de 0 à 100 mètres sont codées en considérant un pas de 4 mètres, tandis qu'un pas de 16 m est utilisé pour les longueurs comprises entre 100 et 500, un pas de 128 m est utilisé pour les longueurs comprises entre 500 et 1908 m et la valeur 62 est utilisée pour indiquer les longueurs supérieures à 1908 m ;
- la valeur 63 est utilisée pour invalider ou supprimer l'événement statique ;
- un attribut appelé début de voie, décrit sur 5 bits, indique le premier numéro de voie pour lequel l'événement statique est valable ;
- les événements statique hors route sont associés à un début de voie égal à 0 tandis que la bande d'arrêt d'urgence est associée à une voie numéro 1 et les voies sont comptées à partir de la voie 2 jusqu'à la voie 31 ;
- un attribut appelé fin de voie, décrit sur 5 bits, indique le dernier numéro de voie pour lequel l'événement statique est valable ;
Evénements feux de circulation :
- les événements feux de circulation sont associés aux changements de phases des feux;
- un champ du message lié à un tel évènement est appelé « manœuvre de circulation », cartographié sur 2 bits, il indique si la phase renseignée est valable pour aller tout droit, tourner à gauche ou à droite ;
- un autre champ appelé « phase courante », localisé sur 3 bits, indique la couleur de la phase courante ;
- un autre champ appelé « phase suivante », renseigné sur 3 bits également, indique la prochaine couleur de la phase suivante ;
- encore un autre champ appelé « heure de la phase suivante », utilisant 16 bits, indique l'heure à laquelle la phase suivante se produira, de préférence avec un pas de 100 ms ;
- dans ce champ, la plage de valeurs va de 0 à 36000 ;
- la valeur 36001 est la valeur si la phase suivante est dans plus de 1 heure ;
- la valeur 65535 est utilisée en cas d’extinction des feux de circulation ;
- un autre champ appelé « début de voie », utilisant 4 bits, indique le numéro de la première voie pour laquelle cette phase est valable ;
- un autre champ appelé « fin de voie », utilisant 4 bits, indique le numéro de la dernière voie pour laquelle cette phase est valable ;
- dans ces deux derniers champs, le numéro de voie 0 est utilisé pour les voies hors route, le numéro 1 pour la bande d'arrêt d'urgence, et les autres numéros pour les autres voies, en commençant la numérotation à 2 pour la voie la plus à droite.

Bien entendu, les différentes caractéristiques, variantes et formes de réalisation de l'invention peuvent être associées les unes avec les autres selon diverses combinaisons dans la mesure où elles ne sont pas incompatibles ou exclusives les unes des autres.

Description détaillée de l'invention

La description qui va suivre en regard des dessins annexés, donnés à titre d’exemples non limitatifs, fera bien comprendre en quoi consiste l’invention et comment elle peut être réalisée.

Sur l’unique dessin annexé :

est une vue d’un véhicule automobile et d’une partie de son environnement.

Sur la , on a représenté un véhicule automobile 10 adapté à mettre en œuvre l’invention.

Il s’agit ici d’une voiture. En variante, il pourrait s’agir d’un autre type de véhicule (camion, moto, bus…).

Ici, ce véhicule automobile 10 comporte classiquement un habitacle dans lequel se trouve notamment un siège pour le conducteur du véhicule, un groupe motopropulseur, un système de freinage et un système de direction permettant de faire tourner le véhicule. Classiquement, le système de direction comporte un actionneur de direction assistée pilotable électroniquement, le groupe motopropulseur comporte un actionneur de commande de moteur pilotable électroniquement, et le système de freinage comporte un actionneur de freinage pilotable électroniquement.

Ce véhicule automobile 10 est en outre équipé d’au moins une interface homme-machine. En pratique, il comporte ici un écran tactile couplé à des enceintes.

Il est également équipé, ici, d’un système de retenue réversible des occupants, typiquement d’un système de blocage commandé de la ceinture de sécurité.

Le véhicule automobile 10 comporte par ailleurs une unité électronique de traitement qui comporte plusieurs calculateurs (microprocesseurs ou microcontrôleurs), des mémoires et des interfaces d'entrée et de sortie.

Grâce à ses interfaces d'entrée, l’unité électronique de traitement est adaptée à recevoir différentes données d’entrée, qui proviennent de capteurs, de calculateurs tiers, ou d’entités tierces (autres véhicules, équipements routiers, téléphones de piétons, réseau…). Ces données d’entrée sont relatives au véhicule automobile (vitesse…) et à son environnement (position sur la route, cartographie…). La technologie V2X est en particulier employée à cet égard.

On notera que ces données d’entrée sont par exemple issues de messages de notification d’évènement décentralisé (plus connus sous l’acronyme anglais DENM pour « Decentralised Event Notification Message ») et de messages d’avertissement coopératif (plus connus sous l’acronyme anglais CAM pour « Cooperative Awareness Message ») émis par des véhicules tiers situés dans l’environnement du véhicule automobile 10.

Grâce à ses interfaces de sortie, l’unité électronique de traitement est adaptée à commander l’interface homme-machine afin de fournir au conducteur des informations. Elle est également adaptée à commander l’actionneur de direction assistée, l’actionneur de commande de moteur, et l’actionneur de freinage de façon à piloter le véhicule automobile 10 de façon autonome ou semi-autonome.

Grâce à ses mémoires, l’unité électronique de traitement mémorise une application informatique, constituée de programmes d’ordinateur (ou « logiciels ») comprenant des instructions dont l’exécution par les calculateurs permet la mise en œuvre du procédé décrit ci-après.

Dans la suite de cet exposé, on considérera que chaque « logiciel » permet de mettre en œuvre une « fonction » particulière.

Il est ainsi prévu des logiciels ADAS d’aide à la conduite du véhicule (régulation automatique de la vitesse du véhicule, maintien du véhicule au centre de sa voie…). Il est aussi prévu de logiciels IHM assurant l’affichage d’informations sur l’écran tactile et l’émission de messages sonores via les enceintes et un logiciel de navigation qui mémorise une cartographie d’une région et qui est en mesure notamment de déterminer la position du véhicule automobile 10 dans cette cartographie, de calculer le meilleur trajet à suivre pour atteindre une destination particulière, et de commander l’affichage de la position du véhicule et du trajet sur l’écran tactile.

Chacun de ces logiciels forme un « client ». Chaque client nécessite de recevoir une partie seulement des données d’entrée afin d’être en mesure d’exécuter la fonction pour laquelle il a été conçu.

Il est alors prévu une interface principale entre l’interface d’entrée qui reçoit les données d’entrée et ces clients.

Cette interface principale, également appelée fournisseur d’horizon artificiel, est alors programmée pour filtrer les données d’entrée de manière à générer un horizon artificiel représentatif de l’environnement du véhicule automobile 10, et pour émettre cet horizon artificiel sur le réseau du véhicule.

Le réseau du véhicule, sur lequel sont branchés les clients, est ici de type BUS CAN. Ainsi, l’interface principale peut émettre sur ce réseau des messages à intervalles réguliers, ici tous les 100ms.

Chaque client est alors en mesure de récupérer sur le réseau tout ou partie des informations contenues dans cet horizon artificiel.

Chaque client comporte pour cela un composant-logiciel appelé « reconstructeur » qui est en mesure de lire les informations requises pour que le client puisse assurer sa fonction.

On notera que l’horizon artificiel pourra être défini comme un ensemble de données informatiques permettant de caractériser une partie de l’environnement du véhicule (notamment les évènements dont la connaissance est utile pour piloter le véhicule automobile 10).

Le traitement exécuté par l’interface principale se divise en un pré-traitement générique qui filtre les données d’entrée de manière grossière et un post-traitement qui réalise un filtrage plus précis, en tenant compte de la topologie des rues où se trouvent les « évènements » pertinents (véhicules, objets, situations circonstancielles).

Ce filtrage permet d’offrir aux clients un horizon artificiel qui leur convient, c’est-à-dire des données qui décrivent suffisamment le véhicule et son environnement mais qui sont en nombre suffisamment restreint pour que la puissance de calcul des clients suffise à traiter ces données.

Pour cela, l’interface principale fonctionne conformément au protocole ADASIS, dans une version 2.0 ou ultérieure.

Ce protocole propose de représenter l’horizon artificiel par trajets (voir ).

Ainsi, compte tenu des différents embranchements de la route, l’interface principale est en mesure de déterminer tous les trajets que le véhicule est susceptible d’emprunter.

Il est prévu de distinguer un trajet principal 102 (par exemple celui qui suit la route empruntée initialement), et des trajets secondaires 101, 103, 104, 105 qui prennent naissance sur le trajet principal 102 ou sur d’autres trajets secondaires.

Il est en outre prévu de définir chaque trajet secondaire par un bout (qui indique la position de sa jonction avec le trajet principal ou secondaire où il prend naissance) et des attributs (qui caractérisent ce trajet).

Sur chaque trajet se trouvent des évènements dont les positions par rapport au bout sont définies par un écart.

Des évènements sont permanents (panneau, dos d’âne…), tandis que d’autres sont temporaires.

Parmi ces évènements temporaires, on peut distinguer les objet (véhicule…) et les situations circonstancielles (position de fin d’embouteillage, alerte…).

Le protocole ADASIS propose de ne considérer qu’un nombre limité de trajets (ici 56) se trouvant à l’avant du véhicule. Il propose en outre de ne considérer qu’une longueur limitée de chaque trajet, ici d’environ 8 km. Ces limitations permettent ne pas surcharger les calculateurs du véhicule. Ainsi, l’horizon artificiel présente une portée limitée.

Ce protocole est alors conçu de manière à ce que l’interface principale puisse envoyer sur le BUS CAN (à destination des clients) six types de messages. Ces types de messages sont les suivants :
- des messages de position relatifs à la position du véhicule 10,
- des messages de bout relatifs à la position du début du trajet concerné,
- des messages de segment caractérisant les attributs principaux d’une partie du trajet,
- des messages courts caractérisant les évènements sur le trajet qui peuvent être exprimés en 10 bits,
- des messages longs caractérisant les évènements sur le trajet qui peuvent être exprimés en 32 bits,
- des messages de métadonnées.

Dans le cadre de la présente invention, on s’intéressera uniquement aux messages longs.

Un tel message long est envoyé sur le BUS CAN lorsqu’un évènement pertinent pour la conduite du véhicule 10 est détecté sur l’un des trajets, dans une zone géographique considérée comme pertinente.

Un tel message comprend plusieurs données définies par le tableau suivant.

Champ	Longueur (en bits)	Intervalle de valeurs
Type de message	3	5
Compteur de cycle	2	0 à 3
Retransmission	1	0, 1
Index de trajet	6	8 à 63
Ecart	13	0 à 8190
Mise à jour	1	0, 1
Type de profile	5	1 à 31, 0
Point de contrôle	1	0, 1
Valeur	32	0 à 232-2, 232-1

Un message long est donc codé en 64 bits. On comprend sur ce tableau que les 3 premiers bits caractérisent le type de message, les deux suivants sont un compteur de cycle… Chaque message long comporte donc plusieurs parties.

Dans ce tableau, la colonne « champ » indique ainsi à quoi correspond chaque partie du message. La colonne « longueur » indique le nombre de bits que prend chaque partie dans le message. La colonne « intervalle de valeurs » indique les valeurs que chaque partie du message peut prendre.

L’élaboration d’un tel message est bien connue de l’Homme du métier, via le protocole ADASIS. Elle ne sera donc pas ici décrite en détail.

On pourra seulement préciser que le champ « type de message » présentera ici une valeur qui est toujours la même puisqu’on ne s’intéressera dans la suite qu’aux messages longs.

Le champ « index de trajet » présente une valeur qui permet d’identifier le trajet où l’évènement est localisé.

Le champ « écart » présente une valeur qui permet de localiser l’évènement sur le trajet.

Le champ « type de profile » permet de caractériser l’évènement par un type particulier. Ainsi, si sa valeur est égale à 1, l’évènement est une longitude, s’il est égal à 2, il s’agit d’une latitude, s’il est égal à 3, il s’agit d’une altitude, s’il est égal à 8, il s’agit d’un panneau de signalisation, s’il est égal à 9, il s’agit d’une limite de vitesse pour poids lourds. On notera que dans le protocole ADASIS, les valeurs 11 à 15 sont réservées pour des types standards, et que les valeurs 16 à 31 sont réservés pour des types spécifiques.

Le champ « valeur » permet quant à lui de stocker les données correspondant au type de profile (la valeur de la longitude, le type de panneau, la valeur de la limite de vitesse…).

En résumé, le champ « type de profile » indique à quoi la donnée stockée dans le champ « valeur » s’applique. Il désigne ainsi un type d’attribut caractérisant l’évènement (latitude, longitude, panneau, limite de vitesse).

Un « attribut » sera ici défini comme une caractéristique d’un évènement.

L’invention propose d’utiliser trois des valeurs 16 à 31 réservés pour des types spécifiques, afin de définir trois nouveaux types d’attributs, à savoir les attributs d’évènements temporaires statiques ou pseudo-statique, les attributs d’évènements temporaires dynamiques et les attributs d’évènements feux de circulation.

Un évènement statique est un évènement immobile.

Un évènement pseudo statique est un évènement qui bouge peu, compte tenu de sa vitesse et/ou de sa position par rapport au véhicule. Ainsi, un évènement dont la vitesse est inférieure à un seuil de vitesse (par exemple 5 km/h) ou dont la position est distante du véhicule au-delà d’un seuil de distance (par exemple 1000 mètres) est considéré comme pseudo statique.

On notera ici que chacun de ces seuils peut être fixe ou peut être une fonction de la vitesse du véhicule automobile 10 et/ou de la vitesse de l'événement et/ou de l'environnement. A titre d’exemple, les seuils pourront être plus ou moins grand selon le type d’environnement urbain, autoroutier ou rural dans lequel évolue le véhicule.

Un exemple d’évènement temporaire statique ou pseudo-statique est un véhicule à l’arrêt sur le trajet considéré, ou la fin d’une file d’attente dangereuse sur ce trajet.

Un évènement dynamique est défini par opposition aux évènements précités. Il s’agit par exemple d’un véhicule d’urgence en intervention.

Un attribut d’évènement feux de circulation permet de fournir par exemple la phase courante du feu de circulation (typiquement sa couleur) et le temps restant avant que cette phase change.

Ici, les événements temporaires dynamiques sont associés à la valeur 28.

En d’autres termes, lorsque le champ « type de profil » est égal à 28, cela signifie que le champ « valeur » va comporter une juxtaposition de plusieurs données caractérisant par différents aspects un évènement temporaire dynamique.

Le champ « valeur » de 32 bits est ainsi codé en plusieurs parties de 2 à 10 bits, qui sont définies dans le tableau suivant.

Champ	Longueur (en bits)	Intervalle de valeurs
Evènement dynamique compressé	5	0 à 31
ID	6	0 à 62, 63
Age	10
Voie	4	0 à 15
Direction	2	0 à 2
Valeur	5	0 à 30, 31

Le champ « évènement dynamique compressé » sera détaillé ci-après. Il permet de catégoriser l’évènement dynamique.

Le champ « ID » permet d’identifier l’évènement temporaire dynamique par un numéro compris entre 0 et 62. Le numéro 63 est réservé au cas où tous les autres numéros sont pris. L’interface principale libère ce numéro 63 dès que ce n’est plus le cas.

On pourra ici noter que si on atteint le nombre maximum d’évènements dynamiques (63), il sera possible de se contenter d’avertir le constructeur d’horizon qu’un trop-plein est survenu. En variante, il sera possible de comparer le nouvel évènement avec ceux déjà classés. Si le plus éloigné d’entre eux (par rapport au véhicule) est plus éloigné que le nouvel évènement, il sera possible de libérer son ID et de le remplacer par celui du nouvel évènement. Dans le cas contraire, le nouvel évènement ne sera pas pris en compte.

On notera ici qu’un évènement dynamique sera identifié deux fois, d’une part par ce champ « ID », mais aussi par le champ « index de trajet » utilisé dans la table 1.

Grâce à cette double identification, lorsque deux messages associés à un même évènement sont envoyés successivement (par exemple parce que la position et/ou la vitesse de cet évènement a changé), il sera implicite que le message le plus ancien est obsolète puisqu’il est remplacé par le nouveau message. De cette manière, il ne sera pas nécessaire d’envoyer un message d’annulation d’un évènement dynamique.

A titre d’exemple, un évènement dynamique tel qu’un véhicule d’intervention roulant pourra être codé dans l’horizon artificiel en envoyant successivement des messages longs mis à jour. Dans cette configuration, le reconstructeur de chaque client pourra comprendre que ces messages sont associés à un même véhicule en intervention, dont la vitesse et la position évoluent, sans qu’il ne soit nécessaire de lui envoyer pour cela des messages d’annulation des messages précédents.

Le champ « âge » correspond au temps passé depuis que l’évènement a été élaboré, à 10 ms près. Il couvre une durée de 10s. Pour bien comprendre à quoi ce champ réfère, il faut rappeler que dans ce mode de réalisation, un message est transmis toute les 100 ms sur le BUS CAN. Quant plusieurs évènements se produisent simultanément, plusieurs messages vont donc être élaborés et ces messages vont être transmis successivement les uns après les autres. Il peut donc arriver qu’un message soit transmis plusieurs centaines de millisecondes voire plusieurs secondes après avoir été élaboré. Dans cette éventualité, le champ « âge » va permettre d’indiquer depuis combien de temps le message a été élaboré.

Le champ « voie » indique la voie sur laquelle l’évènement s’applique. Ce champ s’applique aux voies de circulation du véhicule (celles que le véhicule peut emprunter compte tenu du sens selon lequel il circule). Ainsi, les évènements situés en dehors de ces voies sont associés à la valeur 0, les évènements situés dans la bande d’arrêt d’urgence sont associés à la valeur 1, et les évènements situés sur les voies de circulation sont associés à des valeurs comprises entre 2 et 14 (2 correspondant à la voie la plus à gauche, 3 à la voie immédiatement à côté…).

Le champ « direction » indique la direction selon laquelle l’évènement circule. Il prend la valeur 0 si l’évènement circule dans le même sens que le véhicule 10 et la valeur 1 sinon.

Le champ « valeur » est utilisé pour coder la vitesse de l’évènement. Il s’agit d’une valeur approximative. Chaque valeur correspond à un intervalle de vitesses, comme cela est défini dans le protocole ADASIS v2.0.4, à la table 12. A titre d’exemple, les valeur suivantes peuvent correspondre :
- « 1 » : une vitesse inférieure à 5 km/h,
- « 2 » : une vitesse comprise entre 5 et 7 km/h,
- « 2 » : une vitesse comprise entre 7 et 10 km/h,
- « 4 » : une vitesse comprise entre 10 et 15 km/h
- …
- « 28 » : une vitesse comprise entre 140 et 150 km/h,
- « 29 » : une vitesse supérieure à 150 km/h.

On notera que ce champ « valeur » peut prendra la valeur 31 dans un cas bien particulier. Lorsque ce champ prend la valeur 31, le message signifie que le message envoyé précédemment au sujet de ce même évènement (identifié par le champ ID) doit être effacé.

Le champ « évènement dynamique compressé » indique le type d’évènement dynamique auquel le message réfère.

On peut rappeler à ce sujet que l’ETSI, qui est l’organisme en charge des normes relatives à la technologie V2X, a déjà créé un tableau répertoriant les différents types d’évènements. Ce tableau distingue des grandes catégories (les causes) et des sous catégories (les sous-causes).

Ce tableau correspond aux quatre premiers champs du tableau suivant.

Description de la cause	Code cause	Description de la sous-cause	Code sous-cause	Code cause compressé
Travaux routiers	3	Entretien routier lent	3	1
		Nettoyage des rues	5
		Service d'hiver	6
Présence humaine sur la route	12	Indisponible	0	2
		Cycliste sur la chaussée	2
		Motocycliste sur la chaussée	3
Conduite à contresens	14	Non disponible	0	3
		Véhicule roulant dans la mauvaise voie	1
		Véhicule roulant dans le mauvais sens de marche	2
Travaux de sauvetage et de récupération en cours	15	Indisponible	0	4
		Véhicules d'urgence	1
		Sauvetage hélicoptère - atterrissage	2
		Police - activité en cours	3
		Urgence médicale en cours	4
		Enlèvement d'enfants en cours	5
Véhicule lent	26	Indisponible	0	5
		Entretien Véhicule	1
		Véhicules ralentissant pour regarder un accident	2
		Convoi exceptionnel lent	3
		Convoi exceptionnel large	4
		Convoi	5
		Chasse-neige	6
		Véhicule de dégivrage ou de salage	7
Véhicule d'urgence approchant	95	Indisponible	0	6
		Véhicule d'urgence en approche	1
		Véhicule prioritaire en approche	2
Risque de collision	97	Non disponible	0	7
		Risque de collision longitudinale	1	8
		Risque de collision aux passages à niveau	2	9
		Risque de collision latérale	3	10
		Risque de collision impliquant un usager vulnérable de la route	4	11
Violation du signal	98	Non disponible	0	12
		Violation d’un Stop	1
		Infraction aux feux de circulation	2
		Violation du règlement de virage	3
Situation dangereuse	99	Non disponible	0	13
		Feux de freinage électroniques d'urgence	1	14
		Système de pré-crash activé	2	15
		ESP (Electronic Stability Program) activé	3	15
		ABS (Système de freinage antiblocage) activé	4	15
		AEB (Freinage Automatique d'Urgence) activé	5	14
		Avertissement de freinage activé	6	14
		Alerte de risque de collision activée	7	14
Statut dynamique de l’objet		Non disponible		0

On notera sur ce tableau que chaque cause est définie par un premier code (seconde colonne) et chaque sous-cause est définie par un second code (quatrième colonne).

Cette classification prévoie de laisse libre de nombreux codes de cause (on passe ainsi directement de 3 à 12), si bien que stocker les valeurs de causes nécessite un grand nombre de bits (en l’occurrence, il en faudrait 7).

Ici, l’idée consiste à remplacer le code de la cause par un code cause compressé, indiqué par la dernière colonne du tableau ci-dessus. Ainsi, il est possible de coder le code cause compressé et le code sous cause en un nombre restreints de bits, ici en 5 bits. Ces deux codes sont alors stockés dans le champ « évènement dynamique compressé ».

Ici, les événements temporaires statiques ou pseudo-statiques sont associés à la valeur 29.

En d’autres termes, lorsque le champ « type de profil » est égal à 29, cela signifie que le champ « valeur » va comporter une juxtaposition de plusieurs données caractérisant par différents aspects un évènement temporaire statique ou pseudo-statique.

Le champ « valeur » de 32 bits est ainsi codé en plusieurs parties de 2 à 7 bits, qui sont définies dans le tableau suivant.

Champ	Longueur (en bits)	Intervalle de valeurs
Evènement compressé	5	0 à 31
Sous-Cause	4	0 à 15
ID	7	0 à 126, 127
Valeur	6	0 à 62, 63
Voie de départ	4	0, 1, 2 à 31
Voie d’arrivée	4	0, 1, 2 à 31
Confiance	2	0 à 3

Les champs « évènement compressé » et « sous-cause » seront détaillés ci-après. Ils permettent de catégoriser l’évènement statique ou pseudo-statique.

Le champ « ID » permet d’identifier l’évènement par un numéro compris entre 0 et 126. Le numéro 127 est réservé au cas où tous les autres numéros sont pris. Comme pour le même champ dans le cas d’un évènement dynamique, l’interface principale est programmée pour libérer ce numéro dès que ce n’est plus le cas et pour sélectionner les évènements les plus proches avant ceux qui sont les plus éloignés lorsque l’ensemble des numéros sont pris.

Ici encore, un évènement statique ou pseudo-statique sera identifié deux fois, d’une part par ce champ « ID », mais aussi par le champ « index de trajet » utilisé dans la table 1. Grâce à cette double identification, il deviendra implicite qu’un évènement statique s’annule et est remplacé par les informations contenues dans un nouveau message.

Le champ « valeur » est utilisé pour coder la longueur L de l’évènement. Il prend la valeur 0 si la longueur n’est pas connue. Il prend sinon une valeur comprise entre 1 et 62. Sa valeur dépend alors de la longueur de l’évènement. Sa valeur est ici codée de la manière suivante :
- si la longueur est comprise entre 0 et 100 m, sa valeur est égale à la valeur entière de L/4,
- si la longueur est comprise entre 100 et 500 m, sa valeur est égale à la valeur entière de (L - 100) / 16 + 25,
- si la longueur est comprise entre 500 et 1908 m, sa valeur est égale à la valeur entière de (L - 500) / 128 + 50,
- si la longueur est supérieure à 1098 m, sa valeur est égale à 62.

On notera que ce champ « valeur » peut prendra la valeur 63 dans un cas bien particulier. La valeur 63 indiquera que le message est relatif à un évènement statique qui doit être effacé, libérant ainsi l’identifiant du champ « ID » utilisé.

Le champ « voie de départ » indique la première voie sur laquelle l’évènement s’applique. Ce champ est codé de la même manière que le champ « voie » précité.

Le champ « voie d’arrivée » indique la dernière voie sur laquelle l’évènement s’applique. Ce champ est codé de la même manière que le champ « voie de départ ».

Le champ « confiance » indique le niveau de confiance dans la détection de l’évènement, la valeur 0 indiquant un niveau de confiance minimum et 3 indiquant un niveau de confiance maximum.

Le champ « évènement compressé » est codé sur 5 bits.

Pour définir ce champ, on peut noter que l’ETSI a déjà créé un tableau répertoriant les différents types d’évènements statiques qu’un véhicule peut rencontrer. Ce tableau distingue des grandes catégories (les causes) et des sous catégories (les sous-causes).

Si les sous-causes sont ici encore codés par des entiers naturels de valeurs réduites (ce qui nécessite peu de bits pour les coder), il n’en va pas de même pour les causes.

Ainsi, le champ « sous-cause » reprend les numéros affectés par l’ETSI sans les modifier, tandis que le champ « évènement compressé » prend des numéros différents de ceux affectés par l’ETSI.

Le tableau suivant permet d’indiquer la correspondance entre les numéros de l’ETSI et les numéros ici employés afin de le coder en un nombre réduit de bits.

Type	Code cause ETSI	Evènement compressé
Circulation	1	1
Accident	2	2
Travaux	3	3
Impraticabilité	5	4
Conditions météorologiques défavorables - état - adhérence	6	5
Aquaplaning	7	6
Emplacement dangereux - État de la surface	9	7
Emplacement dangereux - Obstacle sur la route	10	8
Emplacement dangereux - Animal sur la route	11	9
Présence humaine sur la route	12	10
Conduite dans le mauvais sens	14	11
Travaux de sauvetage et de récupération en cours	15	12
Conditions météorologiques - extrêmes	17	13
Conditions météorologiques - visibilité	18	14
Conditions météorologiques - précipitations	19	15
Véhicule lent	26	16
Fin de file dangereuse	27	17
Panne de véhicule	91	18
Suite d’accident	92	19
Problème humain	93	20
Véhicule à l'arrêt	94	21
Véhicule d'urgence en approche	95	22
Zone dangereuse : indication - Courbe dangereuse	96	23

A ce stade, on pourra noter qu’un évènement statique devienne dynamique ou vis-versa. Dans cette éventualité, un nouveau message long correspondant à la nouvelle catégorie de l’évènement sera envoyé sur le BUS CAN.

Les événements feux de circulation sont associés à la valeur 30.

En d’autres termes, lorsque le champ « type de profil » est égal à 30, cela signifie que le champ « valeur » va comporter une juxtaposition de données caractérisant l’état d’un feu de circulation.

On notera que si le feu de circulation est situé à un croisement, un message distinct peut être émis pour chaque direction dans le croisement, même si le même feu et la même phase sont valables pour aller tout droit et pour tourner à droite ou à gauche.

Le champ « valeur » de 32 bits est ainsi codé en plusieurs parties de 2 à 16 bits, qui sont définies dans le tableau suivant.

Champ	Longueur (en bits)	Intervalle de valeurs
Direction de feu tricolore	2	0 à 3
Phase actuelle	3	1 à 7
Phase suivante	3	1 à 7
Temps avant phase suivante	16	0 à 36000
Voie de départ	4	0, 1, 2 à 15
Voie d’arrivée	4	0, 1, 2 à 15

Le champ « Direction de feu tricolore » indique vers quelle voie de circulation l’évènement est associé. Il prend la valeur 0 s’il est associé à la direction initiale (tout droit), la valeur 1 pour tourner à gauche, la valeur 2 pour tourner à droite et la valeur 3 pour toutes les directions.

Le champ « phase actuelle » indique la phase courante du feu de circulation. Il prend la valeur 1 s’il est au vert, 2 s’il est au rouge, 3 s’il est orange, 4 s’il est entre le orange et le rouge, 5 s’il clignote en rouge, 6 s’il clignote en orange et 7 s’il est sombre.

Le champ « phase suivante » indique la prochaine phase du feu de circulation. Sa valeur est définie de la même manière que pour le champ phase actuelle.

Le champ « temps avant phase suivante » indique, en fonction du temps universel UTC, l'heure à laquelle la phase suivante interviendra.

Le champ « voie de départ » indique la première voie sur laquelle l’évènement s’applique. Ce champ est codé de la même manière que le champ « voie » précité.

Le champ « voie d’arrivée » indique la dernière voie sur laquelle l’évènement s’applique. Ce champ est codé de la même manière que le champ « voie de départ ».

Le champ « temps avant phase suivante » pourra plus précisément être codé de la manière suivante.

L’heure exacte extraite du système UTC ne peut pas être codée en 16 bits. L’idée est alors de faire en sorte que ce champ code l’heure UTC avec une précision de 100 ms seulement, modulo une heure.

Ici, ce champ prend la valeur 36001 dans le cas où la phase suivante est dans plus d'une heure (et la valeur 65535 en cas d'annulation des feux de circulation). Sinon, il prend une valeur comprise entre 0 et 36000. On notera que les valeurs 36002 à 65534 ne seront pas utilisés.

On peut alors donner l’exemple suivant.

S’il est 14h00 et que la phase suivante interviendra dans moins d’une heure, à 14h40mn52s300ms, alors le champ prendra la valeur : 40*60*10+52*10+3=24523 (soit 0x5FCB).

A ce stade, on pourra noter que les messages sont envoyés sur le réseau CAN BUS, ce qui permet au client d’acquérir une partie pertinente de l’horizon artificiel et d’assurer correctement la fonction pour laquelle il a été conçu.

De cette façon et à titre d’exemple non limitatif, le système de navigation pourra sélectionner un itinéraire qui évite au mieux les bouchons, le système d’aide à la conduite ADAS pourra réguler la vitesse du véhicule de façon à tenir compte des phases des feux et des plaques de verglas, et l’Interface Homme-Machine (IHM) pourra afficher sur le tableau de bord des alertes pour attirer l’attention du conducteur sur des dangers.

On pourra ici noter qu’une partie seulement des messages pourront être envoyés sur le réseau. Ainsi, un filtrage pourra être effectué afin d’envoyer uniquement les messages longs liés à des évènements situés à proximité du véhicule, par exemple à une portée de moins de 2 km de ce dernier.

Plus précisément ici, ce filtrage pourra consister à envoyer les messages longs correspondant à des évènements statiques qu’à condition que l’évènement se situe à une distance du véhicule 10 inférieure à un premier seuil, lequel premier seuil est inférieur à la portée sur laquelle le client reçoit des informations relatives à la cartographie.

Il pourra en outre consister à envoyer les messages longs correspondant à des évènements dynamiques qu’à condition que l’évènement se situe à une distance du véhicule 10 inférieure à un second seuil, lequel second seuil est inférieur au premier seuil.

Ce filtrage pourra en outre consister à ne transmettre que les messages longs associés à des évènements qui sont situés soit sur le trajet principal 102, soit sur des trajets secondaires mais à moins de 200m de leur embranchement avec le trajet principal 102.

La présente invention n’est nullement limitée au mode de réalisation décrit et représenté, mais l’homme du métier saura y apporter toute variante conforme à l’invention.

A titre d’exemple, on pourrait ne pas utiliser d’évènement feu de circulation. A contrario, on pourrait prévoir de distinguer un plus grand nombre de catégorie d’évènements temporaires (statiques proches, statiques éloignés, dynamiques proches, dynamiques éloignés…).

Claims (10)

1. Procédé d’élaboration d’un horizon artificiel pour un véhicule automobile (10), comprenant des étapes de :
   - réception de données d’entrée relatives au véhicule automobile (10) et à son environnement,
   - détermination de différents trajets (101 - 105) empruntables par le véhicule automobile (10), et
   - génération de messages caractérisant ledit horizon artificiel, dont au moins un message long associé à un évènement se trouvant sur l’un ou l’autre des trajets (101 - 105), chaque message long comportant plusieurs champs, dont au moins un premier champ relatif à un type d’attribut caractérisant l’évènement et un second champ indiquant la valeur de cet attribut,
   caractérisé en ce que le premier champ peut prendre au moins deux valeurs distinctes respectivement associées à un nombre correspondant de catégories prédéfinies d’évènements temporaires, lesdites catégories étant distinguées en fonction de la vitesse de l’évènement temporaire et/ou de la position de l’évènement temporaire relativement au véhicule automobile (10).
2. Procédé d’élaboration selon la revendication 1, dans lequel une catégorie d’événements correspond à des évènements dynamiques, une catégorie d’événements correspond à des évènements statiques ou pseudo-statiques vis-à-vis du véhicule automobile (10), et une catégorie d’évènement correspond à des feux de circulation.
3. Procédé d’élaboration selon la revendication 2, dans lequel un évènement est considéré comme dynamique lorsque sa vitesse est supérieure à un premier seuil et/ou lorsque sa distance au véhicule automobile (10) est supérieure à un second seuil.
4. Procédé d’élaboration selon la revendication 3, dans lequel le premier seuil et/ou le second seuil est une fonction de la vitesse du véhicule automobile (10) et/ou de la vitesse de l'événement et/ou de l'environnement.
5. Procédé d’élaboration selon l’une des revendications 2 à 4, dans lequel, lorsque la vitesse et/ou la distance au véhicule automobile (100) d’un évènement varie dans le temps, la valeur du premier champ peut changer.
6. Procédé d’élaboration selon l’une des revendications 2 à 5, dans lequel l’un au moins de évènements suivants est considéré comme dynamique :
   - un véhicule d'urgence en intervention,
   - un véhicule dont un système de freinage d'urgence est activé,
   - un véhicule dont un système de retenue réversible des occupants est activé,
   - une personne ou un animal sur le trajet,
   - des travaux routiers mobiles sur le trajet,
   - un véhicule roulant à contresens,
   - des travaux mobiles de sauvetage et de récupération en cours,
   - un véhicule au moins un tiers plus lent que la vitesse maximum autorisée,
   - un véhicule générant un risque de collision,
   - un véhicule violant le code de la route,
   - une situation dangereuse.
7. Procédé d’élaboration selon l’une des revendications 2 à 6, dans lequel l’un au moins de évènements suivants est considéré comme statique :
   - un accident,
   - des travaux routiers,
   - une portion de trajet impraticable,
   - des conditions météorologiques défavorables,
   - une zone d’aquaplaning,
   - une zone dangereuse,
   - une zone de travaux de sauvetage et de récupération en cours,
   - un véhicule à l’arrêt,
   - une fin de file d’embouteillage dangereuse.
8. Procédé d’élaboration selon l’une des revendications 1 à 7, dans lequel chaque message long associé à une catégorie d’évènement temporaire comporte deux champs permettant d’identifier de deux façons distinctes chaque évènement.
9. Procédé d’élaboration selon l’une des revendications 1 à 8, dans lequel les données d’entrée sont au moins en partie issues d’un message de notification d’évènement décentralisé (DENM) et/ou d’un message d’avertissement coopératif (CAM) émis par un véhicule tiers.
10. Véhicule automobile (10) comprenant des clients logiciels parmi lesquels une interface homme-machine et/ou un système de navigation et/ou des systèmes d’aide à la conduite, caractérisé en ce qu’il comporte une interface principale qui est programmée pour mettre en œuvre un procédé d’élaboration conforme à l’une des revendications précédentes, afin de fournir à chaque client une partie au moins de l’horizon artificiel élaboré.