FR3099265A1 - Method and device for updating the software of an on-board computer of a vehicle, comprising an execution memory, a backup memory and a control memory - Google Patents

Abstract

The invention relates to a method for updating software for a vehicle, comprising execution (ME), backup (MS) and control (MC) memories comprising steps of: - Issuing a request controlling a writing in the control memory (MC) of at least one updated software block (B ', C'), - Sending of a request controlling a verification of said at least one updated software block ( B ', C') stored in control memory (MC), - Sending of a request commanding the copy from the execution memory (ME) to the backup memory (MS) of the plurality of blocks (A, B , C), - Sending of a request commanding the copy from the control memory (MC) to the execution memory (ME) of said at least one updated software block (B ', C'), - Sending a request controlling a check of the integrity of the software blocks (A, B ', C') of the execution memory (ME). Figure for the abstract: Figure 5

Description

Method and device for updating software of an on-board computer of a vehicle, comprising an execution memory, a backup memory and a control memory

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 update (for Over The Air).

Technology background

In the remainder of the description, when the file to be downloaded contains instructions or the executable code of software, reference will also be made to downloading software.

The increasing complexity of the on-board electronic function leads to a proliferation of electronic boxes (or computers) mounted on motor vehicles.

In order to limit the resulting diversity, it was decided to transfer the hardware diversity to the software whenever possible and to download these computers. The operation is carried out using an off-board tool which connects to the vehicle's diagnostic socket and allows the software to be programmed in the memory of the computer(s) which ensures correct operation of the vehicle produced, taking into account the characteristics (engine, options) unique to this vehicle.

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

Methods and systems for downloading files into computers on board motor vehicles are already known in the state of the art, such as those described for example in the document FR-A-2719924. This document details the different successive stages of the procedure used during the assembly of vehicles or in the after-sales network of a manufacturer, during the correction of a service by file exchange.

However, with the aim of making vehicles ever safer for their customers, car manufacturers are planning to be able to carry out certain updates directly at the end customer, similar to what already exists in the consumer field for a PC. or a smartphone for example. In fact, the means of connectivity present in the vehicles already make it possible to exchange a great deal of information with the outside world (traffic information, navigation information, data for repairs or for insurers, etc.) and these exchanges are in full swing. expansion. This results in an increased demand for the protection of customer data, but also for significant protection of these vehicles given the possibilities of cyber-attack and the risk to road safety. Indeed, upon detection of an attack of this type and the availability of a corrective "patch" (software or software module) capable of removing or reducing the risks, the speed at which this fix can be installed is undoubtedly of paramount importance. In this case, an OTA update can save a lot of time compared to an organized recall of vehicles in the garage of the approved or independent network.

To be able to carry out this type of operation directly with the end customer, it is nevertheless necessary to take into consideration several aspects which add to the complexity of this operation.

Updating the software of an automobile computer can in some cases make it unavailable or even have major consequences for both the occupants of the vehicle and its environment. This is the reason why the OTA update of certain ECUs and in particular those associated with vehicle dynamics require a mechanism called Rollback (or backtracking, or even returning to a previous state) which makes it possible to return to the previous software configuration in the event of the detection of a problem occurring during the update of the software of one or more computers of the vehicle.

This type of problem can occur, for example, in the case where the destination computer tries to write a value to a corrupted memory cell, for example, or in the case of a transmission error due, for example, to an electromagnetic field, or still other cases.

Such a type of problem is generally detected by the destination computer (for example by means of a verification of a CRC Cyclic Redoundancy Check in the case of an erroneous reception). In this case, information will be transmitted to the master computer to request the execution of the rollback process.

For example, 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 a terminal updated using the patch data on a per block.

The control unit is configured to request the terminal to perform a rollback for restoring 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).

Despite all these precautions and these verification systems, it is still possible that certain cases of malfunction cannot be detected after the OTA update.

An object of the present invention is to propose a solution for quickly restoring a software update to a previous state of a computer of a vehicle in particular 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 are stored a plurality of blocks (A, B, C) of current software, a backup memory (MS) and a control memory (MC), characterized in that it comprises steps of:

- Emission (312) of a request commanding a writing in control memory (MC) of at least one updated software block (B', C'),

- Emission (313) of a request ordering a verification of said at least one updated software block (B′, C′) stored in the control memory (MC),

- Emission (322) of a request ordering the copy from the execution memory (ME) to the backup memory (MS) of the plurality of blocks (A, B, C) of the current software,

- Emission (332) of a request ordering the copy (332) from the control memory (MC) to the execution memory (ME) of said at least one updated software block (B', C'),

- Emission (333) of a request ordering a verification of the integrity of the software blocks (A,B',C') of the execution memory (ME),

And if an error is detected then:

- Emission (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 software blocks current (A, B, C).

The advantage of the invention, when a test of the integrity of the data received ends in failure, is that it allows the installation procedure to be interrupted without delay and the initial software to be restarted immediately because the execution memory (Executing Memory) has not yet been modified.

The invention therefore offers a time saving but also enhanced security insofar as it eliminates additional risks of data corruption inevitably linked to the successive operations of generating blocks of software common in the solutions of the state of the art.

By using an additional verification memory, the probability of having to execute a Rollback is lower than with other known solutions in the state of the art. This considerably decreases the risk of failure when performing the return to the n-1 configuration of the vehicle.

Advantageously, the method for updating software of a computer according to the invention further comprises a step of sending a request ordering said computer to erase the control memory, prior to the sending of the request commanding the writing in control memory of at least one updated block of software.

Advantageously, the method for updating computer software according to the invention further comprises a step of sending a request ordering said computer to erase the backup memory, prior to sending the request controlling the copy from the execution memory to the backup memory of the plurality of blocks of the current software.

Advantageously, the method for updating software of a computer according to the invention further comprises a step of sending a request ordering said computer to check the integrity of the plurality of blocks of the current software in the backup memory.

Advantageously, the method for updating software of a computer according to the invention further comprises a step of sending a request ordering said computer to erase from the execution memory the software blocks to be updated. up to date.

Advantageously, the step of returning to a state prior to the update further comprises a prior 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 execution memory.

Advantageously, the step of returning to a state prior to the update further comprises a step of stopping the update comprising a command to return to a state prior to the update to other computers affected 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 software of a computer according to the invention.

Brief description of figures

Other characteristics and advantages of the invention will emerge from the description of the non-limiting embodiments of the invention below, with reference to the appended figures, in which:

schematically illustrates a system, according to a particular embodiment of the present invention;

schematically illustrates a computer, according to a particular embodiment of the present invention;

schematically illustrates an updating method, according to a particular embodiment of the present invention.

schematically illustrates sub-steps of a step of resetting to a state prior to an update, according to a particular embodiment of the present invention.

illustrates an example of the successive states of a computer's memories during an update.

DESCRIPTION OF EXAMPLES OF EMBODIMENT OF THE INVENTION

The subject of the invention is in particular a method allowing the updating, via a wired communication or a wireless communication, of an on-board computer equipped with an external memory of double capacity of the execution memory. In the event of failure during the software update operation, 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.

Referring to Figure 1, 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. Typically, the wireless connection or link is a connection by radio waves (3G, 4G, etc.).

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

The off-board server 102 is for example a generic computer comprising at least one memory and one processor.

The vehicle 101 and the off-board server 102 communicate via an extended 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,…).

The ECU1 computer also called update management computer (or FOTA Master – for Full Over-The-Air) which allows the updating of the ECU2 to ECU3 computers, has for this purpose mechanisms capable of transferring the files from data received in frames expected by the destination computers ECU2, ECU3 to install their software. Note that the computer playing the role of FOTA master in a vehicle may or may not be the same computer as the one with the wireless communication functions.

An operator via a terminal 107 can carry out the checks and transmits instructions remotely 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 to come.

The ECU1, ECU2, ECU3 computers can be updated in a garage. Updating software in a garage responds to a specific procedure (case 1 in figure 1) during which the operator becomes responsible for the vehicle entrusted to him. In this respect, he 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 finished, he carries out certain checks in order to to ensure its proper functioning. In the event of a problem being detected, either during 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 customer. . The mechanic 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 (case 2 in figure 1), none of this is possible and it is therefore necessary to add in each computer a mechanism making it possible to return to the previous version in the event of issue.

To carry out the operations described in this patent proposal, the FOTA master communicates with the target computer via the communication network available in the vehicle (for example CAN, Ethernet or other). For this, it uses a dedicated communication protocol, such as, for example, the UDS protocol (ISO14229 standard) commonly used to carry out diagnostics or to download the software of on-board computers in motor vehicles.

Referring to Figure 2, the computer 200 according to the invention comprises:

- a microcontroller 201 comprising provided with a Flash memory ME, of a given size N, used to execute the downloaded software and named 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 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 wired or OTA method even before launching any modification of the content execution memory.

According to the first variant of the invention, 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 by a 206 SPI (Serial Peripheral Interface) bus, but it could be another data link.

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 carried out within a reasonable time, seen by the customer. Advantageously, the data exchanged between the internal memory and the external memory are encrypted, so as to improve the security of the update.

According to a second variant of the invention, 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 one memory to another. In addition, this variant makes it possible to dispense with additional components used to manage communication with an external memory. On the other hand, this variant involves using a microcontroller with an internal memory of a size at least twice the maximum size of the software.

We will now present the method according to the invention in support of Figure 3, illustrating steps of said method and Figure 5, showing an example of implementation of said method.

In the example of FIG. 5, the computer to be updated 200, or target computer, has software in its execution memory ME. This software is made up 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 target computer 200 (via a wired communication or a wireless communication) and are placed in the control memory MC in order to verify their integrity. This makes it possible not to alter the software currently in the ME execution memory.

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 blocks of data 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, called Rollback, executed in the event of installation failure during which the entire content of the backup memory MS is copied into the execution memory ME in order to return to the initial software.

Advantageously, before the update of the target computer, 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 agrees to execute this request only if the security conditions are met (eg: vehicle stationary, traction chain deactivated, etc.)

In a reprogramming session, the FOTA master communicates directly with the boot software of the target computer 200. Depending on the requests sent by the FOTA master, the computer boot software can perform various operations (write, copy, integrity check) on one of the three memories it has (execution memory ME, backup memory MS or control memory MC). Figure 3 describes a succession of actions to be performed by the FOTA master to install new software in the target computer 200.

Before the execution of the update method according to the invention, 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.

Advantageously, the first phase 310 comprises the following steps:

In a first step 311, the FOTA master sends a request to ask the target computer to erase the control memory MC.

In a second step 312, the FOTA master writes the data received from the remote server (via wired or wireless communication) into the control memory MC of the target computer 200 using dedicated requests. This operation is repeated for each block of data to be updated.

In the embodiment according to which the control memory MC is in an external memory 205, it is the boot software of the target computer which manages transparently for the FOTA master the exchanges carried out on the communication bus 206 (for example SPI type) between the microcontroller 201 and its external memory 205.

In a third step 313, 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 verification can be carried out using a CRC Cyclic Redoundancy Check or any other known state-of-the-art method (example: calculation, using a hash function, of a "condensate » of the content of the data downloaded into the target computer, and comparison of the result with a reference value transmitted beforehand by the FOTA master). If the memory is composed of several data blocks, each block has its own integrity checking mechanism (based on the same method or different methods).

In the event of failure during one of the first 311 , second 312 or third 313 steps, the FOTA master receives a negative response from the target computer 200. In this case, the FOTA master abandons the normal running of the procedure. installation to execute a procedure for stopping the installation 314.

At the end of the first phase 310, 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 update file 510.

Advantageously, the second phase 320 includes the following steps.

In a fourth step 321, the FOTA master sends a request to ask the computer 200 to erase the entire backup memory MS.

In a fifth step 322, 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.

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

In case of failure during one of the fourth 321, fifth 322 or sixth 323 step, the target computer 200 returns a negative response to the FOTA master. The FOTA master then executes the installation shutdown procedure 314.

At the end of the second phase 320, the target computer 200 is in a third state 503 in which: the execution memory ME comprises the three blocks of 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 current software blocks A, B, C

According to a feature of the invention, the third phase 330 is executed only 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 likely to be modified subsequently. For this, it can for example store a variable (or flag) in non-volatile memory, which will be tested each time computer 200 is initialized to check whether the application software loaded in execution memory ME can be executed or not.

Advantageously, the third phase 330 comprises the following steps.

In a seventh step 331, the FOTA master sends as many requests as necessary to ask the target computer 200 to erase all the blocks of data 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.

In an eighth step 332, 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.

In a ninth step 333, the FOTA master sends as many requests as necessary to ask the target computer to check the data integrity of each data block updated in the execution memory ME. This verification is advantageously carried out by the same methods as in the third step 313.

At the end of the third phase 330, the target computer is in a fourth state 504 in which: the execution memory ME comprises a block of current software A, and two blocks of updated software 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 current software A, B, C

In the event of failure during one of the seventh 331, eighth 332 or ninth 333 steps, the target computer 200 returns a negative response to the FOTA master. The FOTA master then executes the operation to return to a state prior to the update (Rollback).

If the third phase 333 has been executed correctly, then the computer boot software declares the application software valid (and therefore modifies the corresponding variable). The newly downloaded software will therefore be automatically executed by the computer 200 during its next reset caused either by a request from the FOTA master, or by a power cut and then restart.

The procedure for stopping the installation 314 is executed only in the event of failure of the installation before the third phase 330.

Two cases are to be distinguished according to 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 several ECUs 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. In the event of abandonment, as the content of the execution memory ME has not yet been modified at this stage of the operations, the computer 200 is operational from the next reset, without a Rollback operation.

If several computers are affected by the update, in particular when consistency must be ensured between the software versions of the vehicle's different computers:

• If at the time of the error, only the target computer 200 has started its update, then the FOTA master proceeds as for the first case (sending a message to the operator and no rollback if aborted),
• If at the time of the error, other computers in the vehicle have already been updated, the FOTA master triggers the Rollback process in all the vehicle computers that require it until the state prior to the update is found in the other computers of the vehicle.

As indicated previously, in the event of a failure during one of the seventh 331 , eighth 332 or ninth 333 steps, the FOTA master then executes the operation to return to a state prior to the update (Rollback).

Referring to Figure 4, the rollback step 400 includes the following sub-steps.

Advantageously, the FOTA master transmits 401 a message to the HMI 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 the entire execution memory ME.

The FOTA master sends 403 a request to ask the target computer 200 to copy the entire content 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.

At the end of the rollback operation, the computer can again operate with its initial software after its reinitialization caused either by a request from the FOTA master, or by a power cut and then restart.

At the end of the rollback operation 400, the target computer is in a fifth state 505 in which: the execution memory ME comprises the three blocks of 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 current software blocks A, B, C.

Claims (9)

Method for updating software of an on-board computer of a vehicle, comprising an execution memory (ME) in which are stored a plurality of blocks (A, B, C) of current software, a backup memory (MS) and a control memory (MC), characterized in that it comprises steps of:
- Emission (312) of a request commanding a writing in control memory (MC) of at least one updated software block (B', C'),
Emission (313) of a request ordering a verification of said at least one updated software block (B', C') stored in the control memory (MC),
Emission (322) of a request controlling the copy from the execution memory (ME) to the backup memory (MS) of the plurality of blocks (A, B, C) of the current software,
Emission (332) of a request ordering the copy (332) from the control memory (MC) to the execution memory (ME) of said at least one updated software block (B', C'),
Emission (333) of a request ordering a verification of the integrity of the software blocks (A, B', C') of the execution memory (ME),
And if an error is detected then:
Emission (400) of a request commanding a return to a state prior to 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). Method for updating computer software according to claim 1, further comprising a step of sending (311) a request ordering said computer to erase the control memory (MC), prior to the transmission (312) of the request commanding the writing in the control memory (MC) of at least one updated block of software (B', C'). Method for updating computer software according to one of the preceding claims, further comprising a step of sending (321) a request ordering said computer to erase the backup memory (MS), prior to the transmission (322) of the request controlling the copy from the execution memory (ME) to the backup memory (MS) of the plurality of blocks of the current software (A, B, C). Method for updating computer software according to one of the preceding claims, further comprising a step of sending (323) a request ordering said computer to verify the integrity of the plurality of blocks of the current software (A, B, C) in the backup memory (MS). Method for updating computer software according to one of the preceding claims, further comprising a step of sending (331) a request ordering said computer to erase from the execution memory (ME ) the software blocks to be updated (B, C). Method for updating computer software according to one of the preceding claims, in which the step of returning to a state prior to the update further comprises a prior step of erasing (402) the execution memory of the computer and a verification step (404) of the integrity of the plurality of blocks of current software (A, B, C) in the execution memory (ME). Method for updating computer software according to one of the preceding claims, in which the step of returning to a state prior to the update further comprises a step of stopping the update ( 314) comprising a command to return to a state preceding the update to other computers concerned by said update. 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 any one of Claims 1 to 7. Vehicle characterized in that it comprises a computer software update device according to the preceding claim.