FR 3132588 A1 20230811 FR 2201036 A 20220207 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 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. 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). 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. 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. 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. 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. 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. 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. 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. 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. 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é.