FR3099264A1 - Procédé et dispositif de mise à jour d’un logiciel d’un calculateur embarqué d’un véhicule, comportant une mémoire d’exécution et une mémoire de sauvegarde - Google Patents
Procédé et dispositif de mise à jour d’un logiciel d’un calculateur embarqué d’un véhicule, comportant une mémoire d’exécution et une mémoire de sauvegarde Download PDFInfo
- Publication number
- FR3099264A1 FR3099264A1 FR1908402A FR1908402A FR3099264A1 FR 3099264 A1 FR3099264 A1 FR 3099264A1 FR 1908402 A FR1908402 A FR 1908402A FR 1908402 A FR1908402 A FR 1908402A FR 3099264 A1 FR3099264 A1 FR 3099264A1
- Authority
- FR
- France
- Prior art keywords
- software
- memory
- computer
- update
- blocks
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading
Abstract
L’invention concerne un procédé de mise à jour d’un logiciel d’un calculateur embarqué d’un véhicule, comportant une mémoire d’exécution (ME) dans laquelle sont stockés une pluralité de blocs (A, B, C) d’un logiciel courant, une mémoire de sauvegarde (MS), caractérisé en ce qu’il comporte des étapes de : Emission d’une requête commandant la copie depuis la mémoire d’exécution (ME) vers la mémoire de sauvegarde (MS) de la pluralité de blocs (A, B, C) du logiciel courant, Emission d’une requête commandant une écriture en mémoire d’exécution (ME) d’au moins un bloc de logiciel mis à jour (B’,C’), Emission d’une requête commandant une vérification dudit au moins un bloc de logiciel mis à jour (B’,C’) stocké en mémoire d’exécution (ME). Figure pour l’abrégé : Figure 5
Description
L’invention concerne la mise à jour logicielle d’un ou plusieurs calculateurs d’un véhicule automobile réalisée à distance d’un outil de diagnostic aussi appelée mise à jour OTA (pour Over The Air).
Arrière-plan technologique
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 déjà 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 par exemple 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 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).
Cette solution présente l’inconvénient de devoir générer des blocs de logiciels et de vérifier leur intégrité au cours de la procédure de rollback. Ceci augmente le risque d’échec de la procédure de rollback.
Un objet de la présente invention est de proposer une solution pour remettre rapidement à un état précédent une mise à jour logicielle un calculateur d’un véhicule en particulier lorsqu’un fichier de mise à jour est corrompu.
L’invention concerne en particulier un procédé de mise à jour d’un logiciel d’un calculateur embarqué d’un véhicule, comportant une mémoire d’exécution (ME) dans laquelle sont stockés une pluralité de blocs (A, B, C) d’un logiciel courant, une mémoire de sauvegarde (MS), caractérisé en ce qu’il comporte des étapes de :
- Emission (312) d’une requête commandant la copie depuis la mémoire d’exécution (ME) vers la mémoire de sauvegarde (MS) de la pluralité de blocs (A, B, C) du logiciel courant,
- Emission (322) d’une requête commandant une écriture en mémoire d’exécution (ME) d’au moins un bloc de logiciel mis à jour (B’,C’),
- Emission (323) d’une requête commandant une vérification dudit au moins un bloc de logiciel mis à jour (B’,C’) stocké en mémoire d’exécution (ME),
Et si une erreur est détectée alors :
- Emission (400) d’une requête commandant un retour à un état précédent la mise à jour comportant une copie (403) depuis la mémoire de sauvegarde (MS) vers la mémoire d’exécution (ME) de la pluralité de blocs du logiciel courant (A, B, C).
L’invention a pour avantage lorsqu’un test d’intégrité des données reçues abouti à un échec, de permettre d’interrompre sans délai la procédure d’installation et de relancer rapidement le logiciel initial car celui-ci est sauvegardé dans la mémoire de sauvegarde.
L’invention offre donc un gain de temps mais aussi une sécurité renforcée dans la mesure où elle élimine des risques supplémentaires de corruption des données inévitablement liées aux opérations successives de génération de bloc de logiciels au cours de la phase de rollback dans la solution de l’état de la technique.
Avantageusement, le procédé de mise à jour d’un logiciel d’un calculateur selon l’invention comporte en outre une étape d’émission d’une requête commandant audit calculateur d’effacer la mémoire de sauvegarde, préalablement à l’émission de la requête commandant la copie depuis la mémoire d’exécution vers la mémoire de sauvegarde de la pluralité de blocs du logiciel courant.
Avantageusement, le procédé de mise à jour d’un logiciel d’un calculateur selon l’invention comporte en outre une étape d’émission d’une requête commandant audit calculateur de vérifier l’intégrité de la pluralité de blocs du logiciel courant dans la mémoire de sauvegarde.
Avantageusement, le procédé de mise à jour d’un logiciel d’un calculateur selon l’invention comporte en outre une étape d’émission d’une requête commandant audit calculateur d’effacer de la mémoire d’exécution les blocs de logiciels à mettre à jour.
Avantageusement, l’étape de retour à un état précédent la mise à jour comporte en outre une étape préalable d’effacement de la mémoire d’exécution du calculateur et une étape de vérification de l’intégrité de la pluralité de blocs du logiciel courant dans la mémoire d’exécution.
Avantageusement, le procédé de mise à jour d’un logiciel d’un calculateur selon l’invention comporte en outre une étape d’arrêt de la mise à jour comportant une commande de retour à un état précédent la mise à jour à d’autres calculateurs concernés par ladite mise à jour.
L’invention concerne aussi un dispositif de mise à jour d’un logiciel d’un calculateur, ledit dispositif comprenant une mémoire associée à au moins un processeur, configuré pour mettre en œuvre les étapes du procédé selon l’invention
L’invention concerne aussi un véhicule caractérisé en ce qu’il comporte un dispositif de mise à jour d’un logiciel d’un calculateur selon l’invention.
Brève description des figures
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 :
DESCRIPTION D’EXEMPLES DE REALISATION DE L’INVENTION
L’invention a notamment pour objet un procédé permettant la mise à jour, via une communication filaire ou une communication sans fils, d’un calculateur embarqué muni d’une mémoire externe de capacité égale de la mémoire d’exécution. En cas d’échec pendant l’opération de mise à jour du logiciel, la procédure prévoit une opération de Rollback qui permet de revenir à la version n-1 pour que le véhicule puisse retrouver sa fonctionnalité.
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 Full 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.
Un opérateur via un terminal 107 peut réaliser les vérifications et transmet des instructions à distance au véhicule 101. Ces instructions sont transmises au véhicule 101 par voie d’onde qui peut être de la 4G, du WIFI ou toute autre technologie de communication sans fil à venir.
Les calculateurs ECU1, ECU2, ECU3 peuvent être mis à jour dans un garage. La mise à jour d’un logiciel dans un garage répond à une procédure spécifique (cas 1 de la figure 1) 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 « safe and secure » avant de lancer cette opération à partir d’un outil 106 branché sur une prise dédiée 108 du véhicule 101 Puis une fois l’opération terminée, il 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. Le garagiste est donc à ce titre un maillon important de la chaine safety mais est aussi en charge de s’assurer de la qualité de l’opération réalisée.
Lors d’une mise à jour OTA chez un client (cas 2 de la figure 1), rien de tout cela n’est possible et il convient donc d’ajouter dans chaque calculateur un mécanisme permettant de revenir à la version antérieure en cas de problème.
Pour réaliser les opérations décrites dans cette proposition de brevet, le FOTA master communique avec le calculateur cible via le réseau de communication disponible dans le véhicule (par exemple CAN, Ethernet ou autre). Il utilise pour cela un protocole de communication dédié, comme par exemple, le protocole UDS (norme ISO14229) couramment employé pour réaliser le diagnostic ou le téléchargement du logiciel des calculateurs embarqués dans les véhicules automobiles.
En référence à la figure 2, le calculateur 200 selon l’invention comporte :
- un microcontrôleur 201 comprenant muni d’une mémoire Flash ME, d’une taille donnée N, utilisée pour exécuter le logiciel téléchargé et nommée mémoire d’exécution ME (ou Executing Memory en anglais),
- Une mémoire de sauvegarde MS (ou Backup Memory en anglais), d’une taille au moins égale à la taille donnée N, utilisée comme mémoire de sauvegarde permettant de revenir à la version précédente du logiciel en cas de problème lors de l’installation,
Selon une première variante de l’invention, la mémoire de sauvegarde MS appartient à une mémoire Flash externe 205, d’une taille à moins égale à la taille donnée N.
La mémoire Flash externe est liée au microcontrôleur par exemple par un bus 206 SPI (Serial Peripheral Interface), mais il pourrait s’agir d’une autre liaison de données.
Ce bus peut être remplacé par toute autre technologie de bus de communication dont le débit d’échange de données est suffisant pour que l’installation du nouveau logiciel soit réalisée dans un délai raisonnable vu du client. De façon avantageuse, les données échangées entre la mémoire interne et la mémoire externe sont chiffrées, de façon à améliorer la sécurité de la mise à jour.
Selon une deuxième variante de l’invention, la mémoire de sauvegarde MS peut être intégrée dans la mémoire du microcontrôleur 201. Cette variante a pour avantage de ne pas avoir besoin de chiffrer les données lors d’une copie d’une mémoire à l’autre. En outre, cette variante permet de se passer composants additionnels utilisés pour gérer la communication avec une mémoire externe. Par contre cette variante implique d’utiliser un microcontrôleur disposant d’une mémoire interne de taille au moins double de la taille maximale du logiciel.
On va maintenant présenter le procédé selon l’invention à l’appui de la figure 3, illustrant des étapes dudit procédé et de la figure 5, montrant un exemple de mise en œuvre dudit procédé.
Dans l’exemple de la figure 5, le calculateur à mettre à jour 200, ou calculateur cible, dispose d’un logiciel dans sa mémoire d’exécution ME. Ce logiciel est composé de 3 blocs de données A, B et C.
Le procédé selon l’invention comporte :
Une première phase 310 au cours de laquelle : la totalité du contenu de la mémoire d’exécution ME est dupliqué dans la mémoire de sauvegarde MS afin de conserver une copie du logiciel d’origine.
Une deuxième phase 320 au cours de laquelle : les données à mettre à jour (blocs B’ et C’ dans l’exemple) contenues dans le fichier à télécharger sont transmises au calculateur cible et sont écrites dans la mémoire d’exécution ME à la place des blocs de l’ancien logiciel (blocs B et C dans l’exemple). Les blocs de données non concernés par la mise à jour ne sont pas modifiés (bloc A dans l’exemple).
Une troisième phase, dite de Rollback, exécutée en cas d’échec de l’installation au cours de laquelle la totalité du contenu de la mémoire de sauvegarde MS est recopiée dans la mémoire d’exécution ME afin de revenir au logiciel initial.
Avantageusement, avant la mise à jour du calculateur cible, le FOTA master place le calculateur 200 dans un état dédié à la programmation (où le fonctionnel est désactivé) en utilisant une requête d’entrée en session reprogrammation. Le calculateur cible 200 accepte d’exécuter cette requête uniquement si les conditions sécuritaires sont remplies (ex : véhicule à l’arrêt, chaîne de traction désactivée, etc.)
En session reprogrammation, le FOTA master communique directement avec le logiciel de boot du calculateur cible 200. En fonction des requêtes envoyées par le FOTA master, le logiciel de boot du calculateur peut exécuter différentes opérations (écriture, copie, contrôle d’intégrité) sur l’une des deux mémoires dont il dispose (mémoire d’exécution ME ou mémoire de sauvegarde MS). La figure 3 décrit une succession d’actions à réaliser par le FOTA master pour installer un nouveau logiciel dans le calculateur cible 200.
Avant l’exécution du procédé de mise à jour selon l’invention, le calculateur cible 200 se trouve dans un premier état 501, dit état initial, dans lequel : la mémoire d’exécution ME comporte trois blocs d’un logiciel courant A, B, C.
Avantageusement, la première phase 310 comporte les étapes suivantes :
Dans une première étape 311, le FOTA master envoie une requête pour demander au calculateur cible 200 d’effacer la mémoire de sauvegarde MS.
Dans une deuxième étape 312, le FOTA master envoie une requête pour demander au calculateur cible 200 de copier la totalité du contenu de la mémoire d’exécution ME dans la mémoire de sauvegarde MS.
Dans une troisième étape 313, le FOTA master envoie une requête (j) pour demander au calculateur cible de contrôler l’intégrité des données copiées dans la mémoire de sauvegarde (Backup memory). Cette vérification peut être réalisée à l’aide d’un CRC Cyclic Redoundancy Check ou toute autre méthode connue de l’état de l’art (exemple : calcul, à l’aide d’une fonction de hachage, d’un « condensat » du contenu des données et comparaison du résultat avec une valeur de référence transmise au préalable par le FOTA master). Si la mémoire est composée de plusieurs blocs de données, chaque bloc dispose de son propre mécanisme de contrôle d’intégrité (basé sur la même méthode ou des méthodes différentes).
En cas d’échec lors d’une des première 311, deuxième 312 ou troisième 313 étape, le FOTA master reçoit une réponse négative de la part du calculateur. Dans ce cas, le FOTA master abandonne le déroulement normal de la procédure d’installation pour exécuter la procédure d’arrêt de l’installation 314.
A l’issue de la première phase 310, le calculateur cible 200 se trouve dans un deuxième état 502 dans lequel : la mémoire d’exécution ME comporte les trois blocs du logiciel courant A, B, C, et la mémoire de sauvegarde MS comporte les trois blocs du logiciel courant A, B, C.
Selon une caractéristique de l’invention, la deuxième phase 320 n’est exécutée que si la première phase 310 a été réalisée avec succès au préalable. A partir de cette phase, le logiciel de boot du calculateur cible 200 invalide le logiciel applicatif présent dans la mémoire d’exécution ME car il est susceptible d’être modifié par la suite des opérations. Pour cela, il peut par exemple stocker une variable (ou flag) en mémoire non-volatile, qui sera testée à chaque initialisation du calculateur 200 pour vérifier si le logiciel applicatif chargé en mémoire d’exécution ME peut être exécuté ou non.
Avantageusement, la deuxième phase 320 comporte les étapes suivantes.
Dans une quatrième étape 321, Le FOTA master envoie une requête pour demander au calculateur cible d’effacer tous les blocs de données à mettre à jour dans la mémoire d’exécution ME. La liste des blocs de données à mettre à jour est fournie au FOTA master via le fichier de téléchargement 510.
Dans une cinquième étape 322, le FOTA master écrit les données reçues (par communication filaire ou sans fils depuis le serveur) dans la mémoire d’exécution ME du calculateur cible 200 à l’aide d’une ou plusieurs requête(s). Cette opération est réitérée pour chaque bloc de donnée à mettre à jour.
Dans une sixième étape 323, le FOTA master envoie une requête pour demander au calculateur cible 200 de contrôler l’intégrité des données de chaque bloc de données mis à jour dans la mémoire d’exécution ME. Cette vérification est avantageusement réalisée par les mêmes méthodes qu’à la troisième étape 313.
A l’issue de la deuxième phase 320, le calculateur cible 200 se trouve dans un troisième état 503 dans lequel : la mémoire d’exécution ME comporte un bloc du logiciel courant A et deux blocs du logiciel mis à jour, B, C, et la mémoire de sauvegarde MS comporte les trois blocs du logiciel courant A, B, C.
En cas d’échec lors d’une des quatrième 321, cinquième 322 ou sixième 323 étape, le calculateur cible 200 renvoie une réponse négative au FOTA master. Le FOTA master exécute alors l’opération de retour à un état précédent la mise à jour (Rollback).
Si la deuxième phase 320 s’est exécutée correctement, alors le logiciel de boot du calculateur déclare le logiciel applicatif valide. Le logiciel nouvellement téléchargé est donc automatiquement exécuté par le calculateur lors de la réinitialisation provoquée soit par une requête de la part du FOTA master, soit par une coupure puis remise de l’alimentation du calculateur cible 200.
La procédure d’arrêt de l’installation 314 est exécutée uniquement en cas d’échec de l’installation avant la troisième phase 330.
Deux cas sont à distinguer selon le type d’intervention initialement prévue par l’opérateur : (cas 1) seul le calculateur cible est mis à jour ou (cas 2) plusieurs calculateurs sont concernés par la mise à jour.
Le FOTA master détermine si un plusieurs calculateurs sont concernés par la mise à jour.
Si un seul calculateur est concerné par la mise à jour, le FOTA master envoie un message pour proposer à l’opérateur soit de relancer, soit d’abandonner l’installation. En cas d’abandon, comme le contenu de la mémoire d’exécution ME n’a pas encore été modifié à ce stade des opérations, le calculateur 200 est opérationnel dès le prochain reset, sans opération de Rollback.
Si plusieurs calculateurs sont concernés par la mise à jour, en particulier lorsqu’une cohérence doit être assurée entre les versions de logiciel des différents calculateurs du véhicule :
- Si au moment de l’erreur, seul le calculateur cible 200 a commencé sa mise à jour alors, le FOTA master procède comme pour le premier cas (envoi d’un message à l’opérateur et absence de rollback si abandon),
- Si au moment de l’erreur, d’autres calculateurs dans le véhicule ont déjà été mis à jour, le FOTA master déclenche le processus de Rollback dans tous les calculateurs du véhicule qui le nécessitent jusqu’à retrouver un état précédent la mise à jour dans les autres calculateurs du véhicule.
Comme indiqué précédemment, en cas d’échec lors d’une des quatrième 321, cinquième 322 ou sixième 323 étape, le FOTA master exécute alors l’opération de retour à un état précédent la mise à jour (Rollback).
En référence à la figure 4, l’étape de rollback 400 comporte les sous-étapes suivantes.
Avantageusement, le FOTA master transmet 401 un message à l’IHM pour informer l’opérateur qu’une opération de Rollback est en cours sur un ou plusieurs calculateurs du véhicule.
Le FOTA master envoie 402 une requête pour demander au calculateur cible 200 d’effacer la totalité de la mémoire d’exécution ME.
Le FOTA master envoie 403 une requête pour demander au calculateur cible 200 de copier la totalité du contenu de la mémoire de sauvegarde MS dans la mémoire d’exécution ME.
Le FOTA master envoie 404 une requête pour demander au calculateur cible de contrôler l’intégrité des données copiées dans la mémoire d’exécution ME. Cette vérification est avantageusement réalisée par les mêmes méthodes qu’à la troisième étape 313.
A l’issue de l’opération de rollback, le calculateur peut de nouveau fonctionner avec son logiciel initial après sa réinitialisation provoquée soit par une requête du FOTA master, soit par une coupure puis remise de l’alimentation.
A l’issue de l’opération de rollback 400, le calculateur cible se trouve dans un quatrième état 504 dans lequel : la mémoire d’exécution ME comporte les trois blocs du logiciel courant A, B, C, et la mémoire de sauvegarde MS comporte les trois blocs du logiciel courant A, B, C.
Claims (8)
- Procédé de mise à jour d’un logiciel d’un calculateur embarqué d’un véhicule, comportant une mémoire d’exécution (ME) dans laquelle sont stockés une pluralité de blocs (A, B, C) d’un logiciel courant, une mémoire de sauvegarde (MS), caractérisé en ce qu’il comporte des étapes de :
- Emission (312) d’une requête commandant la copie depuis la mémoire d’exécution (ME) vers la mémoire de sauvegarde (MS) de la pluralité de blocs (A, B, C) du logiciel courant,
- Emission (322) d’une requête commandant une écriture en mémoire d’exécution (ME) d’au moins un bloc de logiciel mis à jour (B’,C’),
- Emission (323) d’une requête commandant une vérification dudit au moins un bloc de logiciel mis à jour (B’,C’) stocké en mémoire d’exécution (ME),
Et si une erreur est détectée alors :
- Emission (400) d’une requête commandant un retour à un état précédent la mise à jour comportant une copie (403) depuis la mémoire de sauvegarde (MS) vers la mémoire d’exécution (ME) de la pluralité de blocs du logiciel courant (A, B, C). - Procédé de mise à jour d’un logiciel d’un calculateur selon la revendication 1, comportant en outre une étape d’émission (311) d’une requête commandant audit calculateur d’effacer la mémoire de sauvegarde (MS), préalablement à l’émission (312) de la requête commandant la copie depuis la mémoire d’exécution (ME) vers la mémoire de sauvegarde (MS) de la pluralité de blocs du logiciel courant (A, B, C).
- Procédé de mise à jour d’un logiciel d’un calculateur selon l’une des revendications précédentes, comportant en outre une étape d’émission (313) d’une requête commandant audit calculateur de vérifier l’intégrité de la pluralité de blocs du logiciel courant (A, B, C) dans la mémoire de sauvegarde (MS).
- Procédé de mise à jour d’un logiciel d’un calculateur selon l’une des revendications précédentes, comportant en outre une étape d’émission (321) d’une requête commandant audit calculateur d’effacer de la mémoire d’exécution (ME) les blocs de logiciels à mettre à jour (B, C).
- Procédé de mise à jour d’un logiciel d’un calculateur dans lequel l’étape de retour à un état précédent la mise à jour comporte en outre une étape préalable d’effacement (402) de la mémoire d’exécution (ME) du calculateur et une étape de vérification (404) de l’intégrité de la pluralité de blocs du logiciel courant (A, B, C) dans la mémoire d’exécution (ME).
- Procédé de mise à jour d’un logiciel d’un calculateur dans lequel l’étape de retour à un état précédent la mise à jour comporte en outre une étape d’arrêt de la mise à jour (314) comportant une commande de retour à un état précédent la mise à jour à d’autres calculateurs concernés par ladite mise à jour.
- Dispositif de mise à jour d’un logiciel d’un calculateur, ledit dispositif comprenant une mémoire associée à au moins un processeur, configuré pour mettre en œuvre les étapes du procédé selon l’une quelconque des revendications 1 à 6.
- Véhicule caractérisé en ce qu’il comporte un dispositif de mise à jour d’un logiciel d’un calculateur selon la revendication précédente.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1908402A FR3099264B1 (fr) | 2019-07-24 | 2019-07-24 | Procédé et dispositif de mise à jour d’un logiciel d’un calculateur embarqué d’un véhicule, comportant une mémoire d’exécution et une mémoire de sauvegarde |
| CN202080053253.9A CN114144759A (zh) | 2019-07-24 | 2020-07-01 | 用于更新车辆的车载计算机的软件的更新方法和更新装置，所述车载计算机包括执行存储器、备份存储器和检查存储器 |
| EP20746261.5A EP4004712A1 (fr) | 2019-07-24 | 2020-07-01 | Procédé et dispositif de mise à jour d'un logiciel d'un calculateur embarqué d'un véhicule, comportant une mémoire d'exécution, une mémoire de sauvegarde et une mémoire de contrôle |
| PCT/FR2020/051149 WO2021014064A1 (fr) | 2019-07-24 | 2020-07-01 | Procédé et dispositif de mise à jour d'un logiciel d'un calculateur embarqué d'un véhicule, comportant une mémoire d'exécution, une mémoire de sauvegarde et une mémoire de contrôle |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1908402 | 2019-07-24 | ||
| FR1908402A FR3099264B1 (fr) | 2019-07-24 | 2019-07-24 | Procédé et dispositif de mise à jour d’un logiciel d’un calculateur embarqué d’un véhicule, comportant une mémoire d’exécution et une mémoire de sauvegarde |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3099264A1 true FR3099264A1 (fr) | 2021-01-29 |
| FR3099264B1 FR3099264B1 (fr) | 2021-07-09 |
Family
ID=68987814
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1908402A Active FR3099264B1 (fr) | 2019-07-24 | 2019-07-24 | Procédé et dispositif de mise à jour d’un logiciel d’un calculateur embarqué d’un véhicule, comportant une mémoire d’exécution et une mémoire de sauvegarde |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3099264B1 (fr) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2719924A1 (fr) | 1994-05-11 | 1995-11-17 | Peugeot | Procédé de déverrouillage de l'accès d'un outil de téléchargement d'un fichier, à un calculateur. |
| US20180018160A1 (en) * | 2015-03-16 | 2018-01-18 | Hitachi Automotive Systems, Ltd. | Software updating apparatus and software updating method |
| US20190057214A1 (en) | 2017-08-21 | 2019-02-21 | Kabushiki Kaisha Toshiba | Update control device, terminal, and method of controlling |
-
2019
- 2019-07-24 FR FR1908402A patent/FR3099264B1/fr active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2719924A1 (fr) | 1994-05-11 | 1995-11-17 | Peugeot | Procédé de déverrouillage de l'accès d'un outil de téléchargement d'un fichier, à un calculateur. |
| US20180018160A1 (en) * | 2015-03-16 | 2018-01-18 | Hitachi Automotive Systems, Ltd. | Software updating apparatus and software updating method |
| US20190057214A1 (en) | 2017-08-21 | 2019-02-21 | Kabushiki Kaisha Toshiba | Update control device, terminal, and method of controlling |
Non-Patent Citations (2)
| Title |
|---|
| DANIEL MCKENNA ET AL: "Making Full Vehicle OTA Updates a Reality", 31 May 2016 (2016-05-31), XP055373147, Retrieved from the Internet <URL:http://www.nxp.com/assets/documents/data/en/white-papers/Making-Full-Vehicle-OTA-Updates-Reality-WP.pdf> [retrieved on 20170516] * |
| MANSOR HAFIZAH ET AL: "Don't Brick Your Car: Firmware Confidentiality and Rollback for Vehicles", 2015 10TH INTERNATIONAL CONFERENCE ON AVAILABILITY, RELIABILITY AND SECURITY, IEEE, 24 August 2015 (2015-08-24), pages 139 - 148, XP032795237, DOI: 10.1109/ARES.2015.58 * |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3099264B1 (fr) | 2021-07-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11455165B2 (en) | Hot updates to controller software using tool chain | |
| US10834207B2 (en) | System and method for updating software in an electronic device | |
| US10514900B2 (en) | Software updating apparatus and software updating method | |
| US10162625B2 (en) | Vehicle control storage methods and systems | |
| CN107102849B (zh) | 用于周期性点火开关断开的文件替换的方法和设备 | |
| FR3096153A1 (fr) | Procédé et dispositif de retour à un état précédent une mise à jour logicielle d’un calculateur d’un véhicule à distance | |
| US20220107929A1 (en) | System and Method Implementing a Distributed Audit Trail | |
| EP4004712A1 (fr) | Procédé et dispositif de mise à jour d'un logiciel d'un calculateur embarqué d'un véhicule, comportant une mémoire d'exécution, une mémoire de sauvegarde et une mémoire de contrôle | |
| CN113885929A (zh) | 高精度地图的远程升级方法 | |
| CN117407020A (zh) | Ota升级刷写方法、装置、电子设备及存储介质 | |
| FR3099264A1 (fr) | Procédé et dispositif de mise à jour d’un logiciel d’un calculateur embarqué d’un véhicule, comportant une mémoire d’exécution et une mémoire de sauvegarde | |
| FR3099265A1 (fr) | Procédé et dispositif de mise à jour d’un logiciel d’un calculateur embarqué d’un véhicule, comportant une mémoire d’exécution, une mémoire de sauvegarde et une mémoire de contrôle | |
| WO2022064118A1 (fr) | Procédé et dispositif de mise à jour d'un logiciel d'un calculateur embarqué d'un véhicule, comportant une mémoire d'exécution, une mémoire de sauvegarde et une mémoire de contrôle | |
| FR3114415A1 (fr) | Procédé et dispositif de mise à jour d’un logiciel d’un calculateur embarqué d’un véhicule, comportant une mémoire d’exécution et une mémoire de sauvegarde | |
| WO2021032915A1 (fr) | Procédé et dispositif de mise à jour d'un logiciel d'un calculateur embarqué d'un véhicule, comportant une mémoire d'exécution et une mémoire de sauvegarde | |
| EP4118548A1 (fr) | Procédé et dispositif de mise à jour d'un logiciel comportant des adresses physiques vers la mémoire d'un calculateur embarqué d'un véhicule | |
| EP4066103A1 (fr) | Procédé de mise à jour de système numérique | |
| EP3924831A1 (fr) | Procédé de mise à jour d'un calculateur automobile de façon à lui ajouter une fonctionnalité supplémentaire | |
| EP3991029A1 (fr) | Procédé de dialogue avec un calculateur sur bus embarqué de véhicule | |
| FR3100638A1 (fr) | Procédé et dispositif de mise à jour d’un calculateur cible à partir d’un script interprété | |
| CN112287348B (zh) | 一种车载模块的自刷新方法和系统 | |
| WO2021205655A1 (fr) | Système de commande embarqué et procédé de diagnostic d'anomalie | |
| FR2903791A1 (fr) | Procede de telechargement d'un module logiciel. | |
| WO2021023694A1 (fr) | Procédé d'écriture dans une zone de données sécurisée d'un calculateur sur bus embarqué de véhicule | |
| FR2928473A1 (fr) | Procede et disositif pour assurer une coherence entre des telechargements de differentes versions d'un logiciel. |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20210129 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |