EP4004712A1 - 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 - 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, une mémoire de sauvegarde et une mémoire de contrôle

Info

Publication number
EP4004712A1
EP4004712A1 EP20746261.5A EP20746261A EP4004712A1 EP 4004712 A1 EP4004712 A1 EP 4004712A1 EP 20746261 A EP20746261 A EP 20746261A EP 4004712 A1 EP4004712 A1 EP 4004712A1
Authority
EP
European Patent Office
Prior art keywords
memory
software
computer
request
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.)
Withdrawn
Application number
EP20746261.5A
Other languages
German (de)
English (en)
Inventor
Francois Rochette
Thierry Lopez
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.)
Stellantis Auto SAS
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
Priority claimed from FR1908403A external-priority patent/FR3099265B1/fr
Priority claimed from FR1908402A external-priority patent/FR3099264B1/fr
Application filed by PSA Automobiles SA filed Critical PSA Automobiles SA
Publication of EP4004712A1 publication Critical patent/EP4004712A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • 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
    • 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/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1004—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum
    • 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/1441—Resetting or repowering
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories

Definitions

  • the invention relates to the software update of one or more computers of a motor vehicle carried out remotely from a diagnostic tool also called an OTA update (for Over The Air).
  • OTA update for Over The Air
  • Communication between the tool and the computer generally makes use of either the CAN 500kbps technology known from the current state of the art or the 100 Mbits / s Ethernet technology being deployed in the automotive world in order to transfer the data to be programmed.
  • Methods and systems for downloading files in computers on board motor vehicles such as those described for example in document FR-A-2719924, are already known in the state of the art. This document details the various successive stages of the procedure used during vehicle assembly or in a manufacturer's after-sales network, when correcting a service by exchanging a file.
  • This type of problem can arise for example in the case where the destination computer tries to write a value on a corrupted memory cell for example, or in the case of a transmission error due for example to a field
  • Such a type of problem is generally detected by the recipient computer (for example by checking a CRC Cyclic Redoundancy Check in the event of an incorrect reception). In this case, information will be sent to the master computer to request the execution of the rollback process.
  • document US20190057214 discloses an update control device comprising a first communication unit, a second communication unit, and a control unit.
  • the first communication unit is configured to receive patch data for each block of software and first authentication data for each authentication block of software in an updated terminal using the patch data on a basis. by block.
  • the control unit is configured to request the terminal to rollback for restoration from a first block to a (M-1) th block using the patch data upon receipt of an update result indicating a failure in an authentication of an Mth block (M> 1).
  • An object of the present invention is to provide a solution for quickly resetting a computer of a vehicle in particular to a state prior to a software update when an update file is corrupted.
  • the invention relates in particular to a method for updating software of an on-board computer of a vehicle, comprising an execution memory (ME) in which a plurality of blocks (A, B, C) are stored. of current software, a backup memory (MS) and a control memory (MC), characterized in that it comprises the steps of:
  • Sending (400) of a request commanding a return to a state preceding the update comprising a copy (403) from the backup memory (MS) to the execution memory (ME) of the plurality of blocks of the current software (A, B, C).
  • the invention has the advantage, when an integrity test of the data received leads to a failure, to allow the installation procedure to be interrupted without delay and to immediately restart the initial software because the execution memory (Executing Memory) has not yet been changed.
  • the invention therefore saves time but also improves security insofar as it eliminates additional risks of data corruption. inevitably linked to the successive operations of generating blocks of current software in the solutions of the state of the art.
  • the method for updating the software of a computer further comprises a step of sending a request commanding said computer to erase the control memory, prior to sending the request commanding the writing in control memory of at least one block of updated software.
  • the method for updating software of a computer further comprises a step of sending a request commanding said computer to erase the backup memory, prior to the transmission of the request controlling the copy from the execution memory to the backup memory of the plurality of blocks of the current software.
  • the method for updating software of a computer further comprises a step of sending a request commanding said computer to check the integrity of the plurality of blocks of the current software in the backup memory.
  • the method for updating software of a computer further comprises a step of sending a request commanding said computer to erase from the execution memory the software blocks to be put. up to date.
  • the step of returning to a state preceding the update further comprises a preliminary step of erasing the execution memory of the computer and a step of verifying the integrity of the plurality of blocks of the current software in runtime memory.
  • the step of returning to a state preceding the update further comprises a step of stopping the update comprising a command to return to a state preceding the update to other computers concerned by said update. up to date.
  • the invention also relates to a device for updating computer software, said device comprising a memory associated with at least one processor configured to implement the steps of the method according to the invention.
  • the invention also relates to a vehicle characterized in that it comprises a device for updating the software of a computer according to the invention.
  • FIG. 1 schematically illustrates a system, according to a particular embodiment of the present invention
  • FIG. 2 schematically illustrates a computer, according to a particular embodiment of the present invention
  • FIG. 3 schematically illustrates an updating method, according to a particular embodiment of the present invention.
  • FIG 4 schematically illustrates the sub-steps of a step for resetting to a state preceding an update, according to a particular embodiment of the present invention.
  • FIG 5 illustrates an example of the successive states of memories of a computer during an update.
  • the subject of the invention is in particular a method making it possible to update, via a wired communication or a wireless communication, an on-board computer provided with an external memory of double the capacity of the execution memory.
  • the procedure provides for a Rollback operation which makes it possible to return to version n-1 so that the vehicle can regain its functionality.
  • the system according to the invention comprises a vehicle 101 connected to a remote update server 102.
  • the vehicle 101 comprises a plurality of computers ECU1, ECU2, ECU3 including an on-board communication unit which communicates with the server 102, via a wireless connection.
  • the connection or wireless link is a connection by radio waves (3G, 4G, ).
  • the computers ECU1, ECU2, ECU3 communicate with each other via a data bus 104 (for example of the CAN type).
  • the unloaded server 102 is for example a generic computer comprising at least one memory and one processor.
  • the vehicle 101 and the unloaded server 102 communicate via a wide area network 105 such as a fixed communication network 103 (or WAN for “Wide Area Network”), for example the Internet network to which the vehicle is connected by a wireless link (3G, 4G, ).
  • the ECU1 computer also called the update management computer (or
  • FOTA Master - for Full Over-The-Air which allows the updating of computers ECU2 to ECU3, has for this purpose mechanisms capable of transferring the data files received in frames expected by the recipient ECU2, ECU3 computers to install their software.
  • the computer playing the role of FOTA master in a vehicle may or may not be the same computer as the one which has wireless communication functions.
  • An operator via a terminal 107 can perform the checks and transmits remote instructions to the vehicle 101. These instructions are transmitted to the vehicle 101 by wave which can be 4G, WIFI or any other wireless communication technology. come.
  • ECU1, ECU2, ECU3 calculators can be updated in a garage.
  • Updating software in a garage responds to a specific procedure (case 1 in FIG. 1) during which the operator becomes responsible for the vehicle entrusted to him. In this regard, it places the vehicle in a "safe and secure" environment. before launching this operation from a tool 106 connected to a dedicated socket 108 of the vehicle 101 Then once the operation is complete, it performs certain checks to ensure that it is operating correctly. If a problem is detected, either during the course of the procedure or after the update, the technician will take the necessary measures to correct the anomaly (new test, change of part, etc.) before returning the vehicle. to the client. The mechanic is therefore an important link in the safety chain as such, but is also in charge of ensuring the quality of the operation carried out.
  • the FOTA master communicates with the target computer via the communication network available in the vehicle (for example CAN, Ethernet or other).
  • the communication network available in the vehicle (for example CAN, Ethernet or other).
  • the FOTA master uses a dedicated communication protocol, such as, for example, the UDS protocol (standard IS014229) commonly used for diagnosing or downloading software for on-board computers in motor vehicles.
  • UDS protocol standard IS014229
  • the computer 200 according to the invention comprises:
  • microcontroller 201 comprising equipped with a Flash memory ME, of a given size N, used to run the downloaded software and called the execution memory ME (or Executing Memory in English),
  • a backup memory MS (or Backup Memory in English), of a size at least equal to the given size N, used as backup memory allowing to return to the previous version of the software in the event of a problem during the installation
  • - A control memory MC (or Checking Memory in English), of a size at least equal to the given size N, used to check the integrity of the new software received by wire or OTA method before even launching any modification of the contents of the execution memory.
  • the backup memory MS and the control memory MC belong to an external Flash memory 205, of a size at least equal to twice the given size N.
  • the external flash memory is linked to the microcontroller, for example via a 206 SPI (Serial Peripheral Interface) bus, but it could be another data link.
  • SPI Serial Peripheral Interface
  • This bus can be replaced by any other communication bus technology whose data exchange rate is sufficient for the installation of the new software to be completed within a reasonable timeframe as seen by the customer.
  • the data exchanged between the internal memory and the external memory are encrypted, so as to improve the security of the update.
  • the backup memory MS and the control memory MC can be integrated into the memory of the microcontroller 201.
  • This variant has the advantage of not needing to encrypt the data during a copy of the data. 'one memory to another.
  • this variant eliminates the need for additional components used to manage communication with an external memory.
  • this variant involves using a microcontroller with an internal memory of at least double the size of the software.
  • the computer to be updated 200 or the target computer, has software in its execution memory ME.
  • This software is composed of 3 data blocks A, B and C.
  • the method according to the invention comprises: A first phase 310 during which: the update data (blocks B ’and C’ in the example) contained in the file to be downloaded are transmitted to the
  • a second phase 320 during which: the entire content of the execution memory ME is duplicated in the backup memory MS in order to keep a copy of the original software.
  • a third phase 330 during which: the data blocks contained in the control memory MC, blocks B 'and C' in the example, are copied into the execution memory ME in order to replace the blocks of the old software (blocks B and C in the example).
  • the data blocks not affected by the update are not modified (block A in the example).
  • a fourth phase executed in the event of an installation failure during which the entire contents of the MS backup memory are copied back to the ME execution memory in order to revert to the initial software.
  • the FOTA master places the computer 200 in a state dedicated to programming (where the functional is deactivated) by using a request to enter a reprogramming session.
  • the target computer 200 accepts to execute this request only if the safety conditions are met (eg: vehicle stationary, traction chain deactivated, etc.)
  • the FOTA master communicates directly with the boot software of the target computer 200.
  • the computer boot software can perform different operations (write, copy, integrity check) on one of the three memories available (ME execution memory, MS backup memory or MC control memory).
  • Figure 3 describes a succession of actions to be performed by the FOTA master to install new software in the target computer 200.
  • the target computer 200 is in a first state 501, called the initial state, in which: the execution memory ME comprises three blocks of current software.
  • the first phase 310 comprises the following steps:
  • a first step 31 1 the FOTA master sends a request to ask the target computer to erase the control memory MC.
  • the FOTA master writes the data received from the remote server (by wired or wireless communication) in the control memory MC of the target computer 200 using dedicated requests. This operation is reiterated for each block of data to be updated.
  • control memory MC is in an external memory 205
  • it is the boot software of the target computer which transparently manages for the FOTA master the exchanges carried out on the communication bus 206 (for example type SPI) between the microcontroller 201 and its external memory 205.
  • the FOTA master sends a request to ask the target computer 200 to check the integrity of the data copied into the control memory MS.
  • This check can be carried out using a CRC Cyclic Redoundancy Check or any other method known to the state of the art (example: calculation, using a hash function, of a "hash »Of the content of the data downloaded in the target computer, and comparison of the result with a reference value transmitted beforehand by the FOTA master). If the memory is made up of several blocks of data, each block has its own integrity control mechanism (based on the same method or different methods).
  • the FOTA master receives a negative response from the target computer 200. In this case, the FOTA master abandons the normal course of the procedure. installation to perform an installation shutdown procedure 314.
  • the target computer 200 is in a second state 502 in which: the execution memory ME comprises three blocks of current software A, B, C and the control memory MC comprises the updated software blocks B ', C' from the update file 510.
  • the second phase 320 comprises the following steps.
  • the FOTA master sends a request to ask the computer 200 to erase all of the backup memory MS.
  • the FOTA master sends a request to ask the target computer 200 to copy the entire content of the execution memory ME into the backup memory MS.
  • a sixth step 323 the FOTA master sends a request to ask the target computer 200 to check the integrity of the data copied into the backup memory MS. This verification is advantageously carried out by the same methods as in the third step 313.
  • the target computer 200 If one of the fourth 321, fifth 322, or sixth 323 steps fails, the target computer 200 returns a negative response to the FOTA master. The FOTA master then executes the installation shutdown procedure 314.
  • the target computer 200 is in a third state 503 in which: the execution memory ME comprises the three blocks of the current software A, B, C, the control memory MC comprises the updated software blocks B ', C' from the update file 510, and the backup memory MS comprises the three blocks of the current software A, B, C
  • the third phase 330 is only executed if the first phase 310 and the second phase 320 have been successfully completed beforehand. From this phase, the boot software of the target computer 200 invalidates the application software present in the execution memory ME because it is liable to be modified by subsequent operations. For this, it can for example store a variable (or flag) in non-volatile memory, which will be tested each time the computer 200 is initialized to check whether the application software loaded in the execution memory ME can be executed or not.
  • the third phase 330 comprises the following steps.
  • the FOTA master sends as many requests as necessary to ask the target computer 200 to erase all the data blocks to be updated in the execution memory ME.
  • the list of data blocks to be updated is provided to the FOTA master via the download file.
  • the FOTA master sends as many requests as necessary to ask the target computer 200 to copy each block of data to be updated from the control memory MC to the execution memory ME.
  • a ninth step 333 the FOTA master sends as many requests as necessary to request the target computer to check the data integrity of each updated data block in the execution memory ME. This verification is advantageously carried out by the same methods as in the third step 313.
  • the target computer is in a fourth state 504 in which: the execution memory ME comprises a block of the current software A, and two blocks of the updated software B ', C' ; the control memory MC contains the updated software blocks B ’, C’ from the update file 510; and the backup memory MS comprises the three blocks of the current software A, B, C
  • the target computer 200 If one of the seventh 331, eighth 332, or ninth 333 steps fails, the target computer 200 returns a negative response to the FOTA master. The FOTA master then performs the operation of returning to a state prior to the update (Rollback).
  • the newly downloaded software will therefore be automatically executed by the computer 200 during its next reinitialization caused either by a request from the FOTA master, or by a power cut and then on again.
  • the installation shutdown procedure 314 is executed only if the installation fails before the third phase 330.
  • the FOTA master determines whether one or more computers are affected by the update. If only one computer is concerned by the update, the FOTA master sends a message to suggest to the operator either to restart or to abandon the installation.
  • the computer 200 is operational from the next reset, without a Rollback operation.
  • the FOTA master proceeds as for the first case (sending a message to the operator and no rollback if abort),
  • the FOTA master triggers the Rollback process in all the ECUs of the vehicle that require it until a state preceding the update is returned. day in the other computers of the vehicle.
  • the FOTA master then executes the rollback operation.
  • the rollback step 400 comprises the following substeps.
  • the FOTA master transmits 401 a message to GIHM to inform the operator that a Rollback operation is in progress on one or more computers of the vehicle.
  • the FOTA master sends 402 a request to ask the target computer 200 to erase all of the execution memory ME.
  • the FOTA master sends 403 a request to ask the target computer 200 to copy the entire contents of the backup memory MS into the execution memory ME.
  • the FOTA master sends 404 a request to ask the target computer to check the integrity of the data copied into the execution memory ME. This verification is advantageously carried out by the same methods as in the third step 313.
  • the computer can again operate with its initial software after its reinitialization caused either by a request from the FOTA master, either by cutting and then resuming the power supply.
  • the target computer is in a fifth state 505 in which: the execution memory ME comprises the three blocks of the current software A, B, C, the control memory MC comprises the updated software blocks B ', C' from the update file 510, and the backup memory MS comprises the three blocks of the current software A, B, C.
  • the invention also relates to a method allowing the updating, via a wired communication or a wireless communication, of an on-board computer provided with an external memory of equal capacity of the memory d. 'execution.
  • the procedure provides for a Rollback operation which allows a return to version n-1 so that the vehicle can regain its functionality.
  • the vehicle comprises a plurality of computers including an on-board communication unit which communicates with the server 102, via a wireless connection.
  • the connection or wireless link is a connection by radio waves (3G, 4G, ).
  • the computers communicate with each other via a data bus (eg CAN type).
  • a data bus eg CAN type.
  • the unloaded server is for example a generic computer comprising at least one memory and one processor.
  • the vehicle and the disembarked server communicate via a wide area network such as a fixed communication network (or WAN for “Wide Area Network”), for example the Internet network to which the vehicle is connected by a wireless link (3G, 4G, etc. .).
  • a wide area network such as a fixed communication network (or WAN for “Wide Area Network”), for example the Internet network to which the vehicle is connected by a wireless link (3G, 4G, etc. .).
  • the computer also called the update management computer (or FOTA Master - for Full Over-The-Air) which allows the computers to be updated, has for this purpose mechanisms capable of transferring the data files received in frames. expected by the recipient computers to install their software.
  • the computer playing the role of FOTA master in a vehicle may or may not be the same computer as the one which has wireless communication functions.
  • An operator via a terminal can perform the checks and transmits remote instructions to the vehicle. These instructions are transmitted to the vehicle by wave which can be 4G, WIFI or any other wireless communication technology to come.
  • the calculators can be updated in a garage. Updating software in a garage responds to a specific procedure during which the operator becomes responsible for the vehicle entrusted to him. In this regard, he places the vehicle in a "safe and secure" environment before launching this operation from a tool connected to a dedicated socket on the vehicle. Then once the operation is complete, it performs certain checks to ensure that it is working properly. If a problem is detected, either during the course of the procedure or after the update, the technician will take the necessary measures to correct the anomaly (new test, change of part, etc.) before returning the vehicle. to the client.
  • the garage owner is therefore an important link in the safety chain, but is also in charge of ensuring the quality of the operation carried out. During an OTA update at a customer's site, none of this is possible and it is therefore necessary to add in each computer a mechanism to revert to the previous version in the event of a problem.
  • the FOTA master communicates with the target computer via the communication network available in the vehicle (for example CAN, Ethernet or other).
  • the communication network available in the vehicle (for example CAN, Ethernet or other).
  • the FOTA master uses a dedicated communication protocol, such as, for example, the UDS protocol (standard IS014229) commonly used for diagnosing or downloading software for on-board computers in motor vehicles.
  • UDS protocol standard IS014229
  • the calculator according to the invention comprises:
  • microcontroller comprising equipped with a Flash memory, of a given size N, used to run the downloaded software and called the execution memory (or Executing Memory in English),
  • a backup memory of a size at least equal to the given size N, used as a backup memory allowing to revert to the previous version of the software in the event of a problem during installation,
  • the backup memory belongs to an external Flash memory, of a size at least equal to the given size N.
  • the external flash memory is linked to the microcontroller, for example via a 206 SPI (Serial Peripheral Interface) bus, but it could be another data link.
  • SPI Serial Peripheral Interface
  • This bus can be replaced by any other communication bus technology whose data exchange rate is sufficient for the installation of the new software to be completed within a reasonable timeframe as seen by the customer.
  • the data exchanged between the internal memory and the external memory are encrypted, so as to improve the security of the update.
  • the backup memory MS can be integrated into the memory of the microcontroller.
  • This variant has the advantage of not needing to encrypt the data when copying from one memory to another.
  • this variant eliminates the need for additional components used to manage communication with an external memory.
  • this variant involves using a microcontroller having an internal memory of size at least double the maximum size of the software.
  • the computer to be updated, or target computer has software in its execution memory. This software is composed of 3 data blocks A, B and C.
  • the method according to the invention comprises:
  • a first phase during which: the entire content of the execution memory is duplicated in the backup memory in order to keep a copy of the original software.
  • the data blocks not affected by the update are not modified (block A in the example).
  • a third phase is executed in the event of an installation failure during which the entire contents of the backup memory are copied into the execution memory in order to return to the initial software.
  • the FOTA master before updating the target computer, places the computer in a state dedicated to programming (where the functional is deactivated) by using a request to enter a reprogramming session.
  • the target computer accepts to execute this request only if the safety conditions are met (eg: vehicle stationary, traction chain deactivated, etc.)
  • the FOTA master communicates directly with the boot software of the target ECU.
  • the computer boot software can perform various operations (write, copy, integrity check) on one of the two memories available to it (ME execution memory or backup memory MS).
  • the target computer before the execution of the updating method according to the invention, is in a first state, called the initial state, in which: the execution memory ME comprises three blocks of one current software A, B, C.
  • the first phase comprises the following steps: In a first step, the FOTA master sends a request to ask the target computer 200 to erase the backup memory MS.
  • the FOTA master sends a request to ask the target computer to copy the entire contents of the execution memory ME into the backup memory MS.
  • the FOTA master sends a request) to ask the target computer to check the integrity of the data copied to the backup memory.
  • This check can be carried out using a CRC Cyclic Redoundancy Check or any other method known to the state of the art (example: calculation, using a hash function, of a "hash »Of the data content and comparison of the result with a reference value transmitted beforehand by the FOTA master). If the memory is made up of several blocks of data, each block has its own integrity control mechanism (based on the same method or different methods). If one of the first, second or third stages fails, the FOTA master receives a negative response from the computer. In this case, the FOTA master will abandon the normal flow of the installation procedure to perform the stop installation procedure.
  • the target computer is in a second state 502 in which: the execution memory ME comprises the three blocks of the current software A,
  • B, C, and the backup memory MS comprises the three blocks of the current software A, B,
  • the second phase is only executed if the first phase has been successfully completed beforehand. From this phase, the boot software of the target computer invalidates the application software present in the execution memory because it is liable to be modified by the rest of the operations. For this, it can for example store a variable (or flag) in non-volatile memory, which will be tested each time the computer is initialized to verify whether the application software loaded in the execution memory can be executed or not.
  • the second phase comprises the following steps.
  • the FOTA master sends a request to ask the target computer to erase all the data blocks to be updated in the execution memory ME.
  • the list of data blocks to be updated is provided to the FOTA master via the download file.
  • the FOTA master writes the received data (by
  • the FOTA master sends a request to request the target computer 200 to check the data integrity of each updated data block in the execution memory ME. This verification is advantageously carried out by the same methods as in the third step.
  • the target computer is in a third state in which: the execution memory comprises a block of the current software A and two blocks of the updated software, B, C, and the memory of backup comprises the three blocks of the current software A, B, C.
  • the target computer If one of the fourth, fifth or sixth steps fails, the target computer returns a negative response to the FOTA master.
  • the FOTA master then performs the operation of returning to a state prior to the update (Rollback).
  • the computer boot software declares the application software valid.
  • the newly downloaded software is therefore automatically executed by the computer during the reset caused either by a request from the FOTA master, or by cutting and then resuming the power to the target computer.
  • the installation shutdown procedure is performed only if the installation fails before the third phase.
  • Two cases are to be distinguished depending on the type of intervention initially planned by the operator: (case 1) only the target computer is updated or (case 2) several computers are affected by the update.
  • the FOTA master determines whether one or more computers are affected by the update.
  • the FOTA master sends a message to suggest to the operator either to restart or to abandon the installation.
  • the FOTA master proceeds as in the first case (sending a message to the operator and no rollback if abandoned),
  • the FOTA master triggers the Rollback process in all the ECUs of the vehicle that require it until a state preceding the update is returned. in the other computers of the vehicle.
  • the FOTA master then performs the operation of returning to a state prior to the update (Rollback).
  • the rollback step has the following substeps.
  • the FOTA master transmits a message to GI HM to inform the operator that a Rollback operation is in progress on one or more computers of the vehicle.
  • the FOTA master sends a request to ask the target ECU to erase all of the execution memory.
  • the FOTA master sends a request to ask the target ECU to copy the entire contents of the backup memory to the execution memory.
  • the FOTA master sends a request to ask the target ECU to check the integrity of the data copied to the execution memory. This verification is advantageously carried out by the same methods as in the third step.
  • the computer can again operate with its initial software after its reset caused either by a request from the FOTA master, or by a power cut and then on again.
  • the target computer is in a fourth state in which: the execution memory comprises the three blocks of the current software A, B, C, and the backup memory comprises the three blocks current software A, B, C.
  • the invention relates in particular to a method for updating software of an on-board computer of a vehicle, comprising an execution memory in which are stored a plurality of blocks (A, B, C) of a current software, a backup memory, characterized in that it comprises the steps of:
  • the invention has the advantage when an integrity test of the data received leads to a failure, to allow the installation procedure to be interrupted without delay and to quickly restart the initial software since it is saved in the memory of the device. backup.
  • the invention therefore saves time but also enhanced security insofar as it eliminates additional risks of data corruption inevitably linked to successive software block generation operations during the rollback phase in the solution. state of the art.
  • the method for updating software of a computer further comprises a step of sending a request commanding said computer to erase the backup memory, prior to the transmission of the request controlling the copy from the execution memory to the backup memory of the plurality of blocks of the current software.
  • the method for updating software of a computer further comprises a step of sending a request commanding said computer to check the integrity of the plurality of blocks of the current software in the backup memory.
  • the method for updating software of a computer further comprises a step of sending a request commanding said computer to erase from the execution memory the software blocks to be put. up to date.
  • the step of returning to a state preceding the update further comprises a preliminary step of erasing the execution memory of the computer and a step of verifying the integrity of the plurality of blocks of the current software in runtime memory.
  • the method for updating the software of a computer further comprises a step of stopping the update comprising a command to return to a state preceding the update to other computers affected by said update.
  • the invention also relates to a device for updating computer software, said device comprising a memory associated with at least one processor, configured to implement the steps of the method according to the invention.
  • the invention also relates to a vehicle characterized in that it comprises a device for updating the software of a computer according to the invention.

Landscapes

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

Abstract

L'invention concerne un procédé de mise à jour d'un logiciel d'un véhicule, comportant des mémoires d'exécution (ME), de sauvegarde (MS) et de contrôle (MC) comportant des étapes de : - Emission d'une requête commandant une écriture en mémoire de contrôle (MC) 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 de contrôle (MC), - 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), - Emission d'une requête commandant la copie depuis la mémoire de contrôle (MC) vers la mémoire d'exécution (ME) dudit au moins un bloc de logiciel mis à jour (B',C'), - Emission d'une requête commandant une vérification de l'intégrité des blocs (A,B',C') de logiciel de la mémoire d'exécution (ME).

Description

DESCRIPTION
Titre : 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
Domaine technique
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 connaît 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 ).
Malgré toutes ces précautions et ces systèmes de vérifications, il reste possible que certains cas de mauvais fonctionnement ne puissent pas être détectés à l’issue de la mise à jour OTA.
Résumé de l’invention
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 mis à 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) et une mémoire de contrôle (MC), caractérisé en ce qu’il comporte des étapes de :
Emission (312) d’une requête commandant une écriture en mémoire de contrôle (MC) d’au moins un bloc de logiciel mis à jour (B’,C’),
Emission (313) d’une requête commandant une vérification dudit au moins un bloc de logiciel mis à jour (B’,C’) stocké en mémoire de contrôle (MC),
Emission (322) 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 (332) d’une requête commandant la copie (332) depuis la mémoire de contrôle (MC) vers la mémoire d’exécution (ME) dudit au moins un bloc de logiciel mis à jour (B’, C’),
Emission (333) d’une requête commandant une vérification de l’intégrité des blocs (A,B’,C’) de logiciel de la 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 immédiatement le logiciel initial car la mémoire d’exécution (Executing Memory) n’a pas encore été modifiée.
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 blocs de logiciel courant dans les solutions de l’état de la technique.
En utilisant une mémoire de vérification supplémentaire, la probabilité de devoir exécuter un Rollback est plus faible qu’avec les autres solutions connues dans l’état de l’art. Ceci diminue considérablement le risque d’échec lors de l’exécution du retour à la configuration n-1 du véhicule.
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 contrôle, préalablement à l’émission de la requête commandant l’écriture en mémoire de contrôle d’au moins un bloc de logiciel mis à jour.
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, l’étape de retour à un état précédent la mise à jour 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 : [Fig. 1] illustre de façon schématique un système, selon un exemple de réalisation particulier de la présente invention ;
[Fig. 2] illustre de façon schématique un calculateur, selon un exemple de réalisation particulier de la présente invention;
[Fig. 3] illustre schématiquement un procédé de mise à jour, selon un exemple de réalisation particulier de la présente invention.
[Fig 4] illustre schématiquement des sous-étapes d’une étape de remise à un état précédent une mise à jour, selon un exemple de réalisation particulier de la présente invention.
[Fig 5] illustre un exemple des états successifs de mémoires d’un calculateur au cours d’une mise à jour.
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é double 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 chaîne 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 IS014229) 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, - Une mémoire de contrôle MC (ou Checking Memory en anglais), d’une taille au moins égale à la taille donnée N, utilisée pour vérifier l’intégrité du nouveau logiciel reçu par méthode filaire ou OTA avant même de lancer toute modification du contenu de la mémoire d’exécution. Selon première variante de l’invention, la mémoire de sauvegarde MS et la mémoire de contrôle MC appartiennent à une mémoire Flash externe 205, d’une taille au moins égale à deux fois 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 et la mémoire de contrôle MC peuvent être intégrées 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 : les données de mise à jour (blocs B’ et C’ dans l’exemple) contenues dans le fichier à télécharger sont transmises au
calculateur cible 200 (via une communication filaire ou une communication sans fils) et sont placées dans la mémoire de contrôle MC afin de vérifier leur intégrité. Ceci permet de ne pas altérer le logiciel actuellement dans la mémoire d’exécution ME. Une deuxième phase 320 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 troisième phase 330 au cours laquelle : les blocs de données contenus dans la mémoire de contrôle MC, blocs B’ et C’ dans l’exemple, sont recopiés dans la mémoire d’exécution ME afin de remplacer les 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 quatriè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 trois mémoires dont il dispose (mémoire d’exécution ME, mémoire de sauvegarde MS ou mémoire de contrôle MC). 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.
Avantageusement, la première phase 310 comporte les étapes suivantes :
Dans une première étape 31 1 , le FOTA master envoie une requête pour demander au calculateur cible d’effacer la mémoire de contrôle MC. Dans une deuxième étape 312, le FOTA master écrit les données reçues du serveur distant (par la communication filaire ou sans fils) dans la mémoire de contrôle MC du calculateur cible 200 à l’aide de requête dédiées. Cette opération est réitérée pour chaque bloc de donnée à mettre à jour.
Dans le mode de réalisation selon lequel la mémoire de contrôle MC est dans une mémoire externe 205, c’est le logiciel de boot du calculateur cible qui gère de manière transparente pour le FOTA master les échanges réalisés sur le bus de communication 206 (par exemple de type SPI) entre le microcontrôleur 201 et sa mémoire externe 205.
Dans une troisième étape 313, le FOTA master envoie une requête pour demander au calculateur cible 200 de contrôler l’intégrité des données copiées dans la mémoire de contrôle MS. 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 « condensât » du contenu des données téléchargées dans le calculateur cible, 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 31 1 , deuxième 312 ou troisième 313 étape, le FOTA master reçoit une réponse négative de la part du calculateur cible 200. Dans ce cas, le FOTA master abandonne le déroulement normal de la procédure d’installation pour exécuter une 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 trois blocs d’un logiciel courant A, B, C et la mémoire de contrôle MC comporte les blocs de logiciel mis à jour B’, C’ issus du fichier de mise à jour 510.
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 200 d’effacer la totalité de la mémoire de sauvegarde MS. Dans une cinquième étape 322, 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 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 copiées dans la mémoire de sauvegarde MS. Cette vérification est avantageusement réalisée par les mêmes méthodes qu’à la troisième étape 313.
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 la procédure d’arrêt de l’installation 314.
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 les trois blocs du logiciel courant A, B, C, la mémoire de contrôle MC comporte les blocs de logiciel mis à jour B’, C’ issus du fichier de mise à jour 510, 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 troisième phase 330 n’est exécutée que si la première phase 310 et la deuxième phase 320 ont été réalisées 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 troisième phase 330 comporte les étapes suivantes. Dans une septième étape 331 , le FOTA master envoie autant de requêtes que nécessaire pour demander au calculateur cible 200 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. Dans une huitième étape 332, le FOTA master envoie autant de requêtes que nécessaire pour demander au calculateur cible 200 de copier chaque bloc de données à mettre à jour depuis la mémoire de contrôle MC vers la mémoire d’exécution ME.
Dans une neuvième étape 333, le FOTA master envoie autant de requêtes que nécessaire pour demander au calculateur cible 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 troisième phase 330, le calculateur cible se trouve dans un quatrième état 504 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’ ; la mémoire de contrôle MC comporte les blocs de logiciel mis à jour B’, C’ issus du fichier de mise à jour 510 ; 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 septième 331 , huitième 332 ou neuvième 333 é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 troisième phase 333 s’est exécutée correctement, alors le logiciel de boot du calculateur déclare le logiciel applicatif valide (et donc modifie la variable
correspondante). Le logiciel nouvellement téléchargé sera donc automatiquement exécuté par le calculateur 200 lors de sa prochaine réinitialisation provoquée soit par requête de la part du FOTA master, soit par une coupure puis remise de l’alimentation.
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 septième 331 , huitième 332 ou neuvième 333 é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 à GIHM 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 cinquième état 505 dans lequel : la mémoire d’exécution ME comporte les trois blocs du logiciel courant A, B, C, la mémoire de contrôle MC comporte les blocs de logiciel mis à jour B’, C’ issus du fichier de mise à jour 510, et la mémoire de sauvegarde MS comporte les trois blocs du logiciel courant A, B, C.
Deuxième mode de réalisation.
Dans un autre mode de réalisation, l’invention a aussi 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é. Le véhicule comprend une pluralité de calculateurs 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 communiquent entre eux par l’intermédiaire d’un bus de données (par exemple de type CAN).
Le serveur débarqué est par exemple un calculateur générique comportant au moins une mémoire et un processeur. Le véhicule et le serveur débarqué communique via un réseau étendu tel que un réseau de communication fixe (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 aussi appelé calculateur de gestion de mise à jour (ou encore FOTA Master - pour Full Over-The-Air) qui permet la mise à jour des calculateurs, dispose à cet effet des mécanismes capables de transférer les fichiers de données reçues en trames attendues par les calculateurs 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 peut réaliser les vérifications et transmet des instructions à distance au véhicule. Ces instructions sont transmises au véhicule par voie d’onde qui peut être de la 4G, du WIFI ou toute autre technologie de communication sans fil à venir.
Les calculateurs peuvent être mis à jour dans un garage. La mise à jour d’un logiciel dans un garage répond à une procédure spécifique au cours de laquelle, l’opérateur devient responsable du véhicule qui lui a été confié. A cet égard, il place le véhicule dans un environnement « safe and secure » avant de lancer cette opération à partir d’un outil branché sur une prise dédiée du véhicule. 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 chaîne 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, 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 IS014229) couramment employé pour réaliser le diagnostic ou le téléchargement du logiciel des calculateurs embarqués dans les véhicules automobiles.
Le calculateur selon l’invention comporte :
- un microcontrôleur comprenant muni d’une mémoire Flash, d’une taille donnée N, utilisée pour exécuter le logiciel téléchargé et nommée mémoire d’exécution (ou Executing Memory en anglais),
- Une mémoire de sauvegarde (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 appartient à une mémoire Flash externe, 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. 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. Le calculateur à mettre à jour, ou calculateur cible, dispose d’un logiciel dans sa mémoire d’exécution. 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 au cours de laquelle : la totalité du contenu de la mémoire d’exécution est dupliqué dans la mémoire de sauvegarde afin de conserver une copie du logiciel d’origine.
Une deuxième phase 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 à 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 est recopiée dans la mémoire d’exécution afin de revenir au logiciel initial.
Avantageusement, avant la mise à jour du calculateur cible, le FOTA master place le calculateur 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 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. 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).
Selon un exemple de réalisation, avant l’exécution du procédé de mise à jour selon l’invention, le calculateur cible se trouve dans un premier état, 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 comporte les étapes suivantes : Dans une première étape, 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, le FOTA master envoie une requête pour demander au calculateur cible 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, le FOTA master envoie une requête ) 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 « condensât » 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, deuxième ou troisième é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.
A l’issue de la première phase, le calculateur cible 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 n’est exécutée que si la première phase a été réalisée avec succès au préalable. A partir de cette phase, le logiciel de boot du calculateur cible invalide le logiciel applicatif présent dans la mémoire d’exécution 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 pour vérifier si le logiciel applicatif chargé en mémoire d’exécution peut être exécuté ou non. Avantageusement, la deuxième phase comporte les étapes suivantes.
Dans une quatrième étape, 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.
Dans une cinquième étape, 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 à 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, 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.
A l’issue de la deuxième phase, le calculateur cible se trouve dans un troisième état dans lequel : la mémoire d’exécution comporte un bloc du logiciel courant A et deux blocs du logiciel mis à jour, B, C, et la mémoire de sauvegarde comporte les trois blocs du logiciel courant A, B, C.
En cas d’échec lors d’une des quatrième, cinquième ou sixième étape, le calculateur cible 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 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.
La procédure d’arrêt de l’installation est exécutée uniquement en cas d’échec de l’installation avant la troisième phase. 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 n’a pas encore été modifié à ce stade des opérations, le calculateur 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 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, cinquième ou sixième étape, le FOTA master exécute alors l’opération de retour à un état précédent la mise à jour (Rollback).
L’étape de rollback comporte les sous-étapes suivantes. Avantageusement, le FOTA master transmet un message à GI HM 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 une requête pour demander au calculateur cible d’effacer la totalité de la mémoire d’exécution.
Le FOTA master envoie une requête pour demander au calculateur cible de copier la totalité du contenu de la mémoire de sauvegarde dans la mémoire d’exécution.
Le FOTA master envoie 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. Cette vérification est avantageusement réalisée par les mêmes méthodes qu’à la troisième étape.
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, le calculateur cible se trouve dans un quatrième état dans lequel : la mémoire d’exécution comporte les trois blocs du logiciel courant A, B, C, et la mémoire de sauvegarde comporte les trois blocs du logiciel courant A, B, C.
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 dans laquelle sont stockés une pluralité de blocs (A, B, C) d’un logiciel courant, une mémoire de sauvegarde, 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 vers la mémoire de sauvegarde 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 d’au moins un bloc de logiciel mis à jour,
Emission d’une requête commandant une vérification dudit au moins un bloc de logiciel mis à jour stocké en mémoire d’exécution,
Et si une erreur est détectée alors :
Emission d’une requête commandant un retour à un état précédent la mise à jour comportant une copie depuis la mémoire de sauvegarde vers la mémoire d’exécution de la pluralité de blocs du logiciel courant. 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.

Claims

REVENDICATIONS
1. 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) et une mémoire de contrôle (MC), caractérisé en ce qu’il comporte des étapes de :
- Emission (312) d’une requête commandant une écriture en mémoire de contrôle (MC) d’au moins un bloc de logiciel mis à jour (B’,C’),
Emission (313) d’une requête commandant une vérification dudit au moins un bloc de logiciel mis à jour (B’,C’) stocké en mémoire de contrôle (MC),
Emission (322) 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 (332) d’une requête commandant la copie (332) depuis la mémoire de contrôle (MC) vers la mémoire d’exécution (ME) dudit au moins un bloc de logiciel mis à jour (B’,C’),
Emission (333) d’une requête commandant une vérification de l’intégrité des blocs (A,B’,C’) de logiciel de la 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).
2. Procédé de mise à jour d’un logiciel d’un calculateur selon la revendication 1 , comportant en outre une étape d’émission (31 1 ) d’une requête commandant audit calculateur d’effacer la mémoire de contrôle (MC), préalablement à l’émission (312) de la requête commandant l’écriture en mémoire de contrôle (MC) d’au moins un bloc de logiciel mis à jour (B’,C’).
3. 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 la mémoire de sauvegarde (MS), préalablement à l’émission (322) 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).
4. 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 (323) 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).
5. 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 (331 ) 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).
6. Procédé de mise à jour d’un logiciel d’un calculateur selon l’une des
revendications précédentes, 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 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).
7. Procédé de mise à jour d’un logiciel d’un calculateur selon l’une des
revendications précédentes, 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.
8. 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 à 7.
9. 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.
EP20746261.5A 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 Withdrawn EP4004712A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR1908403A FR3099265B1 (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, une mémoire de sauvegarde et une mémoire de contrôle
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
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

Publications (1)

Publication Number Publication Date
EP4004712A1 true EP4004712A1 (fr) 2022-06-01

Family

ID=71786985

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20746261.5A Withdrawn 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

Country Status (3)

Country Link
EP (1) EP4004712A1 (fr)
CN (1) CN114144759A (fr)
WO (1) WO2021014064A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4290396A1 (fr) * 2022-06-07 2023-12-13 Valeo Internal Automotive Software Egypt, a limited liability company Mise à jour de logiciel d'un circuit électronique pour un véhicule

Family Cites Families (3)

* 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.
EP3405923B1 (fr) * 2016-01-22 2023-10-11 BlackBerry Limited Mise à jour d'une unité de commande dans un véhicule
JP2019036238A (ja) 2017-08-21 2019-03-07 株式会社東芝 更新制御装置、端末、更新制御方法およびプログラム

Also Published As

Publication number Publication date
WO2021014064A1 (fr) 2021-01-28
CN114144759A (zh) 2022-03-04

Similar Documents

Publication Publication Date Title
US20160306624A1 (en) Vehicle control storage methods and systems
FR2937437A1 (fr) Procede de fonctionnement d'un equipement embarque, equipement associe et aeronef comprenant un tel equipement
FR3067136A1 (fr) Procede de mise a jour d’un calculateur embarque de vehicule
EP4127911A1 (fr) Dispositifs et procédé de contrôle d'unités de commande électroniques d'un véhicule automobile
WO2021014064A1 (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
US20220107929A1 (en) System and Method Implementing a Distributed Audit Trail
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
EP4066103A1 (fr) Procédé de mise à jour de système numérique
CN113885929A (zh) 高精度地图的远程升级方法
WO2021181015A1 (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
CN117407020A (zh) Ota升级刷写方法、装置、电子设备及存储介质
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
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
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
EP4018347A1 (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
WO2020165518A1 (fr) Procédé de mise à jour d'un calculateur automobile de façon à lui ajouter une fonctionnalité supplémentaire
FR3099835A1 (fr) Procédé d’écriture dans une zone de données sécurisée d’un calculateur sur bus embarqué de véhicule.
WO2020259956A1 (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é
FR3143146A1 (fr) Unite de commande electronique pour vehicule comprenant une boite noire transactionnelle, et procede de fonctionnement d’une telle unite de commande electronique
FR2903791A1 (fr) Procede de telechargement d'un module logiciel.
EP3225007A1 (fr) Procédé de communication entre un outil de production et un véhicule automobile
FR3111447A1 (fr) Gestion de versions de logiciels embarqués à partir d’une empreinte informatique
CN118400266A (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: 20220113

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: 20230731

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: STELLANTIS AUTO SAS

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: 20231212