FR3096153A1 - Procédé et dispositif de retour à un état précédent une mise à jour logicielle d’un calculateur d’un véhicule à distance - Google Patents

Abstract

L’invention concerne un procédé de retour à un état précédent une mise à jour logicielle à distance d’au moins un calculateur (ECU2, ECU3) d’un véhicule (101) depuis un serveur (102) de mise à jour distant, ledit procédé étant caractérisé en ce qu’il comprend des étapes de : - Réception, par le serveur (102) de mise à jour distant, d’une demande de retour à un état précédent pour le au moins un calculateur (ECU2, ECU3), - Vérification d’au moins une condition prédéterminée, ladite condition étant relative à un temps estimé entre la dernière mise à jour à distance du au moins un calculateur (ECU2, ECU3) et la demande de retour à un état précédent, - Si la condition prédéterminée est vérifiée alors l’émission d’une commande de retour à un état précédent pour le au moins un calculateur (ECU2, ECU3). Figure pour l’abrégé : Figure 1

Description

Procédé et dispositif de retour à un état précédent une mise à jour logicielle d’un calculateur d’un véhicule à distance

L’invention concerne la mise à jour logicielle d’un ou plusieurs calculateurs d’un véhicule automobile réalisée à distance au moyen d’un outil de diagnostic aussi appelée mise à jour OTA (pour Over The Air).

Dans la suite de la description, lorsque le fichier à télécharger contient des instructions ou le code exécutable d'un logiciel, on parlera également de téléchargement d'un logiciel.

La complexité croissante de la fonction électronique embarquée entraîne une multiplication des boîtiers électroniques (ou calculateurs) montés sur les véhicules automobiles.

Afin de limiter la diversité qui en résulte, il a été décidé de reporter lorsque cela est possible la diversité matérielle sur le logiciel et de pratiquer un téléchargement de ces calculateurs. L'opération est réalisée moyennant un outil débarqué qui se connecte sur la prise diagnostic du véhicule et permet de programmer dans la mémoire du ou des calculateurs le logiciel qui assure un fonctionnement conforme du véhicule produit en prenant en compte les caractéristiques (motorisation, options) propres à ce véhicule.

La communication entre l'outil et le ou les calculateurs fait généralement usage soit de la technologie CAN 500kbps connue de l’état de l’art actuel ou de la technologie Ethernet 100 Mbits/s en cours de déploiement dans le monde automobile afin de transférer les données à programmer.

On connaît déjà dans l'état de la technique des procédés et des systèmes de téléchargement de fichiers dans des calculateurs embarqués à bord de véhicules automobiles, tels que ceux décrits par exemple dans le document FR-A-2719924. Ce document détaille les différentes étapes successives de la procédure utilisée lors de l'assemblage des véhicules ou dans le réseau après-vente d'un constructeur, lors de la correction d'une prestation par échange de fichier.

Cependant, dans le but de rendre les véhicules toujours plus sûrs pour leurs clients, les constructeurs automobiles envisagent de pouvoir réaliser certaines mises à jour directement chez le client final, à l’image de ce qui existe déjà dans le domaine du consumériste pour un PC ou un smartphone par exemple. En effet, les moyens de connectivité présents dans les véhicules permettent déjà d’échanger de nombreuses informations avec l’extérieur (informations de trafic, de navigation, de données pour la réparation ou pour les assureurs, …) et ces échanges sont en pleine expansion. Il en résulte une demande accrue pour la protection des données clients, mais aussi pour une protection importante de ces véhicules compte tenu des possibilités de cyber-attaque et du risque encouru sur la sécurité routière. En effet, lors de la détection d’une attaque de ce type et de la disponibilité d’un « patch » correctif (un logiciel ou module logiciel) en mesure d’en supprimer ou d’en réduire les risques, la vitesse à laquelle cette correction peut être installée revêt sans aucun doute un aspect primordial. Dans ce cas, une mise à jour OTA peut permettre de gagner beaucoup de temps en comparaison d’un rappel organisé des véhicules dans le garage du réseau agrée ou indépendant.

Pour pouvoir réaliser ce type d’opération directement chez le client final, il convient néanmoins de prendre en considérations plusieurs aspects qui ajoutent à la complexité de cette opération.

La mise à jour du logiciel d’un calculateur d’une automobile peut dans certains cas la rendre indisponible ou encore induire des conséquences importantes tant pour les occupants du véhicule que pour son environnement. C’est la raison pour laquelle la mise à jour en OTA de certains calculateurs et en particulier ceux qui sont associés à la dynamique du véhicule nécessitent un mécanisme appelé Rollback (ou retour en arrière, ou encore retour à un état précédent) qui permet de revenir à la configuration logicielle antérieure dans le cas de la détection d’un problème survenue pendant la mise à jour du logiciel d’un ou plusieurs calculateurs du véhicule.

Ce type de problème peut intervenir dans le cas où le calculateur destinataire essaye d’écrire une valeur sur une cellule mémoire corrompue par exemple, ou dans le cas d’une erreur de transmission due par exemple à un champ électromagnétique, ou d’autres cas encore.

Un tel type de problème est généralement détecté par le calculateur destinataire (par exemple au moyen d’une vérification d’un CRC Cyclic Redoundancy Check dans le cas d’une réception erronée). Dans ce cas, une information sera transmise au calculateur maitre pour demander l’exécution du processus de rollback.

On connait par exemple par le document US20190057214 un dispositif de commande de mise à jour qui comprend une première unité de communication, une seconde unité de communication, et une unité de commande. La première unité de communication est configurée pour recevoir des données de patch pour chaque bloc, des logiciels et des premières données d'authentification pour chaque bloc d'authentification d'un logiciel dans un terminal mis à jour en utilisant les données de patch sur une base par bloc.

L'unité de commande est configurée pour demander au terminal d'effectuer un rollback pour restauration d’un premier bloc à un (M-1) ième bloc en utilisant les données de patch à réception d'un résultat de mise jour indiquant une défaillance dans une authentification d’un bloc Mième (M> 1).

Malgré toutes ces précautions et ces systèmes de vérifications, il reste possible que certains cas de mauvais fonctionnement ne puissent pas être détectés à l’issue de la mise à jour OTA alors que dans un garage, avec un technicien procédant à l’opération, ils l’auraient été

En effet, la mise à jour d’un logiciel dans un garage répond à une procédure spécifique au cours de laquelle, l’opérateur devient responsable du véhicule qui lui a été confié. A cet égard, il place le véhicule dans un environnement sûr (« safe and secure ») avant de lancer cette opération, puis une fois l’opération terminée, effectue certains contrôles afin de s’assurer de son bon fonctionnement. En cas de problème détecté, soit lors du déroulement de la procédure ou après la mise à jour, le technicien prendra les mesures nécessaires à la correction de l’anomalie (nouvel essai, changement de pièce, …) avant de restituer le véhicule au client. Pour contrôler l’état du véhicule avant sa restitution au client, le garagiste utilise aussi et d’abord ses sens (ouïe dans le cas du démarrage, vue des indicateurs, mise en service de certaines fonctions, … et va parfois même jusqu’à devoir réaliser un roulage).

Lors d’une mise à jour OTA chez un client, rien de tout cela n’est possible et il convient donc d’ajouter un logiciel dédié se substituant au garagiste pour vérifier le bon fonctionnement avant de « restituer » le véhicule au client.

Malgré l’utilisation d’un logiciel dédié, il reste possible que, dans certains cas, le logiciel ne détecte aucune anomalie mais que le client constate que son véhicule ne démarre pas (on a par exemple téléchargé un logiciel compatible dans une ECU ne générant pas de code d’erreur, mais pas la version attendue pour le véhicule en question).

Dans un tel cas, il est probable que le client appelle le service du constructeur et que la seule façon de lui permettre d’utiliser son véhicule pour atteindre le garage le plus proche consiste à lui déclencher à distance le mécanisme de rollback afin de revenir à la version antérieure sur son véhicule.

Une difficulté demeure cependant, elle est liée au fait que la conception de cette fonctionnalité repose sur l’exigence de respect d’un haut niveau de protection contre la malveillance et de possibles attaques à distance qui pourraient profiter de cette fonctionnalité pour demander un retour à la version antérieure d’un ou plusieurs calculateurs sans que cette demande ne soit fondée.

Un objet de la présente invention est de proposer une solution pour remettre en état à distance un véhicule lorsqu’un client constate un disfonctionnement de celui-ci suite à une mise à jour à distance, tout en maintenant un haut niveau de protection face à de possibles attaques à distance.

L’invention concerne en particulier un procédé de retour à un état précédent suite à une mise à jour logicielle à distance d’au moins un calculateur (ECU2, ECU3) d’un véhicule (101) depuis un serveur (102) de mise à jour distant, ledit procédé étant caractérisé en ce qu’il comprend des étapes de :

- Réception (201), par le serveur (102) de mise à jour distant, d’une demande de retour à un état précédent pour le au moins un calculateur (ECU2, ECU3),

- Vérification (202) d’au moins une condition prédéterminée, ladite condition étant relative à un temps estimé entre la dernière mise à jour à distance du au moins un calculateur (ECU2, ECU3) et la demande de retour à un état précédent,

- Si la condition prédéterminée est vérifiée alors l’émission (203) d’une commande de retour à un état précédent pour le au moins un calculateur (ECU2, ECU3).

Ainsi, au moyen de cette invention, il devient possible de demander et de réaliser une opération consistant à revenir à la version logicielle antérieure à la dernière mise à jour OTA mais seulement dans un temps prédéterminé afin de prévenir le véhicule contre des actions malveillantes.

Ainsi, cette invention permet, dans le cas d’une mise à jour OTA menée jusqu’à son terme, à un client de formuler une demande auprès d’une assistance technique pour revenir à la version antérieure et pouvoir utiliser son véhicule en toute sécurité pour rejoindre un garage ou une succursale.

L’invention permet en outre de disposer de mécanismes qui sur condition permettent de supprimer cette possibilité de retour à la version antérieure afin de ne pas compromettre la sécurité du véhicule dans le cas de cyberattaques des véhicules connectés.

Selon un mode de réalisation, la au moins une condition prédéterminée comprend une comparaison, par le serveur de mise à jour (102), entre une date de mise à jour dudit au moins un calculateur (ECU2, ECU3), dite première date et une date de réception de la demande de retour à un état précédent la mise à jour pour ledit au moins un calculateur (ECU2, ECU3), dite deuxième date, la condition étant remplie si la différence entre la deuxième et la première date est inférieure à un premier seuil prédéterminé.

Cette caractéristique met en œuvre un mécanisme permettant de s’affranchir de l’horloge du véhicule. Le rollback est autorisé après vérification dans le serveur de mise à jour 102 du moment où cette opération de mise à jour a eu lieu.

Selon un autre mode de réalisation, le véhicule (101) comportant un calculateur de gestion de mise à jour (ECU1), la au moins une condition prédéterminée comprend une comparaison, par le calculateur de gestion de mise à jour (ECU1), d’un nombre de démarrage du véhicule (101) depuis la mise à jour à distance dudit au moins un calculateur (ECU2, ECU3) et d’un deuxième seuil prédéterminé, la condition étant remplie si le nombre de démarrage est inférieur au deuxième seuil.

Cette caractéristique met en œuvre un mécanisme permettant de s’affranchir de l’horloge du véhicule. Le rollback n’est autorisé que tant que le nombre de démarrage du véhicule est inférieur à un seuil prédéterminé (par exemple inférieur à 3 redémarrage).

Avantageusement, le procédé de retour à un état précédent selon l’invention, comprend en outre une étape d’écriture en mémoire d’un identifiant dudit au moins un calculateur (ECU2, ECU3) mis à jour, ledit identifiant étant associé à une variable indiquant si un retour à un état précédent une mise à jour est autorisé.

Avantageusement, la variable associée à un identifiant dudit au moins un calculateur (ECU2, ECU3), est modifiée consécutivement à une mise à jour, de sorte que la variable indique qu’un retour à un état précédent est autorisé, et en ce que la variable est modifiée lorsqu’une condition prédéterminée n’est plus vérifiée, de sorte que la variable indique qu’un retour à un état précédent est interdit.

L’invention concerne aussi un produit programme d’ordinateur comportant des instructions adaptées pour l’exécution des étapes du procédé selon l’invention, lorsque le programme d’ordinateur est exécuté par au moins un processeur.

L’invention concerne aussi un serveur de mise à jour comportant au moins un processeur et une mémoire caractérisé en ce qu’il est configuré pour mettre en œuvre le procédé selon l’invention.

L’invention concerne aussi un système de mise à jour comportant un véhicule caractérisé en ce qu’il comporte en outre un serveur l’invention.

D’autres caractéristiques et avantages de l’invention ressortiront de la description des modes de réalisation non limitatifs de l’invention ci-après, en référence aux figures annexées, sur lesquelles :

illustre de façon schématique un système, selon un exemple de réalisation particulier de la présente invention ;

illustre schématiquement un procédé de retour à un état précédent selon un exemple de réalisation particulier de la présente invention.

illustre de façon schématique un calculateur, selon un exemple de réalisation particulier de la présente invention.

En référence à la figure 1, le système selon l’invention comporte un véhicule 101 connecté à un serveur 102 de mise à jour distant.

Le véhicule 101 comprend une pluralité de calculateurs ECU1, ECU2, ECU3 dont une unité de communication embarquée qui communique avec le serveur 102, par l'intermédiaire d'une connexion sans fil. Typiquement, la connexion ou liaison sans fil est une connexion par ondes radio (3G, 4G, …).

Les calculateurs ECU1, ECU2, ECU3 communiquent entre eux par l’intermédiaire d’un bus de données 104 (par exemple de type CAN).

Le serveur débarqué 102 est par exemple un calculateur générique comportant au moins une mémoire et un processeur.

Le véhicule 101 et le serveur débarqué 102 communique via un réseau étendu 105 tel que un réseau de communication fixe 103 (ou WAN pour "Wide Area Network"), par exemple le réseau Internet auquel véhicule se connecte par une liaison sans fil (3G, 4G, …).

Le calculateur ECU1 aussi appelé calculateur de gestion de mise à jour (ou encore FOTA Master – pour Firmware Over-The-Air) qui permet la mise à jour des calculateurs ECU2 à ECU3, dispose à cet effet des mécanismes capables de transférer les fichiers de données reçues en trames attendues par les calculateurs ECU2, ECU3 destinataires pour installer leur logiciel. A noter que le calculateur jouant le rôle de FOTA master dans un véhicule peut ou non être le même calculateur que celui qui dispose des fonctions de communication sans fils.

On suppose que l’un des calculateurs ECU2 ou ECU3 est mis à jour en OTA, par l’intermédiaire du calculateur de gestion de mise à jour ECU1. Suite à cette mise à jour, le client constate que son véhicule 101 se trouve dans un état qui n’est pas celui auquel il s’attend. Ce dernier contacte l’assistance du constructeur au moyen d’une IHM disponible dans son véhicule (si le véhicule dispose de cette fonctionnalité) ou au moyen de son smartphone 106 : cette communication est représentée par la flèche (1).

Un opérateur via un terminal 107, après avoir réalisé les vérifications qui s’imposent quant à l’identité du demandeur et le bienfondé de la demande, transmet une information de demande de génération de Rollback sur le véhicule 101, par exemple sous la forme d’une API dédiée.

Cette commande va être transmise au véhicule (2) par voie d’onde qui peut être de la 4G, du WIFI ou toute autre technologie de communication sans fil à venir.

Le procédé décrit ci-après comporte des conditions supplémentaires permettant d’interdire la mise en œuvre d’un rollback de façon à réduire le risque d’attaque à distance cherchant à tirer profit d’un rollback.

En référence à la figure 2, le procédé de retour à un état précédent une mise à jour logicielle d’au moins un calculateur ECU2, ECU3 comprend des étapes de :

- Réception 201, par le serveur 102 de mise à jour distant, d’une demande de retour à un état précédent pour ledit au moins calculateur ECU2, ECU3,

- Vérification 202 d’au moins une condition prédéterminée, ladite condition étant relative à un temps estimé entre la dernière mise à jour OTA dudit au moins un calculateur ECU2, ECU3 et la demande de retour à un état précédent,

- Si la condition prédéterminée est vérifiée alors l’émission 203, à destination du véhicule 101, d’une commande de retour à un état précédent pour ledit calculateur.

Pour des raisons de cybersécurité, il convient de définir au moins une condition (ou trigger) destinée à autoriser ou interdire ce retour à la version précédente. Le véhicule 101 ne dispose pas d’une référence horaire fiable : en particulier parce qu’une batterie peut toujours être débranchée et que les calculateurs ne disposent pas de piles internes de sauvegarde.

L’invention met donc en œuvre un mécanisme permettant de s’affranchir de l’horloge du véhicule.

Dans un premier mode de réalisation, l’exécution la demande de rollback n’est autorisée que tant que le nombre de démarrage du véhicule est inférieur à un seuil V1 prédéterminé (par exemple inférieur à 3 redémarrage). On peut en effet considérer que le client ne soit pas toujours en état de constater certaines anomalies lors du premier démarrage réalisé juste après la mise à jour OTA.

Dans un deuxième mode de réalisation, le rollback est autorisé après vérification dans le serveur de mise à jour 102 du moment où cette opération de mise à jour a eu lieu. Pour ce faire, après une mise à jour du calculateur ECU2, ECU3, le véhicule 101 transmet une information sur l’état de la mise à jour au serveur 102. Cette information est alors mémorisée dans le serveur avec un horodatage associé.

Selon une première variante du deuxième mode de réalisation, la au moins une condition prédéterminée comprend une comparaison, par le serveur de mise à jour 102, entre une date de mise à jour du calculateur ECU2, ECU3, dite première date et une date de réception d’une demande de retour à un état précédent de la mise à jour pour ledit calculateur ECU2, ECU3, dite deuxième date, la condition étant remplie si la différence entre la deuxième et la première date est inférieure à un premier seuil prédéterminé.

Dans cette variante, en réponse à la réception de la demande de Rollback, le serveur 102 compare l’heure d’arrivée de cette demande avec celle de mise à jour OTA du logiciel. En cas d’écart trop important, il filtre cette demande, informe l’opérateur et transmet une information au véhicule lui-demandant d’interdire à partir de maintenant la possibilité de déclenchement du rollback.

Selon une deuxième variante deuxième mode de réalisation, une information est transmise directement depuis le serveur 102 vers le véhicule 101 dès lors que la différence entre l’heure tracée de la mise à jour réussie et un seuil est franchi (par exemple 2 jours).

Toute demande de rollback sera dès lors filtrée en automatique par le serveur 102.

De façon avantageuse, la au moins une condition prédéterminée comprend une comparaison, par le calculateur embarqué du véhicule d’un nombre de démarrage du véhicule depuis la mise à jour OTA dudit calculateur et d’un deuxième seuil prédéterminé, la condition étant remplie si le nombre de démarrage est inférieur au deuxième seuil.

Selon une caractéristique de l’invention, le procédé de retour à un état précédent comprend en outre une étape d’écriture en mémoire d’un identifiant du au moins un calculateur mis à jour, ledit identifiant étant associé à une variable indiquant si un retour à un état précédent une mise à jour est autorisé.

La variable associée à un identifiant d’un calculateur est modifiée consécutivement à une mise à jour, de sorte que la variable indique qu’un retour à un état précédent est autorisé, et en ce que la variable est modifiée lorsqu’une condition prédéterminée n’est plus vérifiée, de sorte que la variable indique qu’un retour à un état précédent est interdit.

Pour pouvoir réaliser un rollback déclenché, il faut que le calculateur jouant le rôle de FOTA Master (ECU1) mémorise certains paramètres lors d’une mise à jour OTA et que la mémorisation de ces paramètres soit conservée jusqu’à l’annulation de la possibilité de jouer ce rollback.

Pour cela, lors de la mise à jour OTA d’un ou plusieurs calculateurs, les identifiants des calculateurs mis à jour sont sauvegardés en mémoire non volatile dans le calculateur FOTA Master (ECU1). Tant que ces identifiants sont présents en mémoire non volatile, un rollback déclenché reste possible.

Lorsque le calculateur FOTA Master reçoit une demande de rollback déclenché, il utilise les identifiants des calculateurs dont il dispose dans sa mémoire interne pour leur transmettre une demande de retour à un état précédent (aussi appelé version n-1). Cette demande peut être réalisée au moyen d’une requête de diagnostic spécifique selon par exemple un protocole comme l’UDS (Unified Diagnostic Services) connu de l’état de l’art.

Lorsqu’une condition est atteinte alors ces valeurs d’identifiants sont effacées de la mémoire du FOTA master (ECU1) de telle sorte qu’il ne soit plus possible à partir de cet instant de revenir à la version n-1 d’aucun calculateur.

La figure 3 représente un exemple de serveur 900 de mise à jour. Ce dispositif 900 peut prendre la forme d’un boitier comprenant des circuits imprimés, de plusieurs circuits imprimés reliés par des connections filaires ou non filaires, de tout type d’ordinateur. On entend par circuit imprimé tout type de dispositif apte à effectuer au moins une opération électrique ou électronique.

Le dispositif 900 comprend une mémoire vive 901 pour stocker des instructions pour la mise en œuvre par un processeur 902 du procédé selon l’invention. Le dispositif 900 comporte aussi une mémoire de masse 903 pour le stockage de données destinées à être conservées après la mise en œuvre du procédé.

Le dispositif 900 peut en outre comporter un processeur de signal numérique (DSP) 904.

Une ou plusieurs des étapes du procédé peuvent être effectuées par des composants différents. Ainsi, le procédé peut être mis en œuvre par une pluralité de processeurs, mémoire vive, mémoire de masse, interface d’entrée, interface de sortie et/ou DSP. Dans ces situations, le dispositif 900 peut être décentralisé, au sein d’un réseau local (plusieurs processeurs reliés entre eux par exemple) ou d’un réseau étendu.

Le dispositif 900 comporte également une interface d’entrée 905 pour la réception notamment des données utilisées par le procédé et une interface de sortie 906 pour la transmission des données produites par le procédé.

Claims (8)

1. Procédé de retour à un état précédent une mise à jour logicielle à distance d’au moins un calculateur (ECU2, ECU3) d’un véhicule (101) depuis un serveur (102) de mise à jour distant, ledit procédé étant caractérisé en ce qu’il comprend des étapes de :
   - Réception (201), par le serveur (102) de mise à jour distant, d’une demande de retour à un état précédent pour le au moins un calculateur (ECU2, ECU3),
   - Vérification (202) d’au moins une condition prédéterminée, ladite condition étant relative à un temps estimé entre la dernière mise à jour à distance du au moins un calculateur (ECU2,ECU3) et la demande de retour à un état précédent,
   - Si la condition prédéterminée est vérifiée alors l’émission (203) d’une commande de retour à un état précédent pour le au moins un calculateur (ECU2, ECU3).
2. Procédé de retour à un état précédent selon la revendication 1, caractérisé en ce que la au moins une condition prédéterminée comprend une comparaison, par le serveur de mise à jour (102), entre une date de mise à jour dudit au moins un calculateur (ECU2, ECU3), dite première date et une date de réception de la demande de retour à un état précédent la mise à jour pour ledit au moins un calculateur (ECU2, ECU3), dite deuxième date, la condition étant remplie si la différence entre la deuxième et la première date est inférieure à un premier seuil prédéterminé.
3. Procédé de retour à un état précédent selon l’une des revendications précédentes, caractérisé en ce que, le véhicule (101) comportant un calculateur de gestion de mise à jour (ECU1), la au moins une condition prédéterminée comprend une comparaison, par le calculateur de gestion de mise à jour (ECU1), d’un nombre de démarrage du véhicule (101) depuis la mise à jour à distance dudit au moins un calculateur (ECU2, ECU3) et d’un deuxième seuil prédéterminé, la condition étant remplie si le nombre de démarrage est inférieur au deuxième seuil.
4. Procédé de retour à un état précédent selon l’une des revendications précédentes, caractérisé en ce qu’il comprend en outre une étape d’écriture en mémoire d’un identifiant dudit au moins un calculateur (ECU2, ECU3) mis à jour, ledit identifiant étant associé à une variable indiquant si un retour à un état précédent une mise à jour est autorisé.
5. Procédé de retour à un état précédent selon la revendication précédente, caractérisé en ce que la variable associée à un identifiant dudit au moins un calculateur (ECU2, ECU3), est modifiée consécutivement à une mise à jour, de sorte que la variable indique qu’un retour à un état précédent est autorisé, et en ce que la variable est modifiée lorsqu’une condition prédéterminée n’est plus vérifiée, de sorte que la variable indique qu’un retour à un état précédent est interdit.
6. Produit programme d’ordinateur comportant des instructions adaptées pour l’exécution des étapes du procédé selon l’une des revendications 1 à 5, lorsque le programme d’ordinateur est exécuté par au moins un processeur.
7. Serveur de mise à jour comportant au moins un processeur et une mémoire caractérisé en ce qu’il est configuré pour mettre en œuvre le procédé selon l’une des revendications 1 à 5.
8. Système de mise à jour comportant un véhicule (101) caractérisé en ce qu’il comporte en outre un serveur (102) selon la revendication précédente.