FR 2877750 A1 20060512 FR 0411885 A 20041108 La présente invention concerne un procédé d'activation/désactivation d'une fonction de pilotage d'un organe fonctionnel d'un véhicule automobile, à partir d'un outil externe à celui-ci. Plus particulièrement, l'invention se rapporte à un tel procédé d'activation/désactivation d'une fonction mise en oeuvre par une unité de traite-ment d'informations embarquée à bord d'un véhicule et associée à une mémoire volatile, une mémoire non-volatile et une 'mémoire de défauts. On assiste depuis quelques années à une augmentation très importante du nombre de calculateurs embarqués à bord des véhicules automobiles. Ces calculateurs également appelés unités de contrôle électroniques ou unités de traitement d'informations , contribuent notamment à renforcer le confort et la sécurité du véhicule et de ses occupants, en offrant une multitude de nouvelles fonctions logicielles. Conçues dans le but d'améliorer les prestations du véhicule vendu au 15 client, ces fonctions peuvent parfois se révéler complexes à mettre en oeuvre lorsqu'il s'agit de garantir la conformité de production du véhicule. En effet, au fil de son avancée sur la chaîne d'assemblage et en bout d'usine de production, le véhicule subit une série d'opérations et de traitements spécifiques à l'unité de production. De par leur caractère exceptionnel dans la durée de vie du véhicule, ces situations particulières sont difficilement prises en compte lors de la conception. Elles ont pour principales conséquences, le déclenchement intempestif de certaines fonctions logicielles tout au long de la chaîne de fabrication. Ce sont alors autant de perturbations que les opérateurs doivent neutraliser au prix de gestes supplémentaires. La production s'en trouve alors consi- dérablement ralentie, car il faut consacrer plus de temps à chaque véhicule. De plus, l'inconfort et la fatigue des opérateurs sont sensiblement accrus. Enfin, un oubli de l'opérateur peul: également aboutir à la détérioration des installations par exemple de l'unité de production. Ainsi par exemple, si l'on prend la fonction de serrage automatique du frein de stationnement qui est une fonction hébergée dans un calculateur de frein de stationnement électrique, également appelé calculateur FSE, celle-ci serre automatiquement le frein de stationnement lorsque le moteur du véhicule passe de l'état tournant à l'état non tournant. Le desserrage nécessite alors une inter- vention d'un opérateur (appui sur l'une des pédales et/ou sur un bouton- poussoir). Cette fonction permet d'améliorer le confort du conducteur du véhicule, en lui évitant de serrer manuellement le frein de stationnement lorsque son véhicule s'arrête. Elle répond également à une contrainte réglementaire qui oblige le système à maintenir le véhicule à l'arrêt dans une pente à 8%, alors que la commande de serrage manuel du frein est défectueuse. Cependant, cette fonction provoque certains problèmes qui peuvent être rencontrés par exemple en usine de fabrication. Le premier problème concerne un risque de blocage de la ligne de 10 production. En effet, en zone d'étanchéité et en zone de protection extérieure, un véhicule est entraîné uniquement par deux roues. Si le frein de stationnement est serré, ce véhicule ne peut pas être déplacé. Un autre risque concerne l'usure prématurée des tapis roulants de l'usine. Si le frein de stationnement est serré, le véhicule applique un effort exceptionnellement important au niveau des jonctions des tapis roulants, mettant en péril les moteurs d'entraînement de ceux-ci. De même, des problèmes de convoyage de véhicules non fonctionnels dans l'unité de production peuvent également apparaître. En effet, des chariots sont prévus pour tracter les véhicules dans cette unité, par leurs roues avant. Un véhicule dont le frein de stationnement est serré n'est donc pas déplaçable. On conçoit alors que lors de chacune des étapes de production citées cidessus, il est nécessaire d'opérer un desserrage manuel du frein de station- nement afin de permettre au véhicule de continuer à avancer sur la ligne de production. Différentes solutions ont déjà été proposées pour tenter de résoudre ces problèmes. La première solution consiste à créer, dès la conception du logiciel du calculateur, un mode de fonctionnement particulier réservé à l'usine. Cependant, la création d'un nouveau mode de fonctionnement nécessite de définir le comportement de chacune des fonctions du logiciel lorsque le mode est actif. Ceci revient à doubler le travail de spécification, de codage et de validation du logiciel. Or, le besoin exprimé plus haut ne concerne qu'un nombre très limité de fonctions et ne justifie pas une telle surcharge de travail, d'autant plus que le problème et donc l'activation des fonctions supplémentaires développées, ne se rencontrent qu'une seule et unique fois dans la vie du véhicule, c'est-à-dire lors de sa fabrication. Par ailleurs, si l'on utilise un mode de fonctionnement spécifique en usine, il est nécessaire de quitter ce mode avant la commercialisation du véhicule, c'est-à-dire passer celui-ci dans un mode après-vente en sortie d'usine. Il existe alors un risque de trouver un véhicule resté en mode usine parmi ceux livrés aux clients. Enfin, les routines associées au mode usine sont résidantes en mémoire non-volatile des calculateurs. Par conséquent, un passage accidentel dans ce mode reste possible pendant toute la durée de vie du véhicule, comme par exemple à la suite d'un déroutement d'un programme causé par une perturbation électromagnétique. Ceci peut alors entraîner des risques pour la sécurité des personnes et/ou du véhicule. Une seconde solution consiste à charger le logiciel du calculateur d'activer automatiquement la fonction lorsque le véhicule aura parcouru un certain nombre de kilomètres, par exemple déterminé à l'avance. Cependant, à la sortie de l'usine, toutes les fonctions doivent être disponibles dans le véhicule. Il n'est pas envisageable de livrer au client, un véhicule qui ne soit pas totalement fonctionnel. La difficulté consiste alors à déterminer à l'avance le nombre de kilomètres adéquat en sachant que tous les véhicules ne parcourent pas la même distance dans l'usine. En effet, certains passent par le plateau de retouche, d'autres sont prélevés par échantillon à la sortie du flux de montage pour subir des essais sur piste, etc.. De plus, un même véhicule peut être assemblé dans différentes usines d'un groupe et aujourd'hui toutes les usines d'un groupe ne sont pas forcément réalisées selon le même modèle. En effet, malgré une forte volonté de converger vers une cible commune, il existe des disparités dans l'agencement des postes de travail. Ces disparités sont le plus souvent dues à des raisons historiques ou à des contraintes liées à la surface disponible du site. En résumé, on constate qu'il n'est pas possible de figer lors de la conception du logiciel ni le moment ni l'endroit où la fonction devra être neutralisée. Ces paramètres sont en effet directement dépendants de l'usine où est fabriqué le véhicule. Le but de l'invention est donc de résoudre ces problèmes. A cet effet, l'invention a pour objet un procédé d'activation/désactivation d'une fonction de pilotage d'un organe fonctionnel d'un véhicule automobile, à partir d'un outil externe à celuici, dans lequel la fonction est mise en oeuvre par une unité de traitement d'informations du véhicule, associée à une mémoire volatile, une mémoire non-volatile et une mémoire de défauts, caractérisé en ce qu'il comporte, pour la désactivation de la fonction, des étapes de: - émission par l'outil externe d'une requête d'inhibition de la fonction, contenant en outre une signature de l'outil; - stockage en mémoire volatile de la signature de l'outil; - stockage en mémoire de défauts d'un code de défaut fonction inhibée ; - établissement en mémoire non-volatile d'un drapeau de fonction à l'état inhibé après vérification de la présence d'une signature d'outil; - renvoi vers l'outil d'un acquittement; et activation de moyens d'alerte d'un opérateur pour lui indiquer que la fonction est inhibée; et pour l'activation de la fonction,, des étapes de: - émission par l'outil d'une requête de suppression de l'inhibition de la fonction; - établissement en mémoire non-volatile du drapeau de fonction à l'état activé ; - désactivation des moyens d'alerte de l'opérateur; effacement du code de défaut dans la mémoire de défauts; et - renvoi vers l'outil d'un acquittement. Suivant d'autres caractéristiques de l'invention: - à chaque initialisation de l'unité de traitement d'informations, la zone de mémoire volatile destinée à recevoir la signature de l'outil est remise à zéro et les moyens d'alerte sont activés si le drapeau est à l'état fonction inhibée ; - l'outil externe est un outil de bord de ligne de montage du véhicule; - l'outil est raccordé au véhicule à travers la prise de diagnostic de celui-ci; et - l'outil est raccordé au véhicule à travers une ligne K ou un bus multiplexé de transmission d'informations de celui-ci. L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés, sur lesquels: - la Fig.1 représente un schérna synoptique illustrant le raccordement d'un outil externe à une unité de traitement d'informations embarquée à bord d'un véhicule automobile; et - les Figs.2, 3, 4, 5 et 6 illustrent un procédé d'activation/désactivation selon l'invention. Le procédé selon l'invention est mis en oeuvre en utilisant un outil externe à un véhicule et en reliant celui-ci à une unité de traitement d'informations embarquée à bord du véhicule et assurant la mise en oeuvre de la fonction qu'il convient d'activer ou de désactiver. Ainsi par exemple sur la figure 1, on a illustré le raccordement d'un outil externe au véhicule désigné par la référence générale 1, à une unité de traite-ment d'informations embarquée désignée par la référence générale 2. L'outil externe au véhicule est. par exemple raccordé à travers la prise de diagnostic 3 du véhicule à l'unité de traitement d'informations. Une ligne K ou encore un bus multiplexé de transmission d'informations peut être utilisé de façon classique. En fait, l'unité de traitement d'informations 2 est raccordée à une mémoire volatile destinée à stocker une signature de l'outil et désignée par la réfé- rence générale 4, à une mémoire non-volatile de stockage d'un drapeau d'état de la fonction désignée par la référence générale 5, à une mémoire de défauts désignée par la référence générale 6 et enfin à des moyens d'alerte d'un opérateur permettant d'indiquer à celui-ci l'état de la fonction, ces moyens d'alerte étant désignés par la référence générale 7 et comprenant par exemple des moyens d'alerte lumineux tels qu'un voyant ou encore des moyens d'affichage d'un mes-sage quelconque sur un écran multifonctions embarqué à bord du véhicule. L'outil externe, tel que l'outil 1, est par exemple formé par un outil de diagnostic implanté en bord de ligne de montage du véhicule, à différents en- droits de l'usine ou de la ligne de production. Ces outils peuvent alors être utilisés pour activer/désactiver une fonction mise en oeuvre par une unité de traitement d'informations embarquée telle que l'unité 2. A cet effet, cet outil externe 1 est adapté pour émettre à destination de l'unité de traitement d'informations 2, une requête d'inhibition de la fonction ou au contraire une requête de suppression de cette inhibition de la fonction. Ces requêtes permettent alors d'inhiber ou de réactiver la fonction correspondante à partir d'un outil de bord de ligne implanté le long de la ligne de production et connecté au véhicule. Ceci permet alors de n'inhiber la fonction que pendant le temps strictement nécessaire, c'est-à-dire celui où cette fonction risque de gêner des opérations de montage du véhicule. Il peut effectivement se révéler utile que la fonction soit disponible le reste du temps et par exempte ne pas priver des essayeurs, de fonctions telles que la fonction d'ABS ou d'ESP pour des essais. Ainsi, le procédé selon l'invention est d'une grande souplesse en permettant de s'adapter à toutes les usines d'un constructeur par exemple, quelle que soit leur configuration. De plus, il ne nécessite pas la mise en oeuvre d'un protocole de communication particulier, puisqu'il réutilise de façon avantageuse, celui déjà implé- menté dans les calculateurs embarqués pour les fonctions de diagnostic et de téléchargement. Dès lors qu'un mécanisme est résidant dans une mémoire non-volatile d'un calculateur, il existe un risque pour que cette routine logicielle soit activée par accident. Pour éviter tout risque, on propose d'implémenter un mécanisme de signature-outil qui oblige le calculateur à vérifier qu'un outil est bien connecté avant de d'autoriser par exemple l'inhibition d'une fonction. De plus, pour garantir qu'aucun véhicule ne sera commercialisé avec la fonction inhibée, on propose de mettre en place un code de défaut spécifique stocké dans la mémoire de défauts du calculateur lorsque la fonction est inhibée. En bout de ligne, lors des tests de conformité, si l'outil de diagnostic révèle la présence de ce code de défaut dans la mérnoire de défauts du calculateur, alors le véhicule est renvoyé au plateau de retouche. De plus, une alerte visuelle quelconque, tel qu'un voyant par exemple, est allumée au combiné où un message est affiché sur un écran multifonctions embarqué, pour indiquer à un opérateur que la fonction est par exemple inhibée. Par simple contrôle visuel, l'opérateur peut alors vérifier que la fonction a bien été réactivée lorsque le véhicule quitte l'usine, le voyant ou le message devant être désactivé. On a en effet illustré sur les figures 2 et 3 par exemple, le traitement d'une requête d'inhibition d'une fonction, émise par l'outil externe 1 au véhicule à destination de l'unité de traitement d'informations 2. La première étape du traitement de cette requête par l'unité de traitement d'informations consiste alors à écrire, lors de l'étape 10, la signature de l'outil en mémoire volatile 4 associée à l'unité de traitement d'informations 2. Puis en 11, l'unité de traitement d'informations 2 vérifie si un drapeau d'état de fonction, établi dans la mémoire non-volatile 5, est dans un état inhibé ou non. Si c'est le cas, lors de l'étape 12, un acquittement positif est renvoyé par l'unité de traitement d'informations vers l'outil externe au véhicule. Si ce n'est pas le cas, lors de l'étape 13, l'unité de traitement d'informations stocke un code de défaut fonction inhibée en mémoire de défauts 6 associée à l'unité de traitement d'informations. Puis en 14, l'unité active les moyens d'alerte 7 de l'opérateur pour lui 25 indiquer que la fonction est inhibée. Comme cela a été indiqué précédemment, ces moyens d'alerte peu-vent par exemple comporter un voyant d'alerte ou encore un message particulier destiné à être affiché sur un écran multifonctions du véhicule. Puis en 15, le drapeau d'état de la fonction est positionné par l'unité, sur l'état inhibé dans la mémoire non-volatile 5. Le détail de cette étape 15 est donné sur la figure 3, où l'on voit qu'avant de procéder à cet établissement, l'unité de traitement d'informations vérifie la présence d'une signature d'outil dans la mémoire volatile 4, lors de l'étape 16. Si une signature d'outil est bien présente, le drapeau est bien positionné dans l'état inhibé en 17. Par contre, si aucune signature n'est présente en 16, une erreur d'écriture est signalée lors de l'étape 18. Après ces opérations et si l'on en revient à la figure 2, une vérification est effectuée en 19 pour contrôler l'écriture du drapeau. Si cette écriture est cor- recte, l'acquittement 12 décrit précédemment est envoyé vers l'outil externe. Si l'écriture ne s'est pas passée correctement, un acquittement négatif est envoyé en 20. On conçoit alors que si la fonction Fx est déjà inhibée lorsque le calculateur reçoit la requête de demande d'inhibition, celui-ci répond positivement à l'outil externe au véhicule. En effet, une réponse négative risquerait de faire dé-router le véhicule vers le plateau de retouche alors que cela n'est pas nécessaire. Une requête d'effacement des défauts envoyée par l'outil externe ne doit pas effacer le drapeau inhibition de la fonction Fx. Cette inhibition de la fonction Fx doit persister même après une réinitialisation du calculateur, que celle-ci soit logicielle ou et matérielle. Le seul moyen de désinhiber cette fonction consiste alors à envoyer une requête de suppression de l'inhibition de cette fonction, comme cela est illustré sur la figure 4. Ainsi, en 21, un test est effectué par l'unité de traitement d'informations pour déterminer si le drapeau d'état indique un état inhibé ou acti- vé de la fonction. Si l'état indiqué par le drapeau n'est pas l'état fonction inhibée, alors la fonction est active et un acquittement positif est envoyé à l'outil lors de l'étape 22. Par contre, si le test en 21 indique que le drapeau correspond à une fonction inhibée, alors lors de l'étape 23, on établit en mémoire nonvolatile 5, le drapeau de fonction à l'état activé . Puis, en 24, on désactive les moyens d'alerte 7 de l'opérateur, par exemple en coupant le voyant correspondant ou en supprimant le message correspondant sur l'écran multifonctions embarqué. Enfin, en 25, on efface le code de défaut dans la mémoire de défauts 6 du calculateur. A la suite de ces différentes opérations, l'unité envoie l'acquitte- ment positif en 22 vers l'outil. Si la fonction Fx est déjà active lorsque le calculateur reçoit la requête, celui-ci répond positivement à l'outil externe au véhicule. En effet, une réponse négative risquerait de faire dérouter le véhicule vers le plateau de retouche alors que cela n'est pas nécessaire. A chaque fois que la fonction Fx est appelée, le logiciel applicatif doit alors vérifier que cette fonction n'a pas été inhibée avant d'autoriser son exécu- tion. Ceci est réalisé comme cela est illustré sur la figure 5, par contrôle de l'état du drapeau. Ainsi par exemple, lors de l'étape 26, si le drapeau n'est pas établi à l'état fonction inhibée , alors cette fonction peut être exécutée en 27, tandis que cela n'est pas le cas si la fonction est inhibée, la fonction n'étant alors pas exécutée. Comme cela a été indiqué précédemment, l'outil envoie sa signature sous la forme de paramètres dans la requête transmise à destination de l'unité de traitement d'informations. A la réception de cette signature, l'unité de traitement d'informations la range alors à une adresse de mémoire RAM prédéfinie dans le programme. La présence en mémoire RAM de la valeur exacte de la signature-outil garantit à cette unité de traitement d'informations, qu'un outil de diagnostic est bien connec-té. Pour protéger efficacement contre les risques mentionnés précédem- ment, il convient de placer la fonction dans un secteur particulier de la mémoire et d'insérer un test de cette mémoire de signature d'outil au sein des séquences de déverrouillage du composant. Le programme applicatif ne peut alors appeler la routine d'écriture du microprocesseur qu'après avoir vérifié que la signature-outil attendue se trouve 25 bien l'adresse de mémoire RAM prévue à cet effet. De même, à chaque initialisation du calculateur, le logiciel applicatif doit effectuer différentes opérations comme cela est illustré sur la figure 6. En effet, à chaque initialisation de l'unité de traitement d'informations 2, la zone de mémoire volatile destinée à recevoir la signature de l'outil est re- mise à zéro lors par exemple de l'étape 28, tandis qu'un test est effectué en 29 pour déterminer si le drapeau d'état de fonction indique une fonction inhibée ou non. Si c'est le cas, en 30, les moyens d'alerte sont activés, par exemple par allumage du voyant ou déclenchement de l'affichage du message correspondant sur l'écran multifonctions. II va de soi bien entendu que d'autres modes de réalisation encore 5 peuvent être envisagés. 1'1 REVENDICATIONfi 1. Procédé d'activation/désactivation d'une fonction de pilotage d'un organe fonctionnel d'un véhicule automobile, à partir d'un outil externe (1) à celui-ci, dans lequel la fonction est mise en oeuvre par une unité de traitement d'informations (2) du véhicule, associée à une mémoire volatile (4), une mémoire non-volatile (5) et une mémoire de défauts (6), caractérisé en ce qu'il comporte, pour la désactivation de la fonction, des étapes de: - émission par l'outil externe (1) d'une requête d'inhibition de la fonction, contenant en outre une signature de l'outil; - stockage (10) en mémoire volatile (4) de la signature de l'outil; stockage (13) en mémoire de défauts (6) d'un code de défaut fonction inhibée ; - établissement (15) en mémoire non-volatile (5) d'un drapeau de fonction à l'état inhibé après vérification de la présence d'une signature d'outil; - renvoi (12) vers l'outil d'un acquittement; et activation (14) de moyens d'alerte (7) d'un opérateur pour lui indiquer que la fonction est inhibée; et pour l'activation de la fonction, des étapes de: - émission par l'outil (1) d'une requête de suppression de l'inhibition de la fonction; - établissement (23) en mémoire non-volatile (5) du drapeau de fonction à l'état activé ; - désactivation (24) des rnoyens d'alerte (7) de l'opérateur; - effacement (25) du code de défaut dans la mémoire de défauts (6) ; et - renvoi (22) vers l'outil d'un acquittement. 2. Procédé selon la revendication 1, caractérisé en ce qu'à chaque initialisation de l'unité de traitement d'informations (2), la zone de mémoire volatile (4) destinée à recevoir la signature de l'outil est remise à zéro (28) et les moyens d'alerte (7) sont activés (30) si le drapeau est à l'état fonction inhibée (29). 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que l'outil externe (1) est un outil de bord de ligne de montage du véhicule. 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'outil (1) est raccordé au véhicule à travers la prise de diagnostic de celui-ci (3). 5. Procédé selon la revendication 4, caractérisé en ce que l'outil (1) est 5 raccordé au véhicule à travers une ligne K ou un bus rnultiplexé de transmission d'informations de celui-ci.