EP3924831A1 - Procédé de mise à jour d'un calculateur automobile de façon à lui ajouter une fonctionnalité supplémentaire - Google Patents

Procédé de mise à jour d'un calculateur automobile de façon à lui ajouter une fonctionnalité supplémentaire

Info

Publication number
EP3924831A1
EP3924831A1 EP20705441.2A EP20705441A EP3924831A1 EP 3924831 A1 EP3924831 A1 EP 3924831A1 EP 20705441 A EP20705441 A EP 20705441A EP 3924831 A1 EP3924831 A1 EP 3924831A1
Authority
EP
European Patent Office
Prior art keywords
module
boot
new
computer
updating
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.)
Withdrawn
Application number
EP20705441.2A
Other languages
German (de)
English (en)
Inventor
Thierry Lopez
Francois Rochette
Pierre SCHMIDT
Emmanuel GEORGES
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
PSA Automobiles SA
Original Assignee
PSA Automobiles SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by PSA Automobiles SA filed Critical PSA Automobiles SA
Publication of EP3924831A1 publication Critical patent/EP3924831A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
    • G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/658—Incremental updates; Differential updates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/0284—Multiple user address space allocation, e.g. using different base addresses
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1408—Protection against unauthorised use of memory or access to memory by using cryptography
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72—Details relating to flash memory management
    • G06F2212/7201—Logical to physical mapping or translation of blocks or pages

Definitions

  • TITLE Method for updating an automotive computer so as to add additional functionality to it
  • the invention relates to a method and a system for downloading at least one file into one or more computers.
  • the downloading operation is carried out by means of an off-board tool which is connected to the vehicle's diagnostic socket and makes it possible to program in the memory of the computer (s), software which ensures correct operation of the vehicle produced, taking into account the characteristics (engine , options) specific to this vehicle.
  • the first type of computer (OSEK / AUTOSAR) is less expensive, suitable for supporting automotive safety-type constraints (for example: reduced reset time, memory execution speed), but does not offer the flexibility to accommodate new functionalities during the serial life of the software. It is, for example, not possible to accommodate a new module not planned at the origin of the project.
  • the second type of calculator (LINUX / WINDOWS) is similar to what we can find on a PC. It is particularly suited to the execution of complex graphical UI and offers the flexibility of integrating various applications (entertainment or responsible driving by indicating for example the consumption of the vehicle) but at an incompatible cost of a generalization to the l 'all the computers of a car and especially unsuited to taking into account all the constraints of the automobile (in particular road safety).
  • the objective of the invention is to provide a method and system making it possible to provide the flexibility of upgrading the second type of computer to computers of the first type (OSEK / AUTOSAR) without degrading their ability to take into account the constraints. essential relating to road safety, taking into account the economic constraints of the automotive world.
  • the aim of the invention is therefore to provide a means complementary to a change in vehicle architecture (modification of the technology of the internal communication networks) making it possible to reduce the time for updating the software of a computer of the first type. (for example OSEK / AUTOSAR) by reprogramming only part of the software.
  • the start-up procedure comprises a part comprising a software structure
  • said method comprises steps of:
  • the invention makes it possible to add a new functionality developed in the form of a software module to an OSEK / AUTOSAR type computer without requiring a complete reprogramming of the computer software.
  • the invention therefore also makes it possible to significantly reduce the computer download time, whether it be:
  • the software structure includes a start address and an end address of the first application module.
  • the new software structure also includes a start address and an end address of the new module.
  • the new module in response to the detection of the data relating to the new module, it further comprises a step of verifying a signature associated with said new module and in the absence of said signature, it comprises downloading said new module. module and the associated signature.
  • the step of reprogramming the first application module includes an update of the signature associated with said first module.
  • the step of adding the new module comprises steps of:
  • the first part of the boot and the second part of the boot belong to two distinct memory segments.
  • the invention also relates to a computer program comprising instructions for implementing the method of updating an automobile computer according to the invention, when it is executed on one or more processors.
  • the invention also relates to a device for assisting a driver of a vehicle, comprising at least a processor and a memory characterized in that it is configured to implement the updating method according to the invention.
  • the invention also relates to a vehicle characterized in that it comprises a device according to the invention.
  • FIG 1 shows the simplified structure of a computer memory according to the state of the art
  • FIG 2a shows the simplified structure of a memory of a computer according to the invention, before an update.
  • FIG 2b shows the simplified structure of a memory of a computer according to the invention, after an update of the second part of the boot.
  • FIG 2c shows the simplified structure of a memory of a computer according to the invention, after reprogramming of the module using a new functionality.
  • FIG 2d shows the simplified structure of a memory of a computer according to the invention, after the addition of a module containing a new functionality.
  • FIG 3 shows a flowchart representing an updating method adapted to the architecture according to the invention.
  • the invention applies to computers making it possible to develop computers multifunction: engine (CMM), automatic gearbox (BVA), core architecture (BSI, VSM).
  • CCM engine
  • BVA automatic gearbox
  • BSI core architecture
  • VSM VSM
  • the software code is executed directly from a flash eprom component.
  • all links to memory are made when compiling the software.
  • static links are, for example, computers based on a software architecture of the OSEK / AUTOSAR type.
  • Such a computer when programmable, generally consists of a flash eprom component divided into several segments:
  • a first segment called software boot is the one which allows the computer when it is powered on to initialize its registers and to check that it has valid content before switching to its application software (the one which ensures the service requested).
  • the program pointer In the event that this application software is not valid (software not yet downloaded or partially downloaded), the program pointer must remain in the boot zone pending execution of the update procedure for the missing software.
  • the computer update procedure must therefore be an integral part of this boot;
  • One or more other segments depending on whether the computer application software can be downloaded monolithically or by part. For example, a part dedicated to calibration can be downloaded independently from the download of the application software.
  • FIG. 1 represents the simplified memory structure of the flash eprom of a computer 10 of the OSEK / AUTOSAR type comprising a boot zone 11 containing the procedure for updating the application software (also called an application), a zone for the application software and a calibration part 13 downloadable independently of one another.
  • the boot zone 11 contains the procedure for updating the application software and the calibration zone.
  • This boot software itself not being downloadable.
  • Values of Hash HS1 and Hash HC1 respectively represent the values of computer signatures calculated by means for example of an algorithm of the SH1, MD5 or other type on the areas of the application software and of the calibration in order to check their integrity at the time of the update.
  • the integrity check consists of providing the computer with the value of the signature (e.g. Hash HS1 as a reference) and asking it to perform the calculation on the content of the code received and recorded in memory (e.g. application software ) using the same algorithm as that used to establish the reference value. By comparing the result obtained by the calculation with the reference value (Hash HS1 in our example), the computer is able to determine whether the updated software is valid or not.
  • the value of the signature e.g. Hash HS1 as a reference
  • memory e.g. application software
  • Figure 2a shows an example of a computer architecture according to the invention.
  • the application software is divided into several logic modules.
  • the reachable number of modules depends on the size of the eprom flash memory.
  • a microcontroller (pc) of an engine control computer for example, has 10 MB to 16 MB of eprom flash memory on board.
  • Each module has a computer signature (Hash HMx) to ensure memory integrity when programming a module.
  • the computer boot software according to the invention comprises two parts:
  • the first part of the boot (BOOT_1) includes the computer update procedure and is delivered with the computer, it cannot be reprogrammed using tools that can be used in the factory when the computer is commissioned or afterwards -sale in the case of a software evolution.
  • the second part of the boot includes the structure of the functional software (the start and end addresses of each individually programmable module), the updating of which will be made possible by the client tools.
  • the second part of the boot includes a start address (M1V1) and a end address (M1V2) of Module 1 and a start address (M2V1) and end address (M2V2) of Module 2
  • the first part of the boot BOOT_1 and the second part of the boot BOOT_2 belong to two distinct segments of the flash eprom memory. This ensures the security and robustness of the process, in particular by securing BOOT 1.
  • FIG. 3 shows a flowchart representing an updating method adapted to the architecture according to the invention described above.
  • This updating method comprises a step of updating the second part of the boot BOOT_2 with a new software structure.
  • This first step includes the reprogramming of the second part of the BOOT_2 boot by adding the start and end addresses of the new module (the one that contains the functionality to be added).
  • FIG. 2b represents the simplified structure of a memory of a computer according to the invention, after an update of the second part of the boot.
  • the second part of the boot now includes, in addition to the previous addresses, a start address (M3V1) and an end address (M3V2) of Module 3.
  • the updating method according to the invention further comprises a step of reinitializing the computer 200.
  • the computer 200 detects that a new module 3 exists in its software structure and that it is not downloaded because the corresponding Hash HM3 value has not been transmitted to it (it is not entered in Memory).
  • the computer is configured to consider that the application software is not in a functional state and to remain in the first of the boot BOOT_1 which then executes the software update procedure.
  • the update method according to the invention further comprises a step of reprogramming the module using the new functionality.
  • FIG. 2c represents the simplified structure of a memory of a computer according to the invention, after reprogramming of the module using the new functionality.
  • module 2 that calls (in other words has a link static 250 to a memory segment) to the new functionality (whose code is in module 3).
  • this module 2 it will be necessary to reprogram this module 2 by including the call function (s) to module 3 and by writing the Hash value HM2.1 because this value has changed.
  • the update method according to the invention further comprises a step of adding a module containing the new functionality.
  • FIG. 2d represents the simplified structure of a memory of a computer according to the invention, after the addition of the module containing the new functionality. This is the new module described in the second part of the BOOT_2 boot.
  • the update method according to the invention further comprises a step of reinitializing (Reset) the computer 200.
  • the computer checks that all the modules necessary for the correct functioning of the controlled device are correctly programmed (according to the description expected in the BOOT_2 module).
  • module 2 is reprogrammed than module 2 and only module 3 is added to have a new expected functionality rather than reprogramming the entire computer, which corresponds well to reduced programming time compared to the initial situation.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention a pour objet un procédé de mise à jour d'un calculateur (200) automobile de façon à lui ajouter une fonctionnalité supplémentaire, ledit calculateur (200) comportant une mémoire de démarrage comprenant une procédure de démarrage et une mémoire applicative stockant au moins un premier module applicatif (Module2), ledit premier module applicatif (Module2) comportant des liens statiques vers ladite mémoire applicative, ledit procédé comporte des étapes de : Mise à jour de la structure logicielle avec une nouvelle structure logicielle (BOOT_2'), Réinitialisation dudit calculateur (200) et détection dans la nouvelle structure logicielle (BOOT_2') d'une donnée relative à un nouveau module applicatif (Module3), Reprogrammation du premier module applicatif (Module2) faisant appel à la fonctionnalité supplémentaire, Ajout, dans la mémoire applicative, du nouveau module applicatif (Module3) comportant la fonctionnalité supplémentaire, Réinitialisation dudit calculateur (200).

Description

DESCRIPTION
TITRE : Procédé de mise à jour d'un calculateur automobile de façon à lui ajouter une fonctionnalité supplémentaire
L'invention concerne un procédé et un système de téléchargement d'au moins un fichier dans un ou plusieurs calculateurs.
Dans la suite de cette description, lorsque le fichier à télécharger contient des instructions ou le code exécutable d'un logiciel, on parle é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 de téléchargement 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, un logiciel qui assure un fonctionnement conforme du véhicule produit en prenant en compte les caractéristiques (motorisation, options) propres à ce véhicule.
On rappelle que dans l’industrie automobile, principalement deux types de calculateurs sont utilisés :
- Les premiers permettent de développer les calculateurs multifonctions : moteur (CMM), de boite de vitesses automatique (BVA), de cœur d’architecture (BSI, VSM). Sur ces calculateurs, le code logiciel est exécuté directement depuis un composant flash eprom. De plus, tous les liens vers la mémoire sont réalisés lors de la compilation du logiciel. On parle ici de liens statiques. Il s’agit par exemple des calculateurs reposant sur une architecture logicielle de type OSEK / AUTOSAR.
- Les seconds, sont notamment intégrés dans des automobiles qui disposent de larges écrans d’affichage (NAC, RCC, ...) et de connectivité (BTA / BSRF). Ces calculateurs reposent sur des technologies très différentes, issues de l’électronique grand public et disposent en particulier de plateformes logicielles de type Linux ou Windows. Ces dernières permettent notamment l’accueil d’application « autonomes » développées par ailleurs. Sur ces plateformes, les liens mémoires sont établis en dynamique, et une application est d’abord chargée dans la RAM du calculateur avant son exécution.
Le premier type de calculateur (OSEK / AUTOSAR) est moins cher, adapté au support des contraintes de type sécurité automobile (par exemple : temps de reset réduit, vitesse d’exécution mémoire), mais n’offre pas la souplesse d’accueil de nouvelles fonctionnalités pendant la vie série du logiciel. Il n’est, par exemple, pas possible d’accueillir un nouveau module non prévu à l’origine du projet.
Le second type de calculateur (LINUX / WINDOWS) s’apparente à ce que nous pouvons retrouver sur un PC. Il est particulièrement adapté à l’exécution d’IHM graphique complexe et offre la souplesse d’intégration d’applications diverses (divertissement ou conduite responsable en indiquant par exemple les consommations du véhicule) mais à un coût non compatible d’une généralisation à l’ensemble des calculateurs d’une automobile et surtout inadapté à la prise en compte de l’ensemble des contraintes automobiles (en particulier la sécurité routière).
L’objectif de l’invention est de proposer un procédé et système permettant d’apporter la souplesse d’évolution du second type de calculateur sur les calculateurs du premier type (OSEK / AUTOSAR) sans dégradation sur leur capacité à prendre en compte les contraintes essentielles se rapportant à la sécurité routière en tenant compte des contraintes économiques du monde automobile.
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 FR2719924. Ce document détaille différentes étapes successives d’une 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, l'accueil de nouvelles fonctionnalités embarquées poussent à des tailles mémoires embarquées et des besoins en temps de téléchargement de ces mémoires de plus en plus grands.
Le but de l'invention est donc d’apporter un moyen complémentaire à un changement d’architecture véhicule (modification de la technologie des réseaux de communication internes) permettant de réduire le temps de mise à jour du logiciel d’un calculateur du premier type (par exemple OSEK / AUTOSAR) en ne reprogrammant qu’une partie du logiciel.
Elle propose plus précisément à cet effet un procédé de mise à jour d’un calculateur automobile de façon à lui ajouter une fonctionnalité supplémentaire, ledit calculateur comportant une mémoire de démarrage comprenant une procédure de démarrage et une mémoire applicative stockant au moins un premier module applicatif (Module2), ledit premier module applicatif comportant des liens statiques vers ladite mémoire applicative,
Caractérisé en ce que, la procédure de démarrage comprend une partie comprenant une structure logicielle, ledit procédé comporte des étapes de :
- Mise à jour de la structure logicielle, avec une nouvelle structure logicielle,
- Réinitialisation dudit calculateur et détection dans la nouvelle structure logicielle d’une donnée relative à un nouveau module applicatif,
- Reprogrammation du premier module applicatif faisant appel à la fonctionnalité supplémentaire,
- Ajout, dans la mémoire applicative, du nouveau module applicatif comportant la fonctionnalité supplémentaire,
- Réinitialisation dudit calculateur.
L’invention permet d’ajouter une nouvelle fonctionnalité développée sous la forme d’un module logiciel à un calculateur de type OSEK / AUTOSAR sans nécessiter une reprogrammation complète du logiciel du calculateur.
L’invention permet aussi par conséquent de réduire significativement le temps de téléchargement du calculateur que ce soit :
- en usine (dans le cas d’une retouche ou d’une modernisation),
- en après-vente dans le cas d’une correction de prestation ou d’ajout d’un nouveau service (vente d’une nouvelle fonction compatible d’un véhicule mais non prévue à l’origine),
- chez le client final dans le cadre du développement du téléchargement OTA (Over The Air) en diminuant par la même occasion les coûts de télécommunication.
Avantageusement, la structure logiciel comporte une adresse de début et une adresse de fin du premier module applicatif. La nouvelle structure logicielle comporte, en outre, une adresse de début et une adresse de fin du nouveau module.
Avantageusement, en réponse à la détection de la donnée relative au nouveau module, il comprend en outre une étape de vérification d’une signature associée audit nouveau module et en l’absence de ladite signature, il comprend le téléchargement dudit nouveau module et de la signature associée.
Avantageusement, l’étape de reprogrammation du premier module applicatif comporte une mise à jour de la signature associée audit premier module.
Avantageusement, l’étape d’ajout du nouveau module comporte des étapes de :
- écriture d’une signature associée audit nouveau module,
- programmation du contenu dudit nouveau module,
- validation dudit nouveau module en comparant une signature déterminée à partir dudit nouveau module signature associée audit nouveau module (Module 3).
Avantageusement, la première partie du boot et la deuxième partie du boot appartiennent à deux segments de mémoire distincts.
L’invention concerne aussi un programme d’ordinateur comportant des instructions pour mettre en œuvre le procédé de mise à jour d’un calculateur automobile selon l’invention, lorsqu’il est exécuté sur un ou plusieurs processeurs.
L’invention concerne aussi un dispositif d’assistance d’un conducteur d’un véhicule, comportant au moins un processeur et une mémoire caractérisé en ce qu’il est configuré pour mettre en œuvre le procédé de mise à jour selon l’invention.
L’invention concerne aussi un véhicule caractérisé en ce qu’il comporte un dispositif selon l’invention.
[Fig 1] représente la structure simplifiée d’une mémoire d’un calculateur selon l’état de la technique
[Fig 2a] représente la structure simplifiée d’une mémoire d’un calculateur selon l’invention, avant une mise jour.
[Fig 2b] représente la structure simplifiée d’une mémoire d’un calculateur selon l’invention, après une mise jour de la deuxième partie du boot.
[Fig 2c] représente la structure simplifiée d’une mémoire d’un calculateur selon l’invention, après une reprogrammation du module faisant appel à une nouvelle fonctionnalité.
[Fig 2d] représente la structure simplifiée d’une mémoire d’un calculateur selon l’invention, après l’ajout d’un module contenant une nouvelle fonctionnalité.
[Fig 3] montre un logigramme représentant un procédé de mise à jour adapté à l’architecture selon l’invention.
L’invention s’applique à des calculateurs permettant de développer les calculateurs multifonctions : moteur (CMM), de boite de vitesses automatique (BVA), de cœur d’architecture (BSI, VSM). Sur ces calculateurs, le code logiciel est exécuté directement depuis un composant flash eprom. De plus, tous les liens vers la mémoire sont réalisés lors de la compilation du logiciel. On parle ici de liens statiques. Il s’agit par exemple des calculateurs reposant sur une architecture logicielle de type OSEK / AUTOSAR.
Un tel calculateur lorsqu’il est programmable est généralement constitué d’un composant flash eprom divisé en plusieurs segments :
- Une premier segment appelé boot logiciel est celui qui permet au calculateur lors de sa mise sous tension d’initialiser ses registres et de vérifier qu’il dispose d’un contenu valide avant de basculer vers son logiciel applicatif (celui qui permet d’assurer la prestation demandée). Dans le cas où ce logiciel applicatif n’est pas valide (logiciel non encore téléchargé ou partiellement téléchargé), le pointeur programme doit rester dans la zone de boot en attente d’exécution de la procédure de mise à jour du logiciel manquant. La procédure de mise à jour du calculateur doit donc faire partie intégrante de ce boot ;
- Un ou plusieurs autres segments selon que le logiciel applicatif du calculateur puisse être téléchargé de manière monolithique ou par partie. On peut par exemple télécharger une partie dédiée à la calibration de manière indépendante au téléchargement du logiciel applicatif.
La figure 1 représente la structure mémoire simplifiée de la flash eprom d’un calculateur 10 de type OSEK / AUTOSAR comportant une zone de boot 1 1 contenant la procédure de mise à jour du logiciel applicatif (aussi appelé application), une zone de pour le logiciel applicatif et d’une partie calibration 13 téléchargeables indépendamment l’une de l’autre. La zone de boot 1 1 contient la procédure de mise à jour du logiciel applicatif et de la zone de calibration. Ce logiciel de boot, n’étant pas lui-même téléchargeable. Des valeurs de Hash HS1 et Hash HC1 représentent respectivement les valeurs de signatures informatiques calculées au moyen par exemple d’un algorithme de type SH1 , MD5 ou autre sur les zones du logiciel applicatif et de la calibration afin de vérifier leur intégrité au moment de la mise à jour.
On rappelle que le contrôle d’intégrité consiste à fournir au calculateur la valeur de la signature (ex : Hash HS1 en référence) et de lui demander d’effectuer le calcul sur le contenu du code reçu et inscrit en mémoire (ex : logiciel applicatif) en utilisant le même algorithme que celui ayant servi à établir la valeur de référence. En comparant le résultat obtenu par le calcul avec la valeur de référence (Hash HS1 dans notre exemple), le calculateur est en mesure de déterminer si le logiciel mis à jour est valide ou non.
Sur la base de cette structure logicielle, pour que la calibration ou le logiciel applicatif puisse être téléchargé indépendamment de l’autre, il convient d’avoir placé ces deux modules dans deux segments flash eprom différents. Pour pouvoir modifier le logiciel applicatif et ajouter par exemple une nouvelle fonction, il faudra développer un nouveau logiciel compris entre l’espace mémoire réservé à cet effet (défini au début du projet) et reprogrammer au minimum la totalité de la zone logiciel applicatif. En réalité, il conviendra de reprogrammer la totalité du logiciel et de la calibration étant admis qu’il semble difficile d’ajouter de nouvelles fonctions sans une part de calibration associée.
Dans ce schéma, l’ajout d’une nouvelle fonctionnalité à un logiciel en vie série du produit (correction ou ajout d’une prestation) oblige sur un calculateur OSEK / AUTOSAR à reprogrammer la totalité de la mémoire dédiée au fonctionnement de l’organe (logiciel applicatif et calibration).
La figure 2a montre un exemple d’une architecture de calculateur selon l’invention. Dans cette architecture, le logiciel applicatif est découpé en plusieurs module logiques. Le nombre atteignable de modules dépend de la taille de la mémoire flash eprom. A titre d’exemple, un microcontrôleur (pC) d’un calculateur de contrôle moteur embarque par exemple 10 Mo à 16 Mo de mémoire flash eprom.
Dès lors, il est possible de découper le logiciel applicatif en une pluralité de modules disposés dans des segments ou page de la mémoire flash eprom différents afin de permettre leur programmation de manière indépendante. Chaque module disposant d’une signature informatique (Hash HMx) permettant d’assurer de l’intégrité mémoire lors de la programmation d’un module.
En outre, le logiciel de boot du calculateur selon l’invention comprend deux partie :
- La première partie du boot (BOOT_1 ) comprend la procédure de mise à jour du calculateur et est livrée avec le calculateur, elle n’est pas reprogrammable au moyen d’outils utilisables en usine lors de la mise en service du calculateur ou en après-vente dans le cas d’une évolution logicielle.
- La deuxième partie du boot (BOOT_2) comprend la structure du logiciel fonctionnel (les adresses de début et de fin de chaque module programmable individuellement) et dont la mise à jour sera rendue possible par les outils client. Dans l’exemple de la figure 2a, la deuxième partie du boot (BOOT_2) comporte une adresse de début (M1V1 ) et une adresse de fin (M1V2) du Module 1 et une adresse de début (M2V1 ) et une adresse de fin (M2V2) du Module 2
De façon avantageuse, la première partie du boot BOOT_1 et la deuxième partie du boot BOOT_2 appartiennent à deux segments de la mémoire flash eprom distincts. Ceci permet d’assurer la sécurité et la robustesse du processus en particulier en sécurisant BOOT 1 .
La figure 3 montre un logigramme représentant un procédé de mise à jour adapté à l’architecture selon l’invention décrite ci-avant.
Ce procédé de mise à jour selon l’invention comporte une étape de mise à jour de la deuxième partie du boot BOOT_2 avec une nouvelle structure logicielle.
Cette première étape comprend la reprogrammation de la deuxième partie du boot BOOT_2 en ajoutant les adresses de début et de fin du nouveau module (celui qui contient la fonctionnalité à ajouter).
La figure 2b représente la structure simplifiée d’une mémoire d’un calculateur selon l’invention, après une mise jour de la deuxième partie du boot.
Dans l’exemple de la figure 2b, la deuxième partie du boot (BOOT_2) comporte à présent, outre les adresses précédentes, une adresse de début (M3V1 ) et une adresse de fin (M3V2) du Module 3.
Le procédé de mise à jour selon l’invention comporte en outre une étape de réinitialisation du calculateur 200.
Lors de la réinitialisation, le calculateur 200 détecte qu’un nouveau module 3 existe dans sa structure logicielle et qu’il n’est pas téléchargé car la valeur de Hash HM3 correspondant ne lui a pas été transmise (elle n’est pas inscrite dans la mémoire). Le calculateur est configuré pour considérer que le logiciel applicatif n’est pas dans un état fonctionnel et rester dans la première du boot BOOT_1 qui exécute alors la procédure de mise à jour du logiciel.
Le procédé de mise à jour selon l’invention comporte en outre une étape de reprogrammation du module faisant appel à la nouvelle fonctionnalité.
La figure 2c représente la structure simplifiée d’une mémoire d’un calculateur selon l’invention, après la reprogrammation du module faisant appel à la nouvelle fonctionnalité.
Supposons que ce soit le module 2 qui fasse appel (autrement dit comporte un lien statique 250 vers un segment de mémoire) à la nouvelle fonctionnalité (dont le code est dans le module 3). Dans ce cas, il conviendra de reprogrammer ce module 2 en incluant la (les) fonction(s) d’appel vers le module 3 et en écrivant la valeur Hash HM2.1 car cette valeur a évolué.
Le procédé de mise à jour selon l’invention comporte en outre une étape d’ajout d’un module contenant la nouvelle fonctionnalité.
La figure 2d représente la structure simplifiée d’une mémoire d’un calculateur selon l’invention, après l’ajout du module contenant la nouvelle fonctionnalité. Il s’agit du nouveau module décrit dans la deuxième partie du boot BOOT_2.
Pour ajouter le module 3 contenant la nouvelle fonctionnalité, on commencera par écrire la valeur de Hash HM3 du module puis par programmer le contenu de ce module. Pour déclarer ce module valide, le calculateur comparera l’intégrité logicielle du contenu programmer avec la valeur de HM3.
Le procédé de mise à jour selon l’invention comporte en outre une étape de réinitialisation (Reset) du calculateur 200.
Lors de la réinitialisation (aussi appelé reset), le calculateur vérifie que l’ensemble des modules nécessaires au bon fonctionnement de l’organe piloté sont bien programmé (en fonction de la description attendue dans le module BOOT_2).
Avec ce procédé, et en reprenant l’exemple, seul le module 2 est reprogrammé que le module 2 et seul le module 3 est ajouté pour disposer d’une nouvelle fonctionnalité attendue plutôt que de reprogrammer la totalité du calculateur, ce qui correspond bien à un temps réduit de programmation par rapport à la situation initiale.

Claims

REVENDICATIONS
1. Procédé de mise à jour d'un calculateur (200) automobile de façon à lui ajouter une
fonctionnalité supplémentaire, ledit calculateur (200) comportant une mémoire de démarrage comprenant une procédure de démarrage et une mémoire applicative stockant au moins un premier module applicatif (Module2), ledit premier module applicatif (Module2) comportant des liens statiques vers ladite mémoire applicative,
Caractérisé en ce que, la procédure de démarrage comprend une partie (BOOT_2) comprenant une structure logicielle, ledit procédé comporte des étapes de :
Mise à jour (31) de la structure logicielle (BOOT_2), avec une nouvelle structure logicielle (BOOT_2'),
Réinitialisation (32) dudit calculateur (200) et détection dans la nouvelle structure logicielle (BOOT_2') d'une donnée relative à un nouveau module applicatif (Module3),
Reprogrammation (33) du premier module applicatif (Module2) faisant appel à la fonctionnalité supplémentaire,
Ajout (34), dans la mémoire applicative, du nouveau module applicatif (Module3) comportant la fonctionnalité supplémentaire,
Réinitialisation (35) dudit calculateur (200).
2. Procédé de mise à jour d'un calculateur (200) automobile selon la revendication 1,
caractérisé en ce que la structure logiciel (BOOT_2) comporte une adresse de début (M2V1) et une adresse de fin (M2V2) du premier module (Module2) applicatif et en ce que la nouvelle structure logicielle (BOOT_2') comporte, en outre, une adresse de début (M3V1) et une adresse de fin (M3V1) du nouveau module (Module3).
3. Procédé de mise à jour d'un calculateur (200) automobile selon l'une des revendications précédentes, caractérisé en ce qu'en réponse à la détection de la donnée relative au nouveau module (Module3), il comprend en outre une étape de vérification d'une signature associée audit nouveau module (Module3) et en l'absence de ladite signature, il comprend le téléchargement dudit nouveau module (Module3) et de la signature associée (HM3).
4. Procédé de mise à jour d'un calculateur (200) automobile selon l'une des revendications précédentes, caractérisé en ce que l'étape de reprogrammation (63) du premier module applicatif (Module2) comporte une mise à jour de la signature associée audit premier module (Module2).
5. Procédé de mise à jour d'un calculateur (200) automobile selon l'une des revendications précédentes, caractérisé en ce que l'étape d'ajout (34) du nouveau module (Module 3) comporte des étapes de :
écriture d'une signature (HM3) associée audit nouveau module (Module 3), programmation du contenu dudit nouveau module (Module3),
validation dudit nouveau module (Module 3) en comparant une signature déterminée à partir dudit nouveau module (Module3) et la signature (HM3) associée audit nouveau module (Module 3).
6. Procédé de mise à jour d'un calculateur (200) automobile selon l'une des revendications précédentes, caractérisé en ce que, la procédure de démarrage comprenant une première (BOOT_l) et une deuxième (BOOT_2) partie, la première (BOOT_l) et la deuxième partie de la procédure de démarrage (BOOT_2) appartiennent à deux segments de mémoire distincts.
7. Programme d'ordinateur comportant des instructions pour mettre en oeuvre le procédé de mise à jour d'un calculateur (200) automobile selon l'une des revendications précédentes, lorsqu'il est exécuté sur un ou plusieurs processeurs.
8. Dispositif d'assistance d'un conducteur d'un véhicule, comportant au moins un processeur et une mémoire caractérisé en ce qu'il est configuré pour mettre en oeuvre le procédé de mise à jour selon l'une des revendications 1 à 5.
9. Véhicule caractérisé en ce qu'il comporte un dispositif selon la revendication précédente.
EP20705441.2A 2019-02-13 2020-01-27 Procédé de mise à jour d'un calculateur automobile de façon à lui ajouter une fonctionnalité supplémentaire Withdrawn EP3924831A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1901424A FR3092676B1 (fr) 2019-02-13 2019-02-13 Procédé de mise à jour d’un calculateur automobile de façon à lui ajouter une fonctionnalité supplémentaire
PCT/FR2020/050119 WO2020165518A1 (fr) 2019-02-13 2020-01-27 Procédé de mise à jour d'un calculateur automobile de façon à lui ajouter une fonctionnalité supplémentaire

Publications (1)

Publication Number Publication Date
EP3924831A1 true EP3924831A1 (fr) 2021-12-22

Family

ID=67262553

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20705441.2A Withdrawn EP3924831A1 (fr) 2019-02-13 2020-01-27 Procédé de mise à jour d'un calculateur automobile de façon à lui ajouter une fonctionnalité supplémentaire

Country Status (4)

Country Link
EP (1) EP3924831A1 (fr)
CN (1) CN113454608A (fr)
FR (1) FR3092676B1 (fr)
WO (1) WO2020165518A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3125147B1 (fr) * 2021-07-08 2023-06-16 Continental Automotive Procédé de gestion d’une zone mémoire d’une unité de contrôle électronique de véhicule automobile
CN116133011A (zh) * 2023-02-17 2023-05-16 福思(杭州)智能科技有限公司 车载系统的升级方法、系统及装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2719924B1 (fr) 1994-05-11 1996-08-14 Peugeot Procédé de déverrouillage de l'accès d'un outil de téléchargement d'un fichier, à un calculateur.
FR2903791B1 (fr) * 2006-07-13 2008-10-17 Airbus France Sas Procede de telechargement d'un module logiciel.
FR2964764B1 (fr) * 2010-09-15 2012-08-31 Peugeot Citroen Automobiles Sa Methode de transfert etage vers un calculateur de vehicule automobile, d'un code applicatif puis de parametres de calibration de ce code applicatif.
FR3018413B1 (fr) * 2014-03-07 2016-03-18 Peugeot Citroen Automobiles Sa Procede et systeme pour le telechargement accelere de donnees
GB2527060B (en) * 2014-06-10 2021-09-01 Arm Ip Ltd Method and device for updating software executed from non-volatile memory

Also Published As

Publication number Publication date
FR3092676A1 (fr) 2020-08-14
CN113454608A (zh) 2021-09-28
FR3092676B1 (fr) 2021-01-15
WO2020165518A1 (fr) 2020-08-20

Similar Documents

Publication Publication Date Title
AU2011329096B2 (en) Networked recovery system
WO2015121418A2 (fr) Procédé de déploiement d'un ensemble d'application(s) logicielle(s)
EP4127911B1 (fr) Dispositifs et procédé de contrôle d'unités de commande électroniques d'un véhicule automobile
EP3991029A1 (fr) Procédé de dialogue avec un calculateur sur bus embarqué de véhicule
EP3924831A1 (fr) Procédé de mise à jour d'un calculateur automobile de façon à lui ajouter une fonctionnalité supplémentaire
EP1649363B1 (fr) Procede de gestion des composants logiciels integres dans un systeme embarque
CN115250464A (zh) Ota管理器、中心、系统、更新方法、以及车辆
US20150039872A1 (en) Multiple Signed Filesystem Application Packages
WO2012107189A2 (fr) Procede de reprogrammation d'un calculateur, support de memorisation de donnees et calculateur de vehicule automobile
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
CN112214233A (zh) 一种用于恢复物联网终端固件的方法以及系统
EP4217852B1 (fr) Mise a jour du logiciel d´un calculateur embarque d'un vehicule en utilisant des memoires d'execution, de sauvegarde et de controle
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
EP4018347B1 (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
FR2930828A1 (fr) Procede de validation de la modification d'un programme installe pour une unite de commande electronique d'un vehicule automobile.
WO2024121096A1 (fr) Unite de commande electronique pour vehicule comprenant une boite noire transactionnelle, et procede de fonctionnement d'une telle unite de commande electronique
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
FR2928473A1 (fr) Procede et disositif pour assurer une coherence entre des telechargements de differentes versions d'un logiciel.
EP3907638B1 (fr) Contrôleur de démarrage sécurisé pour un système embarqué, système embarqué et procédé de démarrage sécurisé associés
FR3111447A1 (fr) Gestion de versions de logiciels embarqués à partir d’une empreinte informatique
WO2023280756A1 (fr) Procédé de gestion d'une zone mémoire d'une unité de contrôle électronique de véhicule automobile
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
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
WO2025104386A1 (fr) Système et méthode pour la mise à jour logicielle d'un véhicule
CN120234025A (zh) 诊断应用程序的升级方法、电子设备及计算机程序产品

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210708

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20230202

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20230613