FR2946301A1 - Dispositif et procede de commande adaptative d'une flotte de vehicules automobiles - Google Patents

Abstract

L'invention vise un système et un procédé de mise en service adaptative d'une flotte de véhicules automobiles, dans laquelle chaque véhicule est muni d'un contrôleur de bord capable d'agir sur des organes de bord en fonction d'un jeu de paramètres utilisateur dont le codage est spécifique du véhicule, le procédé comprenant les étapes suivantes : a. munir le contrôleur de bord d'une interface d'entrée propre à recevoir un premier jeu de données, et d'un convertisseur de données du premier jeu en paramètres utilisateur, b. prévoir une structure de base de données, cette structure comprenant un champ pour un identifiant utilisateur et au moins un champ pour un jeu de données d'itinérance, c. remplir la base de données, d. munir la base de données d'une interface de travail propre à : d1. recevoir des données d'identifiant utilisateur, d2. sur réception de données d'identifiant utilisateur, extraire une partie au. moins du jeu de données d'itinérance correspondant aux données d'identifiant utilisateur pour transmission à la première interface du contrôleur de bord d'un véhicule automobile en tant que premier jeu de données.

Description

TFR0694 1 Dispositif et procédé de commande adaptative d'une flotte de véhicules automobiles

L'invention concerne un procédé de mise en service adaptative 5 d'une flotte de véhicules automobiles, ainsi qu'un système de commande adaptative des véhicules de cette flotte.

Une flotte désigne un ensemble de véhicules, de modèles potentiellement différents, géré par une même entité physique 10 ou morale.

On s'intéresse plus particulièrement aux flottes de véhicules destinées à être utilisées par des conducteurs différents. Les flottes de ce type peuvent être qualifiées de 15 partagées . Elles sont assez largement répandues.

Les entreprises de location de véhicules automobiles, par exemple, maintiennent en service et mettent à disposition de leurs clients une flotte de véhicules, souvent hétérogène. 20 De nombreuses entreprises ou organismes utilisent également une flotte partagée. Tel peut être le cas des entreprises de livraison, des entreprises ou organisations de distribution de courrier, ou encore des entreprises de transport en 25 commun.

De manière générale, on rencontre des flottes partagées lorsque le nombre de véhicules à disposition des conducteurs potentiels est inférieur au nombre de ces conducteurs. Par définition, dans une flotte partagée, un même véhicule peut être utilisé par des conducteurs différents, éventuellement de manière régulière et fréquente. 30

2 Pour un conducteur particulier, l'utilisation d'un véhicule d'une flotte partagée a pour conséquence l'utilisation d'un véhicule précédemment utilisé par un autre conducteur.

Et pour un utilisateur régulier, les véhicules conduits peuvent être différents les uns des autres, y compris en termes de modèles.

Parallèlement à cela, les véhicules automobiles actuels peuvent être adaptés dans une large mesure au conducteur, en particulier pour ce qui concerne le confort dans l'habitacle, la conduite du véhicule, l'adaptation du poste de conduite ou encore l'utilisation des équipements accessoires.

Depuis longtemps par exemple, le poste de conduite peut être adapté à la morphologie du conducteur. Avant d'utiliser son véhicule, ce dernier doit s'assurer du bon positionnement de son siège par rapport aux différentes pédales et du dossier par rapport au volant. Il doit également régler l'orientation des différents rétroviseurs du véhicule.

Avec le temps, les possibilités d'adaptation des équipements du véhicule au conducteur ont été multipliées : des possibilités de réglage ont été ajoutées aux équipements classiques, ou de base, du véhicule, comme le réglage en hauteur du volant ou du siège, et de nouveaux équipements sont apparus lesquels nécessitent, ou permettent, un paramétrage utilisateur, comme les outils d'aide à la navigation ou les autoradios par exemple.

L'adaptation du véhicule nécessite cependant un certain effort de la part de son conducteur, du fait du nombre d'équipements à régler et de l'éventuelle complexité des réglages.

3 Et l'utilisateur d'une flotte partagée doit régulièrement réitérer ces réglages du fait qu'un autre a précédemment utilisé, et donc réglé, son véhicule.

Cette situation est d'autant plus gênante que l'utilisation d'un véhicule de la flotte est fréquente, par exemple pour une mise en service quotidienne.

Cette gêne se trouve augmentée lorsque des véhicules de modèles différents sont utilisés, car s'ajoute en plus la difficulté du réglage lui-même, a fortiori lorsque le véhicule est inconnu de l'utilisateur.

Sur un tout autre plan, il existe une difficulté qui provient de l'absence de moyens permettant au gestionnaire de la flotte de procéder à des réglages identiques sur l'ensemble des véhicules de cette flotte, tels que l'activation obligatoire de l'ensemble des dispositifs du véhicule permettant de réduire la consommation du véhicule (limiteur de vitesse, arrêt/redémarrage automatique du moteur, blocage de la température ambiante dans l'habitacle).

Le procédé et le système proposés visent à améliorer cette situation.

Le procédé visé permet une mise en service adaptative d'une flotte de véhicules automobiles, dans laquelle chaque véhicule est muni d'un contrôleur de bord capable d'agir sur des organes de bord en fonction d'un jeu de paramètres utilisateur dont le codage est spécifique du véhicule, le procédé comprenant les étapes suivantes : a. munir le contrôleur de bord d'une interface d'entrée propre à recevoir un premier jeu de données, et

4 d'un convertisseur de données du premier jeu en paramètres utilisateur, b. prévoir une structure de base de données, cette structure comprenant un champ pour un identifiant utilisateur et au moins un champ pour un jeu de données d'itinérance, c. remplir la base de données, d. munir la base de données d'une interface de travail propre à : dl. recevoir des données d'identifiant utilisateur, d2. sur réception de données d'identifiant utilisateur, extraire une partie au moins du jeu de données d'itinérance correspondant aux données d'identifiant utilisateur pour transmission à la première interface du contrôleur de bord d'un véhicule automobile en tant que premier jeu de données. Ce procédé prévoit en outre l'utilisation d'un outil de transmission sans fil entre l'interface de travail et l'interface d'entrée du contrôleur de bord pour la transmission du jeu de données d'itinérance. Ce procédé prévoit aussi l'utilisation d'un support de mémorisation de données par l'intermédiaire duquel la transmission des données d'itinérance peut être réalisée entre l'interface de travail et l'interface d'entrée du contrôleur de bord. Selon le procédé, l'étape a. comprend : al. Prévoir un contrôleur supplémentaire dans le véhicule automobile capable de recevoir de secondes données et de les convertir en premières données, les premières données étant spécifiques dudit véhicule tandis que les secondes données sont communes aux véhicules de la flotte. De manière similaire, l'étape a. comprend : a2. munir le contrôleur de bord d'une interface de sortie propre à délivrer un troisième jeu de données, et d'un convertisseur des paramètres utilisateur en données 5 de troisième jeu, et dans lequel, à l'étape d., l'interface de travail est en outre capable de : d3. recevoir les données de troisième jeu, d4. sur réception de ces données de troisième jeu et de données d'identifiant utilisateur, mettre à jour le champ pour le jeu de données d'itinérance correspondant avec ce troisième jeu de données. L'invention vise aussi un système de commande adaptative de véhicules automobiles dans une flotte comprenant : - un contrôleur de bord installable dans des véhicules de la flotte, capable d'émettre une série d'instructions agissant sur les organes de bord en fonction de paramètres utilisateur dont le codage est spécifique du véhicule, ledit contrôleur comprenant : - une interface d'entrée propre à recevoir un premier jeu de données, - un convertisseur de données pour convertir les données du premier jeu en paramètres utilisateur, une structure de base de données comprenant un champ pour un identifiant utilisateur et au moins un champ pour un jeu de données d'itinérance, la base de données étant remplie de données d'identifiant utilisateur et de données d'itinérance, - une interface de travail pour la structure de base de données agencée pour : recevoir des données d'identifiant utilisateur

6 - sur réception de ces données d'identifiant utilisateur, extraire une partie au moins du jeu de données d'itinérance correspondant, un outil de transmission actif entre l'interface de travail et l'interface d'entrée du contrôleur de bord d'un véhicule automobile pour le transfert des données d'itinérance extraites en tant que premier jeu de données. Avantageusement, l'outil de transmission est de type sans 10 fil. Avantageusement encore, le système comprend en outre un support de mémorisation de données par l'intermédiaire duquel la transmission des données d'itinérance peut être réalisée entre l'interface de travail et l'interface d'entrée du 15 contrôleur de bord. Selon une première variante, un contrôleur supplémentaire capable de recevoir de secondes données et de les convertir en premières données est installé dans le véhicule automobile, les premières données étant spécifiques dudit 20 véhicule tandis que les secondes données sont communes aux véhicules de la flotte. Le contrôleur de bord comprend en outre : - une interface de sortie propre à délivrer un troisième jeu de données, et 25 - un convertisseur des paramètres utilisateur en données de troisième jeu, et dans lequel l'interface de travail est en outre agencée pour : - recevoir les données de troisième jeu, 30 - sur réception de ces données de troisième jeu et de données d'identifiant utilisateur, mettre à jour le champ pour le jeu de données d'itinérance correspondant avec ce troisième jeu de données.

7 Ce procédé et ce système permettent à un utilisateur de retrouver l'ensemble de ses réglages personnels, liés à sa morphologie ou à ses goûts, et de rétablir ces réglages de manière automatique, et ce quelque soit le véhicule en question.

D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description ci-après, et des dessins annexés, sur lesquels : La figure 1 est un schéma fonctionnel illustrant un système de commande selon un premier mode de réalisation de l'invention,

15 - La figure 2 est un schéma fonctionnel illustrant un contrôleur de bord pour le système de la figure 1,

La figure 3 est un schéma fonctionnel illustrant un microprogramme à exécution par le contrôleur de la 20 figure 2,

La figure 4 est un schéma fonctionnel illustrant un système de commande selon un second mode de réalisation de l'invention, La figure 5 est un schéma fonctionnel illustrant un contrôleur additionnel pour le système de commande de la figure 4,

30 La figure 6 est un schéma fonctionnel illustrant un microprogramme à exécution par le contrôleur additionnel de la figure 5, et 25

8 - Les figures 7 à 10 sont des schémas fonctionnels illustrant des variantes de réalisation d'un outil de communication pour les systèmes des figures 1 et 4.

Ces dessins contiennent des éléments de caractères certains, en sorte qu'ils pourront contribuer à la définition de l'invention, le cas échéant.

La figure 1 montre un premier mode de réalisation d'un système de commande adaptative de véhicules automobiles dans une flotte, lequel est désigné ci-après premier système de commande 1. La flotte en question comprend une pluralité de véhicules automobiles, de modèles potentiellement différents.

Le premier système de commande 1 comprend plusieurs contrôleurs de bord, ou contrôleurs ECU 3, propres à être installés chacun à bord d'un véhicule de la flotte.

Chaque contrôleur ECU 3 est capable d'interaction avec certains au moins des organes de bords du véhicule automobile correspondant, en particulier pour commander ces derniers selon des paramètres stockés dans une mémoire accessible par le contrôleur ECU 3. Le codage de ces paramètres est spécifique du modèle de véhicule automobile ou du véhicule automobile lui-même, en particulier car des véhicules de modèles différents peuvent embarquer des organes de bords de modèles différents, et donc à commander différemment.

Le premier système de commande 1 comprend en outre une base 30 de données utilisateurs, ou base USRDB 5.

La structure de la base USRDB 5 comprend au moins un champ d'identifiant utilisateur et au moins un champ de données de profil utilisateur maintenus en relation mutuelle.

9 Les données de profil utilisateur comprennent toutes données susceptibles de participer à la définition de l'environnement du conducteur à l'intérieur de l'habitacle du véhicule et de l'interaction entre ce conducteur et ledit véhicule. Les données de profil utilisateur comprennent en particulier toutes données de nature à être exploitées pour la commande, le paramétrage, le fonctionnement, la mise à jour, l'exploitation des organes de bord d'un véhicule automobile.

Les données de profil utilisateur peuvent également comprendre des données issues de l'environnement du conducteur à l'intérieur de l'habitacle du véhicule ou de l'interaction entre ce conducteur et ledit véhicule. Les données de profil utilisateur comprennent des données susceptibles de varier d'un utilisateur à un autre.

Dans la base USRDB 5, les données de profil utilisateur sont 20 stockées sous une forme indépendante de tout modèle de véhicule automobile. Les données de profil utilisateur sont communes à l'ensemble des véhicules de la flotte - y compris lorsque celle-ci comprend des véhicules de différents modèles - en leur forme et en leur valeur. On entend par là que ces 25 données de profil utilisateur vont pouvoir être exploitées par tout contrôleur ECU 3 équipant un véhicule de la flotte, quel que soit le modèle de ce véhicule.

Ces données de profil utilisateur peuvent être qualifiées de 30 données d'itinérance, du point de vu de l'utilisateur, car elles permettent de définir l'environnement du conducteur et son interaction avec celui-ci, à tout moment et sur tout véhicule. En ce sens, les données de profil suivent un15 10 utilisateur d'un véhicule à un autre et peuvent être qualifiées d'universelles du point de vue des véhicules.

Les données de profil utilisateur stockées dans la base USRDB 5 5 sont spécifiques d'un utilisateur, mais peuvent être exploitées indifféremment par les véhicules de la flotte.

Lorsqu'une même donnée de profil utilisateur, ou un même ensemble de données, est susceptible d'être exploitée par 10 plusieurs véhicules de la flotte, y compris de modèles différents, cette donnée est mémorisée une unique fois dans la base USRDB 5, sous une forme indépendante de ces véhicules.

15 Cela n'exclut pas le stockage additionnel dans la base USRDB 5 de données spécifiques à la fois d'un utilisateur et de certains seulement des véhicules de la flotte, en particulier d'un même modèle, en relation avec les données d'identifiant de cet utilisateur. Autrement dit, la base USRDB 5 peut 20 également maintenir des données exploitables uniquement par des organes de bord des véhicules de certains modèles seulement.

Les données de profil utilisateur, ou d'itinérance, peuvent 25 par exemple comprendre :

- des données relatives au système de climatisation d'un véhicule, telles que des données de température d'habitacle préférée, des données d'état préféré du système de 30 climatisation (en fonctionnement ou arrêté), des données de température de déclenchement du système de climatisation, des données de niveau d'ouverture pour des organes de ventilation, des données de débit d'air soufflé, des données de différentiel préféré entre une température d'habitacle et

11 une température d'extérieur, du véhicule et la température de l'habitacle, des données de mode de fonctionnement du système de climatisation (circuit d'air ouvert ou fermé), ou analogues ; - des données relatives au système d'assistance à la navigation, par exemple de type GPS - pour Global Positioning System ou système de localisation mondial - telles que des données d'adresses, des données de préférence pour la sélection parmi plusieurs itinéraires (rapidité, économie, distance à parcourir, consommation, par exemple), des données d'état du guidage vocale (activé, désactivé, voix féminine ou masculine), ou analogues ; - des données relatives à la configuration du poste de conduite, telles que des données de morphologie du conducteur (longueur de bras, longueur de jambes, ou analogues), des données de définition absolue du poste de conduite (angle d'inclinaison du dossier par rapport à la verticale, hauteur de l'assise par rapport au plancher du véhicule, hauteur de l'accoudoir par rapport au plancher du véhicule ou à l'assise, distance volant-dossier en un point référence de ce dernier, distance volant-assise, position indexée du volant, hauteur de la ceinture de sécurité sur le montant du véhicule), ou analogues ;

- des données relatives à l'autoradio, telles que des données d'identification de stations de radios préférées, des données de niveau sonore, des données d'équaliseur sonore, ou analogues ;

- des données d'activation, de réglage, ou d'inhibition de la fonction d'éclairage temporisé (en anglais follow me home ), ou analogues ; de sorte à maintenir allumé les

12 phares ou l'éclairage intérieur d'un véhicule pendant un temps spécifiquement adapté à l'utilisateur.

- des données de position d'arrêt intermédiaire du système d'assistance à l'ouverture ou fermeture d'ouvrant (en anglais Power Closure System ), ou analogues ; de sorte à programmer la motorisation du coffre pour que ce dernier s'ouvre à un hauteur compatible avec la taille de l'utilisateur ou encore éviter que l'ouvrant de coffre vienne heurter un plafond (spécificité d'un utilisateur) ; on peut aussi prévoir une temporisation sur la condamnation des ouvrants du véhicule.

- des données spécifiques du conducteur - autres que des données liées aux préférences de ce dernier -, en particulier statistiques, telles que des données de kilométrage cumulé, des données de consommation cumulée, des données de vitesse moyenne, des données de dépassement de vitesse maximum autorisée, ou analogues.

Le contrôleur ECU 3 comprend une interface d'entrée/sortie, ou interface I/O 7, propre à recevoir des données de profil utilisateur pour exploitation.

Les interfaces I/O 7 respectives des contrôleurs ECU 3 de la flotte sont agencées de manière analogues, c'est-à-dire quelles permettent la réception des données de profil utilisateur sous une forme qui leur est commune.

Cela ne signifie pas que les données de profils utilisateurs stockées dans la base USRDB 5 ne subissent pas une quelconque conversion de format, mais simplement que cette conversion n'est pas spécifique d'un contrôleur ECU 3 de la flotte en particulier. Autrement dit, lorsqu'une modification de format

13 doit être apportée aux données de profil utilisateur telles que stockées dans la base USRDB 5 pour réception par l'interface I/O 7 d'un contrôleur ECU 3, cette conversion est telle que les données converties sont compatibles avec une réception par l'interfaces I/O 7 de chacun des contrôleurs ECU 3 de la flotte.

Le premier système de commande 1 comprend encore une interface de travail, ou interface UI 9, capable 10 d'interaction avec la base USRDB 5.

L'interface UI 9 est propre à recevoir des données d'identifiant utilisateurs et, sur réception de ces données, à générer une requête à destination de la base USRDB 5 pour 15 en extraire une partie au moins des données de profil utilisateur associées à l'identifiant en question.

L'interface UI 9 peut prendre de nombreuses formes différentes, qui dépendent en particulier de la structure de 20 la base USRDB 5, du moteur de cette base, des moyens informatiques mis en œuvre pour le maintien de cette base, des moyens informatiques utilisés pour le fonctionnement de l'interface UI 9 et de la situation physique des moyens informatiques liés à cette interface UI 9 par rapport à ceux 25 liés à la base USRDB 5.

La base USRDB 5 peut être maintenue par un serveur accessible à distance, par exemple au travers du réseau Internet. Dans ce cas l'interface UI 9 peut comprendre une page Internet 30 lisible par l'intermédiaire d'un navigateur.

La base USRDB 5 peut également être maintenue sur un serveur de fichier uniquement accessible depuis le réseau local auquel est relié le serveur en question. Dans ce cas,

14 l'interface UI 9 peut prendre la forme d'un programme exécutable s'appuyant sur le protocole de communication du réseau pour interrogation de cette base de données USRDB 5.

L'interface UI 9 et la base USRDB 5 peuvent également opérer sur une même machine physique.

Le premier système de commande 1 comprend également un outil de transmission de données, ou outil COM 11, actif entre 10 l'interface UI 9 et l'interface I/O 7.

L'outil COM 11 permet la transmission des données de profil utilisateur extraites par l'interface UI 9 à l'interface I/O 7 du contrôleur ECU 7 d'un véhicule de la flotte. 15 L'émission des données de profil utilisateur peut être commandée par l'intermédiaire de l'interface UI 9. Cette émission peut être automatique, en ce sens qu'elle intervient après l'extraction des données de profil utilisateur de la 20 base USRDB 5 sans autre action de déclenchement, ou nécessité une telle action, par exemple une action de l'utilisateur.

Les données d'identifiant utilisateur pourraient être adressées à l'interface UI 9 par l'intermédiaire de l'outil 25 COM 11, c'est-à-dire être émises depuis le contrôleur ECU 3 d'un véhicule de la flotte, par l'intermédiaire de l'interface I/O 7.

Lorsque l'outil COM 11 permet une transmission de données 30 bidirectionnelle, l'interface UI 9 peut également être agencée de manière à recevoir des données depuis un contrôleur ECU 7 pour stockage dans la base USRDB 5 en tant que données de profil utilisateur.

15 La figure 2 montre un contrôleur ECU 3 en détail.

Outre l'interface I/O 7, un contrôleur ECU 3 comprend un ou plusieurs calculateurs, ou unité CPU 13, de la mémoire MEM 15, et une pluralité de ports d'entrée/sortie, désignés dans leur ensemble ports I/O 17, reliés aux différents organes de bords contrôlables du véhicule automobile. L'ensemble de ces éléments est relié d'une manière permettant l'échange de données et/ou d'instructions. Ces éléments interagissent sous l'action d'un microprogramme de bord.

La figure 3 illustre fonctionnellement un microprogramme de bord 19.

Le microprogramme 19 comprend un noyau système, ou noyau KER 21, pour la gestion de l'ensemble des ports I/O 17 et l'interface I/O 7 notamment.

Le microprogramme 19 comprend également une pluralité de modules fonctionnels, chacun de ces modules étant agencé de manière à gérer, en coopération avec le noyau KER 21, un organe de bord, ou un ensemble d'organes de bords fonctionnellement liés. La figure 3 montre, à titre d'exemple uniquement, un module de climatisation, ou module CLIM 23, capable d'adresser des signaux de commandes aux différents organes de climatisation du véhicule, tels que des ventilateurs, des thermostats, ou analogues, un module d'aide à la navigation, ou module GPS 25, et un module autoradio, ou module SND 27.

Chacun des modules fonctionnels est capable d'émettre des signaux de commande à destination du ou des organes de bord qu'il contrôle, en fonction de paramètres, par exemple stockés dans la mémoire MEM 15.

Certains au moins de ces modules fonctionnels sont capables également de commander l'enregistrement de paramètres modifiés dans la mémoire MEM 15, en réponse notamment à une action utilisateur sur un élément de l'interface véhicule.

Le codage de ces paramètres est spécifique du véhicule automobile dans lequel le contrôleur ECU 3 peut être installé, ou du moins du modèle de ce véhicule. Les différents modules fonctionnels sont également spécifiques, en ce qu'ils commandent ou interagissent avec des organes de bord ou des éléments d'interface conducteur potentiellement différents d'un véhicule à un autre (ou d'un modèle de véhicule à un autre).

La spécificité de ces paramètres a trait à leur forme de stockage, leur valeur et/ou leur signification, qui dépendent en grande partie de l'agencement du ou des modules fonctionnels utilisant ces paramètres.

Ces paramètres fonctionnels comprennent des paramètres utilisateur, c'est-à-dire des paramètres dont la valeur dépend d'un choix du conducteur, exprimé par exemple par une interaction avec l'interface du véhicule.

Par exemple, la mémoire MEM 15 peut stocker un paramètre de température ambiante utilisable par le module CLIM 23 pour mettre en oeuvre une boucle de régulation destinée à atteindre cette température ambiante. 30 La mémoire MEM 15 peut stocker en tant que paramètres une liste de fréquences correspondant à des stations de radio préférée pour usage par le module SND 27. 25

17 La mémoire MEM 15 peut encore stocker une liste d'adresses à utiliser par le module GPS 25.

Des paramètres de hauteur de siège, d'inclinaison de dossier, éloignement de volant, hauteur de volant peuvent également être stockées dans la mémoire MEM 15 pour usage par le module CFG 29.

Le stockage des différents paramètres dans la mémoire MEM 15 10 peut se faire sous la forme d'une ou plusieurs tables.

La mémoire MEM 15 est représentée fonctionnellement sur la figure 2. En pratique, cette mémoire MEM 15 peut comprendre un plusieurs dispositifs à mémoire. Et les paramètres 15 fonctionnels peuvent être mémorisés sur l'un ou l'autre de ces dispositifs à mémoire. De même, la mémoire MEM 15 peut comprendre tout ou partie d'un dispositif à mémoire physiquement installé dans un organe de bord, c'est-à-dire à l'écart du ou des éléments physiques constituant le reste 20 contrôleur ECU 3.

Le microprogramme 19 comprend en outre un convertisseur de données, ou convertisseur CONV 31, propre à recevoir un jeu de données de profil utilisateur, telles que reçues à 25 l'interface I/O 7, à convertir et à faire mémoriser ces données de profil utilisateur sous la forme de paramètres utilisateurs.

L'agencement du convertisseur CONV 31 dépend de la nature et 30 de la forme des données de profil utilisateur stockées dans la base USRDB 5 et de la nature et de la forme des paramètres fonctionnels stockés dans la mémoire MEM 15.

18 Selon la donnée du profil utilisateur, les différents cas de figure peuvent se présenter : - Un unique paramètre correspond à la donnée de profil utilisateur. Le convertisseur CONV 31 est alors principalement agencer pour formater la donnée de profil utilisateur pour stockage dans la mémoire MEM 15. Ce peut être le cas, par exemple, pour une donnée de température préférée dans l'habitacle. Le cas échéant, le convertisseur CONV 31 peut être agencé pour réaliser en supplément un changement d'unité de la valeur de la donnée de profil utilisateur. Par exemple, la donnée de température préférée, telle que mémorisée dans la base USRDB 5, peut être exprimée en degrés Celsius tandis que le module CLIN 23 est agencé pour utiliser une température exprimée en degrés Fahrenheit.

Toujours pour exemple, la donnée de profil utilisateur peut comprendre des données d'identification d'une station de radio appréciée (typiquement le nom de cette station), tandis que cette station appréciée doit être stockée dans la mémoire MEM 15 sous la forme d'une donnée homogène à fréquence pour être exploitée par le module SND 27 : le convertisseur CONV 25 est alors agencé de manière à associer aux données d'identifiant de station les données de fréquence correspondantes. Le convertisseur 31 peut être agencé de manière à faire appel à une ou plusieurs tables de conversion stockées dans la mémoire MEM 15. Par exemple, une table de conversion de ce type peut comprendre des données de type nom de stations associées à des données de fréquence.

- À une donnée de profil utilisateur peut correspondre plusieurs paramètres dans la mémoire MEM 15. Dans ce cas, le convertisseur CONV 31 peut être agencé pour comprendre des profils de conversion, chaque profil étant configuré de manière à associer une valeur à chacun des jeux de paramètres en fonction de la valeur de la donnée de profil

19 en question. Par exemple, à une valeur d'une donnée de profil utilisateur correspondant à la taille du conducteur peut être associé un ensemble de valeur de paramètres correspondant aux réglages du poste de conduite (hauteur de siège, éloignement du dossier, hauteur du volant, etc...). L'invention prend ainsi en compte le fait qu'une même taille de conducteur n'implique pas la même position de conduite sur un véhicule type 4X4 et dans un véhicule de typer Coupé.

Comme un contrôleur ECU 3 est spécifique du véhicule auquel il est destiné, ou du moins du modèle de ce véhicule, il équipe de préférence le véhicule automobile dès la fabrication de ce dernier. Le microprogramme d'un contrôleur de bord existant dans un véhicule peut également être reprogrammé de manière que ce contrôleur de bord fonctionne de manière identique au -contrôleur ECU 3.

Dans le premier cas, le premier système de commande 1 s'applique uniquement à des véhicules neufs, voire à des véhicules spécialement configurés pour fonctionner dans ce système, étant donné qu'un constructeur automobile peut ne pas souhaiter que l'ensemble des véhicules qu'il commerciale intègre un contrôleur ECU 3.

Dans le second cas, il s'agit de charger un nouveau microprogramme dans le contrôleur de bord de chacun des véhicules, opération qui peut s'avérer délicate, fastidieuse et potentiellement interdite par le constructeur automobile.

La figure 4 montre un second mode de réalisation d'un système de commande adaptative de véhicules automobiles dans une flotte, avantageusement mis en œuvre avec des véhicules automobiles déjà équipés d'un contrôleur de bord.

20 Dans ce second mode de réalisation, le système de commande adaptative de véhicules automobiles dans une flotte est désigné second système de commande 33.

Comme le premier système de commande 1, le second système commande 33 comprend la base USRDB 5, l'interface UI 7.

Chaque véhicule de la flotte comprend un contrôleur de bord, ou contrôleur ECU 35, spécifique du véhicule. Typiquement, le contrôleur ECU 35 équipe le véhicule en question depuis sa fabrication (contrôleur de série ).

Le contrôleur ECU 35 comprend un bus de communication, ou bus 37, par lequel ce contrôleur ECU 35 peut recevoir et transmettre des données, selon un protocole de communication qui peut être ou non spécifique du véhicule automobile ou du moins du modèle de ce véhicule. Le bus 37 constitue ainsi une interface d'entrée/sortie du contrôleur ECU 35 par l'intermédiaire de laquelle ce dernier peut recevoir et émettre des données.

Le second système de commande 33 comprend une pluralité de contrôleurs de bord additionnels, ou contrôleurs NWECU 39, chacun de ces contrôleurs NWECU 39 pouvant être installé à bord d'un véhicule de la flotte.

Chaque contrôleur NWECU 39 comprend une interface I/O 7 analogue à celle des contrôleurs ECU du premier système de commande 1. Le second système de commande 33 comprend un outil COM 11, analogue à celui du premier système de commande 1, pour la transmission de données entre l'interface UI 7 et l'interface30 21 I/O 7 du contrôleur NWECU 39, sous une forme analogue à la forme stockée dans la base USRDB 5.

Le contrôleur NWECU 39 comprend une seconde interface 5 d'entrée/sortie, ou interface I/O 2 41, propre à être reliée au bus 37 du contrôleur ECU 35 pour échanger des données.

Le contrôleur NWECU 39 est agencé de manière à répondre à des données de profil utilisateur reçues par l'intermédiaire de 10 l'interface I/O 7 par l'émission, par l'intermédiaire interface I/O 2 41, de données correspondantes, converties, exploitables par le contrôleur ECU 35 pour la commandes des organes de bord du véhicule.

15 La figure 5 montre le contrôleur NWECU 35 en détail.

Outre l'interface I/O 7 et l'interface I/O 2 41, le contrôleur NWECU 35 comprend un calculateur, ou unité CPU 43, et de la mémoire 45, l'ensemble de ces éléments étant 20 mutuellement reliés de manière à exécuter un microprogramme spécifique.

La figure 6 illustre fonctionnellement le microprogramme exécuté par le contrôleur NWECU 39. 25 Le contrôleur NWECU 39 comprend un noyau 47 et un module de conversion de données, ou module CNV 49, analogue au convertisseur CONV 25 du premier système de commande 1, capable, sur appel du noyau 47, de convertir les données de 30 profil utilisateur en données exploitables par le contrôleur ECU 35.

Le contrôleur ECU 35 n'est pas détaillé sur les figures. Il exécute typiquement un microprogramme, notamment destiné à

22 commander les organes de bord du véhicule automobile, par exemple au moyen de modules dédiés. En d'autres termes, le contrôleur ECU 35 se comporte de manière analogue au contrôleur ECU 3, à l'exception qu'il n'est pas capable de recevoir les données de profil utilisateur sous la forme stockée dans la base USRDB 5. Ceci ne signifie pas pour autant que le microprogramme du contrôleur ECU 35 ne comporte aucune fonction de conversion : le contrôleur ECU 35 est en effet capable de recevoir des données par l'intermédiaire du bus 37 que le microprogramme convertit pour un stockage et une utilisation ultérieure en tant que paramètres pour les différents modules de contrôle des organes de bord.

Le module CNV 49, en combinaison avec le noyau 47, est propre 15 à convertir les données de profil utilisateur en une forme exploitable par le contrôleur ECU 35.

Le module CNV 49 peut faire appel à une ou plusieurs tables de conversions, ou à des profils, stockés dans la mémoire MEM 20 du contrôleur NWECU 39 pour convertir les données de profil utilisateur.

Dans une variante de réalisation non illustrée, le contrôleur NWECU exécute un microprogramme agencé de manière à remplacer 25 le microprogramme exécuté de série par le contrôleur ECU 35 par un microprogramme du contrôleur ECU 3 du premier système de commande. Ceci implique notamment que le microprogramme de remplacement comprend une version des différents modules fonctionnels du contrôleur ECU 35 récrite pour être adaptée à 30 l'utilisation de données stockées dans la MEM de ce contrôleur ECU 35 sous la forme utilisée dans la base USRDB 5, ou à tout le moins dans une forme commune à l'ensemble des véhicules de la flotte, y compris lorsque cette flotte comprend des véhicules de modèles différents.

23 La figure 7 montre une première réalisation de l'outil de communication 11, ou premier outil 11A.

Le premier outil 11A comprend un émetteur/récepteur de données sans fil, ou installation E/R 1 55, relié en communication de données avec l'interface UI 7. Le premier outil 11A comprend en outre un second émetteur/récepteur de données sans fil, ou installation E/R 2 57, relié en communication de données avec l'interface d'entrée du contrôleur ECU 7 et conjugué à l'installation E/R 1 55.

Différentes technologies de transmission sans fil peuvent être employées, selon la portée désirée et le débit nécessaire, par exemple BlueTooth, Wifi, NFC, ondes hertziennes, Infrarouges, ou analogues.

Selon la technologie employée, le premier outil 11A impose une certaine proximité des véhicules à configurer avec 20 l'installation E/R _2 57.

La figure 8 montre une seconde réalisation de l'outil de communication 11, ou second outil 11B.

25 Le second outil 11B comprend un premier port de connexion, ou port PRT 1 59, par exemple type USB, relié en communication de données avec l'interface UI 7, un second port de connexion, ou port PRT 2 61, relié en communication de données avec l'interface I/O 7 du contrôleur ECU 3. Le second 30 outil 11B comprend en outre un support de stockage de données, ou support CRR 63, muni de connecteurs adaptés au port PRT1 59 et au port PRT2 61. Le support CRR 63 est propre à stocker les données de profil utilisateur extraites de la base USRDB 3. De préférence, le port PRT 1 59 et le

24 port PRT 2 sont compatibles entre eux, et le support CRR 63 ne comporte alors qu'un unique connecteur.

La figure 9 montre une troisième réalisation de l'outil de communication 11, ou troisième outil 11C, en tant que développement du premier outil 11A. Le troisième outil 11C comprend en outre support de mémoire, ou support CRR 2 65, muni de moyens d'émission/réception de données compatibles avec l'installation E/R 1, et des moyens d'émission/réception de données compatibles avec l'installation E/R 2. L'installation E/R 1 et l'installation E/R 2 peuvent fonctionner suivant des technologies différentes. Par exemple, le support CRR_2 65 peut prendre la forme d'une mémoire intégrée à un terminal de téléphonie mobile comprenant un module de communication radio à courte portée. L'installation E/R 1 fonctionne alors suivant l'une quelconque des normes de téléphonie mobile, tandis que l'installation E/R 2 peut fonctionner suivant la norme Bluetooth par exemple.

La figure 10 montre une quatrième réalisation de l'outil de communication 11, ou quatrième outil 11D, en tant que variante du troisième outil 11C. Dans ce quatrième outil 11D, l'installation E/R 2 est remplacée par le port PRT 2 et le support CRR_2 est doté d'un connecteur compatible avec ce port PRT 2. Par exemple, le support CRR_2 prend la forme d'un terminal de téléphonie mobile propre à être connecté de manière filaire avec port PRT 2, par exemple de type USB.

Claims (10)

1. Revendications1. Procédé de mise en service adaptative d'une flotte de véhicules automobiles, dans laquelle chaque véhicule est muni d'un contrôleur de bord capable d'agir sur des organes de bord en fonction d'un jeu de paramètres utilisateur dont le codage est spécifique du véhicule, le procédé comprenant les étapes suivantes . a. munir le contrôleur de bord d'une interface d'entrée propre à recevoir un premier jeu de données, et d'un convertisseur de données du premier jeu en paramètres utilisateur, b. prévoir une structure de base de données, cette structure comprenant un champ pour un identifiant utilisateur et au moins un champ pour un jeu de données d'itinérance, c. remplir la base de données, d. munir la base de données d'une interface de travail propre à : dl. recevoir des données d'identifiant utilisateur, d2. sur réception de données d'identifiant utilisateur, extraire une partie au moins du jeu de données d'itinérance correspondant aux données d'identifiant utilisateur pour transmission à la première interface du contrôleur de bord d'un véhicule automobile en tant que premier jeu de données.
2. 2. Procédé selon la revendication 1 comprenant en outre :e. prévoir un outil de transmission sans fil entre l'interface de travail et l'interface d'entrée du contrôleur de bord pour la transmission du jeu de données d'itinérance.
3. 3. Procédé selon la revendication 1 comprenant en outre : f. prévoir un support de mémorisation de données par l'intermédiaire duquel la transmission des données d'itinérance peut être réalisée entre l'interface de travail et l'interface d'entrée du contrôleur de bord.
4. 4. Procédé selon l'une des revendications précédentes, dans lequel l'étape a. comprend : al. Prévoir un contrôleur supplémentaire dans le véhicule automobile capable de recevoir de secondes données et de les convertir en premières données, les premières données étant spécifiques dudit véhicule tandis que les secondes données sont communes aux véhicules de la flotte.
5. 5. Procédé selon l'une des revendications précédentes, dans lequel l'étape a. comprend : a2. munir le contrôleur de bord d'une interface de sortie propre à délivrer un troisième jeu de données, et d'un convertisseur des paramètres utilisateur en données de troisième jeu, et dans lequel, à l'étape d., l'interface de travail est en outre capable de : d3. recevoir les données de troisième jeu, d4. sur réception de ces données de troisième jeu et de données d'identifiant utilisateur, mettre à jour le 10 15 20 25 30champ pour le jeu de données d'itinérance correspondant avec ce troisième jeu de données.
6. 6. Système de commande adaptative de véhicules automobiles dans une flotte, du type comprenant : un contrôleur de bord installable (3, 35) dans des véhicules de la flotte, capable d'émettre une série d'instructions agissant sur les organes de bord en fonction de paramètres utilisateur dont le codage est spécifique du véhicule, ledit contrôleur comprenant . une interface d'entrée (7, 37) propre à recevoir un premier jeu de données, un convertisseur de données (25, 41) pour convertir les données du premier jeu en paramètres utilisateur, une structure de base de données (5) comprenant un champ pour un identifiant utilisateur et au moins un champ pour un jeu de données d'itinérance, la base de données étant remplie de données d'identifiant utilisateur et de données d'itinérance, une interface de travail (9) pour la structure de base de données agencée pour : recevoir des données d'identifiant utilisateur sur réception de ces données d'identifiant utilisateur, extraire une partie au moins du jeu de données d'itinérance correspondant, un outil de transmission (11) actif entre l'interface de travail et l'interface d'entrée du contrôleur de bord d'un véhicule automobile pour le transfert des données d'itinérance extraites en tant que premier jeu de données.
7. 7. Système selon la revendication 6, dans lequel l'outil de transmission (11) est de type sans fil.
8. 8. Système selon la revendication 6, comprenant en outre un support de mémorisation (63, 65) de données par l'intermédiaire duquel la transmission des données d'itinérance peut être réalisée entre l'interface de travail (9) et l'interface d'entrée du contrôleur de bord (7).
9. 9. Système selon l'une des revendications 6 à 8, comprenant un contrôleur supplémentaire installable (39) dans le véhicule automobile et capable de recevoir de secondes données et de les convertir en premières données, les premières données étant spécifiques dudit véhicule tandis que les secondes données sont communes aux véhicules de la flotte.
10. 10. Système selon l'une des revendications 6 à 9, dans lequel le contrôleur de bord (3, 35) comprend en outre : - une interface de sortie (7, 37) propre à délivrer un troisième jeu de données, et - un convertisseur (25, 41) des paramètres utilisateur en données de troisième jeu, et dans lequel l'interface de travail (9) est en outre agencée pour : - recevoir les données de troisième jeu, - sur réception de ces données de troisième jeu et de données d'identifiant utilisateur, mettre à jour le champ pour le jeu de données d'itinérance correspondant avec ce troisième jeu de données.