FR3100638A1 - Procédé et dispositif de mise à jour d’un calculateur cible à partir d’un script interprété - Google Patents

Abstract

L’invention concerne un procédé de mise à jour d’un calculateur cible (211) par un calculateur de gestion de mise à jour (210) comportant une mémoire tampon (212) comportant des étapes de :- Réception (201) de données de mises à jour comportant un script,- Interprétation (202) du script reçu et génération de requêtes à partir du script reçu,- Stockage (203) des requêtes générées dans une mémoire,- Réception (204) d’une information de confirmation d’installation de la mise à jour,- Envoi (205) des requêtes stockées au calculateur cible. Figure pour l’abrégé : Figure 2

Description

Procédé et dispositif de mise à jour d’un calculateur cible à partir d’un script interprété

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).

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.

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 de ces calculateurs directement chez le client final, à l’image de ce qui existe déjà dans le domaine du consumérisme 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 à distance (ou OTA pour Over The Air) 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.

Le format d’échange aujourd’hui pressenti pour contenir ces données de mise à jour ainsi que les séquences à dérouler pour une installation à distance, est l’OTX (Open Test sequence data eXchange) connu de l’état de l’art. De plus, l’utilisation du format OTX permet de virtualiser la diversité liée à la gestion de procédures d’installation qui diffèrent selon que le calculateur dispose d’une mémoire externe simple ou double, ou interne pour la gestion du retour à un état précédent une mise à jour (ou rollback en anglais), et bien d’autres paramètres encore. En effet, cela permet d’une part au niveau du calculateur de gestion de mise à jour de dérouler la procédure par interprétation de l’OTX au lieu de l’exécuter via une fonction codée « en dur » dans ce calculateur, et d’autre part de disposer de la même souplesse de gestion de cette diversité au niveau des systèmes débarqués.

Le document US20180182184 divulgue un procédé pour la configuration d'un véhicule comprenant l'envoi, par un serveur distant à un véhicule, un paquet de données qui comprend une commande pour la configuration du véhicule, l'évaluation si une configuration du véhicule doit être effectuée, et le lancement de la configuration du véhicule. Ce procédé met en œuvre le format de donnée OTX.

L’utilisation de l’OTX présente toutefois un inconvénient lié au temps de traitement engendré par l’interprétation de ce format par le calculateur de gestion de mise à jour. Précisons qu’une mise à jour conduit à une immobilisation du véhicule du client pour des raisons de sécurité. Pour rendre cette immobilisation temporaire la plus acceptable possible par le client et en même temps minimiser la consommation électrique de la batterie, il convient d’en diminuer autant que possible la durée.

Dans certaines situations, le fait de dérouler la procédure d’installation par interprétation directe de l’OTX pour produire les requêtes d’installation est très pénalisant en terme de performance. Ceci rend la solution en l’état incompatible d’une durée d’installation acceptable.

Le document US20180113702 divulgue une méthode pour générer un fichier de reprogrammation pour reprogrammer une unité de commande électronique cible dans un véhicule cible. Des commandes de diagnostic de langage de haut niveau sont générées à l'aide d'un éditeur de script OTX. Il est prévu de convertir des commandes de séquence de diagnostic de langage de haut niveau en des instructions de langage impératives, qui sont compilées en code binaire correspondant aux routines de manipulation. Autrement dit, ce document propose de compiler, au niveau du serveur, le script OTX de façon à supprimer la phase d’interprétation du script au niveau du véhicule. Cette solution a pour avantage de réduire la durée d’installation, au niveau du véhicule, mais a pour inconvénient de perdre la souplesse liée à l’utilisation d’un script OTX interprété par le véhicule.

La présente invention a pour but de conserver le format OTX et la souplesse liée à son interprétation par véhicule tout en optimisant la durée d’installation d’une mise à jour dans un calculateur.

La présente invention a pour but de remédier aux problèmes précités en conservant le format OTX et la souplesse liée à son interprétation par véhicule tout en optimisant la durée d’installation d’une mise à jour dans un calculateur.

A cet effet l’invention a pour objet, un procédé de mise à jour d’un calculateur cible par un calculateur de gestion de mise à jour comportant une mémoire tampon comportant des étapes de :
- Réception de données de mises à jour comportant un script,
- Interprétation du script reçu et génération de requêtes à partir du script reçu,
- Stockage des requêtes générées dans une mémoire,
- Réception d’une information de confirmation d’installation de la mise à jour,
- Envoi des requêtes stockées au calculateur cible.

Avec l’invention, l’utilisation d’un script permet de conserver une souplesse d’utilisation lié notamment à la virtualisation de la diversité liée à la gestion de procédures d’installation qui diffèrent selon que le calculateur dispose d’une mémoire externe simple ou double, ou interne pour la gestion de son rollback.

L’invention permet aussi de réduire sensiblement la durée d’indisponibilité d’un véhicule liée à une mise à jour à distance. En effet, les étapes de téléchargement, d’interprétation du script et de stockage des requêtes en mémoire tampon, ne nécessitent pas de solliciter le calculateur cible qui reste donc disponible et fonctionnel durant l’exécution de ces étapes. Seule l’étape d’envoi des requêtes sollicite le calculateur cible.

Avantageusement, la mémoire tampon est une mémoire non-volatile.

Avantageusement, le procédé de mise à jour d’un calculateur cible selon l’invention, comporte en outre une étape d’exécution, par le calculateur cible, des requêtes reçues.

Avantageusement, le procédé de mise à jour d’un calculateur cible selon l’invention, comporte en outre une étape une deuxième étape d’interprétation du script consécutivement à l’envoi des requêtes.

Cette caractéristique permet de réserver la première interprétation du script à la génération des requêtes impactant le plus le temps de traitement de la mise à jour. La deuxième étape est alors réalisée pour générer les requêtes non générer lors de la première interprétation.

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 calculateur de gestion de mise à jour comportant un microcontrôleur et une mémoire de stockage, caractérisé en ce que la mémoire de stockage comporte une mémoire tampon et en ce qu’il est configuré pour exécuter étapes du procédé selon l’invention.

L’invention concerne aussi un véhicule caractérisé en ce qu’il comporte un calculateur de gestion de mise à jour selon 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 le procédé de mise à jour selon l’invention ;

illustre schématiquement un diagramme montrant l’ordre et la durée d’exécution des étapes d’un procédé de mise à jour selon l’art connu.

illustre schématiquement un diagramme montrant l’ordre et la durée d’exécution des étapes d’un procédé de mise à jour selon l’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.

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 d’avoir un mécanisme de mise à jour robuste et rapide.

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.

La figure 2 schématise le procédé d’installation, dans un calculateur cible 211 (aussi appelé « Target ECU ») d’une mise à jour préalablement reçue par le par un calculateur gestionnaire de mise à jour 210 (aussi appelé « FOTA master »).

Le calculateur cible 211 et le calculateur gestionnaire de mise à jour 210 comporte chacun un microcontrôleur et une mémoire de stockage.

Selon une caractéristique de l’invention la mémoire tampon 212 est une mémoire non-volatile par exemple de type Flash afin de pouvoir conserver les requêtes pendant que le véhicule est arrêté (FOTA master non alimenté électriquement) et éventuellement reprendre l’opération là où elle a été interrompue. Le client peut en effet à tout moment décider de couper le contact durant l’étape d’interprétation du script et de génération des requêtes.

Le procédé comporte une étape de réception 201, par le gestionnaire de mise à jour 210 de données de mise à jour provenant du serveur distant 102. Les données de mise à jour comportent un script qui lorsqu’il est interprété 202 permet de produire les requêtes qui seront stockées 203 en mémoire non volatile 212 afin de conserver en mémoire les requêtes générées dans le cas où le véhicule est arrêté et le calculateur gestionnaire de mise à jour 210 n’est plus alimenté électriquement.

L’installation est précédée d’une étape préalable de transfert des données de la mise à jour depuis le serveur distant 102, pendant le roulage du véhicule. Ceci présente de fait l’avantage de ne pas immobiliser le véhicule ni de consommer la batterie celle-ci étant alors rechargée.

Avantageusement, le script est au format OTX.

Le procédé selon l’invention comporte aussi une étape d’interprétation 202 du script reçu et génération de requêtes à partir du script reçu.

Selon une caractéristique de l’invention, l’interprétation du script génère des requêtes répondant, par exemple, au format du protocole UDS (Unified Diagnostic Services) connu de l’état de l’art et permettant de dérouler la procédure d’installation et de transporter les données à programmer dans la mémoire du calculateur cible 211.

Le procédé selon l’invention comporte aussi une étape de stockage 203 des requêtes générées dans la mémoire tampon 212 du calculateur gestionnaire de mise à jour 210.

La production et l’envoi des requêtes vers la mémoire tampon 212 ont lieu au fur et à mesure de l’interprétation du script. Autrement dit, le calculateur gestionnaire de mise à jour 210 interprète le script et produit les requêtes, et celles-ci sont envoyées à la mémoire tampon 212, au fur et à mesure de cette interprétation, les requêtes sont stockées dans une mémoire tampon 212 jusqu’à ce que l’interprétation du script prenne fin.

Avantageusement, à l’issue de cette étape le procédé comporte en outre une étape d’émission d’une demande de confirmation de l’installation destinée à être proposée à un utilisateur.

Le procédé comporte aussi une étape de réception 204 d’une information de confirmation d’installation de la mise à jour. Cette confirmation provient par exemple du client qui a été préalablement sollicité. Mais la confirmation peut aussi provenir d’un système de détection automatique identifiant automatiquement les conditions permettant d’installer le calculateur (arrêt du véhicule, …).

En réponse à la réception de cette validation, le procédé comporte l’envoi 205 des requêtes au calculateur cible 211.

L’opération d’installation ne consiste plus qu’à lire la mémoire tampon 212 et à envoyer les requêtes (qui sont déjà dans un format optimisé) vers le calculateur cible 211. Il n’y a alors plus d’interprétation du script pour produire les requêtes transportant les données à faire pendant l’installation ce qui en réduit significativement la durée.

Selon une caractéristique de l’invention, en interne du calculateur de mise à jour 210, les requêtes sont d’abord transmises, depuis la mémoire tampon 212, à un module logiciel pilote 213 (ou driver) dit DoCAN ou DoIP selon que la technologie de communication entre le calculateur gestionnaire de mise à jour 210 et le calculateur cible 211 est CAN ou Ethernet. Le pilote logiciel 213 formate les requêtes selon un processus d’encapsulation inspiré du modèle en couche OSI connu de l’état de la technique afin de produire des trames au format du protocole physique CAN ou Ethernet. Ces trames transportent donc les requêtes UDS avec les données à programmer à destination du calculateur cible 211.

Le calculateur cible 211 exécute les requêtes, extrait les données et les programme dans la mémoire Flash de son microcontrôleur (µC).

A noter que la phase de transfert des données est, parmi les étapes qui constituent une mise à jour, la seule opération qui fait usage de la mémoire tampon 212. De façon avantageuse, une balise spécifique insérée dans le script OTX permet de délimiter cette opération et d’indiquer à l’interpréteur OTX lors de l’installation qu’il faut « passer la main » à la mémoire de stockage tampon 212 pour récupérer les données à installer dans le calculateur cible 211 qui auront été pré-calculées. L’interprétation du script a donc lieu une première fois pour générer par pré-calcul les requêtes à envoyer, puis avantageusement une seconde fois, pendant la phase d’installation pour dérouler les autres opérations formant la procédure d’installation mais qui n’impactent pas le temps de mise à jour et peuvent être réalisées pendant la phase d’installation.

Ainsi parmi les opérations n’impactant pas le temps d’installation, l’on peut citer :

• La lecture des données d’identification du calculateur cible
• La commande d’effacement de la mémoire flash du calculateur cible et la commande de supervision de l’opération.
• La commande de déverrouillage de l’accès en écriture à la mémoire de ce calculateur.

De manière globale, il s’agit de requêtes ponctuelles ou bien dont la périodicité est telle que le temps d’interprétation pourra être largement masqué par le temps entre 2 requêtes.

La deuxième étape d’interprétation du script n’est pas obligatoire car il est possible de produire les requêtes dès la première interprétation pour toutes les opérations et pas seulement pour celles qui sont coûteuses en temps. Il n’y a dans ce cas plus de deuxième interprétation de script.

Les figures 3 et 4 illustrent schématiquement un diagramme montrant l’ordre et la durée d’exécution des étapes d’un procédé de mise à jour respectivement selon l’art connu et selon l’invention. Ces diagrammes montrent comment la présente invention, en anticipant l’interprétation du script pour générer les requêtes, permet de considérablement réduire la durée d’installation, donc d’indisponibilité du calculateur cible et donc au final d’immobilisation du véhicule.

Sur les figures 3 et 4, les rectangles hachurés représente l’interprétation du script et les rectangles blancs l’envoi des requêtes générées.

Sur la figure 3, les requêtes sont envoyées au fur et à mesure de l’exécution du script et de leur génération. Autrement dit, l’interprétation est entrecoupée d’envoi de requête car une requête est envoyée dès qu’elle est générée. La durée d’indisponibilité D1 du calculateur cible démarre dès le début 31 de l’exécution du script et dure jusqu’à la fin de son interprétation. La durée d’indisponibilité D1 correspond à la durée d’interprétation du script cumulée à la durée d’envoi des requêtes.

Sur la figure 4, le script est d’abord interprété du début à la fin et les requêtes générées sont stockées. A l’issue de l’interprétation, les requêtes sont envoyées au calculateur cible. La durée d’indisponibilité D2 du calculateur cible démarre seulement au début 41 de l’envoi des requêtes. La durée d’indisponibilité D2 correspond à la durée d’envoi des requêtes.

Claims (7)

1. Procédé de mise à jour d’un calculateur cible (211) par un calculateur de gestion de mise à jour (210) comportant une mémoire tampon (212) comportant des étapes de :
   - Réception (201) de données de mises à jour comportant un script,
   - Interprétation (202) du script reçu et génération de requêtes à partir du script reçu,
   - Stockage (203) des requêtes générées dans une mémoire,
   - Réception (204) d’une information de confirmation d’installation de la mise à jour,
   - Envoi (205) des requêtes stockées au calculateur cible.
2. Procédé de mise à jour d’un calculateur cible selon l’une des revendications précédentes, dans lequel la mémoire tampon (212) est une mémoire non-volatile.
3. Procédé de mise à jour d’un calculateur cible selon l’une des revendications précédentes, comportant en outre une étape d’exécution, par le calculateur cible, des requêtes reçues.
4. Procédé de mise à jour d’un calculateur cible selon l’une des revendications précédentes, comportant en outre une deuxième étape d’interprétation du script consécutivement à l’envoi des requêtes.
5. Produit programme d’ordinateur comportant des instructions adaptées pour l’exécution des étapes du procédé selon l’une des revendications 1 à 4, lorsque le programme d’ordinateur est exécuté par au moins un processeur.
6. Calculateur de gestion de mise à jour (210) comportant un microcontrôleur et une mémoire de stockage, caractérisé en ce que la mémoire de stockage comporte une mémoire tampon (212) et en ce qu’il est configuré pour exécuter étapes du procédé selon l’une des revendications 1 à 4.
7. Véhicule caractérisé en ce qu’il comporte un calculateur de gestion de mise à jour (210) selon la revendication précédente.