METHOD AND DEVICE FOR UPDATING THE SOFTWARE OF A VEHICLE ON-BOARD COMPUTER WITH A RUNTIME MEMORY AND A BACKUP MEMORY

Description

[0001] 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 OTA (Over The Air) update.

[0002] In the rest of the description, when the file to be downloaded contains instructions or the executable code of a software program, we will also refer to it as a software download.

[0003] The increasing complexity of embedded electronic functions leads to a proliferation of electronic control units (or computers) mounted on motor vehicles.

[0004] To limit the resulting diversity, it was decided to transfer the hardware diversity to the software whenever possible and to download these control units. This operation is performed using a remote tool that connects to the vehicle's diagnostic port and programs the software into the memory of the control unit(s) to ensure proper operation of the manufactured vehicle, taking into account its specific characteristics (engine, options).

[0005] Communication between the tool and the computer(s) generally uses either the CAN 500kbps technology known from the current state of the art or the Ethernet 100 Mbits / s technology being deployed in the automotive world in order to transfer the data to be programmed.

[0006] Prior art already exists methods and systems for downloading files into on-board computers in motor vehicles, such as those described for example in document FR-A-2719924. This document details the various successive steps of the procedure used during vehicle assembly or in a manufacturer's after-sales network, when correcting a service by file exchange.

[0007] However, in order to make vehicles even safer for their customers, automakers are considering the possibility of performing certain updates directly at the end customer's location, similar to what already exists for consumers with a PC or smartphone, for example. Indeed, the connectivity options present in vehicles already allow for the exchange of a great deal of information with external systems (traffic information, navigation data, data for repairs or insurance companies, etc.), and this exchange is rapidly expanding. This results in increased demand for the protection of customer data, but also for robust protection of these vehicles, given the potential for cyberattacks and the risk to road safety.Indeed, when such an attack is detected and a patch (software or a software module) is available to eliminate or mitigate the risks, the speed at which this fix can be installed is undoubtedly crucial. In this case, an over-the-air (OTA) update can save considerable time compared to a scheduled vehicle recall at an authorized or independent garage.

[0008] However, to be able to carry out this type of operation directly at the end customer's premises, several aspects must be taken into consideration which add to the complexity of this operation.

[0009] Updating the software of a vehicle's control unit can, in some cases, render the vehicle unavailable or have significant consequences for both the vehicle's occupants and its surroundings. This is why over-the-air (OTA) updates of certain control units, particularly those related to vehicle dynamics, require a mechanism called Rollback (or reverting to a previous state). This mechanism allows the system to revert to the previous software configuration if a problem is detected during the update of one or more of the vehicle's control units.

[0010] This type of problem can occur, for example, when the receiving computer tries to write a value to a corrupted memory cell, or in the case of a transmission error due, for example, to an electromagnetic field, or other cases.

[0011] This type of problem is usually detected by the receiving ECU (for example, by means of a Cyclic Redundancy Check (CRC) in the case of an erroneous reception). In this case, information will be transmitted to the master ECU to request the execution of the rollback process.

[0012] For example, document US20190057214 describes an update command device comprising a first communication unit, a second communication unit, and a command unit. The first communication unit is configured to receive patch data for each software block and initial authentication data for each software authentication block in a terminal being updated using the patch data on a per-block basis.

[0013] The command unit is configured to request the terminal to perform a rollback to restore a first block to a (M-1)th block using patch data upon receipt of an update result indicating a failure in authentication of a Mth block (M> 1).

[0014] This solution has the drawback of requiring the generation of software blocks and the verification of their integrity during the rollback procedure. This increases the risk of rollback failure.

[0015] Document EP 0959405 A2 discloses a method for updating software using two memory areas. One is active, the other passive. The new version is loaded into the passive memory area. After installation, the passive memory area becomes active, and vice versa.

[0016] US document 2016 / 0364230 A1 discloses a partial update to a computer that is embedded in a vehicle

[0017] One object of the present invention is to provide a solution for quickly restoring a software update to a vehicle computer in particular when an update file is corrupted.

[0018] The invention relates in particular to a method of installing a software update for an on-board computer of a vehicle, comprising a memory including a first area in which current software is stored, a second area and a pointer indicating to the computer which instructions to execute, said pointer indicating the first memory area, according to claim 1.

[0019] The invention has the advantage, when a test of the integrity of the received data results in a failure, of allowing the installation procedure to be interrupted without delay and the current software, which is not modified in the execution memory, to continue to be used.

[0020] In addition, a rollback step (for example, following a malfunction noticed by a user) can easily be implemented by modifying the pointer again to return to the software still present in the memory area.

[0021] The invention therefore offers a saving of 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 prior art solution.

[0022] Advantageously, the method for updating the software of a computer according to the invention further comprises the steps of: Issuing a request to write the update to the second area, Issuing a request to verify the integrity of the updated software in the second area.

[0023] Advantageously, the method of updating a computer software according to the invention further includes a step of returning to a state prior to the update, said return to a previous state including a modification of the pointer, so that it indicates the first memory area.

[0024] Advantageously, the method of updating software on a computer according to the invention further includes, following the detection of an error, a step of issuing a request to stop the installation of the update.

[0025] Advantageously, stopping the update installation involves sending a message to the driver to inform them of the installation stopping.

[0026] Advantageously, the method of updating a computer software according to the invention further includes a step of issuing a request commanding a verification of the integrity of the current software in the second area.

[0027] Advantageously, the method of updating software on a computer according to the invention further includes a step of issuing a request commanding a verification of the integrity of the updated software in the second area.

[0028] 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 process according to the invention.

[0029] The invention also relates to a vehicle characterized in that it includes a device for updating the software of a computer according to the invention.

[0030] Other features and advantages of the invention will become apparent from the description of the non-limiting embodiments of the invention below, with reference to the accompanying figures, in which: [ Fig. 1 ] schematically illustrates a system, according to a particular embodiment of the present invention; [ Fig. 2 ] schematically illustrates a calculator, according to a particular embodiment of the present invention; [ Fig. 3 ] schematically illustrates an update process, according to a particular embodiment of the present invention. Fig 4 ] illustrates an example of the successive memory states of a computer during an update.

[0031] With reference to the figure 1 , the system according to the invention comprises a vehicle 101 connected to a remote update server 102.

[0032] Vehicle 101 comprises multiple ECUs (ECU1, ECU2, ECU3), including an onboard communication unit that communicates with server 102 via a wireless connection. Typically, this wireless connection uses radio waves (3G, 4G, etc.).

[0033] The ECU1, ECU2, ECU3 computers communicate with each other via a 104 data bus (for example of CAN type).

[0034] The 102-dispatched server, for example, is a generic computer with at least one memory and one processor.

[0035] The vehicle 101 and the dismounted 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 connects via a wireless link (3G, 4G,...).

[0036] The ECU1 control unit, also called the update management control unit (or FOTA Master - for Firmware Over-The-Air), which enables the updating of ECU2 to ECU3 control units, has mechanisms capable of transferring received data files into frames expected by the recipient ECU2 and ECU3 control units to install their software. Note that the control unit acting as the FOTA master in a vehicle may or may not be the same control unit that performs the wireless communication functions.

[0037] An operator via terminal 107 can perform checks and transmit instructions remotely to vehicle 101. These instructions are transmitted to vehicle 101 via a wave which may be 4G, WIFI or any other future wireless communication technology.

[0038] The ECU1, ECU2, and ECU3 control units can be updated in a garage. Software updates in a garage follow a specific procedure (case 1 of the figure 1 During this process, the operator becomes responsible for the vehicle entrusted to them. To this end, they place the vehicle in a "safe and secure" environment before initiating the operation using a tool 106 connected to a dedicated port 108 on the vehicle 101. Once the operation is complete, they perform certain checks to ensure its proper functioning. If a problem is detected, either during the procedure or after the update, the technician will take the necessary steps to correct the issue (re-testing, part replacement, etc.) before returning the vehicle to the customer. The mechanic is therefore a crucial link in the safety chain and is also responsible for ensuring the quality of the operation performed.

[0039] During an OTA update at a client's site (case 2 of the figure 1 ), none of this is possible and it is therefore necessary to add in each calculator a mechanism allowing a return to the previous version in case of a problem.

[0040] To perform the operations described in this patent proposal, the FOTA master communicates with the target computer via the communication network available in the vehicle (e.g., CAN, Ethernet, or other). It uses a dedicated communication protocol for this purpose, such as the UDS protocol (ISO 14229 standard), commonly used for diagnostics or software downloads of on-board computers in motor vehicles.

[0041] With reference to the figure 2 The calculator 200 according to the invention comprises a microcontroller equipped with a Flash memory 201. The Flash memory 201 comprises: a first zone Z1, also called the execution zone, used to run the downloaded software, and with a size at least equal to a given size N, a second zone Z2, also called the save zone, with a size at least equal to the given size N, used as a save memory allowing the system to revert to the previous version of the software in case of a problem during installation,

[0042] The size of the 201 flash memory is therefore at least twice the given size N.

[0043] Z2 can be a separate memory module from execution memory or be part of the same memory module as an area contiguous to the first area Z1.

[0044] In the example of the figure 2 The address ranges 00000h-0FFFFh (h for hexadecimal) and 10000h-1FFFFh correspond respectively to the first Z1 and second Z2 zones. This memory segregation mechanism, implemented in the microcontroller's hardware by the manufacturer, must therefore be part of the component's native features to be available. The principle of selecting the memory zone for the software to execute is performed using a first pointer, which we will call the "Base address." It contains information in the form of a memory address that indicates whether the microcontroller should retrieve the instructions to be executed from the first Z1 or the second memory zone, Z2. For example... figure 2 This first pointer can therefore only take two values: 00000h if the software to be executed is located in the first bank, and 10000h if the software is located in the second bank. Then, using a native microcontroller process, the address of the instruction to be executed can be added to this first pointer. The resulting address, called the "memory address," allows the current instruction to be retrieved from the correct memory location.

[0045] In the following section, we will see that activating a newly installed update simply involves changing the "Base address" parameter to the base address of the area containing the updated software (version N+1). Similarly, a rollback is performed by writing the base address of the memory area containing the previous version (version N) to the "Base address".

[0046] We will now present the process according to the invention in support of the figure 3 illustrating steps in said process and the figure 4 showing an example of the implementation of said process.

[0047] In the example of the figure 4 , the calculator to be updated 200, or target calculator, has a software (version N) in its execution memory Z1.

[0048] Advantageously, before updating the target ECU, the FOTA master places ECU 200 in a programming-dedicated state (where functionality is disabled) using a reprogramming session entry request. Target ECU 200 agrees to execute this request only if safety conditions are met (e.g., vehicle stationary, drivetrain deactivated, etc.).

[0049] During a reprogramming session, the FOTA master communicates directly with the boot software of the target ECU 200. Depending on the requests sent by the FOTA master, the ECU boot software can perform various operations (writing, copying, integrity checking) on ​​one of its two available memories (execution memory ME or backup memory MS). figure 3 describes a series of actions to be performed by the FOTA master to install new software in the target ECU 200.

[0050] Before the execution of the update process according to the invention, the target computer 200 is in a first state 501, called the initial state, in which: the first area Z1 contains the current software (version N).

[0051] In a first step 311, the FOTA master sends a request to the target computer 200 to clear the second zone Z2.

[0052] In a second step, 312, the FOTA master determines whether the update corresponds to a full or partial installation of the new software. A full installation means that the update downloaded by the FOTA master includes all of the n+1 software and that the current n software does not need to be taken into account to create the new version. Conversely, a partial installation transmits only a portion of the software to be updated, which must be supplemented by the unmodified portion of the n software.

[0053] If the update corresponds to a full installation, the FOTA master sends 313 to the target ECU the update and commands its writing in the second zone Z2.

[0054] The FOTA master then sends a request to the target computer to check the integrity of the data copied into the second area, Z2. This check can be performed using a Cyclic Redundancy Check (CRC) or any other state-of-the-art method (for example, calculating a hash function to generate a "condensate" of the data content and comparing the result with a reference value previously transmitted by the FOTA master). If the memory consists of multiple data blocks, each block has its own integrity check mechanism (based on the same method or different methods).

[0055] At the end of this step the target calculator 200 is in a second state 502, in which: the first area Z1 contains the current software (version N) and the second area Z2 contains the updated software (version N+1).

[0056] The FOTA master then commands the activation 315 of the updated software (version N+1).

[0057] The following section describes the procedure steps if the update is not a full installation. The update contained in the FOTA master does not include all the data.

[0058] The FOTA master sends a request commanding the copy 313' of the current software (version N) from the first zone Z1 to the second zone Z2.

[0059] The FOTA master then sends a request to verify the integrity of the data in the backup memory Z2, which constitutes the duplicate. These two operations are triggered and monitored by a set of UDS requests exchanged between the FOTA master and the target computer, but take place internally within the target computer. If the result is negative, the FOTA master interrupts the installation, and the target computer will continue to execute the application stored in the first area Z1 after the installation attempt.

[0060] At the end of this step the target computer 200 is in a third state 503, in which: the first area Z1 contains the current software (version N) and the second area Z2 contains a copy of the current software (version N).

[0061] When the integrity test is positive, the rest of the installation includes a 316 erasure of the part (or portion) of memory that corresponds to the storage location of the update so that the latter can be written in addition to the data already present in the second area Z2 and which come from the prior copying of version N.

[0062] At the end of this step the target calculator 200 is in a third state 504, in which: the first area Z1 contains the current software (version N) and the second area Z2 contains a copy of the current software (version N) from which the portion to be updated has been removed by memory erasure.

[0063] Next, the FOTA master transmits 317 the data corresponding to the update to the target computer which will write this data into the second area Z2 in order to complete the data already present and thus build version N+1 and thus arrive at state 505.

[0064] The FOTA master commands a new 318 integrity test on the entire second zone Z2 to take into account the modification related to the newly installed portion of software.

[0065] The FOTA master then commands the activation 315 of the updated software (version N+1).

[0066] Note that regardless of the installation phase, particularly the update programming operation, if an error is detected (Flash memory programming error, negative response after several attempts), the FOTA master interrupts the installation without activating the software in the second zone (Z2). Vehicle use remains possible by continuing to run the software contained in the first zone (Z1). An error message is then displayed, indicating the installation failure to the customer, who must then take their vehicle to a garage.

[0067] If, following a successful installation, the customer detects abnormal vehicle operation, a return to the previous version (version N) is possible by performing a rollback. In the case of dual-bank memory, this simply involves reactivating the execution of the software still present in the first zone (Z1). No copying is necessary; the rollback operation consists of reassigning the execution pointer to the first zone (Z1), so that each time the ECU is powered on (vehicle start), the software that runs will be that of the first zone (Z1).

[0068] Note that in the case of a partial installation, for the sake of simplicity, only one module has been shown, but it is perfectly possible to install several modules in Flash memory, whether they are contiguous or not. The location(s) receiving the update are specified in the parameters of the erase and write requests.

[0069] The activation step 315, or the execution of a possible rollback, is carried out by simply reassigning the execution address to the memory area containing the new software (activation) or to the one containing the old version serving as backup memory (rollback) according to a mechanism known from the state of the art.

[0070] It's worth noting that the allocations of "execution memory" (or execution area) and "backup memory" (or backup area) are not fixed, since a given memory bank alternates between execution memory and backup memory with each update. Indeed, when a successful update is proven to meet its intended performance (no rollbacks triggered by the client for a certain period), the backup memory becomes available to accommodate a potential new update, and it is then the execution memory that becomes the backup memory during the installation of the new update. With each successful update, the allocations of execution memory and rollback memory are therefore reversed.

[0071] It can also be noted that, for the sake of simplicity, only the exit case related to a failure occurring during the integrity test has been represented on the figure 3The installation process is carefully monitored at each stage, particularly the memory clearing and the data transfer / writing phase from the FOTA master. If an error occurs after several attempts (for example, three), the installation process terminates, resulting in a failed update.

Claims

1. Method for installing an update of a software of an on-board computer (200) of a vehicle (100), comprising a memory (201) comprising a first zone (Z 1) in which a current software is stored, a second zone (Z 2) and a pointer indicating to the computer which instructions to execute, said pointer indicating the first memory zone (Z 1), wherein it comprises steps of: - Downloading, by an update management computer, a software to be updated or an updated software portion, the update management computer communicating with the on-board computer via a communicating network available in the vehicle, - Emission (311) of a request ordering an erasure of the second zone (Z 2), - Determination (312) whether the update is partial, and following a determination that the update is partial: - Emission (313 ') of a request ordering a copy of the current software from the first zone (Z 1) to the second zone (Z 2), - Emission (316) of a request ordering an erasure in the second memory zone (Z 2) of said software portion to be updated, - Emission (317) of a request ordering a writing of the data corresponding to the update in the second memory zone (Z 2) in order to complete the data already present, so as to obtain an updated software, and a determination consecutively that no error is detected, then: - Transmission (315) of a request ordering an activation of the updated software, said activation comprising a modification of the pointer, so that the latter indicates the second memory zone (Z 2).

2. Method for updating a software of a computer according to claim 1, wherein the updating is total: said method further comprises steps: - Sending (313) of a request ordering a writing of the update in the second zone (Z 2), - Sending (314) of a request ordering a checking of the integrity of the updated software in the second zone (Z 2).

3. Method for updating a software of a computer according to claim 1, further comprising a step of returning to a status previous the updating, said return to a previous status comprising a modification of the pointer, such that the pointer indicates the first memory zone.

4. Method for updating a software of a computer according to one of the previous claims further comprising, following an error detection, a step of sending (320) a request ordering the shutdown of the installation of the update.

5. Method for updating a software of a computer according to claim 1, wherein ordering the shutdown of the installation of the update comprises sending a message intended for the driver to inform him of the shutdown of the installation.

6. Method for updating a software of a computer according to one of the previous claims further comprising a step of sending (314) a request ordering a checking of the integrity of the current software in the second zone (Z 2).

7. Method for updating a software of a computer according to one of the previous claims further comprising a step of sending (318) a request ordering a checking of the integrity of the software updated in the second zone (Z 2).

8. Device for updating a software of a computer, said device comprising a memory associated with at least one processor configured to implement the steps of the method according to any one of claims 1 to 7.

9. Vehicle (100) comprising a device for updating a software of a computer according to the previous claim.