Brevet FR2998992A1 — publié le 20140606

CONTROLEUR DE VEHICULE AUTOMOBILE A PROGRAMMATION FACILITEE [0001] L'invention concerne de manière générale la réduction de la diversité de production des calculateurs de véhicules automobiles. [0002] La part croissante de l'électronique dans une automobile due à l'augmentation des prestations proposées et aux nombreux règlements tels que diagnostic à bord ou OBD pour on-board diagnostic en anglais, sécurité, etc., notamment pour tenir compte de la zone géographique dans laquelle est commercialisé le véhicule, oblige tout constructeur à devoir gérer une diversité de fabrication très importante et en progression continue. [0003] Pour limiter les coûts de fabrication et de gestion de cette diversité, les constructeurs ont par exemple rendu leurs calculateurs téléchargeables. Cette opération permet pour la fabrication de deux véhicules différents munis d'une motorisation identique, de disposer du même processeur matériel de calculateur, ou même boitier matériel. En effet la différentiation est alors assurée par la fabrication de deux logiciels distincts adaptés respectivement à la silhouette sur laquelle ce même moteur est monté. Le besoin de différentier le logiciel se justifie entre autres par le fait que les deux véhicules puissent être de masse et de coefficients de pénétration dans l'air inégaux. [0004] Cependant, très vite, les constructeurs se sont mis à concevoir des logiciels dits enveloppes, en particulier pour réduire ce qui est appelé coûts de figeage de ces logiciels notamment dans le cas d'évolution ou de correction d'une prestation. [0005] En effet, si nous disposons de deux logiciels L1 et L2 associés respectivement à deux véhicules V1 et V2 dans lesquels on monte le même boitier matériel de calculateur de contrôle moteur, ces deux logiciels L1 et L2 devront évoluer dans le cas où il deviendrait nécessaire de corriger une prestation. Il conviendrait ainsi de réaliser un double figeage L1ev et L2ev de ces deux logiciels et d'en supporter le coût associé. Une autre solution est alors de réaliser un logiciel « enveloppe » conçu à la fois pour les deux véhicules V1 et V2 et de simplement paramétrer ce logiciel au moyen d'une opération appelée télécodage consistant à transmettre au logiciel un paramètre représentatif du véhicule V1 ou V2 dont tiendra compte le logiciel lors de l'exécution du code. Le logiciel « enveloppe » nous permet de produire un premier véhicule V1 avec des paramètres a et b respectivement à 1 et 2 lorsque la valeur V1 est transférée au logiciel, ou un second véhicule V2 avec des paramètres a et b respectivement à 3 et 4 lorsque la valeur V2 est transférée au logiciel. [0006] Pour réaliser cela, il est connu de l'état de la technique la possibilité d'utiliser un outil de diagnostic connecté sur la prise de diagnostic centralisée du véhicule lui permettant d'avoir accès aux différents calculateurs au moyen d'un média de communication de type ligne bidirectionnelle série K ou un réseau de type série bidirectionnel tel qu'un réseau CAN pour Controller Area Network dans la terminologie anglo-saxonne, ou encore d'autres comme Ethernet et d'un protocole normalisé de type IS014230 ou IS014229, d'autres protocoles étant également possibles. [0007] Au moyen d'une session de communication dans laquelle l'outil transmet une requête contenant une valeur V1, en gardant notre exemple précédent, et sur réception, le calculateur inscrit dans sa mémoire la valeur de ce paramètre qui sera utilisée par le logiciel pour sa propre configuration lors de la prochaine mise sous tension. [0008] Ce procédé est détaillé dans le document FR 2 805 362 intitulé « Système de configuration d'au moins un calculateur d'un système informatique embarqué à bord d'un véhicule automobile ». [0009] Le système de production d'un constructeur permet d'archiver pour chaque véhicule fabriqué associé à son identification, généralement le numéro d'identification de véhicule ou VIN pour Vehicle Identification Number en anglais qui est notamment apposé sur la carte grise et sur le châssis, les options montées ainsi que les paramètres de configuration du logiciel qui ont permis de sélectionner ces options dans le logiciel. [0010] Lors de la fabrication de chaque véhicule, une base de données archive ainsi l'identification du véhicule produit, le type du calculateur ayant reçu le paramètre V1, un calculateur de type calculateur moteur dans notre exemple, puis le paramètre V1. Ceci permet en cas de changement de pièce, ici de changement du calculateur moteur ultérieur dans la vie de ce même véhicule, de configurer correctement la nouvelle pièce montée avec les paramètres attendus. [0011] Néanmoins un tel système est confronté à l'impossibilité de garantir le télécodage automatique des calculateurs. En effet le problème majeur de ce système est qu'il ne permet pas d'assurer la configuration du calculateur de manière automatique. On entend par automatique le fait qu'un système informatique puisse déterminer seul, sans choix de l'opérateur, et dans tous les cas, les bonnes valeurs des paramètres à transmettre pour configurer correctement le logiciel d'un calculateur de remplacement. Ceci est particulièrement pénalisant dans le cadre de la réparation automobile et la raison essentielle en est due à un manque de traçabilité des changements de pièce d'un véhicule. Il y a plusieurs raisons à cela. La première concerne les difficultés de la traçabilité des véhicules en circulation et plusieurs phénomènes participent à cela. [0012] Lorsque qu'un constructeur produit pendant plusieurs années un type de véhicule, il existe de nombreuses évolutions de ce même produit au cours de ces années de production. On peut citer le cas du remplacement d'un composant d'un fournisseur par un autre de meilleur qualité ou moins cher ou encore de l'intégration de certaines options dans des finitions qui en étaient dépourvues auparavant. Dans le but de limiter les coûts de figeage comme décrit précédemment, le logiciel des dernières productions sera devenu enveloppe et inclura la compatibilité avec les versions précédentes vendues de sorte de limiter la maintenance sur les logiciels antérieurs qui ne sont plus commercialisés. [0013] De plus, bien souvent un constructeur vise le développement d'organes montés sur plusieurs véhicules de gammes différentes. Toujours en vertu de la limitation des coûts de développement et de maintenance des logiciels, supposons que soit réalisé un logiciel applicatif ou enveloppe L1 pouvant fonctionner avec un moteur M1 monté dans un véhicule V1 commercialisé à la date Ti. En usine, ce véhicule est produit. Comme il existe deux options possibles OPT1 et OPT2 associées au niveau de finition du véhicule, nous disposons des paramètres permettant d'activer ou d'inhiber les options en fonction des valeurs attribuées à OPT1 et OPT2. Ces deux paramètres sont obligatoires dans la requête transmise de l'outil au calculateur pour que le logiciel du calculateur considère comme valide les paramètres transmis. A la date T2 = Ti + 1 an est décidée la commercialisation d'un nouveau véhicule V2 sur lequel est aussi monté le moteur M1. En étude, on réalise un logiciel applicatif ou enveloppe L2 pouvant fonctionner avec le moteur M1 et adaptable aux deux véhicules V1 et V2. Cela permet de supprimer le logiciel L1 et donc de limiter les coûts de maintenance ultérieurs dans le cas d'évolutions liées à des corrections logicielles. On obtient un seul logiciel à maintenir au lieu de deux. [0014] Cependant, le véhicule V2 introduit une nouvelle option OPT3. En usine, on produit maintenant à la fois le véhicule V1 et le nouveau véhicule V2. Nous disposons donc maintenant des paramètres permettant d'activer ou d'inhiber les options en fonction des valeurs attribuées à OPT1, OPT2 et OPT3. Ces trois paramètres sont maintenant devenus obligatoires pour les deux véhicules en production V1 et V2 dans la requête transmise de l'outil vers le calculateur pour que le logiciel considère comme valide les paramètres transmis, car il ne faut pas de paramètre supplémentaire ni de paramètre manquant dans cette requête. Cependant un problème est alors engendré en après-vente. En effet le véhicule V1 muni du logiciel L1, à savoir celui qui a été commercialisé à la date Ti, se présente dans le réseau après-vente et l'on décide de remplacer le calculateur de contrôle moteur car celui-ci présente une mal-fonction. Dans ce cas, c'est un calculateur avec un logiciel L2 qui sera proposé pour des raisons de coûts car on ne conserve pas en magasin central l'ensemble des pièces qui sont annulées ou remplacées par de nouvelles compatibles. Pour autant, en prenant le VIN du véhicule et en allant chercher dans la base d'archivage de données de production, on ne trouvera de stockés que les paramètres OPT1 et OPT2, à savoir ceux qui ont été archivés lors de la production du véhicule, mais jamais le paramètre OPT3 pourtant rendu obligatoire pour la configuration du logiciel L2. Or le réseau après-vente d'un constructeur automobile se doit de pouvoir réparer l'ensemble des véhicules vendus et dans un tel système, l'aspect traçabilité est bien une composante essentielle pour pouvoir réaliser la bonne opération en après-vente. [0015] De plus, il n'est pas possible d'exiger que toute opération de remplacement soit tracée. En effet, il semble déjà hors de portée de garantir à une échelle internationale que toutes les opérations de réparation du type remplacement d'un calculateur nécessitant une configuration de son logiciel effectuées dans le propre réseau après-vente du constructeur puissent être tracées, car il faudrait notamment que l'opération ne puisse être réalisée autrement qu'au moyen d'une connexion à un serveur, or il existe de nombreuses zones géographiques où il n'est pas possible d'avoir accès à internet ou à une communication de type 3G. Cette difficulté de traçabilité de l'état des véhicules commercialisés s'est de plus accentuée notamment avec les évolutions de la réglementation et son volet sur la réparation indépendante, autorisant toute personne en faisant demande à disposer des informations de réparation et de fabrication de ses propres outils. Il est ainsi difficile d'imaginer disposer d'une base de données représentative de l'état des véhicules en circulation au sens de l'identification précise des calculateurs, des logiciels et des paramètres de configuration de ces logiciels, en « temps-réel ». [0016] Enfin, il existe une difficulté supplémentaire car même dans le cas où l'ensemble du réseau après-vente d'un constructeur et des indépendants utiliseraient des systèmes ne pouvant s'affranchir de la traçabilité des opérations dans une base de données, et répétons-le, ce n'est pas à la portée de l'état de la technique actuelle, cela ne résoudrait pas le cas du calculateur récupéré dans une casse pour être monté sur un autre véhicule. [0017] Un autre problème de la fonctionnalité actuelle est posé par le changement de répartition mémoire. La répartition mémoire représente la répartition d'un logiciel et de sa calibration dans l'espace mémoire prévu pour cela. Dans une répartition mémoire, chaque constituant d'un logiciel, tel qu'un module, une fonction, ou une calibration, est situé dans une zone prédéfinie par des adresses de début et de fin de l'espace mémoire adressable par le microprocesseur. [0018] La difficulté réside pour le fournisseur à permettre l'intégration de nouvelles fonctionnalités tout au long de la vie série du produit ainsi que la correction de certaines d'entre elles sans que cela ne remette en cause la répartition mémoire initialement définie. [0019] Il s'agit bien là d'une réelle difficulté car dans le cas de la correction d'une prestation se traduisant par une augmentation de la taille du code logiciel ou de la calibration associée à cette prestation, il va forcément y avoir une remise en cause des adresses des fonctions situées dans les espaces mémoire sous la prestation corrigée. Dès lors, il ne sera plus possible par le nouveau logiciel téléchargé de réutiliser certaines zones mémoires dans lesquelles étaient inscrits les paramètres de télécodage précédents. [0020] Tel que représenté à la figure 1 annexée, des adresses 1, 2 et 3 ont été remplacées respectivement par des adresses 4, 5 et 6. Lorsque le logiciel L2 est téléchargé dans la mémoire d'un calculateur muni auparavant du logiciel L1, il n'est plus possible de réutiliser les valeurs des paramètres de télécodage qui se situaient dans la zone mémoire comprise entre les adresses 2 et 3 du calculateur. [0021] L'objectif de l'invention est de pallier à ces différents inconvénients. [0022] Cet objectif est atteint selon l'invention grâce à un contrôleur embarqué de véhicule automobile, comprenant un processeur et une mémoire laquelle mémoire comprend une zone mémoire de logiciel dans laquelle est stocké un logiciel de contrôle et une zone mémoire de calibration dans laquelle est stockée au moins une valeur de paramètre de calibration du contrôle effectué par le logiciel de contrôle, caractérisé en ce que le logiciel de contrôle comprend une variable de fonctionnement et la zone mémoire de calibration stocke un identifiant de paramètre de calibration en association avec la valeur du paramètre de calibration et le logiciel de contrôle est configuré pour commander une recherche de l'identifiant dans la zone mémoire de calibration et, une fois l'identifiant trouvé dans la zone mémoire de calibration, conférer à la variable de fonctionnement du logiciel de contrôle la valeur du paramètre de calibration associée à l'identifiant dans la zone mémoire de calibration. [0023] Avantageusement, le logiciel de contrôle est configuré pour commander une recherche d'un identifiant dans la zone mémoire de calibration et, selon qu'un tel identifiant est trouvé ou non dans la mémoire de calibration au cours de cette recherche, respectivement conférer une valeur de paramètre de calibration associée à l'identifiant dans la mémoire de calibration à une variable de fonctionnement du logiciel de contrôle ou conférer une valeur par défaut à cette variable de fonctionnement du logiciel de contrôle. [0024] Avantageusement, le logiciel de contrôle comprend une liste de valeurs acceptables pour la variable de fonctionnement. [0025] Avantageusement, le logiciel de contrôle est configuré pour comparer la valeur de paramètre de calibration associée à l'identifiant trouvé dans la zone mémoire de calibration avec les valeurs de la liste de valeurs acceptables pour la variable de fonctionnement et pour conférer la valeur de paramètre de calibration à la variable de fonctionnement à condition que cette valeur soit présente dans la liste de valeurs acceptables. [0026] Avantageusement, l'identifiant comporte un indice d'évolution et la liste de valeurs acceptables comporte au moins un indice d'évolution, et le contrôleur possède une fonction qui compare l'indice d'évolution de l'identifiant au dit au moins un indice d'évolution de la liste des valeurs acceptables, cette fonction émettant un message signalant une incohérence au cas où la comparaison révèle que l'identifiant présente un indice d'évolution indiquant une évolution plus avancée que la liste de valeurs acceptables. [0027] Avantageusement, la valeur de paramètre de calibration est stockée en mémoire en codage ASCII. [0028] Avantageusement, le contrôleur est configuré de telle sorte que la recherche de l'identifiant et le fait de conférer à la variable de fonctionnement du logiciel la valeur associée à l'identifiant dans la zone mémoire de calibration sont mis en oeuvre à chaque mise sous tension du contrôleur. [0029] Avantageusement, le contrôleur est un calculateur de pilotage de paramètres de combustion du moteur. [0030] L'invention concerne également un véhicule automobile comportant un tel 20 contrôleur. [0031] L'invention concerne également un tel véhicule automobile lorsqu'il est un véhicule à propulsion électrique. [0032] D'autres caractéristiques, buts et avantages de l'invention apparaitront à la lecture de la description détaillée qui va suivre, faite en référence aux figures annexées sur 25 lesquelles : [0033] - la figure 1 est une vue schématique d'une mémoire de contrôleur avant et après une opération de remplacement d'un logiciel de contrôle, selon l'état de la technique. [0034] - la figure 2 représente une configuration d'une mémoire d'un contrôleur conforme à un mode de réalisation de l'invention. 30 [0035] Le système dont il est question dans le présent mode de réalisation est composé d'une partie débarquée sous la forme d'un outil de génération d'identifiants uniques et d'une partie embarquée dans un véhicule automobile, plus précisément dans le logiciel et une zone mémoire de calibration des calculateurs embarqués du véhicule. [0036] En ce qui concerne la partie débarquée, le système dispose d'un outil permettant 35 sur demande la génération automatique d'identifiants et la vérification de la non utilisation antérieure d'un identifiant pouvant être proposé par un opérateur. Ces identifiants seront ensuite utilisés par le logiciel embarqué des calculateurs en association avec leurs valeurs respectives pour paramétrer le calculateur. Chaque identifiant est composé d'une partie liée à sa possible évolution dans le temps. La composition d'un identifiant est ici la suivante. Lors d'une demande de création d'un nouveau paramètre, le système fournit trois identifiants distincts, par exemple : MOTEUR POSSIBLE nnn, MOTEUR PROGRAMME nnn et MOTEUR VARIABLE nnn. MOTEUR est la racine. POSSIBLE, PROGRAMME ou VARIABLE est le type de l'identifiant, et nnn est l'indice d'évolution de l'identifiant, compris ici entre 000 et 999. [0037] Le premier identifiant est destiné à caractériser ce que le logiciel du calculateur sera susceptible de supporter. Par exemple, l'identifiant MOTEUR POSSIBLE 000 intégré au logiciel d'une boite de vitesses automatique prendra la valeur hexadécimale Ox0F, c'est-à-dire bit3 = 1, bit2 = 1, bit1 = 1 et bit() = 1, précisant ainsi qu'il peut fonctionner avec les moteurs EP6, EW, EC8 et EC5. A noter que ce même identifiant intégré au logiciel d'une seconde boite de vitesses automatique peut par exemple ne fonctionner qu'avec les motorisations EP6 et EC8 et dans ce cas prendrait les valeurs Ox0A, c'est-à-dire bit3 = 1 et bit1 = 1. [0038] Le second identifiant est destiné à caractériser ce que le logiciel utilisera comme paramètre en fonction de la variante véhicule donnée. Par exemple, on produit un véhicule dont le moteur est un EP6 et le logiciel « enveloppe » de la boite de vitesses automatique est adapté pour fonctionner avec cette motorisation. Dans ce cas, la valeur hexadécimale qu'il faudra associer au paramètre MOTEUR PROGRAMME 000 est 0x08, soit la sélection du seul bit3 parmi les possibles. [0039] Enfin, le troisième identifiant est utilisé comme variable interne du logiciel pour récupérer la valeur de l'identifiant programmé. [0040] Toute évolution du contenu de l'identifiant de type possible donne lieu ici à une évolution du mnémonique lui-même. Par exemple, toute affectation supplémentaire d'un moteur dans l'un des bits non utilisés donne lieu à un changement de l'indice d'évolution et donc l'enregistrement de ce nouvel identifiant dans le système afin de ne pas le réattribuer à tort. Tous les identifiants définis sont consignés dans une base de données. Ces identifiants sont uniques et non recyclables. [0041] Chaque calculateur embarqué configurable contient une zone mémoire 10 stockant une procédure de téléchargement du calculateur. Cette zone mémoire est non programmable dans le présent exemple. Le calculateur comporte une zone mémoire 20 d'accueil du logiciel comportant les fonctions de contrôle du contrôleur. Il comporte en outre une zone mémoire 30 d'accueil des paramètres de configuration. Cette zone mémoire 30 peut être située dans une mémoire de type flash telle qu'une mémoire de type mémoire morte reprogrammable ou eprom pour « erasable programmable read-only memory » selon la terminologie anglo-saxonne, sous la forme d'un segment mémoire dédié, ou encore dans une mémoire de type mémoire morte effaçable électriquement et programmable ou mémoire eeprom pour « electrically erasable programmable read-only memory », laquelle est une mémoire réinscriptible, lorsque les calculateurs ne possèdent pas de mémoire de type flash eprom, ce qui est le cas des petits calculateurs comme ceux de direction assistée ou de détection de sous-gonflage dont le logiciel est masqué en mémoire de type à lecture seule ou ROM pour « Read Only Memory » en anglais. Les paramètres de configuration sont ceux qui possèdent un identifiant du type xxx PROGRAMME nnn associé à une valeur à programmer. [0042] Chaque calculateur configurable stocke dans cette zone mémoire 30 à la fois la valeur du paramètre pour la variante véhicule, mais aussi l'identifiant permettant d'associer la valeur à la bonne variable du logiciel. C'est par la reconnaissance des identifiants que tout nouveau logiciel affecte ici les bonnes valeurs des paramètres aux bonnes variables du logiciel et non pas comme dans l'état de l'art actuel par des adresses mémoires. [0043] Dans le présent exemple, la valeur associée à MOTEUR PROGRAMME 000 est 0x08, c'est-à-dire que l'identifiant est associé à une valeur correspondant au choix de l'EP6, c'est-à-dire bit3 = 1. Tous les identifiants de type xxx_POSSIBLE_nnn sont contenus dans le logiciel puisqu'il s'agit des possibilités d'adaptation du logiciel à une variante donnée. Lors de chaque mise sous tension du calculateur, le logiciel active une fonction F1, laquelle est représentée sous la référence 21 sur la figure 2, qui pour chaque identifiant programmé lu dans la zone mémoire réservée au stockage des paramètres, définis dans la zone 30 par un identifiant et une valeur associée, le compare à l'identifiant de la variable contenue dans le logiciel. [0044] Dans l'exemple décrit ici, la fonction F1 présente un pseudo code qui est le suivant : [0045] Pour PARAM = MOTEUR, ..., ... ; /* chaque paramètre à tour de rôle */ [0046] { [0047] Recherche chaine (PARAM PROGRAMME) ; [0048] /* Recherche à partir des adresses de la zone réservée */ [0049] Si identifiant trouvé Alors PARAM VARIABLE = valeur lue après identifiant ; [0050] Sinon Affecte (Valeur_par défaut) à PARAM VARIABLE ; [0051] /* cf. téléchargement d'une version logicielle contenant plus de paramètres que la version initiale */ [0052] } [0053] Supposons que nous n'ayons qu'un unique paramètre MOTEUR à programmer pour configurer notre logiciel de boite de vitesses automatique. Nous proposons le terme MOTEUR à l'outil de base de données permettant la création des identifiants. Ce dernier va nous proposer les trois identifiants suivants : MOTEUR POSSIBLE 000, MOTEUR PROGRAMME 000, MOTEUR VARIABLE 000. Le premier identifiant sera contenu dans le logiciel du calculateur car il s'agit de l'identifiant permettant de connaitre les adaptations possibles du logiciel. Le second correspond au paramètre que l'on va programmer lors de l'étape de production du véhicule. Le troisième est l'identifiant qui va être utilisé par le logiciel pour récupérer la valeur de configuration et qui en fonction de cette valeur permettra l'adaptation du logiciel. Lors de l'étape de production du véhicule, on programme donc au moyen d'un outil de diagnostic le secteur flash eprom ou eeprom contenant la variable de type MOTEUR PROGRAMME 000. [0054] Cette étape consiste à écrire dans ce secteur mémoire à la fois l'identifiant transcrit sous la forme d'un code hexadécimal en code américain normalisé pour l'échange d'information ou code ASCII pour « American Standard Code for Information lnterchange » selon la terminologie anglo-saxonne, et la valeur qui lui est associée. Le codage ASCII où chaque caractère est transformé en un octet est connu de l'état de l'art mais d'autres types de codage peuvent aussi être utilisés en lieu et place. [0055] Au moyen du standard ASCII, nous allons donc écrire en mémoire la suite d'octets suivante : Nom du paramètre MO T EUR_PROGRAMME _ 0 0 0 Ox Ox 4F Ox Ox Ox Ox Ox Ox 4F Ox Ox Ox Ox Ox Ox Ox Ox Ox 5F Ox Ox Ox 4D 54 45 55 52 5F 47 55 47 55 41 4D 4D 45 30 30 30 [0056] Lors de cette étape, le calculateur vérifie au préalable pour le paramètre de configuration programmé dont la racine est MOTEUR, c'est-à-dire MOTEUR PROGRAMME 000, que ce dernier possède bien le même indice d'évolution que celui du paramètre de type xxx POSSIBLE nnn correspondant, c'est-à-dire MOTEUR POSSIBLE 000 ; [0057] Si tel est bien le cas, la configuration est déclarée comme valide et le logiciel du calculateur peut l'utiliser pour paramétrer le fonctionnement de son logiciel lors de la prochaine mise sous tension. Dans le cas contraire, le calculateur envoie un message de refus vers l'outil de diagnostic et se replace dans son état initial, c'est à dire avec une configuration encore jamais programmée. [0058] Cette fonctionnalité permet de s'assurer que l'on ne programme pas un paramètre d'indice d'évolution supérieur à ce qu'est en mesure de traiter le logiciel du calculateur. [0059] En poursuivant cet exemple, il nous faut donc inscrire dans la zone mémoire réservée par le calculateur l'identifiant MOTEUR PROGRAMME 000 ainsi que la valeur 0x08 correspondant au choix de l'EP6. Le codage ASCII va nous permettre de transformer l'identifiant en une suite d'octets, puis de mettre à la suite la valeur 0x08. Cette étape se reproduit autant de fois qu'il y a de paramètres à écrire en mémoire. Cette action correspond à l'état de la zone mémoire 30 de la figure 2. Lors de la mise sous tension le calculateur lance la fonction F1 et accède à la zone des paramètres de configuration, reconnait l'identifiant du paramètre et affecte la valeur associée à la variable du logiciel qui possède la même racine et le même indice d'évolution. Ceci correspond au pseudo-code inscrit dans la zone mémoire 20 de la figure 2, et qui est le suivant, dans le présent cas d'un logiciel téléchargeable pour correction d'une prestation. 25 « PROGRAMME »); [0069] Passe les trois caractères liés à l'indice d'évolution ( ) ; [0070] MOTEUR VARIABLE 000 = Valeur après l'indice d'évolution ; /* soit 0x08 */ [0071] } /* fin de la fonction F1 */ 30 [0072] Fonction CONFIGURATION DU LOGICIEL ( ) [0073] { [0074] Switch (MOTEUR VARIABLE) [0075] { [0076] Case 0x01 : CHOIX = EC5 ; /* bit() à 1 */ 35 [0077] Case 0x02 : CHOIX = EC8 ; /* bit1 à 1 */ [0060] Fonction F1 ( ) [0061] { [0062] Pour la variable MOTEUR VARIABLE 000 [0063] Sur la zone mémoire 30, reconnais les caractères (« MOTEUR ») ; [0064] Si caractères « MOTEUR» non trouvés [0065] { [0066] Alors MOTEUR VARIABLE 000 = valeur par défaut ; [0067] } [0068] Confirme que les caractères suivant (« MOTEUR» sont bien [0078] Case 0x04 : CHOIX = EW ; /* bit2 à 1 */ [0079] Case 0x08 : CHOIX = EP6 ; /* bit3 à 1 */ [0080] Default : CHOIX = sans objet ; [0081] } /* passe */ [0082] Lors de chaque téléchargement d'un nouveau logiciel en remplacement du logiciel initial, fonctionnalité qui est activable au moyen de la zone mémoire 10 de la figure 2, il est possible que cette nouvelle version nécessite la programmation de plus de paramètres que la version initiale. Ceci est en particulier le cas lorsque la deuxième version est aussi développée pour fonctionner avec un véhicule supplémentaire à la première version. [0083] Dans ce cas où le ou les nouveaux paramètres figurant dans le logiciel ne peuvent pas être retrouvés dans la zone mémoire du calculateur qui contient les paramètres de configuration, il sera affecté une valeur par défaut signifiant ainsi « sans objet » pour ce ou ces paramètre(s). Ceci permet de se dispenser de programmer un paramètre nécessaire au bon fonctionnement du logiciel pour une variante véhicule donnée mais non utilisé pour la variante véhicule dont il est question. [0084] Ce mode de réalisation permet en après-vente de ne pas avoir à refaire l'opération de télécodage des calculateurs à la suite d'une opération de téléchargement du logiciel même si la version n+1 ne conserve pas la même répartition en mémoire que la version n qu'elle remplace. [0085] Ce mode de réalisation de l'invention permet au logiciel des calculateurs d'autodéterminer les valeurs par défaut des paramètres de configuration qui ne sont pas utilisés pour la variante de véhicule produite. Il permet donc un gain de coût de par la diminution du temps d'intervention en maintenance ou en garantie, par la suppression de l'opération de télécodage après un téléchargement de logiciel ainsi qu'un gain de qualité en limitant de fait les possibles erreurs lors du paramétrage du calculateur. [0086] Ainsi, un contrôleur ayant une telle configuration de logiciel embarqué à bord d'un véhicule automobile permet que les paramètres de configuration d'un logiciel adaptés à une variante véhicule ne soient programmés que lors de la production de ce véhicule et n'aient nul besoin d'être reprogrammés ensuite pendant sa vie série notamment lors du remplacement du logiciel initial par un nouveau corrigeant une prestation et ce, même si le nouveau logiciel ne conserve pas une répartition en mémoire identique. Dans le cas du remplacement d'une version logicielle par une nouvelle pouvant couvrir plusieurs variantes de véhicules, le calculateur intègre une fonctionnalité lui permettant d'auto déterminer les valeurs par défaut des paramètres de configuration non utiles à la variante véhicule sur laquelle est installée cette nouvelle version. [0087] L'invention présente un intérêt particulier pour les véhicules électriques, lesquels embarquent des contrôleurs de fonctionnalités complexes et sujets à des renouvellements ou évolutions d'équipements multiples au cours de la vie des produits. REVENDICATIONS1. Contrôleur embarqué de véhicule automobile, comprenant un processeur et une mémoire (10,20,30) laquelle mémoire comprend une zone mémoire de logiciel (20) dans laquelle est stocké un logiciel de contrôle (20) et une zone mémoire de calibration (30) dans laquelle est stockée au moins une valeur de paramètre de calibration du contrôle effectué par le logiciel de contrôle, caractérisé en ce que le logiciel de contrôle (20) comprend une variable de fonctionnement et la zone mémoire de calibration (30) stocke un identifiant de paramètre de calibration en association avec la valeur du paramètre de calibration et le logiciel de contrôle (20) est configuré pour commander une recherche de l'identifiant dans la zone mémoire de calibration (30) et, une fois l'identifiant trouvé dans la zone mémoire de calibration (30), conférer à la variable de fonctionnement du logiciel de contrôle (20) la valeur du paramètre de calibration associée à l'identifiant dans la zone mémoire de calibration (30). 2. Contrôleur selon la revendication 1, caractérisé en ce que le logiciel de contrôle (20) est configuré pour commander une recherche d'un identifiant dans la zone mémoire de calibration (30) et, selon qu'un tel identifiant est trouvé ou non dans la mémoire de calibration (30) au cours de cette recherche, respectivement conférer une valeur de paramètre de calibration associée à l'identifiant dans la mémoire de calibration (30) à une variable de fonctionnement du logiciel de contrôle (20) ou conférer une valeur par défaut à cette variable de fonctionnement du logiciel de contrôle (20). 3. Contrôleur selon la revendication 1 ou la revendication 2, caractérisé en ce que le logiciel de contrôle (20) comprend une liste de valeurs acceptables pour la variable de fonctionnement. 4. Contrôleur selon la revendication précédente, caractérisé en ce que le logiciel de contrôle (20) est configuré pour comparer la valeur de paramètre de calibration associée à l'identifiant trouvé dans la zone mémoire de calibration (30) avec les valeurs de la liste de valeurs acceptables pour la variable de fonctionnement et pour conférer la valeur de paramètre de calibration à la variable de fonctionnement à condition que cette valeur soit présente dans la liste de valeurs acceptables. 5. Contrôleur selon la revendication 3 ou la revendication 4, caractérisé en ce que l'identifiant comporte un indice d'évolution et la liste de valeurs acceptables comporte au moins un indice d'évolution, et le contrôleur possède une fonction qui compare l'indice d'évolution de l'identifiant au dit au moins un indice d'évolution de la liste des valeurs acceptables, cette fonction émettant un message signalant une incohérence au cas où lacomparaison révèle que l'identifiant présente un indice d'évolution indiquant une évolution plus avancée que la liste de valeurs acceptables. 6. Contrôleur selon l'une quelconque des revendications précédentes, caractérisé en ce que la valeur de paramètre de calibration est stockée en mémoire (30) en codage ASCII. 7. Contrôleur selon l'une quelconque des revendications précédentes, caractérisé en ce que le contrôleur est configuré de telle sorte que la recherche de l'identifiant et le fait de conférer à la variable de fonctionnement du logiciel la valeur associée à l'identifiant dans la zone mémoire de calibration (30) sont mis en oeuvre à chaque mise sous tension du contrôleur. 8. Contrôleur selon l'une quelconque des revendications précédentes, caractérisé en ce que le contrôleur est un calculateur de pilotage de paramètres de combustion du moteur. 9. Véhicule automobile comportant un contrôleur selon l'une quelconque des revendications précédentes. 10. Véhicule automobile selon la revendication précédente, caractérisé en ce qu'il est un véhicule à propulsion électrique.