Brevet FR2825500A1 — publié le 20021206

La présente invention se rapporte à un procédé de guidage d'un véhicule, à un dispositif de mise en oeuvre de ce procédé, et à un véhicule utilisant ce dispositif. On connaît du document WO 99 09374 un procédé de guidage d'un véhicule du type du type dans lequel, en réponse à une demande de guidage formulée par un utilisateur, a) on transmet d'une unité embarquée à au moins un serveur fixe notamment des données de position dudit véhicule, b) on reporte lesdites données de position sur une cartographie extraite d'au moins une base de données cartographiques reliée audit serveur fixe et c), à partir dudit report, on transmet dudit serveur fixe à ladite unité embarquée des données d'itinéraire en vue de fournir un service de guidage audit utilisateur. Ce procédé de la technique antérieure permet déporter à l'extérieur du véhicule notamment tout le système de positionnement du véhicule sur la base de données cartographiques. Ce procédé permet en outre de centraliser l'offre de service de guidage pour une pluralité de véhicules, et ainsi notamment de communiquer simultanément des informations à ces véhicules, de faire bénéficier ces véhicules instantanément des dernières mises à jour des bases de données cartographiques, etc. Ce procédé présente notamment comme inconvénient de fournir un niveau de service relativement médiocre. Ainsi, selon un premier exemple, lorsque l'unité embarquée se trouve dans une zone d'ombre, c'est-à-dire dans une zone où les échanges de données avec le serveur fixe sont impossibles faute de couverture hertzienne suffisante, l'utilisateur ne peut plus être guidé. Selon un deuxième exemple, lorsque le serveur fixe est saturé en raison d'un trop grand nombre de requêtes en provenance de véhicules, l'utilisateur ne peut plus être guidé. Selon un troisième exemple, lorsqu'un embouteillage se forme de manière soudaine sur l'itinéraire qui a été conseillé à l'utilisateur, le procédé selon la technique antérieure peut ne pas être suffisamment réactif pour proposer rapidement un itinéraire d'évitement. La présente invention a pour but principal d'améliorer le niveau de service fourni à l'utilisateur. On atteint ce but de l'invention avec un procédé de guidage d'un véhicule du type dans lequel, en réponse à une demande de guidage formulée par un utilisateur, a) on transmet d'une unité embarquée à au moins un serveur fixe notamment des données de position dudit véhicule, b) on reporte lesdites données de position sur une cartographie extraite d'au moins une base de données cartographiques reliée audit serveur fixe et c), à partir dudit report, on transmet dudit serveur fixe à ladite unité embarquée des données d'itinéraire en vue de fournir un service de guidage audit utilisateur, remarquable en ce qu'on prédéfinit une pluralité de stratégies d'échanges des données entre ladite unité embarquée et ledit serveur fixe et en ce qu'on sélectionne de manière dynamique celle desdites stratégies qui permet de fournir le meilleur niveau de service de guidage possible audit utilisateur compte tenu des contraintes liées au contexte de fonctionnement de ladite unité embarquée et dudit serveur fixe. Grâce à ces caractéristiques, la stratégie d'échanges de données entre l'unité embarquée et le serveur fixe n'est plus figée : on dispose en permanence d'un choix entre plusieurs stratégies, et on peut choisir à chaque instant celle qui permet d'optimiser le guidage de l'utilisateur compte tenu des conditions de communications et d'environnement dans lesquelles se trouvent l'unité embarquée et le serveur fixe. Suivant d'autres caractéristiques du procédé selon l'invention : - on détermine ledit contexte notamment à partir de paramètres caractérisant la qualité des communications entre ladite unité embarquée et ledit serveur fixe, - on choisit lesdits paramètres de communication dans le groupe des paramètres caractérisant : - la charge dudit serveur fixe, - la couverture de l'itinéraire dudit véhicule par un réseau de télécommunications non filaires, et - la bande passante de ladite unité embarquée en communication, - on détermine ledit contexte notamment à partir de paramètres caractérisant l'environnement où circule ledit véhicule, - on prédéfinit une première stratégie d'échanges dans laquelle on échange lesdites données indépendamment de la position dudit véhicule, - on échange lesdites données à intervalles de temps réguliers, - on prédéfinit une deuxième stratégie d'échanges dans laquelle on échange lesdites données en fonction de la position dudit véhicule, - on transmet de nouvelles données d'itinéraire à ladite unité embarquée lorsque ledit véhicule sort d'une partie prédéfinie de la zone de validité des dernières données d'itinéraire reçues, - on transmet à ladite unité embarquée un nouveau jeu de données d'itinéraire lorsque ledit véhicule arrive dans la dernière zone de validité du dernier jeu de données d'itinéraire reçu, - on transmet en outre à ladite unité embarquée des données d'itinéraire supplémentaires utiles en cas de sortie dudit véhicule de son itinéraire, - on prédéfinit une troisième stratégie d'échanges dans laquelle on envoie lesdites données d'itinéraire à ladite unité embarquée sous la forme d'une feuille de route, - on effectue une mise à jour des données d'itinéraire transmises à ladite unité embarquée au fur et à mesure que ledit véhicule se déplace, - on effectue le calcul d'itinéraire dans ledit serveur fixe, de manière à réduire le volume des données d'itinéraire transmises à ladite unité embarquée, - on transmet lesdites données d'itinéraire à ladite unité embarquée sous la forme d'informations de guidage directement utilisables par ladite unité embarquée, - on transmet lesdites données d'itinéraire à ladite unité embarquée sous la forme de pages de guidage dans un format choisi dans le groupe comprenant le WAP,l'HTML, le c-HTML, et le XML, - on transmet lesdites données d'itinéraire à ladite unité embarquée à la suite d'une requête formulée par ladite unité embarquée, cette requête contenant notamment la position dudit véhicule, - on formule ladite requête à partir d'un script envoyé à ladite unité embarquée en même temps que lesdites données d'itinéraire, - on utilise, pour former ledit script, un langage choisi dans le groupe comprenant le JavaScript, le VBScript, le Perl/CGI et le WMLScript, - on utilise, pour effectuer lesdits échanges de données, un protocole de communication choisi dans le groupe comprenant le GSM, le GPRS/GSM Phase Il et l'UMTS, - on sécurise lesdits échanges de données. La présente invention se rapporte également à un dispositif de mise en oeuvre du procédé susmentionné, comprenant a) une unité embarquée à bord dudit véhicule, b) des moyens embarqués d'indication de la position dudit véhicule interfacés avec ladite unité embarquée, c) au moins un serveur fixe ayant accès à au moins une base de données cartographiques, d) des moyens pour échanger des données entre ladite unité embarquée et ledit serveur fixe, e) des moyens pour engendrer des données d'itinéraire à partir du report de ladite position sur une carte extraite de ladite base de données cartographiques, et f) des moyens pour transmettre ces données d'itinéraire à ladite unité embarquée, remarquable en ce qu'il comprend en outre des moyens pour prédéfinir une pluralité de stratégies d'échanges des données entre ladite unité embarquée et ledit serveur fixe et pour sélectionner de manière dynamique celle desdites stratégies qui permet de fournir le meilleur niveau de service de guidage possible audit utilisateur compte tenu des contraintes liées au contexte de fonctionnement de ladite unité embarquée et dudit serveur fixe. Suivant d'autres caractéristiques de ce dispositif : - lesdits moyens embarqués d'indication de position comprennent un récepteur GPS, - ce dispositif comprend un gyromètre interfacé avec ladite unité embarquée, - ladite unité embarquée comprend des moyens d'interface avec des équipements dudit véhicule, - ledit serveur fixe a en outre accès à une base de données d'informations sur le trafic, - lesdits moyens d'échanges de données sont adaptés pour fonctionner avec un réseau de téléphonie cellulaire. La présente invention se rapporte également à un véhicule automobile, remarquable en ce qu'il utilise un dispositif conforme à ce qui précède. D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre et à l'examen du dessin annexé, dans lequel : - la figure 1 est une vue d'ensemble schématique du dispositif selon l'invention, - la figure 2 représente une page de guidage telle qu'elle peut apparaître sur le terminal de l'unité embarquée du dispositif selon l'invention, - les figures 3 et 4 matérialisent une première stratégie d'échanges de données entre l'unité embarquée et le serveur fixe du dispositif selon l'invention, - les figures 5 et 6 sont analogues respectivement aux figures 3 et 4, pour une première variante d'une deuxième stratégie d'échange de données, - les figures 7 et 8 sont analogues respectivement aux figures 3 et 4, pour une deuxième variante de la deuxième stratégie d'échange de données, - les figures 9 et 10 sont analogues respectivement aux figures 3 et 4, pour une troisième variante de la deuxième stratégie d'échanges de données, et - la figure 11 est analogue à la figure 4, pour une troisième stratégie d'échanges de données. Sur ces figures, des références identiques désignent des entités ou ensembles d'entités identiques ou analogues. On se reporte à présent à la figure 1, sur laquelle on voit que le dispositif selon l'invention comprend tout d'abord une unité 1 destinée à être embarquée à bord d'un véhicule automobile 3. Cette unité embarquée 1 comprend une unité de commande 5 ainsi qu'au moins un module de communication 9 et un module de localisation 11 reliés respectivement à un modem 13 et à un GPS et/ou à un gyromètre 15. On rappelle ici que le sigle GPS désigne un système de positionnement à trois dimensions (Global Positioning System). Il va de soi que tout autre système analogue de positionnement pourrait convenir. On rappelle également qu'un gyromètre est un dispositif permettant de connaître à chaque instant la position des roues directrices d'un véhicule, et par là même d'estimer la position d'un véhicule. L'unité de commande 5 est en outre reliée à un terminal 17 pouvant comprendre un écran d'affichage d'informations de guidage et un actuateur de commande. De manière optionnelle, l'unité embarquée 1 peut en outre comprendre une interface équipements véhicule 19 et une unité audio 21 reliées respectivement aux bus CAN 22 du véhicule 3 et à un ensemble de hautparleur/microphone 23. Le dispositif selon l'invention comprend également un serveur 25 fixe, c'est-à-dire débarqué du véhicule 3. Ce serveur fixe 25 comprend au moins une base de données cartographiques 27, un serveur d'itinéraire 29 et un frontal de communication 31. De manière optionnelle, ce serveur fixe 25 peut également comprendre un serveur d'information sur le trafic 32, une base de données clients 33 et un serveur de formatage 35. L'unité embarquée 1 et le serveur fixe 25 sont susceptibles d'échanger entre eux des données par l'intermédiaire du modem 13, du frontal de communication 31 et d'un réseau de télécommunications non filaires symbolisé par le trait mixte 37. Ce réseau peut par exemple être un réseau de téléphonie mobile utilisant l'un des protocoles de communication suivants : GPRS/GSM phase Il ou UMTS. En option, on peut sécuriser les échanges de données entre l'unité embarquée 1 et le serveur fixe 25. L'unité embarquée 1 dispose de préférence d'un système d'exploitation en temps réel supportant quatre logiciels : - un navigateur permettant d'afficher sur le terminal 17 les informations de guidage transmises, d'exécuter des scripts liés à ces informations, et de proposer un certain nombre de menus utiles pour l'utilisateur lors de la manipulation du terminal ; - un programme de localisation du véhicule 3, chargé de communiquer avec les moyens de positionnement : GPS et/ou gyromètre 15 ; - un programme de gestion des communications entre l'unité embarquée 1 et le serveur fixe 25, chargé d'assurer une bonne interface et le transfert de données entre cette unité et ce serveur ; - un programme d'interface entre l'unité embarquée 1 et le véhicule 3, chargé d'écouter les bus CAN présents et de récupérer les données utiles au guidage ainsi que les données utiles au confort d'utilisation du terminal 17 par le conducteur ; ces données comprennent notamment la vitesse du véhicule, l'état des feux de route, etc. On va à présent décrire le mode de fonctionnement du dispositif selon l'invention. L'utilisateur commence par formuler une demande de guidage sur le terminal 17 (et/ou en utilisant le microphone de l'ensemble 23), laquelle demande peut typiquement consister en un nom de lieu à atteindre, tel qu'un nom de rue, et en un critère de sélection d'itinéraire : itinéraire le plus court, le plus rapide, sans autoroute, etc. Cette demande de guidage est alors transmise à l'unité de commande 5 qui transmet alors une requête de guidage au module de communication 9, puis au modem 13 et au frontal de communication 31 via le réseau 37. En utilisant alors d'une part les données en provenance du GPS et/ou du gyromètre 15, lesquelles sont également transmises par le réseau 37, et d'autre part la base de données cartographiques 27, le serveur fixe 25 peut positionner précisément le véhicule 3 sur une carte routière. En option, le serveur d'itinéraire 29 peut solliciter le serveur d'informations sur le trafic 27, de manière à prendre en compte l'état de circulation des voies pour le guidage. Le serveur d'itinéraire 29 peut également extraire des données de la base de données clients 33 à des fins d'identification de l'utilisateur, de ses habitudes, etc. A partir de l'ensemble de ces données, le serveur d'itinéraire 29 procède alors à un calcul d'itinéraire. Une fois que cet itinéraire est calculé, il est transmis en retour sous forme de données d'itinéraire à l'utilisateur via le réseau 37, l'unité de commande 5, le terminal 17 et/ou le haut-parleur de l'ensemble 23. De préférence, avant d'être transmises à l'unité embarquée 1, les données d'itinéraire sont formatées par le serveur de formatage 35 en informations de guidage utilisables par l'unité embarquée 1 sans aucune transformation supplémentaire. De manière particulièrement préférée, ces informations de guidage consistent en pages de guidage dans un format choisi dans le groupe comprenant le WAP, l'HTML, le c-HTML, et le XML. On peut voir sur la figure 2 un exemple type de page de guidage 39 telle qu'elle apparaît sur le terminal 17 après mise en forme par le serveur de pages formatage 35 et transmission par le réseau 37 à l'unité de commande 5. Comme cela apparaît sur cette figure, la page de guidage 39 peut typiquement comprendre la destination à atteindre 41, le nom de l'axe 43 sur lequel le véhicule 3 est en train de circuler, la direction à suivre 45, la distance et la durée 47 séparant le véhicule 3 de la destination à atteindre, et des renseignements 49 relatifs aux carrefours rencontrés. Dans un mode de réalisation préféré, les données d'itinéraire transmises par le serveur fixe 25 à l'unité embarquée 1 comprennent également des scripts, c'est-à-dire des listes d'instructions que l'unité de commande 5 sera chargée d'appliquer. Ces scripts peuvent notamment permettre de décider sous quelles conditions une nouvelle requête de guidage devra être adressée au serveur fixe 25, dans le but de satisfaire la demande de guidage formulée par l'utilisateur. Ces scripts peuvent également permettre de gérer les stratégies d'échanges de données entre l'unité embarquée 1 et le serveur fixe 25 (voir ci-après). Pour former les scripts, on pourra par exemple utiliser un langage choisi dans le groupe comprenant le JavaScript, le VBScript, le Perl/CGI et le WMLScript. Ainsi, pour satisfaire la demande de guidage formulée par l'utilisateur, il s'établit une succession de requêtes/réponses entre l'unité embarquée 1 et le serveur fixe 25, grâce à quoi l'utilisateur va être guidé de proche en proche jusqu'à la destination voulue. Grâce au fait qu'on envoie à l'unité embarquée 1 un itinéraire déjà calculé, on peut réduire considérablement le volume des données d'itinéraire transmises à l'unité embarquée 1, et ainsi de réduire substantiellement les temps de réponse aux demandes de guidage formulée par l'utilisateur. On notera également que le fait d'envoyer à l'unité embarquée 1 un itinéraire déjà calculé permet de s'affranchir de tout applicatif spécifique dans cette unité embarquée : cette unité peut dès lors être simplifiée à l'extrême, ce qui permet d'abaisser notablement son coût de fabrication. L'absence d'applicatif spécifique permet d'envisager d'utiliser l'unité embarquée 1 de manière polyvalente, c'est-à-dire avec une pluralité de serveurs fournissant des services qui n'ont rien à voir entre eux : guidage, informations, météo... Cette polyvalence ouvre de nombreuses perspectives, étant donnée l'offre croissante de télé-services destinés aux automobilistes. Dans le cas où, avant de transmettre l'itinéraire calculé à l'unité embarquée 1, on le formate en informations de guidage directement utilisables par cette unité embarquée, les avantages susmentionnés sont accrus. On va à présent décrire différentes stratégies d'échanges de données possibles entre l'unité embarquée 1 et le serveur fixe 25. Ces stratégies vont être décrites dans le cas particulier où les informations de guidage sont transmises à l'unité embarquée 1 sous la forme de pages de guidage auxquelles sont associés des scripts, mais il va de soi que ces stratégies pourraient également s'appliquer dans les cas où ces informations sont transmises de toute autre manière, et notamment comme cela est enseigné dans la demande WO 99 09374. On se reporte à présent aux figures 3 et 4, sur lesquelles on a matérialisé une première stratégie d'échanges de données entre l'unité embarquée 1 et le serveur fixe 25. Sur la figure 3, le trait 51 représente l'itinéraire effectivement emprunté par le véhicule 3, les carrés 53 des pages de guidage transmises à l'unité embarquée 1 tout au long de cet itinéraire, et les cercles 55 les zones de validité respectives des informations fournies par les pages de guidage 53. Selon cette première stratégie (voir figure 4), on attache à chaque page 53 transmise un script ordonnant à l'unité embarquée 1 de transmettre la position 57 du véhicule 3 au serveur fixe 25 au bout d'une durée prédéterminée, indépendamment de la position du véhicule. Le serveur fixe 25 localise alors en 59 la position du véhicule sur une carte routière, puis engendre une page de guidage en 61 qu'il transmet ensuite en 63 à l'unité embarquée 1 en vue de l'affichage de cette page en 65 sur le terminal 17. Dans cette première stratégie, les pages de guidage 53 sont transmises à l'unité embarquée 1 à intervalles de temps réguliers, au risque d'être redondantes si le véhicule est arrêté ou avance lentement. Cela est illustré par la figure 3 où l'on voit que les zones 53 se chevauchent, c'est-à-dire que l'on a transmis une nouvelle page de guidage avant même que le véhicule 3 ne soit sorti de la zone de validité de la page de guidage précédente. Cette première stratégie, dans laquelle les échanges entre l'unité embarquée 1 et le serveur fixe 25 sont indépendants de la position du véhicule 3, présente comme avantage d'offrir à l'utilisateur une grande réactivité face aux sorties de route, aux changements de conditions de trafic, etc. Toutefois, cette première stratégie présente comme inconvénient de maximiser le nombre d'échanges entre l'unité embarquée 1 et le serveur fixe 25. Ainsi, cette stratégie ne convient pas lorsque les échanges entre l'unité embarquée 1 et le serveur fixe 25 sont difficiles ou impossibles, par exemple lorsque le serveur fixe 25 est saturé en raison d'un grand nombre d'appels en provenance d'autres véhicules, ou lorsque l'unité embarquée 1 évolue dans une zone d'ombre, c'est-à-dire dans une zone non couverte par le réseau 37 (voir figure 1). On se reporte à présent aux figures 5 à 10, sur lesquelles on a matérialisé trois variantes d'une deuxième stratégie d'échanges de données entre l'unité embarquée 1 et le serveur fixe 25. Dans une première variante de cette deuxième stratégie (voir figure 6), on attache à chaque page 53 transmise un script visant à déterminer la position du véhicule en 67 et à n'ordonner en 57 à l'unité embarquée 1 de transmettre la position du véhicule 3 au serveur fixe 25 que lorsque ce véhicule sort en 68 d'une partie 69 (voir figure 5) située à l'intérieur de la zone de validité des informations fournies par la page de guidage 53 en cours. Chaque partie 69 est délimitée sur la figure 5 par un cercle concentrique du cercle 55 correspondant, et le point où le véhicule 3 quitte cette partie porte la référence 71. Une fois que la position du véhicule 3 a été transmise à l'unité embarquée 25, les opérations se déroulent comme dans le cas de la première stratégie (voir figure 6). Cette première variante permet de réduire le nombre d'échanges entre l'unité embarquée 1 et le serveur fixe 25 par rapport à la première stratégie, tout en garantissant la justesse des informations fournies par chaque page de guidage. On se reporte à présent aux figures 7 et 8, sur lesquelles on a matérialisé la deuxième variante de la deuxième stratégie d'échanges de données entre l'unité embarquée 1 et le serveur fixe 25. Dans cette deuxième variante (voir figure 8), on attache à chaque page de guidage 53 transmise un script visant à mettre certaines informations de cette page à jour en 73. Ces informations peuvent être par exemple des icônes indiquant la direction à emprunter à un carrefour, ou la distance séparant le véhicule 3 de la destination à atteindre. La mise à jour de ces informations peut être effectuée selon des techniques connues de l'homme du métier, comme par exemple en utilisant le cache du navigateur de l'unité embarquée 1. En raison de cette mise à jour, la taille de chaque partie 69 (voir figure 7) peut être plus importante que dans le cas précédent. Cette deuxième variante est plus complexe quant aux algorithmes permettant d'engendrer les scripts placés du côté du serveur fixe 25, et plus lourde quant aux données transmises parce qu'elle nécessite une augmentation de la taille des scripts. Cependant, cette deuxième variante permet de réduire le nombre d'échanges entre l'unité embarquée 1 et le serveur fixe 25. On se reporte à présent aux figures 9 et 10, sur lesquelles on a matérialisé la troisième variante de la deuxième stratégie d'échanges de données entre l'unité embarquée 1 et le serveur fixe 25. Dans cette troisième variante (voir figure 10), on envoie en 74 des jeux de pages de guidage à l'unité embarquée 1. Les scripts contenus dans les jeux de pages permettront ensuite au navigateur d'afficher en 75 des pages de guidage correspondant à la position effective du véhicule 3. On distingue deux types de jeux de pages : ceux qui suivent l'itinéraire 51 proposé par le serveur fixe 25, et ceux qui sont utiles en cas de sortie d'itinéraire par le véhicule 3. Ces derniers jeux de pages contiennent un script de transmission de la position du véhicule en 79 afin de télécharger un nouveau jeu de pages qui correspond à la situation courante. Le même principe est utilisé en cas de demi-tour du véhicule ou bien en cas d'affichage de la dernière page du jeu transmis. On a représenté sur la figure 9, en 81, la zone de validité de la première page 82 d'un jeu 83, en 84 la zone de validité de la dernière page 85 de ce jeu, et en 86 les zones de validité des pages intermédiaires 87 de ce jeu. On a représenté en 88 des zones de sorties d'itinéraire pour lesquelles on va demander au serveur fixe 25 un nouveau jeu de pages de guidage. Cette troisième variante alourdit notablement les données transmises et réduit la précision du positionnement du véhicule 3 dans la mesure où entre deux transmissions de cette position au serveur fixe 25, on ne rapproche pas directement cette position d'une base de données cartographiques. En revanche, cette troisième variante permet de réduire de manière significative le nombre d'échanges entre l'unité embarquée 1 et le serveur fixe 25, étant donné qu'après avoir reçu le jeu de pages de guidage et tant que le véhicule 3 se trouve dans une zone couverte par ce jeu, l'unité embarquée 1 gère ce jeu de manière complètement autonome. Comme on peut le comprendre à la lumière de ce qui précède, les trois variantes de la deuxième stratégie présentent ceci de commun que les échanges de données entre l'unité embarquée 1 et le serveur fixe 25 dépendent de la position du véhicule 3. On se reporte à présent à la figure 11, sur laquelle on a matérialisé une troisième stratégie d'échanges de données entre l'unité embarquée 1 et le serveur fixe 25. Dans cette troisième stratégie, on se contente de transmettre une simple feuille de route 90 à l'unité embarquée 1. Cette feuille de route consiste en une série d'instructions à suivre pour atteindre la destination souhaitée, ces instructions étant figées, c'est-à-dire qu'elles ne sont pas mises à jour régulièrement contrairement aux stratégies précédentes. Il n'y a pas de relation entre la position courante du véhicule automobile et les informations affichées par le terminal embarqué 17 : en cas de sortie de route du véhicule, la feuille de route ne sera modifiée qu'après un échange entre l'unité embarquée 1 et le serveur fixe 25, si toutefois celui-ci est possible. Cette troisième stratégie est une solution minimale du service de guidage lorsque la qualité des communications entre l'unité embarquée 1 et le service de guidage 25 est trop limitée : dans ce cas le débit utile est trop faible pour pouvoir transmettre des pages de guidage en temps réel. Le choix entre les stratégies qui viennent d'être présentées s'effectue au sein du serveur fixe 25 et/ou de l'unité embarquée 1 en fonction du contexte de fonctionnement de ce serveur et de cette unité embarquée. Par contexte de fonctionnement, on entend ici notamment une série de paramètres caractérisant la qualité des communications entre l'unité embarquée 1 et le serveur fixe 25, et une série de paramètres caractérisant l'environnement où circule le véhicule 3. A titre d'exemple, les paramètres de communication peuvent caractériser la bande passante du terminal embarqué 1 en communication et/ou la charge du serveur fixe 25 pour le calcul des pages de guidage et/ou le degré de couverture par le réseau 37 de la zone où se trouve le véhicule 3. A titre d'exemple, les paramètres d'environnement peuvent caractériser les conditions de circulation et/ou les conditions météorologiques sur l'itinéraire du véhicule 3. Ainsi par exemple, s'il s'avère que les conditions de circulation se dégradent brutalement sur un itinéraire précédemment calculé par le serveur fixe 25, on peut imaginer que l'unité embarquée 1 émette une requête prioritaire permettant de passer de la troisième stratégie à la deuxième ou à la première, pour autant que les conditions de communications le permettent, de manière à fournir à l'utilisateur des informations actualisées de manière très réactive. Le principe général qui gouverne le choix des stratégies consiste à fournie en permanence le meilleur niveau de service de guidage possible à l'utilisateur compte tenu des contraintes, notamment de communications et d'environnement, rencontrées par le dispositif de guidage. Par meilleur niveau de service possible , on entend ici que le dispositif de guidage s'efforce en permanence de déterminer celle des stratégies d'échanges de données qui peut fournir le plus d'informations utiles au guidage, c'est-à-dire d'informations permettant de conduire l'utilisateur jusqu'à la destination souhaitée en respectant ses critères de sélection d'itinéraire (itinéraire le plus court, le plus rapide, sans autoroute, etc.). Comme on peut le comprendre à présent, le choix dynamique, c'est-àdire en temps réel entre les stratégies susmentionnées, permet de conférer au service de guidage une grande souplesse de fonctionnement et, au bout du compte, d'améliorer considérablement le niveau de service rendu par rapport à la technique antérieure. Bien entendu, la présente invention n'est pas limitée au mode de réalisation décrit et représenté, fourni à titre d'exemple illustratif et non limitatif. C'est ainsi par exemple que l'on pourrait envisager d'autres stratégies d'échanges de données que celles qui ont été décrites, et/ou que l'on pourrait envisager de combiner certaines de ces stratégies. REVENDICATIONS 1. Procédé de guidage d'un véhicule (3) du type dans lequel, en réponse à une demande de guidage formulée par un utilisateur, a) on transmet d'une unité embarquée (1) à au moins un serveur fixe (25) notamment des données de position dudit véhicule (3), b) on reporte lesdites données de position sur une cartographie extraite d'au moins une base de données cartographiques (27) reliée audit serveur fixe (25) et c), à partir dudit report, on transmet dudit serveur fixe (25) à ladite unité embarquée (1) des données d'itinéraire en vue de fournir un service de guidage audit utilisateur, caractérisé en ce qu'on prédéfinit une pluralité de stratégies d'échanges des données entre ladite unité embarquée (1) et ledit serveur fixe (25) et en ce qu'on sélectionne de manière dynamique celle desdites stratégies qui permet de fournir le meilleur niveau de service de guidage possible audit utilisateur compte tenu des contraintes liées au contexte de fonctionnement de ladite unité embarquée (1) et dudit serveur fixe (25). 2. Procédé selon la revendication 1, caractérisé en ce qu'on détermine ledit contexte notamment à partir de paramètres caractérisant la qualité des communications entre ladite unité embarquée (1) et ledit serveur fixe (25). 3. Procédé selon la revendication 2, caractérisé en ce qu'on choisit lesdits paramètres de communication dans le groupe des paramètres caractérisant : - la charge dudit serveur fixe (25), - la couverture de l'itinéraire (51) dudit véhicule (3) par un réseau de télécommunications non filaires (37), et - la bande passante de ladite unité embarquée (1) en communication. 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on détermine ledit contexte notamment à partir de paramètres caractérisant l'environnement où circule ledit véhicule (3). 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on prédéfinit une première stratégie d'échanges dans laquelle on échange lesdites données indépendamment de la position dudit véhicule (3). 6. Procédé selon la revendication 5, caractérisé en ce qu'on échange lesdites données à intervalles de temps réguliers. 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on prédéfinit une deuxième stratégie d'échanges dans laquelle on échange lesdites données en fonction de la position dudit véhicule (3). 8. Procédé selon la revendication 7, caractérisé en ce qu'on transmet de nouvelles données d'itinéraire à ladite unité embarquée lorsque ledit véhicule (3) sort d'une partie prédéfinie (69) de la zone de validité (55) des dernières données d'itinéraire reçues. 9. Procédé selon l'une des revendications 7 ou 8, dans lequel on transmet des jeux de données d'itinéraire à ladite unité embarquée (1), caractérisé en ce qu'on transmet à ladite unité embarquée (1) un nouveau jeu de données d'itinéraire lorsque ledit véhicule (3) arrive dans la dernière zone de validité (84) du dernier jeu de données d'itinéraire reçu. 10. Procédé selon la revendication 9, caractérisé en ce qu'on transmet en outre à ladite unité embarquée (1) des données d'itinéraire supplémentaires utiles en cas de sortie dudit véhicule (3) de son itinéraire (51). 11. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on prédéfinit une troisième stratégie d'échanges dans laquelle on envoie lesdites données d'itinéraire à ladite unité embarquée (1) sous la forme d'une feuille de route. 12. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on effectue une mise à jour des données d'itinéraire transmises à ladite unité embarquée (1) au fur et à mesure que ledit véhicule (3) se déplace. 13. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on effectue le calcul d'itinéraire dans ledit serveur fixe (25), de manière à réduire le volume des données d'itinéraire transmises à ladite unité embarquée (1). 14. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on transmet lesdites données d'itinéraire à ladite unité embarquée (1) sous la forme d'informations de guidage directement utilisables par ladite unité embarquée (1). 15. Procédé selon la revendication 14, caractérisé en ce qu'on transmet lesdites données d'itinéraire à ladite unité embarquée (1) sous la forme de pages de guidage (39) dans un format choisi dans le groupe comprenant le WAP, l'HTML, le c-HTML, et le XML. 16. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on transmet lesdites données d'itinéraire à ladite unité embarquée (1) à la suite d'une requête formulée par ladite unité embarquée (1), cette requête contenant notamment la position dudit véhicule (3). 17. Procédé selon la revendication 16, caractérisé en ce qu'on formule ladite requête à partir d'un script envoyé à ladite unité embarquée (1) en même temps que lesdites données d'itinéraire. 18. Procédé selon la revendication 17, caractérisé en ce qu'on utilise, pour former ledit script, un langage choisi dans le groupe comprenant le JavaScript, le VBScript, le Perl/CGI et le WMLScript. 19. Procédé selon l'une quelconque des revendications précédentes, caractérisé en qu'on utilise, pour effectuer lesdits échanges de données, un protocole de communication choisi dans le groupe comprenant le GSM, le GPRS/GSM Phase Il et l'UMTS. 20. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on sécurise lesdits échanges de données. 21. Dispositif de mise en oeuvre d'un procédé conforme à l'une quelconque des revendications précédentes, comprenant a) une unité embarquée (1) à bord dudit véhicule (3), b) des moyens embarqués (15) d'indication de la position dudit véhicule (3) interfacés avec ladite unité embarquée (1), c) au moins un serveur fixe (25) ayant accès à au moins une base de données cartographiques (27), d) des moyens (13,31, 37) pour échanger des données entre ladite unité embarquée (1) et ledit serveur fixe (25), e) des moyens pour engendrer des données d'itinéraire à partir du report de ladite position sur une carte extraite de ladite base de données cartographiques (27), et f) des moyens pour transmettre ces données d'itinéraire à ladite unité embarquée (1), caractérisé en ce qu'il comprend en outre des moyens (29) pour prédéfinir une pluralité de stratégies d'échanges des données entre ladite unité embarquée (1) et ledit serveur fixe (25) et pour sélectionner de manière dynamique celle desdites stratégies qui permet de fournir le meilleur niveau de service de guidage possible audit utilisateur compte tenu des contraintes liées au contexte de fonctionnement de ladite unité embarquée (1) et dudit serveur fixe (25). 22. Dispositif selon la revendication 21, caractérisé en ce que lesdits moyens embarqués (15) d'indication de position comprennent un récepteur GPS. 23. Dispositif selon l'une des revendications 21 ou 22, caractérisé en ce qu'il comprend un gyromètre (15) interfacé avec ladite unité embarquée (1). 24. Dispositif selon l'une quelconque des revendications 21 à 23, caractérisé en ce que ladite unité embarquée (1) comprend des moyens d'interface (19) avec des équipements (22) dudit véhicule (3). 25. Dispositif selon l'une quelconque des revendications 21 à 24, caractérisé en ce que ledit serveur fixe (25) a en outre accès à une base de données (32) d'informations sur le trafic. 26. Dispositif selon l'une quelconque des revendications 21 à 25, caractérisé en ce que lesdits moyens d'échanges de données sont adaptés pour fonctionner avec un réseau de téléphonie cellulaire (37). 27. Véhicule automobile (3), caractérisé en ce qu'il utilise un dispositif conforme à l'une quelconque des revendications 21 à 26.