Brevet FR3109001A1 — publié le 20211008

L’invention se rapporte à un procédé de mise à jour, par réception d’un signal contenant un paquet de mise à jour sur un port de contrôleur d’interface (103), d’un calculateur (101) embarqué dans un véhicule automobile, le calculateur (101) à mettre à jour, au moins un calculateur connexe (102) et un ordinateur de bord du véhicule (104) étant connectés entre eux sur un réseau local, l’ordinateur de bord du véhicule (104) étant connecté au contrôleur d’interface (103) par l’intermédiaire d’une passerelle centrale du véhicule (105) configurée pour connecter de façon sécurisée le contrôleur d’interface (103) et l’ordinateur de bord du véhicule (104). L’ordinateur de bord (104) ou la passerelle centrale (105) vérifient des conditions relatives à la légitimité de mise en œuvre de la mise à jour (S4, S4’, S4’’). Si les conditions relatives à la légitimité de mise en œuvre de la mise à jour sont remplies, un message d’inhibition de défauts de diagnostic est transmis à destination d’au moins un calculateur connexe (102), et le calculateur (101) est mise à jour (S5, S5’, S5’’). Figure pour l’abrégé : Fig. 1 Procédé sécurisé d’inhibition d’enregistrement des défauts d’équipements électroniques en vue d’une mise à jour d’un composant du véhicule par le client final L’invention se rapporte au domaine automobile, et plus particulièrement à la mise à jour de calculateurs embarqués dans les véhicules automobiles. L’infodivertissement (« infotainment » selon la terminologie anglo-saxonne) est devenu un atout majeur de vente des véhicules automobiles. Les utilisateurs veulent pouvoir accéder, depuis un écran de contrôle à différents contenus multimédia, ou à différents services de télécommunications ou encore de navigation. Les véhicules sont donc de plus en plus souvent équipés d’un système multimédia connu aussi sous l'acronyme « IVI » (In-Vehicle Infotainment). Les systèmes multimédia comprennent généralement un port USB, qui a au moins deux fonctions. La première est de laisser la possibilité à l’utilisateur de télécharger des fichiers audio et/ou vidéo, de les stocker sur une clé USB, puis d’écouter et/ou voir les contenus correspondants dans le véhicule. La deuxième fonction est de pouvoir mettre à jour des composants du véhicule, afin de bénéficier des dernières fonctionnalités proposées par le constructeur. Via un portail du constructeur, le technicien ou l’utilisateur télécharge la dernière version du composant, puis il insère la clé USB dans le port USB du système multimédia. Les mises à jour, sont effectuées le plus souvent sur des calculateurs du système multimédia, mais il est tout à fait envisageable que les mises à jour s’appliquent à d’autres calculateurs. Par ailleurs, le système multimédia est un composant fortement connecté (port USB, connectivité cellulaire), et se trouve ainsi dans une zone exposée en termes de surface d’attaque malveillante vis-à-vis des calculateurs critiques du véhicule. La mise à jour du calculateur multimédia ne doit donc pas se faire au détriment des impératifs de sûreté. Les calculateurs de véhicules comprennent des mémoires qui sont généralement partitionnées en deux banques accessibles indépendamment (solution dite de « dual banking », ou double banque) ; afin de pouvoir effectuer des opérations de lecture de mémoire tout en effectuant une opération de mise à jour de la mémoire. Dans le cas d’une solution double banque, il reste une phase non transparente de mise à jour (la phase d’activation), durant laquelle le calculateur est redémarré. La phase d’activation dure environ trente secondes. La phase d’installation dans la banque inactive prend, quant à elle, plusieurs minutes, mais ne pose pas de problème car effectuée en tâche de fond, sans perte de fonctionnalité et ne générant pas d’absence de service pour les autres calculateurs. Lors de la phase d’activation de la mise à jour d’un calculateur, , celui-ci disparaît du réseau véhicule, dans le sens où les calculateurs connexes de l’architecture électrique/électronique du véhicule, constateront une anomalie pendant le processus de mise à jour, et généreront un message d’alerte de diagnostic du type DTC (pour « Diagnostic Trouble Code »). Or, il n’est pas concevable que les anomalies soient transmises à l’utilisateur pendant le temps de la mise à jour de manière à ne pas l’inquiéter inutilement, sachant que ces défauts temporaires disparaîtront au prochain redémarrage du calculateur. Les alertes situées au niveau du tableau de bord peuvent être anxiogènes pour l’utilisateur, et sont donc à éviter. Il convient ainsi de ne pas stocker de faux messages d’alerte DTC dans les différents calculateurs, défauts qui devront être analysés avant d’être supprimés en après-vente. Le fait de dédoubler chaque calculateur (ou « dual-banking ») n’empêche pas toujours ces anomalies dans les calculateurs connexes, la mise à jour entraînant un dédoublage qui n’occulte pas la phase de commutation entre le calculateur à mettre à jour et son image, qui, quant à elle, fait disparaître le calculateur. La génération d’alertes DTC est retransmise à l’utilisateur, sous forme de voyants de défaut ou d’indications textuelles, que l’utilisateur n’est généralement pas à même d’interpréter. Par ailleurs, les alertes DTC sont enregistrées dans les calculateurs connexes, ce qui engendre des procédures inutiles d’analyses coûteuses dans le réseau après-vente. Au contraire, les mises à jour asynchrones par attente d’un cycle naturel d’endormissement et réveil du véhicule ne génèrent pas de défaut. Ces mises à jours asynchrones, à l’initiative de l’utilisateur ont donc lieu suite à un processus d’endormissement naturel du véhicule tel que : l’utilisateur coupe le contact, verrouille la portière. Le véhicule détecte alors qu’il n’y a plus d’opération sur le véhicule. Lors du prochain réveil, par exemple une ouverture de portière, le véhicule exécute le logiciel qui avait été chargé avant l’endormissement, ainsi le calculateur ne disparaît pas du réseau ; les calculateurs connexes ne génèrent donc pas d’anomalie. Les mises à jour de calculateur, à l’initiative de l’utilisateur (c’est-à-dire du client) ne peuvent être effectuées que lorsque le véhicule est « endormi ». Le moment d’endormissement n’est pas immédiat, même après une fermeture du véhicule, il faut par exemple attendre l’expiration d’une temporisation, et dans le cas d’un véhicule sans clé (par exemple avec une carte), il faut que l’utilisateur s’éloigne suffisamment du véhicule, ce qui génère des incertitudes quant au déclenchement de l’endormissement. Dans le cas où il y a plusieurs calculateurs, une activation immédiate de la mise à jour est préférable, en synchronisant la réinitialisation de tous les calculateurs, afin d’opérer un redéploiement synchrone en cas de problème. Le cas de réinitialisation synchrone pose des problèmes d’alertes DTC, d’où le besoin d’inhiber les défauts. Les mises à jour peuvent, en alternative, être mises en œuvre en atelier, par un technicien, lors de la maintenance du véhicule. Le technicien constate qu’une mise à jour aurait dû être effectuée, et effectue la mise à jour par clé USB. Néanmoins, en atelier, le technicien n’a pas le temps de mettre en œuvre le mécanisme précité d’endormissement du véhicule. En mettant à jour le calculateur, le technicien fait disparaître le calculateur du réseau, et les calculateurs connexes génèrent des alertes DTC. Le technicien, voyant les alertes DTC (voyants allumés ou indications textuelles), branche alors un outil de diagnostic embarqué, (ou OBD pour On-Board Diagnostics), qui va effacer les alertes DTC afférentes à la mise à jour. L’utilisation d’un outil de diagnostic embarqué génère toutefois une opération supplémentaire pour le technicien. Par ailleurs, un outil de diagnostic embarqué est onéreux (environ 15 k€), donc son utilisation, dans un atelier de maintenance, doit être limitée aux cas où c’est strictement nécessaire. Par ailleurs, la mise à jour du calculateur de façon asynchrone (différé) en atelier pose un problème d’incertitude et de robustesse. Il y a en effet des temporisations et retards à l’endormissement (recroisement moteur par exemple) ou détection de carte d’accès en proximité, qui rendent cette méthode hasardeuse. L’invention vise donc à inhiber les défauts de façon contrôlée et sécurisée lors d’une mise à jour d’un calculateur de véhicule, notamment avec une clé USB, tout en s’affranchissant de la génération d’alertes DTC par les calculateurs connexes du réseau du véhicule. L’invention peut être appliquée à tout type de calculateur du véhicule, et en particulier à un calculateur multimédia du véhicule. Un objet de l’invention est donc un procédé de mise à jour, par réception d’un signal contenant un paquet de mise à jour sur un port de contrôleur d’interface, d’un calculateur embarqué dans un véhicule automobile, le calculateur à mettre à jour, au moins un calculateur connexe et un ordinateur de bord du véhicule étant connectés entre eux sur un réseau local, l’ordinateur de bord du véhicule étant connecté au contrôleur d’interface par l’intermédiaire d’une passerelle centrale du véhicule configurée pour connecter de façon sécurisée le contrôleur d’interface et l’ordinateur de bord du véhicule, le procédé comprenant les étapes suivantes : - réception, au niveau du port de contrôleur d’interface, d’un signal contenant un paquet de mise à jour du calculateur à mettre à jour ; - extraction par le contrôleur d’interface du paquet de mise à jour ; - transmission par le contrôleur d’interface à destination de l’ordinateur de bord ou de la passerelle centrale d’une requête de mise à jour du calculateur ; - vérification, par l’ordinateur de bord ou par la passerelle centrale, de conditions relatives à la légitimité de mise en œuvre de la mise à jour ; - si les conditions relatives à la légitimité de mise en œuvre de la mise à jour sont remplies, transmission à destination d’au moins un calculateur connexe d’un message d’inhibition de défauts de diagnostic, et mise à jour du calculateur. Selon un premier mode de réalisation, - lors de l’étape de transmission de la requête de mise à jour du calculateur, la requête de mise à jour du calculateur est transmise à l’ordinateur de bord ; - lors de l’étape de vérification, l’ordinateur de bord détecte si au moins une condition statique, liée à l’état du véhicule, est satisfaite, et si au moins une condition dynamique, opérée par un utilisateur du véhicule, est satisfaite ; - lors de l’étape de transmission d’un message d’inhibition, l’ordinateur de bord transmet le message d’inhibition de défaut de diagnostic. Avantageusement, la condition dynamique est satisfaite si l’utilisateur du véhicule actionne une séquence combinatoire prédéfinie de commandes du véhicule. Selon un deuxième mode de réalisation, - le procédé comprend, entre les étapes d’extraction et de transmission de la requête de mise à jour du calculateur, une étape d’échange d’un conteneur crypté contenant des droits de mise à jour du calculateur entre le contrôleur d’interface et l’ordinateur de bord ; - à l’issue de l’étape d’échange, l’étape de transmission de la requête de mise à jour du calculateur comprend la transmission de la requête de mise à jour du calculateur à l’ordinateur de bord ; - lors de l’étape de vérification, l’ordinateur de bord détecte si au moins une condition statique, liée à l’état du véhicule, est satisfaite ; - lors de l’étape de transmission d’un message d’inhibition, l’ordinateur de bord transmet le message d’inhibition de défaut de diagnostic. Selon un troisième mode de réalisation, - le procédé comprend, entre les étapes d’extraction et de transmission de la requête de mise à jour du calculateur, une étape d’échange d’un conteneur crypté contenant des droits de mise à jour du calculateur entre le contrôleur d’interface et la passerelle centrale ; - à l’issue de l’étape d’échange, l’étape de transmission de la requête de mise à jour du calculateur comprend la transmission de la requête de mise à jour du calculateur à la passerelle centrale ; - lors de l’étape de vérification, la passerelle centrale détecte si au moins une condition statique, liée à l’état du véhicule, est satisfaite ; - lors de l’étape de transmission d’un message d’inhibition, la passerelle centrale transmet le message d’inhibition de défaut de diagnostic. Avantageusement, l’étape d’échange d’un conteneur crypté contenant des droits de mise à jour du calculateur entre le contrôleur d’interface et la passerelle centrale comprend : - l’émission par le contrôleur d’interface d’un conteneur crypté contenant des droits de mise à jour du calculateur ; - la mise en œuvre des étapes suivantes par la passerelle centrale : -- le stockage du conteneur ; -- l’authentification du conteneur ; -- le décryptage du conteneur ; -- la vérification de l’intégrité du conteneur ; -- la prise en compte des droits de mise à jour du calculateur contenus dans le conteneur. Avantageusement, la transmission du message d’inhibition de défaut de diagnostic est interrompue si la condition statique n’est plus satisfaite. Avantageusement, la mise à jour est effectuée par clé USB, le port de contrôleur d’interface comprenant un port USB. L’invention se rapporte également à un ordinateur de bord de véhicule, configuré pour être connecté à un calculateur à mettre à jour et à au moins un calculateur connexe sur un réseau local de véhicule, l’ordinateur de bord de véhicule étant configuré pour mettre en œuvre les étapes suivantes : - réception d’une requête de mise à jour du calculateur ; - vérification des conditions relatives à la légitimité de mise en œuvre de la mise à jour ; - si les conditions relatives à la légitimité de mise en œuvre de la mise à jour sont remplies, transmission à destination d’au moins un calculateur connexe d’un message d’inhibition de défauts de diagnostic. Avantageusement, l’ordinateur de bord est configuré pour détecter si au moins une condition statique, liée à l’état du véhicule, est satisfaite, et si au moins une condition dynamique, opérée par un utilisateur du véhicule, est satisfaite. En variante, l’ordinateur de bord est configuré pour échanger, avec le contrôleur d’interface, un conteneur crypté contenant des droits de mise à jour du calculateur, et pour détecter si au moins une condition statique, liée à l’état du véhicule, est satisfaite. L’invention se rapporte également à une passerelle centrale de véhicule configurée pour connecter de façon sécurisée un contrôleur d’interface à un réseau local de véhicule comprenant un calculateur à mettre à jour et au moins un calculateur connexe, la passerelle centrale du véhicule étant configurée pour mettre en œuvre les étapes suivantes : - réception d’une requête de mise à jour du calculateur ; - vérification des conditions relatives à la légitimité de mise en œuvre de la mise à jour ; - si les conditions relatives à la légitimité de mise en œuvre de la mise à jour sont remplies, transmission à destination du calculateur connexe d’un message d’inhibition de défauts de diagnostic. Avantageusement, la passerelle centrale de véhicule est configurée pour échanger, avec le contrôleur d’interface, un conteneur crypté contenant des droits de mise à jour du calculateur, et pour détecter si au moins une condition statique, liée à l’état du véhicule, est satisfaite. L’invention se rapporte aussi à un produit programme d’ordinateur comportant des instructions pour l’exécution du procédé précité lorsque le programme est exécuté par un processeur. D’autres caractéristiques, détails et avantages de l’invention ressortiront à la lecture de la description faite en référence aux dessins annexés donnés à titre d’exemple et qui représentent, respectivement : La figure 1 représente un premier mode de réalisation du procédé selon l’invention. La figure 2 est un ordinogramme illustrant la machine à état des conditions d’activation présentes dans le premier mode de réalisation du procédé. La figure 3 illustre un deuxième mode de réalisation du procédé selon l’invention. La figure 4 précise l’étape d’échange d’un conteneur crypté. La figure 5 est un ordinogramme illustrant la machine à état des conditions d’activation présentes dans le deuxième mode de réalisation du procédé. La figure 6 illustre un troisième mode de réalisation du procédé selon l’invention. La figure 7 est un ordinogramme illustrant la machine à état des conditions d’activation présentes dans le troisième mode de réalisation du procédé. Un premier mode de réalisation du procédé selon l’invention est illustré par la figure 1. Le support comprenant la mise à jour 106 (ci-après nommé « support ») est par exemple une clé USB. Il peut être, en alternative, un disque compact, ou tout autre support informatique capable de stocker une mise à jour. Le contenu du support 106 est extrait par un contrôleur d’interface 103. Le contrôleur d’interface 103 peut notamment être un contrôleur USB si le support 106 est une clé USB. Il peut également être un contrôleur de communication radio si la mise à jour est effectuée par liaison radio (procédure également appelée OTA pour « Over The Air »). L’avantage d’une mise à jour par clé USB tient dans le fait qu’une clé USB est facile à utiliser (pour y stocker un composant logiciel comprenant la mise à jour), et qu’elle a une grande capacité de mémoire. Le réseau véhicule est scindé schématiquement en trois zones, comme illustré sur les figures 1, 3 et 6. La zone 1 correspond au domaine connecté (filaire ou non), il s’agit donc d’une zone vulnérable. La zone 2 est une zone pare-feu, destinée à protéger la zone 3. La zone 3 correspond au domaine véhicule (zone protégée/sécurisée). Le contrôleur d’interface 103 est situé dans une zone du véhicule qui est fortement connectée (zone 1 sur la figure 1). Il est en effet situé généralement dans la zone multimédia du véhicule, dans laquelle l’utilisateur peut brancher une clé USB (comprenant potentiellement un contenu infecté). Dans certains véhicules, cette zone permet également à l’utilisateur d’accéder à un réseau local de type WiFi, qui peut également véhiculer des contenus infectés, ou bien de se connecter à d’autres appareils, dont la sûreté n’est pas garantie, par connexion filaire ou non (par exemple Bluetooth, marque déposée). Un utilisateur malveillant pourrait également brancher, via le contrôleur d’interface 103, un ordinateur portable capable d’émuler l’ordinateur de bord du véhicule, et ainsi agir sur des composants critiques du véhicule. Les composants critiques sont ceux utilisés pour la conduite du véhicule. Il est donc essentiel que ces composants soient isolés de la zone 1. Sur la figure 1, les composants critiques sont disposés dans la zone 3, qui correspond au réseau local du véhicule auquel est connecté l’ordinateur de bord 104. L’ordinateur de bord 104 supporte des fonctions avec des privilèges importants, comme par exemple l’inhibition des défauts, c’est pour cela qu’une telle fonction est hébergée en zone 3, zone très protégée du véhicule. On cherche en outre à ne pas exposer des inducteurs directs (signal CAN ou autre message inter-système) vers la zone 1 (contrôleur d’interface 103), qui est une zone vulnérable, et donc considérée comme n’étant pas un organe de confiance. Le branchement d’une clé USB, qui peut contenir des contenus non légitimes ou infectés, ne fait que rajouter un scénario pour exercer les inducteurs. Les différents composants du réseau local peuvent être reliés entre eux via un bus de données CAN (Controller Area Network). L’ordinateur de bord 104 (également appelé BCM ou « Body Control Module » selon la terminologie anglo-saxonne) est une unité électronique capable de gérer et de commander différents composants du véhicule. L’ordinateur de bord 104 prend notamment en compte les différentes entrées (par exemple contact clé, demande de verrouillage, capteurs de température, capteurs de lumière), et génère des sorties adéquates (par exemple éclairage intérieur, extérieur, actionnement des essuie-glaces). Pour des raisons de sûreté, il n’est pas concevable que la zone 1 (domaine connecté) soit directement reliée à la zone 3 (réseau local de l’ordinateur de bord). Ainsi, les données provenant de l’extérieur du véhicule transitent par une passerelle centrale 105. Sur la figure 1, la passerelle centrale 105 n’est connectée qu’à deux domaines (zones 1 et 3), pour des raisons de simplification de la figure1. En réalité, la passerelle centrale 105 est l’élément qui relie tous les domaines électriques/électroniques du véhicule. La passerelle centrale 105 est dotée de fonctions sécuritaires telles des pare-feux, ou encore des systèmes de détection d’intrusion. Dans une première étape S1 du procédé selon l’invention, le contrôleur d’interface 103 extrait le paquet contenant la mise à jour depuis le support 106. Le paquet de données contient les éléments logiciels à installer dans un calculateur 101, ainsi que des métadonnées (description de la mise à jour, date de la sortie de la mise à jour, etc.). Sur la figure 1, le calculateur à mettre à jour 101 est situé dans la zone 1, mais il pourrait également se situer en alternative en zone 3. L’invention trouve toutefois son intérêt si le calculateur à mettre à jour 101 est situé dans la zone 1. En effet, si le calculateur à mettre à jour 101 est en zone sécurisée (zone 3), il pourrait lui-même, après avoir par exemple authentifié une image de mise à jour valide, faire la demande vers l’ordinateur de bord 104, via une interface dans le monde sécurisé (de la zone 3 vers la zone 3), dans ce cas, il n’y aurait pas besoin de mettre en œuvre une vérification sécuritaire de contexte. Les métadonnées peuvent être regroupées (archivées) selon un format donné, par exemple selon l’un des formats suivants : « zip », « rar », « tar » ou encore « iso ». Le paquet de données peut également comprendre un fichier signature, qui correspond à un identifiant de la mise à jour. Le paquet de données est authentifié, et de préférence à plusieurs niveaux, avec une première authentification en zone 1, et dans les calculateurs cibles, toujours dans le principe de ne pas faire confiance à la couche de niveau supérieure qui est vulnérable. Dans une deuxième étape S2 du procédé selon l’invention, le contrôleur d’interface 103 extrait le paquet de données. L’extraction du paquet consiste notamment à extraire un type de fichier prédéterminé du paquet, par exemple le fichier signature. Le contrôleur d’interface 103 peut ensuite vérifier la signature qui a été extraite. La signature permet d’identifier le paquet de données comme étant bien une mise à jour. Une fois que le contrôleur d’interface 103 a vérifié la signature du paquet de mise à jour, il transmet, à l’ordinateur de bord 104, une requête de mise à jour (étape S3). La requête de mise à jour ne contient pas les éléments logiciels nécessaires à la mise à jour, il s’agit uniquement d’une information indiquant à l’ordinateur de bord 104 qu’une mise à jour est disponible sur le support 106. La requête de mise à jour transite, ici directement (après un simple filtrage de la passerelle), par la passerelle centrale 105, pour les raisons évoquées précédemment, après un contrôle de la passerelle à laisser passer la requête. L’ordinateur de bord 104 vérifie ensuite, à l’étape S4, la légitimité de mise en œuvre de la mise à jour du calculateur 101. La passerelle centrale 105 délègue ainsi à l’ordinateur de bord 104 les opérations de contrôle de sûreté. Pour cela, l’ordinateur de bord 104 est programmé pour détecter si des conditions statiques et dynamiques sont réunies pour légitimer la demande de mise à jour et son contexte, comme illustré par la figure 2. La figure 2 représente un ordinogramme de l’étape S4 mise en œuvre pour le premier mode de réalisation de l’invention. Par défaut (étape S41), le processus de génération de la commande d’inhibition n’est pas actif, et les alertes DTC (alertes de défauts de diagnostic) ne sont pas filtrées. A l’étape S42, l’ordinateur de bord 104 reçoit une requête de mise à jour par le contrôleur d’interface 103. A l’étape S43, l’ordinateur de bord 104 détecte si des conditions statiques, liées à l’état du véhicule, sont réunies. Les conditions statiques peuvent être par exemple l’une ou l’autre des conditions suivantes, prise seule ou en combinaison : vitesse nulle, contact coupé, moteur éteint. Dans l’affirmative, l’ordinateur de bord 104 détecte si des conditions dynamiques sont réunies, en particulier si l’utilisateur applique une séquence combinatoire prédéfinie sur le véhicule (étape S44). Ces commandes étant appliquées par l’utilisateur lorsque le véhicule est arrêté, elles n’ont aucune influence sur la conduite du véhicule. Les conditions dynamiques peuvent être par exemple l’une ou l’autre des conditions suivantes, prise seule ou en combinaison : les commandes peuvent consister à réaliser une séquence prédéterminée sur les pédales et/ou sur le boitier de vitesse et/ou sur des boutons accessibles sur le tableau de bord du véhicule. Si les conditions statiques et si les conditions dynamiques ne sont pas remplies, l’ordinateur de bord 104 informe le contrôleur d’interface 103 du rejet de la mise à jour, en raison de conditions non valides (étape S45). Les conditions statiques, qui correspondent à un pré-requis sont ainsi renforcées, car un maliciel (ou logiciel malveillant, ou encore « malware » selon la terminologie anglo-saxonne) dans la zone 1 pourrait permettre d’initier cette commande (étape S42). En effet, la condition dynamique, qui est physique, orientée utilisateur ne pourra être émulée par le maliciel. La combinaison des conditions dynamiques et statiques permet donc de rendre robuste la légitimité du contexte par une action machine à laquelle on rajoute une action humaine. Si la séquence combinatoire prédéfinie est détectée à l’issue de l’étape S44, l’ordinateur de bord 104 transmet au contrôleur d’interface 103 un message de confirmation de la légitimité de mise en œuvre de la mise à jour. Il transmet également à destination de l’ensemble des calculateurs du réseau local un message destiné à inhiber l’émission par ces calculateurs d’alertes DTC durant la phase de mise à jour (étape S46). Si les conditions statiques sont perdues (étape S47), le contrôleur d’interface 103 en est averti et le processus d’inhibition est interrompu (étape S48). A contrario, si l’ordinateur de bord 104 reçoit la requête de fin de mise à jour (étape S49), le message d’inhibition n’est plus transmis (étape S491). Enfin, à l’étape S492, le processus de génération de la commande d’inhibition n’est plus actif. Ainsi, le calculateur 101 est mis à jour, à l’aide des éléments logiciels contenus dans le paquet de mise à jour. Si le calculateur (cible) 101 est dans la zone 3, les éléments logiciels contenus dans le paquet de mise à jour transiteront nécessairement par la passerelle centrale 105, qui les stocke dans une mémoire tampon (ou buffer selon la terminologie anglo-saxonne), et qui vérifie l’authenticité/intégrité pour le calculateur à mettre à jour 101. Etant donné que le calculateur connexe 102 a reçu un message d’inhibition des alertes DTC, il n’émettra et ne stockera aucune de ces alertes durant la phase de mise à jour. Sur les figures, un seul calculateur connexe 102 est représenté. Il apparaît clairement que l’invention peut être mise en œuvre avec une pluralité de calculateurs connexes. Ainsi, l’utilisateur final ne voit pas d’alerte émise en raison de la déconnexion temporaire du calculateur à mettre à jour 101. De même, le technicien, en atelier, n’a plus besoin de supprimer une à une les alertes DTC avec un outil de diagnostic. Le calculateur à mettre à jour 101 est avantageusement un calculateur multimédia, qui doit être mis plus souvent à jour que les autres types de calculateurs. Ce premier mode de réalisation est particulièrement avantageux car, comme l’illustre la figure 1, il peut être mis en œuvre avec des passerelles centrales 105 disponibles dans le commerce, ou déjà installées dans des véhicules. Seul l’ordinateur de bord 104 doit être modifié ou mis à jour (par des moyens logiciels et/ou matériels) pour pouvoir mettre en œuvre la machine d’état des conditions d’activation. La figure 3 illustre un deuxième mode de réalisation de l’invention. Le deuxième mode de réalisation comprend les mêmes éléments que pour le premier mode de réalisation : support comprenant la mise à jour 106, contrôleur d’interface 103 et calculateur à mettre à jour 101dans la zone 1, passerelle centrale 105 dans la zone 2, ordinateur de bord 104, et calculateur connexe 102 dans la zone 3. Les deux premières étapes de réception d’un paquet de mise à jour du calculateur 101 (étape S1’) et d’extraction du paquet par le contrôleur d’interface 103 (étape S2’) sont identiques au premier mode de réalisation. Puis, le procédé selon le deuxième mode de réalisation comprend une étape S22’, illustrée en détail par la figure 4, d’échange d’un conteneur (ou jeton, ou encore « token » selon la terminologie anglo-saxonne) contenant des droits de mise à jour du calculateur 101, entre le contrôleur d’interface 103 et l’ordinateur de bord 104. Le conteneur est sécurisé, c’est-à-dire chiffré. Dans une première étape S221, le contrôleur d’interface 103 transmet, à l’ordinateur de bord 104, un conteneur crypté contenant des droits (étape S221). A l’étape S222, l’ordinateur de bord 104 stocke le conteneur transmis par le contrôleur d’interface 103. Le stockage peut être par exemple effectué dans une mémoire vive de l’ordinateur de bord 104. A l’étape S223, l’ordinateur de bord 104 authentifie le conteneur. A l’étape S224, l’ordinateur de bord 104 décrypte le conteneur. Le conteneur est équivalent à un « pseudo-dossier », dans le sens où il peut comprendre une pluralité de fichiers, selon une arborescence bien définie. Pour décrypter le conteneur, l’ordinateur de bord 104 peut utiliser une clé convenue préalablement avec le contrôleur d’interface 103, sous forme de mot de passe, ou bien utiliser un de certificat de type RSA, ou encore un autre mode de chiffrement/déchiffrement connus de l’homme du métier. A l’étape S225, l’ordinateur de bord 104 vérifie l’intégrité du contenu déchiffré lors de l’étape S224, en effectuant par exemple au moins l’une des actions suivantes : vérification de l’existence dans le jeton d’une demande de mise à jour de calculateur, vérification de la durée de validité de la mise à jour, identification du calculateur devant être mis à jour, type de commande autorisée. Enfin, à l’étape S226, l’ordinateur de bord 104 prend en compte les droits contenus dans le conteneur sécurisé, et transmet un message de réponse positive au contrôleur d’interface 103. L’échange de conteneur permet de réserver l’accès au conteneur aux seuls destinataires autorisés et identifiés. Ainsi, dans le cadre de l’invention, la procédure se poursuit si la procédure de décryptage a abouti entre le contrôleur d’interface 103 et l’ordinateur de bord 104. Le contrôleur d’interface 103 transmet ensuite, à l’étape S3’, la requête de mise à jour du calculateur 101 à l’ordinateur de bord 104. L’ordinateur de bord 104 s’assure que la requête de mise à jour transmise par le contrôleur d’interface 103 est légitime. La machine d’état des conditions d’activation est illustrée en détail à la figure 5. Par défaut (étape S41’), le processus de génération de la commande d’inhibition n’est pas actif, et les alertes DTC (alertes de défauts de diagnostic) ne sont pas filtrées. A l’étape S42’, l’ordinateur de bord 104 reçoit une requête de mise à jour par le contrôleur d’interface 103. Puis, à l’issue du mécanisme d’échange d’un conteneur crypté précité, si la réponse est positive (réponse OK sur la figure 3), l’ordinateur de bord 104 détecte, à l’étape S43’, si des conditions statiques, liées à l’état du véhicule, sont réunies. Si les conditions statiques ne sont pas remplies, l’ordinateur de bord 104 informe le contrôleur d’interface 103 du rejet de la mise à jour, en raison de conditions non valides (étape S45’). A contrario, si les conditions statiques sont remplies, l’ordinateur de bord 104 transmet au contrôleur d’interface 103 un message de confirmation de la légitimité de mise en œuvre de la mise à jour. Il transmet également à destination de l’ensemble des calculateurs du réseau local un message destiné à inhiber l’émission par ces calculateurs d’alertes DTC durant la phase de mise à jour (étape S46’). Si les conditions statiques sont perdues (étape S47’), le contrôleur d’interface 103 en est averti et le processus d’inhibition est interrompu (étape S48’). A contrario, si l’ordinateur de bord 104 reçoit la requête de fin de mise à jour (étape S49’), le message d’inhibition n’est plus transmis (étape S491’). Enfin, à l’étape S492’, le processus de génération de la commande d’inhibition n’est plus actif. Ainsi, par rapport à la machine à état des conditions d’activation du premier mode de réalisation, on supprime, dans la machine à état des conditions d’activation du deuxième mode de réalisation, les conditions dynamiques mises en œuvre par des opérations physiques de l’utilisateur, en rajoutant le mécanisme d’échange d’un conteneur crypté. A l’issue de ce contrôle de sûreté par l’ordinateur de bord 104, un message d’inhibition est transmis à l’ensemble des calculateurs connexes 102, ce qui évitera de générer des alertes DTC lors de la mise à jour du calculateur 101 (étape S5 du procédé). La figure 6 illustre un troisième mode de réalisation du procédé selon l’invention. Pour ce mode de réalisation, les étapes S1’’, S2’’ et S3’’ sont identiques aux étapes S1’, S2’ et S3’ du deuxième mode de réalisation (également identiques aux étapes S1, S2 et S3 du premier mode de réalisation). Le procédé selon le troisième mode de réalisation comprend également, entre les étapes S2’’ et S3’’, une étape S22’’ d’échange d’un conteneur crypté, comme décrit précédemment (à la différence près que l’échange du conteneur crypté a lieu, pour le troisième mode de réalisation, entre le contrôleur d’interface 103 et la passerelle centrale 105). L’étape S4’’ de vérification des conditions relatives à la légitimité de mise en œuvre de la mise à jour est exécutée uniquement par la passerelle centrale 105. La passerelle centrale 105 met en œuvre le processus de vérification des conditions d’activation illustré par la machine de la figure 7. Par défaut (étape S41’’), le processus de génération de la commande d’inhibition n’est pas actif, et les alertes DTC (alertes de défauts de diagnostic) ne sont pas filtrées. A l’étape S42’’, la passerelle centrale 105 reçoit une requête de mise à jour par le contrôleur d’interface 103. Puis, à l’issue du mécanisme d’échange d’un conteneur crypté précité, si la réponse est positive (réponse OK sur la figure 6), la passerelle centrale 105 détecte, à l’étape S43’’, si des conditions statiques, liées à l’état du véhicule, sont réunies. Si les conditions statiques ne sont pas remplies, la passerelle centrale 105 informe le contrôleur d’interface 103 du rejet de la mise à jour, en raison de conditions non valides (étape S45’’). A contrario, si les conditions statiques sont remplies, la passerelle centrale 105 transmet au contrôleur d’interface 103 un message de confirmation de la légitimité de mise en œuvre de la mise à jour. Il transmet également à destination de l’ensemble des calculateurs du réseau local un message destiné à inhiber l’émission par ces calculateurs d’alertes DTC durant la phase de mise à jour (étape S46’’). Si les conditions statiques sont perdues (étape S47’’), le contrôleur d’interface 103 en est averti et le processus d’inhibition est interrompu (étape S48’’). A contrario, si la passerelle centrale 105 reçoit la requête de fin de mise à jour (étape S49’’), le message d’inhibition n’est plus transmis (étape S491’’). Enfin, à l’étape S492’’, le processus de génération de la commande d’inhibition n’est plus actif. Si les conditions de sûreté sont remplies, à l’étape S5’’, la passerelle centrale 105 transmet un message d’activation de l’inhibition d’alerte DTC sur l’ensemble des calculateurs de la zone 3, qui, en retour, envoient un message d’acquittement à la passerelle centrale 105. Puis, le calculateur 101 est mis à jour (étape S5’’). Une fois que la mise à jour est terminée, la passerelle centrale 105 envoie, à destination de l’ensemble des calculateurs de la zone 3, un message d’arrêt de l’inhibition d’alertes DTC. Un message d’acquittement est à nouveau transmis à la passerelle centrale 105. Le troisième mode de réalisation est particulièrement avantageux car l’inhibition est hébergée par la passerelle centrale 105 ; le procédé peut donc être mis en œuvre avec des ordinateurs de bord 104 disponibles dans le commerce, ou avec des ordinateurs de bord 104 déjà embarqués dans des véhicules, sans qu’il y ait besoin de les mettre à jour. Procédé de mise à jour, par réception d’un signal contenant un paquet de mise à jour sur un port de contrôleur d’interface (103), d’un calculateur (101) embarqué dans un véhicule automobile, le calculateur (101) à mettre à jour, au moins un calculateur connexe (102) et un ordinateur de bord du véhicule (104) étant connectés entre eux sur un réseau local, l’ordinateur de bord du véhicule (104) étant connecté au contrôleur d’interface (103) par l’intermédiaire d’une passerelle centrale du véhicule (105) configurée pour connecter de façon sécurisée le contrôleur d’interface (103) et l’ordinateur de bord du véhicule (104), le procédé comprenant les étapes suivantes : - réception, au niveau du port de contrôleur d’interface (103), d’un signal contenant un paquet de mise à jour du calculateur (101) à mettre à jour (S1, S1’, S1’’) ; - extraction par le contrôleur d’interface (103) du paquet de mise à jour (S2, S2’, S2’’) ; - transmission par le contrôleur d’interface (103) à destination de l’ordinateur de bord (104) ou de la passerelle centrale (105) d’une requête de mise à jour du calculateur (S3, S3’, S3’’) ; - vérification, par l’ordinateur de bord (104) ou par la passerelle centrale (105), de conditions relatives à la légitimité de mise en œuvre de la mise à jour (S4, S4’, S4’’) ; - si les conditions relatives à la légitimité de mise en œuvre de la mise à jour sont remplies, transmission à destination d’au moins un calculateur connexe (102) d’un message d’inhibition de défauts de diagnostic, et mise à jour du calculateur (101) (S5, S5’, S5’’). Procédé selon la revendication 1, dans lequel : - lors de l’étape de transmission de la requête de mise à jour du calculateur (S3), la requête de mise à jour du calculateur est transmise à l’ordinateur de bord (104) ; - lors de l’étape de vérification (S4), l’ordinateur de bord (104) détecte si au moins une condition statique, liée à l’état du véhicule, est satisfaite, et si au moins une condition dynamique, opérée par un utilisateur du véhicule, est satisfaite ; - lors de l’étape de transmission d’un message d’inhibition (S5), l’ordinateur de bord (104) transmet le message d’inhibition de défaut de diagnostic. Procédé selon la revendication 2, dans lequel la condition dynamique est satisfaite si l’utilisateur du véhicule actionne une séquence combinatoire prédéfinie de commandes du véhicule. Procédé selon la revendication 1, dans lequel : - le procédé comprend, entre les étapes d’extraction (S2’) et de transmission de la requête de mise à jour du calculateur (S3’), une étape d’échange (S22’) d’un conteneur crypté contenant des droits de mise à jour du calculateur (101) entre le contrôleur d’interface (103) et l’ordinateur de bord (104) ; - à l’issue de l’étape d’échange (S22’), l’étape de transmission de la requête de mise à jour du calculateur (S3’) comprend la transmission de la requête de mise à jour du calculateur à l’ordinateur de bord (104) ; - lors de l’étape de vérification (S4’), l’ordinateur de bord (104) détecte si au moins une condition statique, liée à l’état du véhicule, est satisfaite ; - lors de l’étape de transmission d’un message d’inhibition (S5’), l’ordinateur de bord (104) transmet le message d’inhibition de défaut de diagnostic. Procédé selon la revendication 1, dans lequel : - le procédé comprend, entre les étapes d’extraction (S2’’) et de transmission de la requête de mise à jour du calculateur (S3’’), une étape d’échange (S22’’) d’un conteneur crypté contenant des droits de mise à jour du calculateur (101) entre le contrôleur d’interface (103) et la passerelle centrale (105) ; - à l’issue de l’étape d’échange (S22’’), l’étape de transmission de la requête de mise à jour du calculateur (S3’’) comprend la transmission de la requête de mise à jour du calculateur à la passerelle centrale (105) ; - lors de l’étape de vérification (S4’’), la passerelle centrale (105) détecte si au moins une condition statique, liée à l’état du véhicule, est satisfaite ; - lors de l’étape de transmission d’un message d’inhibition (S5’’), la passerelle centrale (105) transmet le message d’inhibition de défaut de diagnostic. Procédé selon l’une des revendications 4 ou 5, dans lequel l’étape (S22’, S22’’) d’échange d’un conteneur crypté contenant des droits de mise à jour du calculateur entre le contrôleur d’interface (103) et la passerelle centrale (105) comprend : - l’émission par le contrôleur d’interface (103) d’un conteneur crypté contenant des droits de mise à jour du calculateur (S221) ; - la mise en œuvre des étapes suivantes par la passerelle centrale(105) : -- le stockage du conteneur (S222) ; -- l’authentification du conteneur (S223) ; -- le décryptage du conteneur (S224) ; -- la vérification de l’intégrité du conteneur (S225) ; -- la prise en compte des droits de mise à jour du calculateur contenus dans le conteneur (S226). Procédé selon l’une des revendications 2 à 6, dans lequel la transmission du message d’inhibition de défaut de diagnostic est interrompue si la condition statique n’est plus satisfaite. Procédé selon l’une des revendications précédentes, dans lequel la mise à jour est effectuée par clé USB, le port de contrôleur d’interface comprenant un port USB. Ordinateur de bord de véhicule (104), configuré pour être connecté à un calculateur (101) à mettre à jour et à au moins un calculateur connexe (102) sur un réseau local de véhicule, l’ordinateur de bord de véhicule (104) étant configuré pour mettre en œuvre les étapes suivantes : - réception d’une requête de mise à jour du calculateur ; - vérification des conditions relatives à la légitimité de mise en œuvre de la mise à jour ; - si les conditions relatives à la légitimité de mise en œuvre de la mise à jour sont remplies, transmission à destination d’au moins un calculateur connexe (102) d’un message d’inhibition de défauts de diagnostic. Ordinateur de bord de véhicule (104) selon la revendication 9, dans lequel l’ordinateur de bord (104) est configuré pour détecter si au moins une condition statique, liée à l’état du véhicule, est satisfaite, et si au moins une condition dynamique, opérée par un utilisateur du véhicule, est satisfaite. Ordinateur de bord de véhicule (104) selon la revendication 9, dans lequel l’ordinateur de bord (104) est configuré pour échanger, avec le contrôleur d’interface (103), un conteneur crypté contenant des droits de mise à jour du calculateur (101), et pour détecter si au moins une condition statique, liée à l’état du véhicule, est satisfaite. Passerelle centrale de véhicule (105) configurée pour connecter de façon sécurisée un contrôleur d’interface (103) à un réseau local de véhicule comprenant un calculateur (101) à mettre à jour et au moins un calculateur connexe (102), la passerelle centrale du véhicule (105) étant configurée pour mettre en œuvre les étapes suivantes : - réception d’une requête de mise à jour du calculateur (101) ; - vérification des conditions relatives à la légitimité de mise en œuvre de la mise à jour ; - si les conditions relatives à la légitimité de mise en œuvre de la mise à jour sont remplies, transmission à destination du calculateur connexe (102) d’un message d’inhibition de défauts de diagnostic. Passerelle selon la revendication 12, dans lequel la passerelle centrale de véhicule (105) est configurée pour échanger, avec le contrôleur d’interface (103), un conteneur crypté contenant des droits de mise à jour du calculateur (101), et pour détecter si au moins une condition statique, liée à l’état du véhicule, est satisfaite.