FR3108400A1 - procédé de planification d’un trajet pour un véhicule automobile - Google Patents

Abstract

L’invention concerne un procédé de planification d’un trajet pour un véhicule automobile, dans lequel il est prévu des étapes de : - détermination d’une position de départ du véhicule automobile, - sélection d’au moins un type d’évènement routier (CI, POI, DR), - acquisition d’au moins une première contrainte relative à la longueur du trajet, et- calcul d’un trajet qui part de la position de départ, qui respecte chaque première contrainte et qui maximise le nombre et/ou la durée et/ou la longueur des évènements routiers de chaque type sélectionné situés le long du trajet. Figure pour l’abrégé : Fig.1

Description

procédé de planification d’un trajet pour un véhicule automobile

Domaine technique de l'invention

La présente invention concerne de manière générale les essais réalisés lors de la conception et de la validation de nouveaux modèles de véhicules automobiles ou de nouvelles fonctions de véhicules automobiles.

Elle concerne plus particulièrement un procédé de planification d’au moins un trajet qu’au moins un véhicule automobile doit effectuer, comportant des étapes de :
- détermination d’une position de départ de chaque véhicule automobile, et de
- calcul d’un trajet partant de la position de départ.

Elle concerne également un calculateur adapté à mettre en œuvre ce procédé.

Etat de la technique

Il est connu de réaliser des essais sur routes pour valider la conception des systèmes embarqués dans les véhicules automobiles (notamment des systèmes de conduite autonome).

Actuellement, ces essais se font sur des trajets définis au hasard ou sur des trajets planifiés de façon à présenter globalement la même proportion d’axes routiers en agglomération, à la campagne, et sur autoroute.

L’inconvénient est qu’en pratique, de nombreux kilomètres de ces trajets ne sont pas ou peu utiles par valider la conception des systèmes embarqués, puisqu’il ne s’y passe concrètement aucun fait en lien avec les systèmes que l’on cherche à valider.

Présentation de l'invention

Afin de remédier à l’inconvénient précité de l’état de la technique, la présente invention propose un outil permettant de planifier un trajet qui permettra de valider la conception des systèmes embraqués en un nombre le plus restreint possible de kilomètres et/ou en une durée minimum.

Plus particulièrement, on propose selon l’invention un procédé de planification d’un trajet pour un véhicule automobile, dans lequel il est prévu des étapes de :
- détermination d’une position de départ de chaque véhicule automobile,
- sélection d’au moins un type d’évènement routier,
- acquisition d’au moins une première contrainte restreignant le nombre de trajets pouvant être choisis, et de
- choix, par un calculateur, d’un trajet partant de la position de départ, au cours de laquelle le calculateur choisit le trajet de façon à optimiser :
soit le nombre et/ou la durée et/ou la longueur des évènements routiers de chaque type sélectionné le long du trajet, compte tenu de chaque première contrainte acquise,
soit chaque première contrainte, compte tenu d’un nombre souhaité et/ou d’une durée souhaitée et/ou d’une longueur souhaitée des évènements routiers de chaque type sélectionné le long du trajet.

Ainsi, grâce à l’invention, l’usager pourra sélectionner les types d’évènements les plus pertinents pour valider un système particulier du véhicule automobile. Par exemple, l’usager pourra sélectionner les évènements de type « feux tricolores » et « panneaux stop » s’il cherche à valider le système d’arrêt automatique du véhicule. Il pourra sélectionner les évènements de type « tunnels » s’il cherche à valider les caméras utilisées et les systèmes de traitement d’images.

Le trajet sera alors choisi par le calculateur parmi un ensemble de trajets possibles (cet ensemble étant restreint au moyen de chaque première contrainte), de façon à rencontrer un nombre souhaité d’évènement de chaque type sélectionné, ou le plus grand nombre possible d’évènements de chaque type sélectionné afin de pouvoir valider au plus vite le système.

D’autres caractéristiques avantageuses et non limitatives du procédé de planification conforme à l’invention, prises individuellement ou selon toutes les combinaisons techniquement possibles, sont les suivantes :
- il est prévu de sélectionner ledit au moins un type d’évènements routiers parmi au moins un ensemble de types d’évènements routiers correspondant à des infrastructures routières stockées dans une mémoire d’un système de navigation ;
- il est prévu une étape préalable de pointage manuel d’au moins un point d’intérêt sur une carte et de stockage de chaque point d’intérêt dans une mémoire ;
- il est prévu de sélectionner ledit au moins un type d’évènements routiers parmi au moins un ensemble de types d’évènements routiers correspondant à des points d’intérêt stockés dans la mémoire ;
- il est prévu de sélectionner ledit au moins un type d’évènements routiers parmi au moins un ensemble de types d’évènements routiers correspondant à des situations contextuelles qui portent par exemple sur : le trafic routier et/ou les conditions météorologiques, et/ou la hauteur du soleil, et/ou la présence de travaux ;
- il est prévu une étape d’acquisition de données de prédiction relatives à l’évolution de la situation contextuelle sur le trajet, et une étape de détermination d’un meilleur moment pour démarrer le trajet en fonction desdites données de prédiction, de façon à maximiser la durée pendant laquelle le véhicule rencontrera la situation contextuelle le long du trajet ;
- ladite première contrainte est une contrainte de durée ou de longueur de trajet ;
- ladite première contrainte est une contrainte de durée ou de longueur de trajet, ou une contrainte de nombre d’évènements routiers se trouvant sur le trajet, ou une contrainte de durée ou de longueur pendant laquelle les évènements routiers seront rencontrées ;
- il est prévu, avant l’étape de calcul, une étape de saisie d’au moins une seconde contrainte distincte de ladite première contrainte, et à l’étape de calcul, le trajet est calculé de façon à respecter chaque seconde contrainte saisie ;
- la seconde contrainte est une zone géographique dans laquelle le trajet doit être circonscrit ;
- la seconde contrainte est un nombre ou une fréquence d’arrêts que le véhicule automobile doit effectuer ou une catégorie de zones dans lesquelles le véhicule automobile doit effectuer des arrêts ;
- ladite étape de sélection comporte une sous-étape d’affichage de plusieurs types d’évènements routiers sur un écran et une sous-étape de sélection manuelle par un usager d’au moins un des types d’évènements routiers affichés.

L’invention porte également sur un calculateur comportant une interface adaptée à communiquer avec un système de navigation, une mémoire et un processeur adapté à mettre en œuvre un procédé de planification tel que précité.

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 du dessin annexé, donné à titre d’exemple non limitatif, fera bien comprendre en quoi consiste l’invention et comment elle peut être réalisée.

Sur le dessin annexé :

est une vue schématique d’une image affichée par un écran d’affichage lors de la mise en œuvre d’un procédé de planification conforme à la présente invention.

L’invention pourra être mise en œuvre par un système informatique quelconque, embarqué ou non dans un véhicule automobile.

Dans un premier mode de réalisation, on considérera à titre d’exemple que l’invention est mise en œuvre par un calculateur embarqué dans un véhicule d’essais.

Dans un second mode de réalisation décrit dans une seconde partie de cet exposé, on considérera que l’invention est mise en œuvre par un calculateur qui est situé dans un serveur local (fixe) et qui communique avec les calculateurs embaqués dans une flotte de plusieurs véhicules automobiles. En variante, il pourrait ne communiquer qu’avec un calculateur d’un seul véhicule automobile.

Dans ces deux modes de réalisation, le véhicule d’essais est par exemple une voiture qui est dotée de systèmes dont on cherche à valider la conception, que ce soit en termes de fonctionnalité et/ou de sécurité et/ou de fiabilité…

Cette voiture d’essais est équipée, dans l’exemple ici considéré, d’un système de pilotage autonome dont on souhaite vérifier qu’il réagit bien à certains types d’évènements qui pourraient être rencontrés sur un axe routier.

Elle est également équipée d’un système de navigation comportant, d’une part, une puce de géolocalisation qui permet par exemple de relever les coordonnées GPS de la position de la voiture, et, d’autre part, une base de données cartographiques permettant de positionner la voiture sur une carte.

Cette base de données cartographiques est ici qualifiée d’enrichie, en ce sens qu’elle stocke des informations relatives aux axes de circulation eux-mêmes mais aussi des informations relatives aux infrastructures routières présentes le long de chaque axe routier (panneau ou feu de signalisation, bande d’arrêt d’urgence, séparateur de voie…).

Le calculateur embarqué dans le véhicule comporte quant à lui un processeur, une mémoire et une interface d'entrée et de sortie connectée notamment au système de navigation par un bus de données.

Dans le premier mode de réalisation, ce calculateur mémorise une application informatique, constituée de programmes d’ordinateur comprenant des instructions dont l’exécution par le processeur permet la mise en œuvre du procédé décrit ci-après.

Dans le second mode de réalisation, c’est le calculateur du serveur local qui mémorise cette application informatique.

Dans les deux modes de réalisation, le calculateur (embarqué dans le véhicule ou situé dans le serveur local) est connecté à un écran d’affichage et à un moyen de saisie d’informations accessibles à l’usager. En pratique, ces deux éléments sont ici combinés en un seul écran tactile sur lequel l’usager peut saisir des données et lire des informations.

On notera ici que l’usager est un membre de l’équipe de conception de la voiture d’essais.

Pour être en mesure de certifier par exemple le bon fonctionnement du système de pilotage autonome équipant la voiture d’essais, la présente invention consiste à proposer à un usager de choisir des types d’évènements routiers qu’il souhaite que la voiture d’essais rencontre, puis à élaborer un trajet qui passe le plus possible par ce ou ces types d’évènements routiers.

On peut ici définir la notion « d’évènement routier ».

Un évènement routier sera soit une infrastructure présente et/ou visible le long d’un axe routier, soit un lieu particulier situé le long d’un axe routier, soit une circonstance particulière.

On peut ainsi distinguer les évènements routiers ponctuels (un feu tricolore, une intersection, un tunnel) des évènements routiers contextuels (météo, trafic…).

Un évènement routier sera vu par le système de pilotage autonome de la voiture d’essais comme un élément qui permettra à cette voiture de se repérer dans l’espace ou comme une contrainte dont la voiture devra tenir compte lorsqu’elle évoluera dans l’espace.

On peut définir la notion de « type d’évènement routier » comme une sorte particulière d’infrastructures routières ou de contexte. Les feux tricolores formeront donc un type d’évènement routier, les panneaux de signalisation un autre, la température extérieure encore un autre…

En pratique, ici, on classera les évènements routiers en trois catégories.

La première catégorie est celle des infrastructures routières CI. Ces infrastructures routières sont des éléments visibles le long des axes routiers et sensiblement intangibles, qui sont stockées dans la base de données cartographiques.

Cette catégorie recouvre donc différents types d’évènements routiers, tels que par exemple les tunnels, les pistes cyclables, les passages piéton, le type de revêtement des routes, la qualité de surface de ces routes, la qualité des marquages peints sur les routes, les virages, les zones de vitesses limitées, les feux tricolores, les panneaux, les échangeurs, les zones de couverture téléphonique, les passages à niveau, les nombres de voies des routes, la présence de chaussée séparée, le niveau de visibilité des routes compte tenu de l’environnement, les intersections complexes, les intersections simples…

Dans cette première catégorie, les évènements routiers peuvent être associés à un contexte particulier. A titre d’exemple, on sait que l’entrée dans un tunnel est plus dangereuse lorsque le soleil est orienté en face du véhicule (dans cette situation, l’intérieur du tunnel est invisible). Il est alors possible d’associer les infrastructures routières de type « tunnel » à une orientation particulière du soleil. Il en va de même pour d’autres types d’infrastructures routières.

La seconde catégorie est celle des points d’intérêts POI. Il s’agit de lieux qui ont été préalablement pointés par un usager et dont les coordonnées géolocalisées sont stockées dans la mémoire du calculateur ou dans le système de navigation. En pratique, il s’agit de lieux dont il a été constaté que le système de conduite autonome pouvait éprouver des difficultés à les franchir ou à bien les appréhender.

Lorsque l’usager repère un tel lieu lors d’une campagne d’essais sur route, il marque cette position de façon à l’enregistrer comme étant une zone dans laquelle il serait intéressant de faire repasser les voitures d’essais. Il peut en outre associer ce point d’intérêt à un contexte particulier. A titre d’exemple, il peut arriver que, par temps ensoleillé, à une heure particulière de la journée, un bâtiment ou un objet crée sur la route une ombre qui est interprétée à tort par le système de conduite autonome comme une ligne blanche de séparation de voie ou comme un obstacle. Dans cette éventualité, le point d’intérêt est associé à un contexte défini par un créneau horaire et par une météo particulière.

Dans cette seconde catégorie, on peut classer tous les évènements routiers en un seul type (les points d’intérêts). En variante, on peut classer les points d’intérêts en différents types chacun associés à une fonction particulière du système de pilotage autonome.

Par exemple, lorsqu’il repère un point d’intérêt lors d’une campagne d’essais, l’usager peut affecter un point d’intérêt à la fonction « suivi de voie » du système de pilotage autonome (celle qui permet de maintenir le véhicule dans une voie ou d’avertir le conducteur lorsqu’il sort de cette voie) et un autre point d’intérêt à la fonction « freinage automatique » (celle qui permet de ralentir le véhicule en présence d’un obstacle sur la voie). Ainsi, une sortie de métro par laquelle un grand nombre de piétons sortent tous les jours avant de franchir un passage piéton peut être pointé comme un point d’intérêt associé à la fonction « freinage automatique », tandis qu’une zone où une ombre est interprétée à tort comme une ligne blanche de séparation de voie peut être pointée comme un point d’intérêt associé à la fonction « suivi de voie ».

On peut ainsi distinguer autant de types de points d’intérêt qu’il y a de fonctions dans le système de pilotage autonome.

La troisième catégorie d’évènements routiers est celle des situations contextuelles DR. Ces évènements routiers sont des informations qui fluctuent dans le temps et/ou dans l’espace et qui sont accessibles soit directement dans le logiciel de navigation, soit sur un réseau externe tel que le réseau Internet.

Cette catégorie recouvre donc différents types d’évènements routiers relatifs par exemple au trafic (le trafic de véhicule automobile, ou de vélo, ou de piétons ou le trafic routier global), à la météo (la pluviométrie, température…), à la hauteur de soleil (l’orientation du soleil, jour ou nuit…), ou encore à la présence de travaux.

Généralement, chaque type de situation contextuelle (température, trafic routier global…) est associé à un niveau d’importance (une valeur de température, une donnée de fluidité de circulation…).

La notion d’évènement routier ayant été ainsi bien définie, on peut décrire la façon selon laquelle le procédé selon l’invention est mis en œuvre, en étapes successives, par le calculateur.

Dans le premier mode de réalisation, le procédé est mis en œuvre sur une voiture d’essais particulière, qui est équipée de son propre calculateur adapté à mettre en œuvre l’invention.

La première étape consiste à déterminer la position de départ du véhicule automobile.

Cette étape peut être réalisée automatiquement par le calculateur, compte tenu de la position relevée par sa puce de géolocalisation.

En variante, l’usager peut utiliser l’écran tactile pour pointer une position de départ différente.

La seconde étape consiste à sélectionner au moins un type d’évènements routiers que l’usager souhaite que la voiture d’essais rencontre le long du trajet.

Ici, cette étape est mise en œuvre par le calculateur en commandant l’affichage sur l’écran tactile d’un menu tel que celui représenté sur la figure 1. Ce menu est prévu pour permettre à l’usager de sélectionner manuellement le ou les types d’évènements qu’il souhaite que la voiture d’essais rencontre.

Ce menu pourrait présenter des formes très variées. Dans l’exemple illustré sur la figure 1, ce menu comporte sept zones d’affichage Z1, Z2, Z3, Z4, Z5, Z6, Z7.

La première zone d’affichage Z1 permet, lorsque l’usager la sélectionne en appuyant dessus sur l’écran tactile, de laisser à l’usager la possibilité de sélectionner une zone géographique à l’intérieur de laquelle il souhaite que le trajet reste contraint.

Lorsqu’il appuie sur cette zone d’affichage Z1, le calculateur permet à l’usager d’utiliser la carte représentée sur la zone d’affichage Z6, afin de zoomer au besoin dessus, et de définir par plusieurs points le contour extérieur de cette zone géographique.

En variante, il pourrait définir cette zone géographique autrement, par exemple en saisissant un nom de département ou de pays.

La seconde zone d’affichage Z2 permet, lorsque l’usager la sélectionne en appuyant dessus sur l’écran tactile, de laisser à l’usager la possibilité de sélectionner un ou plusieurs types d’évènements parmi la catégorie des infrastructures routières.

En pratique, lorsque l’usager appuie dessus, le calculateur affiche un sous-menu (non représenté) sur lequel sont inscrits et/ou représentés, à côté de cases à cocher, les différents types d’infrastructures routières sélectionnables.

L’usager peut cocher autant de cases qu’il le souhaite pour sélectionner autant de type d’infrastructures routières qu’il le désire.

On notera que lors de cette sélection, ce sous-menu peut laisser la possibilité à l’usager de sélectionner des types d’infrastructures routières associées à des contextes particulier (par exemple des tunnels avec le soleil venant de face).

Pour ressortir de ce sous-menu, l’usager appuie sur un bouton de validation.

Le calculateur revient alors au menu principal, en affichant cette fois, dans la seconde zone d’affichage Z2, les types d’évènements sélectionnés.

La troisième zone d’affichage Z3 permet, lorsque l’usager la sélectionne en appuyant dessus sur l’écran tactile, de laisser à l’usager la possibilité de sélectionner un ou plusieurs points d’intérêts.

En pratique, lorsque l’usager appuie dessus, le calculateur affiche sur la zone d’affichage Z6 les différents points d’intérêts situés dans la zone géographique sélectionnée.

L’usager peut alors appuyer sur autant de points d’intérêt qu’il le souhaite afin de les sélectionner.

La quatrième zone d’affichage Z4 permet, lorsque l’usager la sélectionne en appuyant dessus sur l’écran tactile, de laisser à l’usager la possibilité de sélectionner un ou plusieurs types d’évènements de la catégorie situation contextuelle.

En pratique, lorsque l’usager appuie dessus, le calculateur affiche un sous-menu sur lequel sont inscrits et/ou représentés, à côté de cases à cocher, les différents types de situations contextuelles sélectionnables, et le niveau d’importance qui leur est associé.

A titre d’exemple, le sous-menu peut comporter une case à cocher associée au type d’évènement « trafic » et une autre associée au type d’évènement « météo ». Il peut également comporter des menus déroulants permettant de choisir le niveau de trafic souhaité (aucun, fluide, dense ou bouchonné) et la météo souhaitée (temps clair, temps nuageux, pluie, vent, neige, verglas).

L’usager peut sélectionner autant de situations contextuelles qu’il le souhaite, avec à chaque fois le niveau d’importance correspondant. Pour ressortir de ce sous-menu, l’usager appuie sur un bouton de validation.

Le calculateur revient alors au menu principal, en affichant cette fois, dans la quatrième zone d’affichage Z4, les situations contextuelles sélectionnées.

La cinquième zone d’affichage Z5 permet, lorsque l’usager la sélectionne en appuyant dessus sur l’écran tactile, de laisser à l’usager la possibilité de sélectionner une ou plusieurs contraintes.

Ici, on distinguera deux sortes de contraintes.

Les contraintes de la première sorte, dites premières contraintes, sont prévues pour restreindre le nombre de trajets pouvant être choisis par le calculateur. Elles permettent par exemple, lorsque l’usager indique qu’il souhaite que le véhicule passe devant le plus grand nombre de feux tricolores, de limiter le nombre de trajets sélectionnables par le calculateur de façon à ce que ce dernier ne sélectionne pas un trajet de longueur démesurée.

Les contraintes de la première sorte sont donc relatives à la longueur ou à la durée du trajet.

Cette première sorte de contrainte pourra s’exprimer de différentes manières.

Elle pourra s’exprimer sous la forme d’une durée de trajet ou d’une longueur de trajet à ne pas dépasser.

En variante, elle pourra s’exprimer sous la forme d’un nombre d’évènements routiers particuliers maximum que l’on souhaite rencontrer (typiquement, la contrainte de première sorte peut limiter le trajet en indiquant qu’il doit passer au maximum devant cinquante feux tricolores) ou d’une durée ou longueur maximum pendant laquelle on souhaite rencontrer un évènement routier (typiquement au maximum une heure de conduite sous la pluie).

Encore en variante, cette première sorte de contrainte pourra indiquer qu’il faut minimiser la durée ou la longueur du trajet.

Dans le premier mode de réalisation ici décrit, on pourra considérer que le calculateur laisse à l’usager le choix de définir la contrainte de première sorte en termes de durée de trajet ou d’une longueur de trajet à ne pas dépasser.

La seconde sorte de contrainte, dite deuxième contrainte, permettra à l’usager de forcer le trajet à passer dans des zones particulières et/ou à faire des arrêts particuliers.

Elle permettra par exemple de forcer le trajet à prévoir des temps de pause de 20 minutes toutes les deux heures de conduites, dans des zones adéquates.

Elle permet également de planifier le trajet de façon à ce qu’il fasse régulièrement des arrêts dans des lieux d’un type particulier (station essence, borne de recharge, hôtel…).

On notera dans ce cas que le calculateur devra permettre à l’usager de saisir le niveau de charge ou le niveau de carburant du véhicule au point de départ, si ce dernier n’est pas directement accessible, ainsi que la consommation moyenne du véhicule. De cette manière, le calculateur pourra déterminer quand il devra programmer le premier arrêt à une station essence ou à une borne de charge de batteries d’accumulateurs.

En pratique, lorsque l’usager appuie sur la cinquième zone Z5, le calculateur affiche un sous-menu sur lequel sont inscrits et/ou représentés, à côté de cases à cocher, les différents types de contraintes sélectionnables.

L’usager peut sélectionner autant de contraintes qu’il le souhaite en cochant les cases associées (pour autant qu’il sélectionne au moins une contrainte de la première sorte). Pour ressortir de ce sous-menu, l’usager peut appuyer sur un bouton de validation.

Le calculateur revient alors au menu principal, en affichant cette fois dans la cinquième zone d’affichage Z5 les contraintes sélectionnées.

Le calculateur permet ensuite à l’usager de revenir dans n’importe lequel des sous-menus pour modifier, s’il le souhaite, ses choix.

Une fois satisfait, l’usager peut appuyer sur un bouton de validation présent dans une septième zone d’affichage Z7.

A ce stade, la troisième étape du procédé de planification consiste, pour le calculateur, à calculer un meilleur trajet.

Ce meilleur trajet est défini comme :
- partant de la position de départ,
- satisfaisant l’ensemble des contraintes de la seconde sorte sélectionnées, et comme optimisant :
- soit le nombre et/ou la durée et/ou la longueur des évènements routiers de chaque type sélectionné, tout en satisfaisant les contraintes de la première sorte sélectionnées,
- soit chaque contrainte de la première sorte, compte tenu d’un nombre souhaité et/ou d’une durée souhaitée et/ou d’une longueur souhaitée des évènements routiers de chaque type sélectionné le long du trajet.

Selon une optimisation portant sur les évènements routiers, l’optimisation pourra consister à maximiser, sur le trajet, le nombre et/ou la durée et/ou la longueur des évènements routiers de chaque type sélectionné.

Ainsi, à titre d’exemple, le trajet pourra être calculé de façon à présenter le plus grand nombre de passages devant un ou plusieurs types particuliers d’évènements routiers (par exemple devant des feux tricolores) pendant un laps de temps déterminé (par exemple six heures) défini par une contrainte de la première sorte.

Encore à titre d’exemple, le trajet pourra être calculé de façon à présenter le plus grand nombre de kilomètres ou la plus grande durée de roulage dans un ou plusieurs types particuliers d’évènements routiers (par exemple dans un tunnel) pendant un laps de temps déterminé (par exemple six heures) défini par une contrainte de la première sorte.

Selon un autre exemple, on pourra considérer le cas où l’usager a défini qu’il souhaite que le véhicule passe par le plus grand nombre d’intersections. Dans cette variante, on pourra prévoir que la contrainte de première sorte soit définie par l’usager sous la forme d’un nombre maximum de feux tricolores. Alors, le trajet pourra être calculé de façon à passer par le plus grand nombre d’intersections, sans jamais dépasser le nombre maximum de feux tricolores défini.

Selon une optimisation portant sur chaque contrainte de la première sorte, on pourra considérer le cas où l’usager a défini un nombre d’évènements routiers qu’il souhaite que la voiture d’essais rencontre et/ou une durée (ou longueur) pendant laquelle le véhicule devra rencontrer un évènement routier (par exemple de la pluie). L’optimisation consistera à minimiser la longueur ou la durée du trajet, tout en faisant en sorte que le nombre d’évènements routiers de chaque type soit au minimum celui défini par l’usager. Ainsi, à titre d’exemple, le trajet pourra être calculé de façon à passer devant 50 feux tricolores, sous la pluie, en un laps de temps le plus réduit possible.

Quelle que soit l’optimisation, si aucun trajet partant de la position de départ et satisfaisant l’ensemble des conditions souhaitées n’est trouvé, le calculateur est programmé pour afficher un message d’erreur sur l’écran tactile.

Dans le cas contraire, parmi tous les trajets partant de la position de départ et satisfaisant l’ensemble des conditions souhaitées, le calculateur sélectionne le meilleur.

Si plusieurs types d’évènements routiers sont sélectionnés, le calculateur peut être amené à opérer un compromis. Un exemple de compromis serait par exemple que le nombre de chaque type d’infrastructures routières sélectionnées soit le même (ou le plus proche possible).

On peut prévoir, lorsque des évènements routiers de la catégorie « situations contextuelles » sont sélectionnés, que le calculateur acquiert dans la base de données cartographiques ou sur le réseau Internet (ou sur tout autre réseau ad hoc) des données de prédiction relatives à l’évolution future des situations contextuelles sélectionnées, puis il détermine ensuite le meilleur moment pour démarrer le trajet.

A titre d’exemple, si l’usager souhaite que l’essai se fasse sous la pluie, le calculateur pourra interroger un serveur qui est connecté au réseau Internet et sur lequel les prévisions météorologiques sont accessibles, puis il pourra déterminer l’heure la plus adaptée à la réalisation du trajet sous la pluie.

Le calculateur pourra alors indiquer à l’usager une heure ou un créneau horaire (ou un choix de plusieurs créneaux horaires) auquel il sera recommandé de démarrer le trajet. Cette indication pourra se faire par exemple par l’affichage d’un message correspondant sur l’écran tactile.

Dans le second mode de réalisation, le procédé est mis en œuvre par le calculateur d’un serveur central qui est connecté à une flotte de plusieurs voitures d’essais (ou aux conducteurs de ces voitures) et qui est commandé par l’usager.

Dans ce second mode de réalisation, la position de départ de chaque voiture d’essais est par exemple transmise par les voitures elles-mêmes ou par leurs conducteurs.

De préférence, les voitures d’essais de la flotte sont réparties dans au moins deux pays différents, et avantageusement dans un grand nombre de pays de façon à pouvoir contrôler que le système de conduite autonome fonctionne dans une grande variété de conditions.

Une fois les positions de départ des voitures d’essais connues, l’usager peut sélectionner sur le calculateur du serveur central les types d’évènements routiers que les voitures d’essais doivent rencontrer. Cette opération est réalisée de la même façon qu’énoncée précédemment.

L’usager sélectionne également des contraintes comme décrit supra. Toutefois, dans ce second mode de réalisation, on pourra prévoir de définir des contraintes différentes d’une voiture d’essais à l’autre (en fonction par exemple de leur motorisation thermique, électrique ou hybride), d’un pays à l’autre (la législation en termes de temps de pause pouvant par exemple varier).

Dans ce second mode de réalisation, la contrainte de première sorte, dont on rappelle qu’elle limite la durée des essais routiers, est exprimée de façon différente. Elle est ainsi définie par un nombre souhaité de type d’évènements de chaque sorte que l’on souhaite que les voitures d’essais de la flotte rencontrent pendant une période d’essais maximum donnée (chaque véhicule ayant une fréquence d’utilisation définie).

A titre d’exemple, chaque voiture d’essais pouvant être utilisée cinq jours sur sept pour un roulage de six heures, la contrainte de première sorte peut définir que la durée des essais sera de 6 mois maximum. On pourra alors demander au calculateur de trouver des trajets permettant aux voitures de la flotte de rencontrer 2000 feux tricolores, de rouler 200 heures sous la pluie…

L’étape de calcul des trajets est ensuite opérée pour chaque véhicule, en fonction de sa position de départ et des contraintes qui lui sont spécifiquement associées. Le calcul des trajets peut également être réalisé en fonction du pays dans lequel se trouve le véhicule (il est par exemple inutile de chercher des trajets enneigés dans les pays proches de l’équateur ou dans les pays où l’été sévit).

En pratique, le calculateur du serveur central calcule chaque jour un nouveau trajet pour chaque véhicule, en tenant compte des évènements routiers déjà rencontrés depuis le début des essais et des évènements routiers qu’il reste encore à rencontrer. Le calculateur du serveur central détermine ensuite les moments auxquels les voitures d’essais de la flotte devront commencer leurs trajets, puis il envoie des instructions de démarrage et un trajet associé à chaque voiture.

On peut prévoir que si tous les types d’évènements routiers ont été rencontrés le nombre souhaité de fois avant la fin de la campagne d’essais, le serveur central avertisse l’opérateur qu’il est possible de mettre fin à la campagne d’essais.

Dans le cas contraire, c’est-à-dire si, à la fin de la période de 6 mois de la campagne d’essais, tous les types d’évènements n’ont pas été rencontrés le nombre souhaité de fois, le calculateur en avertit l’opérateur.

Claims (10)

1. Procédé de planification d’au moins un trajet qu’au moins un véhicule automobile doit effectuer, comportant des étapes de :
   - détermination d’une position de départ de chaque véhicule automobile, et de
   - choix, par un calculateur, d’un trajet partant de la position de départ,
   caractérisé en ce qu’il comporte, avant l’étape de choix:
   - une étape de sélection d’au moins un type d’évènement routier (CI, POI, DR), et
   - une étape d’acquisition d’au moins une première contrainte restreignant le nombre de trajets pouvant être choisis, et
   en ce que, à l’étape de choix, le calculateur choisit le trajet de façon à optimiser :
   - le nombre et/ou la durée et/ou la longueur des évènements routiers (CI, POI, DR) de chaque type sélectionné le long du trajet, compte tenu de chaque première contrainte acquise, ou
   - chaque première contrainte acquise, compte tenu d’un nombre souhaité et/ou d’une durée souhaitée et/ou d’une longueur souhaitée des évènements routiers (CI, POI, DR) de chaque type sélectionné le long du trajet.
2. Procédé de planification selon la revendication précédente, dans lequel il est prévu de sélectionner ledit au moins un type d’évènements routiers parmi au moins une catégorie de types d’évènements routiers correspondant à des infrastructures routières (CI) stockées dans une mémoire d’un système de navigation.
3. Procédé de planification selon l’une des revendications précédentes, dans lequel il est prévu une étape préalable de pointage manuel d’au moins un point d’intérêt (POI) sur une carte et dans lequel il est prévu de sélectionner ledit au moins un type d’évènements routiers parmi au moins une catégorie de types d’évènements routiers correspondant à des points d’intérêt (POI) stockés dans une mémoire.
4. Procédé de planification selon l’une des revendications précédentes, dans lequel il est prévu de sélectionner ledit au moins un type d’évènements routiers parmi au moins une catégorie de types d’évènements routiers correspondant à des situations contextuelles (DR) qui portent sur :
   - le trafic routier, et/ou
   - les conditions météorologiques, et/ou
   - la hauteur du soleil, et/ou
   - la présence de travaux.
5. Procédé de planification selon la revendication précédente, dans lequel il est prévu une étape d’acquisition de données de prédiction relatives à l’évolution de la situation contextuelle sur le trajet, et une étape de détermination d’un meilleur moment pour démarrer le trajet en fonction desdites données de prédiction, de façon à maximiser la durée pendant laquelle le véhicule rencontrera la situation contextuelle le long du trajet.
6. Procédé de planification selon l’une des revendications précédentes, dans lequel ladite première contrainte est une contrainte de durée ou de longueur de trajet, ou une contrainte de nombre d’évènements routiers se trouvant sur le trajet, ou une contrainte de durée ou de longueur pendant laquelle des évènements routiers (CI, POI, DR) seront rencontrées.
7. Procédé de planification selon l’une des revendications précédentes, dans lequel il est prévu, avant l’étape de calcul, une étape de saisie d’au moins une seconde contrainte distincte de chaque première contrainte, et dans lequel, à l’étape de calcul, le trajet est calculé de façon à respecter chaque seconde contrainte saisie.
8. Procédé de planification selon la revendication précédente, dans lequel la seconde contrainte est une zone géographique dans laquelle le trajet doit être circonscrit, ou un nombre ou une fréquence d’arrêts que le véhicule automobile doit effectuer, ou une catégorie de zones dans lesquelles le véhicule automobile doit effectuer des arrêts.
9. Procédé de planification selon l’une des revendications précédentes, dans lequel ladite étape de sélection comporte une sous-étape d’affichage de plusieurs types d’évènements routiers sur un écran et une sous-étape de sélection manuelle par un usager d’au moins un des types d’évènements routiers affichés.
10. Calculateur comportant une interface adaptée à communiquer avec un système de navigation, une mémoire et un processeur, caractérisé en ce qu’il est adapté à mettre en œuvre un procédé de planification conforme à l’une des revendications précédentes.