FR2985837A1

FR2985837A1 - Dispositif d'aide a la conduite ameliore

Info

Publication number: FR2985837A1
Application number: FR1200109A
Authority: FR
Inventors: Frans Bocquillon; Francois Doffiny
Original assignee: WIKANGO
Current assignee: WIKANGO
Priority date: 2012-01-13
Filing date: 2012-01-13
Publication date: 2013-07-19
Anticipated expiration: 2032-01-13
Also published as: FR2985837B1

Abstract

Un dispositif d'aide à la conduite comprend une mémoire capable de stocker des données d'alerte, un module de géolocalisation (42), ainsi qu'une interface utilisateur (44) pour communiquer des informations d'alerte tirées des données d'alerte à un utilisateur, Les données d'alerte comprennent des jeux de données d'alerte associant au moins un identifiant d'alerte, des données de géolocalisation, et des données de sélectivité. Le dispositif comprenant en outre un sélecteur capable de produire un ensemble local de jeux de données d'alerte, choisis en fonction de leurs données de géolocalisation associées et de données de géolocalisation courantes, un réducteur agencé pour produire un ensemble réduit de jeux de données d'alerte à partir de l'ensemble local, en fonction d'une règle faisant intervenir un état d'alerte courant du dispositif et au moins les données de sélectivité des jeux de données d'alerte de l'ensemble local, un convertisseur agencé pour générer des données de détection à partir de l'ensemble réduit de jeux de données d'alerte produit par le réducteur, en fonction d'une règle faisant intervenir au moins l'identifiant d'alerte et les données de géolocalisation des jeux de données d'alerte de l'ensemble réduit, et un détecteur agencé pour commander une interface utilisateur en fonction de données tirées d'une comparaison entre des données de géolocalisation courantes et certaines au moins des données de détection.

Description

Dispositif d'aide à la conduite amélioré L'invention concerne les dispositifs d'aide à la conduite.

Depuis quelques années, des dispositifs électroniques ont été développés pour faciliter la conduite. Ces dispositifs reposent sur la géolocalisation par satellite pour calculer et indiquer un itinéraire ou pour assister le conducteur le long de sa route, ainsi que sur les échanges avec un serveur pour recevoir des informations locales à courte durée de validité le long de cet itinéraire.

Ces dispositifs prévoient notamment l'indication d'éléments spécifiques le long de la route, comme des travaux, des dispositifs de contrôle de vitesse, ou des accidents. L'évolution des législations dans certains pays a imposé ou imposera dans un futur proche que ces éléments spécifiques soient présentés sous la forme de « zones dangereuses » qui ne sont plus géolocalisées précisément, mais qui s'étendent sur des distances dépendant de l'axe routier sur lequel circule le véhicule contenant le dispositif. Cette nouvelle législation, bien que mise en oeuvre dans un but d'amélioration de la conduite, a pour conséquence une détérioration de la qualité des informations transmises aux conducteurs.

L'invention vient améliorer la situation. À cet effet, l'invention propose un dispositif d'aide à la conduite, comprenant une mémoire capable de stocker des données d'alerte, un module de géolocalisation, ainsi qu'une interface utilisateur pour communiquer des informations d'alerte tirées des données d'alerte à un utilisateur. Dans ce dispositif, les données d'alerte comprennent des jeux de données d'alerte associant au moins un identifiant d'alerte, des données de géolocalisation, et des données de sélectivité. Ce dispositif comprend en outre : un sélecteur capable de produire un ensemble local de jeux de données d'alerte, choisis en fonction de leurs données de géolocalisation associées et de données de géolocalisation courantes, - un réducteur agencé pour produire un ensemble réduit de jeux de données d'alerte à partir de l'ensemble local, en fonction d'une règle faisant intervenir un état d'alerte courant du dispositif et au moins les données de sélectivité des jeux de données d' alerte de l'ensemble local, - un convertisseur agencé pour générer des données de détection à partir de l'ensemble réduit de jeux de données d'alerte produit par le réducteur, en fonction d'une règle faisant intervenir au moins l'identifiant d'alerte des jeux de données d'alerte de l'ensemble réduit, et - un détecteur agencé pour commander une interface utilisateur en fonction de données tirées d'une comparaison entre des données de géolocalisation courantes et certaines au moins des données de détection. D'autres caractéristiques et avantages de l'invention apparaîtront mieux à la lecture de la description qui suit, tirée d'exemples donnés à titre illustratif et non limitatif, tirés des dessins sur lesquels : - la figure 1 un schéma général d'un système électronique d'aide à la conduite comprenant un dispositif d'aide à la conduite selon l'invention, - la figure 2 représente un diagramme schématique du dispositif de la figure 1, les figures 3 à 7 représentent des diagrammes de flux montrant un exemple de fonctionnement du dispositif de la figure 2, et - les figures 8 à 10 représentent des diagrammes de flux montrant un exemple de fonctionnement en variante du dispositif de la figure 2. Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant. La présente description est de nature à faire intervenir des éléments susceptibles de protection par le droit d' auteur et/ou le copyright. Le titulaire des droits n'a pas d'objection à la reproduction à l'identique par quiconque du présent document de brevet ou de sa description, telle qu'elle apparaît dans les dossiers officiels. Pour le reste, il réserve intégralement ses droits.

La figure 1 représente un dispositif d'aide à la conduite selon l'invention dans son environnement de fonctionnement. Dans le mode de réalisation représenté en figure 1, le système d'aide à la conduite comprend un serveur 2 et un dispositif d'aide à la conduite 4 selon l'invention. Le serveur 2 comprend des moyens de communication 20, un processeur 22, et une base de données 24. Le processeur 22 contrôle les moyens de communication 20 et peut accéder à la base de données 24. Selon les modes de réalisation, le processeur 22 peut comprendre plusieurs coeurs, il peut y avoir plusieurs processeurs 22 (virtuels ou non).

La base de données 24 comprend des données d'aide à la conduite et des données de profil. Le dispositif 4 comprend des moyens de communication 40, des moyens de géolocalisation 42, une interface utilisateur 44, ces éléments étant ensembles commandés par un processeur 46.

Le dispositif 4 est mobile. Il est en particulier destiné à être disposé dans un véhicule, par exemple sur le tableau de bord ou sur le pare-brise. Sa fixation dans le véhicule peut être prévue amovible grâce à des moyens de fixation connus en eux-mêmes, par exemple une ventouse apte à adhérer à la surface intérieure du pare-brise, une pince adaptée pour s'accrocher à une grille de ventilation, des bandes auto-agrippantes pour une fixation sur un guidon, etc. Le dispositif 4 peut ainsi être déplacé et utilisé dans plusieurs véhicules. Dans d'autres modes de réalisation non représentés, le dispositif 4 peut également être prévu solidaire d'un véhicule et/ou être intégré à un ordinateur de bord du véhicule. Dans ces modes de réalisation, le dispositif 4 est mobile dans le sens où il peut être déplacé avec le véhicule. Le dispositif 4 peut être alimenté par l'intermédiaire d'une connectique adaptée aux véhicules, par exemple une prise du type « allume-cigare ». Le dispositif 4 peut également être alimenté en énergie de manière indépendante, par exemple au moyen d'une batterie propre. Par souci de clarté, l'alimentation électrique du dispositif 4 n'est pas représentée sur les figures. Les moyens de communication 40 sont dans l'exemple décrit ici des moyens de téléphonie sans fil, c'est-à-dire compatibles GSM, GPRS, EDGE, 3G ou LTE. D'autres moyens pourront être envisagés. Les moyens de géolocalisation 42 sont dans l'exemple décrit ici des récepteurs GPS. En variante, les moyens de géolocalisation 42 peuvent être déportés et reliés au dispositif 4 par une liaison filaire ou sans fil (Bluetooth par exemple). Pour des raisons de clarté, seuls trois satellites 6 ont été représentés sur les figures, bien que la technologie GPS préconise généralement l'utilisation de quatre satellites ou plus. L'antenne peut être disposée dans un boîtier du dispositif 4 ou être déportée. Le fonctionnement de la géolocalisation par satellite, par exemple via GPS, est connu en lui-même. D'autres moyens de géolocalisation pourront être envisagés, par exemple à partir de la triangulation par rapport aux antennes relais d'un réseau téléphonique. L'interface utilisateur 44 peut comprendre un écran d'affichage, un avertisseur sonore, par exemple un haut-parleur, et des boutons. L'écran d'affichage peut également être un écran tactile, ce qui lui permet alors de remplir à la fois la fonction d'affichage et la fonction de moyen d'entrée pour l'utilisateur. Les boutons peuvent donc être des boutons physiques, c'est-à-dire à actionnement mécanique, ou virtuels, lorsque l'écran est tactile. Lorsqu'un conducteur utilise un dispositif pour le guider en temps réel tout en conduisant un véhicule, fonctionnement qui sera dans ce qui suit qualifié de « mode assistance », le dispositif 4 traite les signaux reçus des satellites 6 pour en tirer des données de géolocalisation. Ces données de géolocalisation sont alors comparées aux données contenues dans des cartes stockées sur le dispositif 4. Celui-ci calcule alors un itinéraire pour relier un point de départ, tiré des données de géolocalisation, et un point d'arrivé, préalablement entré par l'utilisateur. Cet itinéraire peut être optimisé selon divers paramètres définis par l'utilisateur, comme le souhait d'éviter les péages ou les grands axes. En variante, le dispositif ne calcule pas d'itinéraire, et alerte seulement à l'utilisateur lorsqu'il s'approche de lieux particuliers. Le dispositif 4 transmet alors des informations au conducteur via l'interface 44, généralement sous forme d'instructions visuelles sur l'écran et/ou d'instructions vocales par le haut-parleur.

Le dispositif comprend une mémoire de masse (représentée sur la figure 2), qui contient des données de cartographie et de points d'intérêt. Les données de cartographies permettent au processeur 46 de calculer un itinéraire entre une position indiquée par les données de géolocalisation déterminées par les moyens de géolocalisation 42 et une destination définie par d'autres données de géolocalisation. Les données de points d'intérêt permettent à un utilisateur de choisir une destination sans avoir à entrer une adresse particulière. Lors de la conduite, les points d'intérêts situés le long du trajet peuvent également être affichés et/ou indiqués, ce qui conforte le conducteur. En variante, les données de cartographie peuvent être utilisées pour accélérer la mise à jour des données transmises par le serveur 2 et/ou être utilisées pour optimiser la communication avec celui-ci, par exemple en adaptant la communication en fonction de celles-ci. En variante, le dispositif ne contient que des données de type point d'intérêt, et pas de données de cartographie. Dans ce cas, tout élément de nature cartographique est obtenu du serveur lors des échanges avec celui-ci.

En plus de sa capacité de géolocalisation, le dispositif 4 peut recevoir, via les moyens de communication 40, des informations supplémentaires envoyées par le serveur 2. Afin d'obtenir des informations pertinentes compte tenu de sa situation, le dispositif 4 communique ses données de géolocalisation au serveur 2. Le serveur 2 transmet alors en réponse des informations relatives à une zone qui inclut la position désignée par les données de géolocalisation transmises par le dispositif 4. Ces informations peuvent être particulièrement utiles et présentent généralement une durée de validité courte, comme lorsqu'il s'agit d'informations d'embouteillages par exemple. Le type d'informations envoyées par le serveur 2 peut être choisi par défaut, ou être sélectionné par l'utilisateur, par exemple au moyen de l'interface utilisateur 44.

Le dispositif 4 peut également émettre des informations du même type vers le serveur 2, pour leur partage avec d'autres dispositifs. Pour cela, lorsque le serveur 2 reçoit des données de géolocalisation d'un dispositif couplées avec des données d'informations à partager, le processeur 22 du serveur 2 sélectionne des dispositifs situés à proximité de de la position indiquée par les données de géolocalisation, et leur transmet les informations associées.

Par « situés à proximité » on entend de manière générale « dont la position actuelle, la direction, le sens de déplacement et/ou l'itinéraire choisi permettent de considérer que ce dispositif va, dans un futur proche, être dans une zone proche de la position indiquée par les données de géolocalisation ». Par futur proche, on entend ici une durée limitée prédéfinie. Comme mentionné plus haut, ces données sont en général à durée de validité courte. Il n'y a donc pas lieu de stocker ces données de manière prolongée dans le dispositif 4. Ces données peuvent donc être stockées dans la mémoire vive du dispositif 4, et être effacées peu de temps après. Par exemple, ces informations à durée de validité courte peuvent concerner la présence d'un obstacle sur la chaussée, un accident, un trafic perturbé, une voie neutralisée, une déviation, des travaux, un contrôle routier ou radar, etc. Le serveur 2 étant connecté à plusieurs dispositifs similaires au dispositif 4, ces informations peuvent être centralisées, recoupées, confirmées, échangées, interprétées et/ou stockées. Ces informations supplémentaires sont dans ce qui suit appelées données d'aide à la conduite. L'actualisation des données d'aide à la conduite et leur envoi aux dispositifs situés à proximité de la position indiquée par les données de géolocalisation peuvent être déclenchés automatiquement par le serveur 2, ou être demandés par chaque dispositif concerné, automatiquement ou en réponse à une entrée utilisateur. Typiquement, l'état du trafic sur une voie donnée est déterminé automatiquement par le processeur 22, en détectant que la vitesse moyenne des dispositifs sur cette voie est faible par rapport à une vitesse autorisée. Inversement, la détection d'un obstacle sur la chaussée peut difficilement être automatisée, et l'utilisateur doit effectuer une action avec le dispositif 4 pour le déclarer. Par action, on entend par exemple la pression d'un bouton, que ce bouton soit physique ou virtuel par exemple sur un écran tactile. La mémoire du dispositif reçoit donc des informations à durée de validité courte, mises à jour grâce aux données envoyées par les autres dispositifs, en plus des informations « statiques » comme la voirie, les limitations de vitesse, les sens de circulation autorisés, les installations de contrôle routiers ou radar fixes etc. Les données concernant les informations statiques, ci-après données statiques, sont stockées dans la mémoire de masse des dispositifs 4 eux-mêmes. La mise à jour de ces informations est régulière, mais présente une fréquence plus faible que celle des informations à durée de validité courte. Ces données n'ont en effet pas de raison d'être modifiées à des fréquences importantes. Par exemple on peut estimer qu'une actualisation de ce type de données plus d'une fois par jour présente un intérêt négligeable. Il est néanmoins souhaitable que la mise à jour des données statiques ne nécessite pas d'action spécifique de la part de l'utilisateur. En particulier, il est préférable que cette mise à jour puisse être réalisée sans contrainte. Il est aussi préférable que cette mise à jour soit réalisée automatiquement et de manière « transparente », c'est-à-dire sans qu'elle empêche le fonctionnement normal du dispositif, par exemple le mode assistance. Selon un autre mode de réalisation, le dispositif 4 est réalisé par l'exécution d'une application d'aide à la conduite sur un téléphone portable. Par téléphone portable, on entend ici tout téléphone disposant des éléments utiles au fonctionnement de l'application, et en particulier des moyens de géolocalisation par GPS, des moyens de communication et une interface utilisateur compatible avec la pratique de la conduite.

Actuellement, la plupart des téléphones mobiles appelés « Smartphones » ou « téléphones intelligents » remplissent ces besoins. Ainsi, un utilisateur souhaitant utiliser un système d'aide à la conduite selon l'invention, disposant d'un véhicule et d'un Smartphone peut utiliser son téléphone comme dispositif 4 en exécutant cette application. Cela présente l'avantage de ne pas nécessiter l'acquisition d'un boîtier physique distinct. L'acquisition de l'application peut être réalisée par achat à distance par l'intermédiaire d'une plateforme d'achat, comme cela est bien connu des utilisateurs de Smartphones. Comme cela a été mentionné en introduction, certaines législations imposent maintenant certaines limitations quant à la présentation des informations aux utilisateurs des dispositifs 4. Notamment, ces nouvelles législations imposent qu'il ne soit plus fait référence à des éléments déterminés, comme un radar fixe ou un radar mobile, mais qu'il soit fait référence d'une manière générale à des zones dangereuses. Les zones dangereuses doivent être signalisées, non plus sous la forme d'un emplacement spécifique avec une alerte déclenchée quelques centaines de mètres ou quelques kilomètres avant, mais sous la forme d'une plage beaucoup plus large, l'élément d'intérêt n'étant pas spécifiquement indiqué dans cette plage. Cela a pour conséquence que les dispositifs d'aide à la conduite perdent beaucoup en richesse et en précision d'informations transmises aux utilisateurs, au profit d'une 20 harmonisation vraisemblable de la conduite, puisque les plages d'avertissement sont beaucoup plus larges que précédemment. Cela a également pour conséquence que de nombreuses « fausses alertes » risquent d'être déclenchées. En effet, jusqu'à ce jour, les alertes étaient déclenchées par l'entrée 25 dans une « boîte » qui était définie par deux extrémités, dont l'une était formée par l'élément d'intérêt, et l'autre était obtenue par la distance à partir de laquelle il était souhaité que l'utilisateur soit averti. Ces deux extrémités formaient les milieux des deux côtés opposés d'un rectangle dont la largeur était générique. 30 Avec les nouvelles législations, comme la distance a beaucoup augmenté par rapport aux distances classiquement utilisées, et comme l'élément d'intérêt ne peut plus être l'une des extrémités, la solution de la « boîte » dont la longueur serait celle prescrite par la législation ne fonctionne pour ainsi dire plus. En effet, si l'on prend l'exemple d'une autoroute, la distance légale est de plusieurs kilomètres. Dès lors, si l'on considère une boîte de plusieurs kilomètres et de la largeur d'une autoroute, on comprend rapidement que les alertes liées à cette autoroute vont être déclarées sur toutes les routes adjacentes dès que l'autoroute ne sera pas strictement droite. D'ailleurs, afin de respecter l'obligation légale, il sera même vraisemblablement nécessaire d'augmenter la distance d'alerte, ou d'augmenter de manière importante la largeur de la boîte afin d'être sûr que toute l'autoroute est bien couverte. Et cela empirera encore la situation.

Pour finir, dans la mesure où l'alerte doit être donnée pour une zone qui va au-delà de l'élément d'intérêt, tout conducteur qui s'introduira à une distance relativement proche d'une alerte, au-delà du point d'intérêt risque d'être alerté inutilement, ce qui est généralement connu sous l'expression « faux positif » ou « fausse alerte ». Cela peut avoir des conséquences très néfastes sur le trafic et pour la sécurité routière en général.

Dans ce qui suit, il sera fait référence à un « point d'intérêt » pour désigner un jeu de données d'alertes associées à un identifiant d'alerte donné. Pour chaque identifiant d'alerte donné, il existe un ou plusieurs jeux de données d'alerte ou points d'intérêts, qui présentent chacun des données de géolocalisation différentes.

Afin de répondre à tous ces problèmes, la Demanderesse a modifié le dispositif 4 et a notamment enrichi les données liées aux alertes. Ainsi, la Demanderesse a élaboré le dispositif 4 représenté schématiquement sur la figure 2.

Comme on peut le voir sur cette figure, le dispositif 4 comporte, en plus des moyens de communication 40 (non représentés sur cette figure), des moyens de géolocalisation 42 de l'interface 44 et du processeur 46 (non représenté sur cette figure), une mémoire 41, un sélecteur 43, un réducteur 45, un convertisseur 47, et un détecteur 49.

Dans l'exemple décrit ici, le sélecteur 43, le réducteur 45, le convertisseur 47, et le détecteur 49 sont des fonctions et/ou des programmes indépendants mis en oeuvre par le processeur 46. En variante, ces éléments pourront être mis en oeuvre sous forme matérielle et/ou partiellement logicielle, sous commande du processeur 46. Avant de décrire le fonctionnement de chacun du sélecteur 43, du réducteur 45, du convertisseur 47, et du détecteur 49, le nouveau paradigme proposé par la Demanderesse va être décrit. Comme cela a été décrit plus haut, le paradigme des dispositifs existants reposait sur la définition d'un point d'intérêt caractérisé par des données de géolocalisation, par une distance d'alerte, et éventuellement par d'autres données permettant d'améliorer la détection, comme des données angulaires (pour comparer le cap du véhicule à celui supposé de la route), ainsi que d'autres éventuelles données d'ordre « esthétique », comme un lien d'image ou de son d'alerte, etc.

Après avoir réalisé que ce paradigme est incompatible avec les nouvelles législations, la Demanderesse a découvert qu'il est insuffisant de considérer une zone dangereuse comme un seul point lié à une distance définissant ensemble une boîte, et qu'il faut enrichir la définition des zones dangereuses.

Pour cela, la Demanderesse a redéfini la notion de zone dangereuse comme un ensemble de points d'intérêt. Dans l'exemple décrit ici, chaque point d'intérêt est un ensemble de données d'alerte associant : un identifiant d'alerte, des données de sélectivité, des données de géolocalisation, des données de séquence, des données de largeur, et des données de vitesse.

Selon les diverses variantes, certaines de ces données pourraient être omises. Dans le cas minimal, il serait possible de limiter les données d' alerte associées à chaque point d'intérêt aux trois premières données indiquées, c'est-à-dire l'identifiant d'alerte, les données de sélectivité et les données de géolocalisation. L'identifiant d'alerte est un identifiant unique qui permet de regrouper les données d'alerte liées à une alerte donnée. Dans l'exemple décrit ici, l'identifiant d'alerte est un entier naturel à six chiffres, ce qui permet de définir environ un million d'alertes distinctes. Bien sûr il est possible d'utiliser plus de chiffres. Les données de sélectivité sont des données qui sont utilisées par le réducteur 45 pour réduire le nombre de points pris en compte à chaque instant. Dans l'exemple décrit ici, les données de sélectivité sont de trois natures : avant, lieu, et après. Ainsi, un point d'intérêt qui a des données de sélectivité de type « avant » est situé en amont du lieu exact de l'alerte à laquelle est associé ce point d'intérêt, compte tenu du sens de la voirie. C'est l'opposé pour les données de sélectivité de type « après », et c'est le lieu exact pour les données de sélectivité de type « lieu ». Les données de sélectivité peuvent être spécifiées par une chaîne de caractère telle que « avant », « lieu », et « après », ou « IN », « TGT », et « OUT », ou être des valeurs comme « 0 » pour avant, « 1 » pour lieu, et « 2 » pour après, ou toute autre variante. L'utilité de ces données sera explicitée avec la figure 5.

Les données de géolocalisation représentent une latitude et une longitude pour le point d'intérêt dans un système de coordonnées fixé. Dans l'exemple décrit ici, ces données sont codées sur deux champs dont l'un indique la latitude et l'autre la longitude, à cinq chiffres après la virgule, dans le système de coordonnées utilisé avec le GPS. En variante, tout autre type de référentiel peut être utilisé, et les données de géolocalisation peuvent être concaténées en un seul champ ou au contraire éclatées sur plusieurs champs. Les données de séquence sont des données utilisées par le convertisseur 47 pour réduire encore la quantité de points d'intérêt traités. En effet, comme on le verra avec la figure 6, les données de séquence permettent d'éviter d'avoir à déterminer le cap du véhicule.

Les données de largeur permettent de personnaliser les alertes liées à chaque point d'intérêt. En effet, comme cela apparaît, le fait d'utiliser plusieurs points d'intérêt pour une alerte donnée permet de définir une pluralité de boîtes qui se suivent et sont chacune définie par deux points d'intérêts ayant des données de séquence successives.

Les données de largeur permettent de définir pour chaque point d'intérêt la largeur de la boîte qu'il définit avec le point qui le précède. Ainsi, il est possible d'offrir une précision et une fiabilité maximale. En effet, si plusieurs voies sont rapprochées dans une zone donnée, alors les données de largeur pourront être réduites afin de limiter les risques de fausse alerte. Inversement, ces données pourront être augmentées en cas de faible densité de voirie. De plus, ces données permettent d'adapter la largeur à la largeur réelle de la voirie là où est situé le point d'intérêt. Par exemple, il devient possible de définir une largeur très importante au niveau des gares de péage, ce qui permet d'éviter de perdre une alerte.

Enfin, les données de vitesse permettent de personnaliser la vitesse autorisée sur un segment d'alerte donné. En effet, les nouvelles législations peuvent engendrer des complications de ce point de vue. Prenons l'exemple d'une route sur laquelle la vitesse est d'abord limitée à 130 km/h sur une première partie, puis à 110 km/h sur une deuxième partie, puis à nouveau à 130 km/h sur une troisième partie dans laquelle est situé un radar fixe faisant l'objet de l'alerte, et enfin à 90 km/h sur une quatrième partie située après le radar fixe, ces quatre parties formant une alerte selon la législation. Quelle limitation de vitesse le dispositif 4 doit-il déclarer au conducteur ? En effet, si c'est la vitesse au niveau du radar, alors le conducteur pourra croire à tort qu'il peut rouler à 130 km/h dans les deuxième et quatrième parties. Inversement, si c'est la vitesse la plus basse, alors tout un contingent d'automobilistes risquent de rouler très en dessous de la vitesse autorisée, ce qui est néfaste pour la circulation. La spécification de données de vitesse pour chaque point d'intérêt permet de contourner ce problème. La figure 3 représente un diagramme schématique de fonctionnement du dispositif 4. 30 Comme on peut le voir sur cette figure, le dispositif 4 fonctionne selon une boucle. Dans l'exemple décrit ici, cette boucle est synchronisée avec la boucle de géolocalisation GPS, et dure sensiblement une seconde dans l'exemple décrit ici. Il existe également des boucles plus rapides, par exemple le GPS 5 Hz. Dans ce cas, la solution proposée par la Demanderesse est encore plus intéressante car les besoins en efficacité sont augmentés.

Dans une opération 300, la boucle commence avec la détermination des points d'intérêts pertinents compte tenu de la localisation du dispositif 4. En effet, il n'est pas utile de comparer la position du véhicule avec la totalité des données d'alerte existantes. En fait, compte tenu des nouvelles législations, il suffit de sélectionner l'ensemble des points d'intérêt qui sont situés autour du véhicule, à une distance compatible avec la législation. Cela est réalisé par l'appel du sélecteur 43. La figure 4 représente un exemple de mise en oeuvre du sélecteur 43. Comme on peut le voir sur cette figure, le sélecteur 43 commence par appeler la mémoire du dispositif 4 pour déterminer les données de géolocalisation courantes dans une opération 400. En variante, cet appel peut être fait directement auprès des moyens de géolocalisation 42, ou encore ce sont les moyens de géolocalisation 42 qui peuvent appeler le sélecteur 43 avec les données de géolocalisation courantes, une fois celles-ci déterminées. Ensuite, dans une opération 410, le sélecteur 43 détermine les points d'intérêts qui sont situés aux environs des données de géolocalisation courantes. Dans l'exemple décrit ici, cela est réalisé par l'appel d'une fonction Select() qui reçoit les données de géolocalisation courantes Curr_Loc comme argument. La fonction Select() opère en sélectionnant les données d'alerte dont les données de géolocalisation sont situées à l'intérieur d'un carré dont le centre est la position désignée par les données de géolocalisation courantes Curr_Loc. Ce carré peut par exemple avoir une dimension d'environ 4 km fois 4 km. Dans l'exemple décrit ici, cette sélection est optimisée grâce à un ordonnancement spécifique des données d'alerte. En effet, on a vu plus haut que la durée de la boucle est d'une seconde. Il faut donc que toutes les opérations soient réalisées dans un temps inférieur à cette durée. Or la multiplication de fonctions de recherche qui accèdent beaucoup à la mémoire du dispositif 4 pour sélectionner les données pourrait consommer une partie très importante du temps disponible, juste en temps d'accès. Pour éviter cela, la Demanderesse utilise une mémoire 41 à accès très rapide. En variante, la Demanderesse a également découvert qu'il peut être bénéfique d'ordonner les données d'alerte dans la mémoire du dispositif en fonction de leurs données de géolocalisation. Simultanément, la fonction Select() ne sélectionne pas les points d'intérêt par calcul de distance, mais par différence entre leur latitude et leur longitude avec la latitude et la longitude des données de géolocalisation courantes Curr_Loc.

Dans ces deux cas, c'est la comparaison par différence de latitude et de longitude qui explique la sélection des points d'intérêt dans un carré centré sur la position courante, ce qui est plus simple que de calculer une distance. De plus, le fait de ranger de manière ordonnée les données d'alerte élimine la nécessité de tester systématiquement tous les points d'intérêts, et il est possible de réaliser une lecture qui sélectionne quasi directement la plage de points pertinents. En variante, il serait possible de sélectionner les points d'intérêt non pas dans un carré, mais dans un cercle ou une autre forme, et d'opérer différemment pour sélectionner les points d'intérêts inclus dans ce cercle.

Dans encore une autre variante, les points d'intérêts peuvent être regroupés par appartenance à une zone géographique donnée sur la base de leurs données de géolocalisation, par exemple par zones de 4 km par 4 km de côté, et le sélecteur peut agir par détermination d'une ou plusieurs zones correspondant à des données de géolocalisation courantes, et par sélection des points d'intérêt associés à ces zones.

Les données d'alerte sélectionnées par le sélecteur 43 seront désignées par la suite par le terme « ensemble local ». L'ensemble local contient donc toutes les données d'alertes dont les données de géolocalisation sont situées à proximité de la position désignée par les données de géolocalisation courantes.

Une fois l'ensemble local déterminé, la boucle se poursuit avec une opération 310. En effet, l'ensemble local comprend de nombreux points d'intérêt qu'il est possible d'éliminer. L'élimination de ces points d'intérêt est importante, car elle permet là encore de limiter les appels mémoires et les calculs inutiles, afin de préserver la fenêtre d'une seconde. Cette élimination est réalisée par le réducteur 45, dont la figure 5 représente un exemple de fonctionnement.

Comme on peut le voir sur la figure 5, le réducteur 45 commence par recevoir l'ensemble local ChosSet[], et initialise un compteur i avec la valeur 0 dans une opération 500.

Le réducteur 45 effectue alors une boucle dans laquelle chacun des points d'intérêt de l'ensemble local Chos_Set[] est testé afin de vérifier si ce point doit être conservé. Cette boucle vise principalement à retirer tous les points d'intérêt dont les données de sélectivité sont de type « après », alors qu'une alerte n'a pas été détectée.

En effet, il a été montré plus haut que chaque alerte est composée, pour un identifiant d'alerte donné, d'une pluralité de points d'intérêt. Ces points d'intérêts définissent entre eux des boîtes successives. Dans le sens du trajet, qualifié ici d'amont vers l'aval, le véhicule va donc d'abord traverser des boîtes définies par des points d'intérêt dont les données de sélectivité sont de type « avant », puis une boîte dont l'extrémité aval est le point d'intérêt dont les données de sélectivité sont de type « lieu », et enfin des boîtes définies par des points d'intérêt dont les données de sélectivité sont de type « après ». Dans le cas où une alerte n'a pas été détectée au niveau du détecteur 49, cela signifie que la boîte dont l'extrémité aval est le point d'intérêt dont les données de sélectivité sont de type « avant » ou « lieu » n'a pas été traversée. Dans ces conditions, si un point d'intérêt de l'ensemble Chos_Sed] présente des données de sélectivité de type « après », ce point est forcément insignifiant, puisqu'il faudra d'abord que le véhicule traverse cette boîte avant que ce point puisse devenir pertinent. Il n'y a donc aucun risque à retirer ce point d'intérêt puisqu'il n'est pas susceptible de correspondre à une alerte pertinente. Dans l'exemple décrit ici, l'ensemble local peut être vu comme un vecteur dont chaque élément est un point d'intérêt pouvant être adressé au moyen de l'indice i.

Ainsi, dans une opération 510, une fonction Alert() vérifie l'état courant de détection d'alerte au niveau du détecteur 49. Dans l'exemple décrit ici, la fonction Alert() effectue un test qui compare l'identifiant d'alerte détectée courante avec l'identifiant d'alerte du point d'intérêt courant. Ainsi, si aucune alerte n'est en cours, alors l'identifiant d'alerte détectée courante est vide, et le test et négatif. Dans le cas où le détecteur 49 n'a pas détecté d'alerte, le type des données de sélectivité du point d'intérêt courant est testé dans une opération 520 au moyen d'une fonction Out(). Comme on vient de le voir, cette fonction vérifie si le type des données de sélectivité du point d'intérêt courant est « après ». Lorsque ça n'est pas le cas, alors une fonction Pair() est exécutée dans une opération 530 pour déterminer si l'ensemble Chos_Sed] comprend un autre point d'intérêt présentant un identifiant d'alerte identique à celui du point d'intérêt courant. En effet, si un point d'intérêt est le seul parmi les points d'intérêt définissant une alerte donnée alors ce point ne pourra pas non plus servir de base à une alerte pertinente. Lorsque l'opération 520 détecte un type de données de sélectivité égal à « après », ou lorsque l'opération 530 détecte un point d'intérêt « isolé », alors le point d'intérêt courant est supprimé au moyen d'une fonction Suppr() dans une opération 540. Ensuite, ou lorsque l'opération 530 détecte une paire de points d'intérêt, l'indice i est incrémenté dans une opération 550, puis une opération 560 vérifie si l'ensemble Chos_Set[] a été entièrement parcouru. Si ce n'est pas le cas, la boucle reprend en 510. Sinon, elle se termine en 570. En sortie du réducteur 45, l'ensemble local a été minimisé en un ensemble réduit comprenant des points d'intérêt susceptible de produire des alertes pertinentes. L'ensemble réduit est alors transformé en données de détection au moyen du convertisseur 47. La figure 6 représente un exemple de réalisation de cette transformation. On notera que dans ce qui précède, le réducteur 45 opère par suppression de points d'intérêt dans l'ensemble local. Dans ce cas, l'ensemble réduit est donc l'ensemble local dans lequel des points d'intérêts ont été retirés. Cependant, le réducteur 45 pourrait opérer différemment, par création d'un nouvel ensemble de points d'intérêt. Dès lors, la « suppression » d'un point d'intérêt courant par la fonction Suppr() consiste à ne pas ajouter ce point dans l'ensemble réduit. Une fois l'ensemble réduit déterminé, la boucle se poursuit avec une opération 320.

Cette opération consiste à définir des données de détection à partir de l'ensemble réduit, et est réalisée par le convertisseur 47. Comme on peut le voir sur la figure 6, le convertisseur 47 commence par recevoir l'ensemble réduit et par initialiser un indice i à 0 dans une opération 600. Comme pour le réducteur 45, dans l'exemple décrit ici, l'ensemble réduit peut être vu comme un vecteur dont chaque élément est un point d'intérêt pouvant être adressé au moyen de l'indice i. Le convertisseur 47 permet également d'optimiser la production de données de détection. En effet, il peut arriver que deux points d'intérêts ayant un identifiant d'alerte identique fassent partie de l'ensemble réduit, sans que ces points soient consécutifs dans la définition de l'alerte correspondante, et sans que les points qui leur succèdent dans la définition de l'alerte correspondante fassent partie de l'ensemble réduit. Dans ce cas, il ne faut pas générer de données de détection, car elles correspondraient à une boîte erronée. Cela peut par exemple être détecté par comparaison des données de séquence des points d'intérêt présentant un même identifiant d'alerte, ou par comparaison de leurs données de géolocalisation respectives, pour vérifier qu'ils ne sont pas éloignés d'une distance supérieure à un seuil prédéterminé, par exemple de 1 km.

Afin de gérer cette situation, une fonction Seq() teste dans une opération 610 si l'ensemble réduit comprend un point d'intérêt présentant des données de séquence indiquant que ce point est le successeur du point d'intérêt courant dans l'alerte qu'ils aident à définir. Si c'est le cas, alors le convertisseur 47 crée une boîte formant données de détection à partir du point d'intérêt courant et de son successeur identifié avec la fonction Seq() dans une opération 620 au moyen d'une fonction Box(). Ensuite, ou lorsque la fonction Seq() n'identifie pas de successeur, l'indice i est incrémenté dans une opération 630, puis une opération 640 vérifie si l'ensemble Red_Setfl a été entièrement parcouru. Si ce n'est pas le cas, la boucle reprend en 610. Sinon, elle se termine en 650. Enfin, une fois les données de détection déterminées par le convertisseur 47, la boucle se termine avec une opération 330. Ainsi, le détecteur 49 compare les données de géolocalisation courantes avec les données de détection afin de déterminer si une alerte doit être déclarée. La figure 7 représente un exemple de fonctionnement du détecteur 49.

Le détecteur 49 commence avec la réception des données de détection et l'initialisation d'un indice i à 0 dans une opération 700. Comme pour le réducteur 45, dans l'exemple décrit ici, les données de détection peuvent être vues comme un vecteur dont chaque élément est un point d'intérêt pouvant être adressé au moyen de l'indice i.

Ensuite, toutes les données de détection sont testées au moyen d'une fonction Det() dans une opération 710. Dans l'exemple décrit ici, la fonction Det() effectue quatre tests à partir des données de détection courantes Det_Dat[i] et des données de géolocalisation courantes.

Le premier test est le calcul d'un angle formé par le cap du véhicule par rapport à l'axe formé par les deux points d'intérêts définissant la boîte des données de détection. Lorsque cet angle présente une valeur absolue inférieure ou égale à 20°, alors le deuxième test est réalisé. D'une manière générale, cette valeur d'angle pourra être choisie dans une plage de 5° à 45°. Sinon, la fonction Det() renvoie une valeur de condition non remplie, c'est-à-dire d'alerte non détectée. Par cap, on entend toutes données permettant de définir la direction générale du véhicule. Le cap pourra donc être tiré de données GPS spécifiques, ou être déterminer différemment, par exemple à partir des données de géolocalisation courantes de deux boucles successives du dispositif 4.

Le deuxième test est le calcul de la distance entre la position désignée par les données de géolocalisation courantes et le point d'intérêt aval de la boîte des données de détection. En effet, lorsque deux boîtes successives forment un angle l'une avec l'autre, elles sont susceptibles de laisser un espace vide qui appartient pourtant à la route. Afin de gérer cela, il est donc vérifié à chaque fois si le véhicule n'est pas situé dans un cercle dont le centre est le point d'intérêt avant de la boîte courante, et dont le rayon est la moitié de la largeur de la boîte courante. Lorsque c'est le cas, alors la fonction Det() renvoie une valeur de condition remplie, c'est-à-dire d'alerte détectée. Sinon, le troisième test est réalisé. En variante, ce cercle peut être remplacé par une autre forme, comme un carré, comme cela est fait dans le sélecteur 43. Cela permettrait d'augmenter la vitesse d'exécution du test par comparaison de coordonnées au lieu de calculer une distance au centre du cercle. Le troisième test est le calcul de la distance latérale entre la position désignée par les données de géolocalisation courantes et l'axe défini par les points d'intérêt définissant la boîte courante. Dans l'exemple décrit ici, la boîte est définie par deux positions définies par les données de géolocalisation respectives des points d'intérêt définissant la boîte. Par conséquent, la distance latérale correspond à la distance entre la position courante désignée par les données de géolocalisation courantes et une position qui correspond à la projection orthogonale de la position courante sur le segment formé par les deux positions définies par les données de géolocalisation respectives des points d'intérêt définissant la boîte. Si la distance latérale est inférieure à la moitié de la largeur de la boîte, alors le quatrième test est réalisé. Sinon, la fonction Det() renvoie une valeur de condition non remplie, c'est-à-dire d'alerte non détectée.

Le quatrième et dernier test est la détermination de l'ange formé par : le segment défini par la position désignée par les données de géolocalisation courante et le point d'intérêt amont avec l'axe formé par les points d'intérêts amont et aval, et le segment défini par la position désignée par les données de géolocalisation courante et le point d'intérêt aval avec l'axe formé par les points d'intérêts amont et aval.

Si ces deux angles sont inférieurs à 90°, alors les données de géolocalisation courantes désignent un point situé dans la boîte, et la fonction Det() renvoie une valeur de condition remplie, c'est-à-dire d'alerte détectée. Sinon, la fonction Det() renvoie une valeur de condition non remplie, c'est-à-dire d'alerte non détectée. Lorsque la fonction Det() renvoie une valeur de condition remplie, alors le processeur 46 commande l'interface utilisateur 44 avec une fonction Decl() pour déclarer l'alerte d'indice i. Cela peut être fait de manière visuelle, sonore, ou par une combinaison des deux. Ensuite, ou lorsque la fonction Det() renvoie une valeur de condition non remplie, l'indice i est incrémenté dans une opération 730, puis une opération 740 vérifie si le vecteur Det_Dat[] a été entièrement parcouru. Si ce n'est pas le cas, la boucle reprend en 710. Sinon, elle se termine en 750. 15 Les figures 8 à 11 représentent des modes de réalisation en variante des éléments et diagrammes de fonctionnement des figures 4 à 7. Dans ces variantes, la Demanderesse a enrichi les données d'alerte. Ainsi, en plus des données d'alerte définissant des points d'intérêts, la Demanderesse a ajouté des données d'alerte génériques. Les données 20 d'alerte génériques sont des données qui sont associées à un identifiant d'alerte donné, cet identifiant d'alerte étant lui-même associé à un ou plusieurs points d'intérêt. Ces données associées comprennent des informations qui qualifient la zone dangereuse désignée par l'identifiant d'alerte. 25 Dans l'exemple décrit ici, les données d'alerte génériques comprennent : - un identifiant d'alerte, des données de priorité, des données de vitesse autorisée, - des données d'unité, 30 - des données de contrôle de vitesse moyenne, - des données de type d'alerte, et - des données de masquage temporel. 10 Les données de priorité sont des données permettant au détecteur 49 de choisir l'alerte qui doit être signalée lorsque plusieurs alertes sont activées à un instant donné. Ces données peuvent être un identifiant, le détecteur 49 comprenant alors un jeu de règles déterminant l'alerte prioritaire sur la base des identifiants, ou être une valeur, de sorte que c'est l'alerte ayant la valeur de priorité la plus forte ou la plus faible qui a la priorité. Les données d'unité permettent de gérer l'utilisation du dispositif 4 dans des pays dans lesquels les systèmes d'unités sont distincts. Par exemple cela permet de gérer un 10 affichage en km/h ou en mi/h, etc. Les données de contrôle de contrôle de vitesse moyenne permettent d'indiquer un type spécifique de zone dangereuse, sur laquelle c'est la vitesse moyenne qui est mesurée. Typiquement, les données de contrôle de vitesse moyenne comprennent une valeur 15 indiquant la distance sur laquelle la vitesse moyenne est calculée, à comparer avec les données de vitesse autorisée. Les données de type d'alerte permettent de définir deux types d'alertes à détecter. Le premier type est celui décrit avec le premier mode de réalisation, à savoir les boîtes. Le 20 deuxième type d'alerte est dit « cercle ». Ce type d'alerte est défini par un unique point d'intérêt, le centre du cercle, et par une distance représentant le rayon de ce cercle. Enfin, les données de masquage temporel sont des données permettant d'activer une alerte donnée sur des plages de temps restreintes. Par exemple, une zone dangereuse liée 25 à une école pourra présenter des données de masquage temporel indiquant que cette alerte est inactive le dimanche. Par ailleurs, ce mode de réalisation permet également l'utilisation d'une table de vitesses. Ainsi, pour toutes les données de vitesse, le champ pourra contenir une valeur 30 de vitesse ou un identifiant de vitesse. Dans ce deuxième cas, la vitesse qui sera retenue sera la vitesse indiquée dans la table de vitesses en correspondance de cet identifiant. Cela permet par exemple de mettre à jour rapidement un très grand nombre de données de vitesse lorsqu'une législation change, puisqu'il suffit de mettre à jour la table de vitesses. La figure 8 est similaire à la figure 5 et représente une variante de mise en oeuvre du réducteur 45. Les opérations qui sont identiques pour ces deux modes de réalisations sont indiquées par des numéros de référence identiques. Ces deux modes de réalisation diffèrent principalement par la réalisation du test d'alerte plus tôt, et le traitement des alertes de type cercle.

Après une opération 800 similaire à l'opération 500, un test d'alerte déclenchée courante est exécuté dans une opération 810 au moyen d'une fonction Alert(). Cette fonction est une variante de la fonction de l'opération 510, et teste uniquement l'existence d'une alerte déclenchée courante. Cela est un peu moins précis que la fonction Alert() de l'opération 510, car des points d'intérêt dont les données de sélectivité sont de type « après » risquent d'être conservés à tort, mais cela permet en revanche d'économiser en calcul, car le test 810 est exécuté une seule et unique fois, alors que l'opération 510 est répétée pour chaque point d'intérêt courant.

Dans le cas où une alerte déclenchée courante existe, alors les données de type d'alerte associées aux données d'alerte génériques dont l'identifiant d'alerte est celui du point d'intérêt courant sont testées dans une opération 820 au moyen d'une fonction Circ(). En effet, si ces données indiquent que le point d'intérêt courant est associé à une alerte de type cercle, alors ce point doit être conservé, puisqu'il forme une alerte en lui-même.

Si l'opération 820 renvoie une réponse négative, alors l'alerte n'est pas de type cercle, et l'opération 530 est réalisée ensuite pour détecter la présence ou non d'un autre point d'intérêt ayant un identifiant d'alerte identique. Si la fonction Pair() de l'opération 530 renvoie une réponse négative, alors le point d'intérêt courant est supprimé par la fonction Suppr() dans l'opération 540. Sinon, ou lorsque l'opération 820 renvoie une réponse positive, les données de masquage temporel des données d'alerte générique dont l'identifiant d'alerte est identique à celui du point d'intérêt courant sont testées dans une opération 830 au moyen d'une fonction Tim(). La fonction Tim() compare des données d'heure et/ou de date courante aux données de masquage temporel pour déterminer si le point d'intérêt courant correspond à une alerte active ou pas. Si la réponse est négative, alors le point d'intérêt courant est supprimé par la fonction Suppr() dans l'opération 540. Ensuite, ou lorsque la réponse de la fonction Tim() est positive, l'indice i est incrémenté dans l'opération 550, puis une opération 560 vérifie si l'ensemble Chos_Sed] a été entièrement parcouru. Si ce n'est pas le cas, la boucle reprend en 820. Sinon, elle se termine en 570. Dans le cas où une alerte déclenchée courante n'existe pas, les opérations sont similaires, à l'exception d'un test initial supplémentaire réalisé par l'opération 520. Si l'opération 520 retourne un résultat positif, alors les opérations suivantes sont identiques à celles du cas où une alerte déclenchée courante existe. Sinon, le point d'intérêt courant est supprimé dans l'opération 540, et l'indice i incrémenté.

Il convient de noter que l'opération 830 pourrait être exécutée au sein du convertisseur 47 au lieu d'être exécutée au sein du réducteur 45. La figure 9 représente une variante de réalisation du fonctionnement du convertisseur 47 présenté avec la figure 6. Comme on peut le voir sur cette figure, la seule différence avec la figure 6 est l'opération initiale qui a été renumérotée 900 par souci de cohérence, et l'inclusion de deux opérations 910 et 920 qui servent à gérer la génération de données de détection dans le cas où les données de type d'alerte des données d'alerte génériques dont l'identifiant d'alerte est identique à celui du point d'intérêt courant sont de type cercle. Plus précisément, l'opération 910 est identique à l'opération 830, et l'opération 920 comprend l'exécution d'une fonction Bld(), qui crée des données de détection définissant un cercle dont le centre est indiqué par les données de géolocalisation du point d'intérêt courant et dont le rayon est indiqué par les données de largeur de ce même point.

La figure 10 représente une variante de réalisation du fonctionnement du détecteur 49 présenté avec la figure 7. Ce mode de réalisation diffère de celui de la figure 7 en ce qu'il inclut la gestion des alertes de type cercle, et en ce qu'il inclut la gestion de priorité des alertes. Comme pour les figures 8 et 9, la première opération a été renumérotée, ici avec la référence 1000. Ainsi, la fonction Det() est légèrement différente dans la mesure où elle est modifiée pour tenir compte du cas où l'alerte est de type cercle. Dans ce cas, un unique test de distance entre les données de géolocalisation courantes et les données de géolocalisation du centre du cercle est réalisé pour déterminé si l'alerte est déclenchée ou pas. De plus, la fonction Decl() est sortie de la boucle afin de gérer la priorité, et remplacée par une opération 1010. Dans l'opération 1010, une fonction Prio() détermine quelle est l'alerte déclenchée dans la boucle en cours d'exécution qui présente la priorité la plus importante. Il s'agit en fait de faire la comparaison à chaque itération de la boucle, de sorte qu'à la fin de la boucle, il ne reste que l'alerte la plus prioritaire. Ainsi, une fois que l'opération 740 renvoie une réponse négative, l'opération 720 est exécutée pour déclarer l'alerte la plus prioritaire, et la boucle d'exécution du détecteur 49 se termine. Dans ce qui précède, de nombreuses variantes peuvent être envisagées, notamment en ce qui concerne la combinaison des modes de réalisation présentés. Plus spécifiquement, il sera par exemple possible d'intégrer les données d'alerte génériques au premier mode de réalisation, ou de simplifier le deuxième mode de réalisation à la manière du premier, ou d'utiliser le réducteur d'un mode de réalisation avec le convertisseur d'un autre mode de réalisation etc. En outre, il serait possible de compléter le dispositif décrit ci-dessus en offrant la possibilité à l'utilisateur de définir une distance d'alerte prioritaire sur les distances décrites ci-dessus. Dans ce cas, c'est la distance calculée à partir des données de géolocalisation locales et des données de géolocalisation du point d'intérêt concerné qui sert à déterminer le déclenchement de l'alerte.

Enfin, certaines données pourront être omises, c'est-à-dire que certains champs pourront être laissés vides. Dans ce cas, ce sont des valeurs par défaut qui seront utilisées. Par exemple, les données de largeur des données d'alerte pourront être omises, et elles seront remplacées par une valeur prédéterminées. De même, les données de vitesse des données d'alerte pourront être omises, et, en cas de présence de données d'alerte génériques, ce sont les données de vitesse des données d'alerte génériques qui seront retenues, etc.

Selon les variantes, le dispositif pourra présenter les caractéristiques suivantes : - les données de sélectivité indiquent une situation amont ou aval relativement à un point d'intérêt, et dans lequel lorsqu'un état d'alerte courant indique qu'aucune alerte n'est déclenchée, la règle du réducteur (45) exclut de l'ensemble réduit certains au moins des jeux de données d'alerte de l'ensemble local dont les données de sélectivité sont de type aval, - la règle du réducteur (45) exclut de l'ensemble réduit certains au moins des jeux de données d'alerte de l'ensemble local dont les identifiants d'alerte sont uniques dans l'ensemble local, - le convertisseur (47) est agencé pour définir les données de détection par jeux, chacun associant deux à deux certains au moins des jeux de données d'alerte de l'ensemble réduit qui présentent un identifiant d'alerte identique, et dont les données de géolocalisation indiquent un éloignement inférieur à un seuil prédéterminé, - les jeux de données d'alerte comprennent des données de séquence, et dans lequel la règle du convertisseur (47) fait également intervenir une comparaison des données de séquence, de sorte que deux jeux de données d'alertes ne sont associés pour former des données de détection que si leurs données de séquence respectives indiquent qu'ils se succèdent, - pour un jeu de données de détection donné, le détecteur (49) effectue un calcul d'un angle entre un cap de conduite et un axe désigné par les données de géolocalisation des données de détection, et/ou un calcul d'une distance entre une position désignée par les données de géolocalisation courantes et une position désignée par les données de détection, et/ou un calcul d'une distance entre une position désignée par les données de géolocalisation courantes et une position désignée par certaines des données de géolocalisation des données de détection, et/ou un calcul d'un angle entre une position désignée par les données de géolocalisation courantes et deux positions respectives désignées par les données de géolocalisation des données de détection, - certains au moins des jeux de données d'alerte comprennent en outre des données de vitesse, et/ou les données d'alerte comprennent des jeux de données d'alerte génériques, - les jeux de données d'alerte génériques associent au moins un identifiant d'alerte, des données de priorité, des données de type d'alerte, et optionnellement des données de masquage temporel, et/ou des données de vitesse autorisée, et/ou des données de contrôle de vitesse moyenne et/ou des données d'unité, - la commande de l'interface utilisateur (44) par le détecteur (49) dépend des données de priorité. - un au moins du réducteur (45), du convertisseur (47), et du détecteur (49) opère différemment en fonction des données de type d'alerte.

Le fonctionnement de l'invention a été présenté sous forme de dispositif. Il est manifeste que ce fonctionnement correspond à un procédé d'aide à la conduite dont les caractéristiques peuvent être tirées de ce qui précède. De plus, certains éléments pourront être fusionnés ou combinés, comme le réducteur avec le convertisseur, ou le sélecteur avec le réducteur, etc.

Claims

REVENDICATIONS1. Dispositif d'aide à la conduite, comprenant une mémoire (41) capable de stocker des données d'alerte, un module de géolocalisation, ainsi qu'une interface utilisateur (44) pour communiquer des informations d'alerte tirées des données d'alerte à un utilisateur, caractérisé en ce que les données d'alerte comprennent des jeux de données d'alerte associant au moins un identifiant d'alerte, des données de géolocalisation, et des données de sélectivité, le dispositif comprenant en outre : un sélecteur (43) capable de produire un ensemble local de jeux de données d'alerte, choisis en fonction de leurs données de géolocalisation associées et de données de géolocalisation courantes, un réducteur (45) agencé pour produire un ensemble réduit de jeux de données d'alerte à partir de l'ensemble local, en fonction d'une règle faisant intervenir un état d'alerte courant du dispositif et au moins les données de sélectivité des jeux de données d'alerte de l'ensemble local, un convertisseur (47) agencé pour générer des données de détection à partir de l'ensemble réduit de jeux de données d'alerte produit par le réducteur, en fonction d'une règle faisant intervenir au moins l'identifiant d'alerte et les données de géolocalisation des jeux de données d'alerte de l'ensemble réduit, et un détecteur (49) agencé pour commander une interface utilisateur en fonction de données tirées d'une comparaison entre des données de géolocalisation courantes et certaines au moins des données de détection.
2. Dispositif selon la revendication 1, dans lequel les données de sélectivité indiquent une situation amont ou aval relativement à un point d'intérêt, et dans lequel lorsqu'un état d'alerte courant indique qu'aucune alerte n'est déclenchée, la règle du réducteur (45) exclut de l'ensemble réduit certains au moins des jeux de données d'alerte de l'ensemble local dont les données de sélectivité sont de type aval.
3. Dispositif selon la revendication 1 ou 2, dans lequel la règle du réducteur (45) exclut de l'ensemble réduit certains au moins des jeux de données d'alerte del'ensemble local dont les identifiants d'alerte sont uniques dans l'ensemble local.
4. Dispositif selon l'une des revendications précédentes, dans lequel le convertisseur (47) est agencé pour définir les données de détection par jeux, chacun associant deux à deux certains au moins des jeux de données d'alerte de l'ensemble réduit qui présentent un identifiant d'alerte identique, et dont les données de géolocalisation indiquent un éloignement inférieur à un seuil prédéterminé.
5. Dispositif selon la revendication 4, dans lequel certains au moins des jeux de données d'alerte comprennent des données de séquence, et dans lequel la règle du convertisseur (47) fait également intervenir une comparaison des données de séquence, de sorte que deux jeux de données d'alertes ne sont associés pour former des données de détection que si leurs données de séquence respectives indiquent qu'ils se succèdent.
6. Dispositif selon la revendication 4 ou 5, dans lequel pour un jeu de données de détection donné, le détecteur (49) effectue un calcul d'un angle entre un cap de conduite et un axe désigné par les données de géolocalisation des données de détection, et/ou un calcul d'une distance entre une position désignée par les données de géolocalisation courantes et une position désignée par les données de détection, et/ou un calcul d'une distance entre une position désignée par les données de géolocalisation courantes et une position désignée par certaines des données de géolocalisation des données de détection, et/ou un calcul d'un angle entre une position désignée par les données de géolocalisation courantes et deux positions respectives désignées par les données de géolocalisation des données de détection.
7. Dispositif selon l'une des revendications précédentes, dans lequel un jeu de données d'alerte comprend en outre des données de vitesse, et/ou dans lequel les données d'alerte comprennent des jeux de données d'alerte génériques.
8. Dispositif selon la revendication 7, dans lequel les jeux de données d'alerte génériques associent au moins un identifiant d'alerte, des données de priorité, des données de type d'alerte, et optionnellement des données de masquagetemporel, et/ou des données de vitesse autorisée, et/ou des données de contrôle de vitesse moyenne et/ou des données d'unité.
9. Dispositif selon la revendication 8, dans lequel la commande de l'interface utilisateur (44) par le détecteur (49) dépend des données de priorité.
10. Dispositif selon la revendication 8 ou 9, dans lequel un au moins du réducteur (45), convertisseur (47), et du détecteur (49) opère différemment en fonction des données de type d'alerte.