WO2017125181A1 - Method for updating control device software, preferably for a motor vehicle - Google Patents

Abstract

The invention relates to a method for updating software of a control device (10), in particular for motor vehicles, the control device (10) comprising at least one microcontroller (12) which includes at least one electrically deletable memory (14) and can execute different applications (20; 20.1, 20.n); at least one program (16), in particular a flash bootloader, is provided for at least partially deleting and writing an electrically deletable memory (14), said program (16) executing at least parts of an application (20; 20.1, 20.n) while updating at least one application (20.x).

Description

 Description title

 Method for updating software of a control unit, preferably for a motor vehicle

State of the art

The present invention relates to a method for updating software of a control device, preferably for a motor vehicle, according to the preamble of the independent claim.

A generic method is known for example from WO 2005/004160 A2. In order to carry out a software update of a control unit by means of a flash programming of a multi-segment flash memory of the control unit via a serial interface, a request to be made to the flash programming is defined, a sequence of the flash programming by states and transitions of the Software-defined state machines specified and availability, security and

Reliability requirements of each state and each transition of the state machine checked.

Automated electronic control units (ECUs) in automobiles often have the ability to update the software of the ECU or parts of this software. In modern microcontrollers (μθ), this is usually done by erasing and rewriting an electrically erasable memory (flash memory). This so-called flashing is usually done by a special software called flashloader or flashbootloader (FBL). Many car manufacturers define an update process that accurately describes in which order different diagnostic functions are to be performed to perform a software update. For the

Diagnostic communication uses a specific diagnostic protocol. For reprogramming the software finds a change in the so-called Programming mode instead. This mode change involves that

Application software is terminated and on the microcontroller only the Flashbootloader is running. This in turn will help with the help of

Diagnostic communication is used, for example, to perform a clear memory and to transfer new software and flash.

While the Flashbootloader is running, there are complex ones

ECU functions or applications not available because the

appropriate software or application is not executed. During the flash process, even if only parts of the software are updated, no additional application functions can be executed because the flashbootloader is unable to do so. Due to the distribution of software functions to different ECUs and the requirement to be able to update software parts not only in the workshop, but also over radio links over distances, there is a desire

To replace software parts without sacrificing other applications during the time of the update.

Disclosure of the invention

The inventive method according to the features of the independent claim has the advantage that, for example, during an update of an air conditioning function at least one important vehicle function such as the function of central locking or terminal control can be maintained. In addition, memory does not have to be stored redundantly.

This object is achieved according to the invention with the aid of a special program, a so-called flash bootloader, which is able to

Software parts of an application to execute or a corresponding

 Application while updating other applications. So it's a Flashbootloader with the ability to

Execute application software.

Preferably, the electrically writable memory (flash memory) is divided into blocks. A block is the smallest, erasable unit. There are several blocks in one partition and all memory is usually there several partitions. In the solutions described, the problem is that the blocks of a partition can not be accessed (execute code, read data), while within this partition an Erase or. Delete operation or a write operation is performed. This has the consequence that a sensible division of software or. Application functions on the available flash partitions must be made to ensure that no code is executed, which lies in one of the partitions to be programmed.

As before, the basic software consists of an application software or application and a Flashbootloader. The Flashbootloader is used to update all parts of the software at once. In addition, the Flashbootloader is able to exchange parts of the application software while running other parts of the application (s). For this, the Flashbootloader needs to know the dependencies and the exact location in the memory of the applications to be executed. This is made possible, for example, by administrative data in the memory, in which, for example, function pointers are deposited that point to the applications to be executed. When creating this administrative data (for example, during the so-called build process), all dependencies must be known so that all

necessary functions are part of the administrative data.

Further expedient developments emerge from further dependent claims and the description.

Brief description of the drawings

Hereinafter, an embodiment of the invention will be described in detail with reference to the accompanying drawings. Showing:

FIG. 1 shows the schematic structure of the control device with partitioning including administrative data,

FIG. 2 is a sequence diagram of the flash boot loader with support for applications; Figure 3 is a schematic representation of two flash phases with

Flashbootloader as well

FIG. 4 shows an exemplary partitioning of the electrically erasable

 Memory.

Embodiment of the invention

A control unit 10 comprises at least one microcontroller 12. In the

Microcontroller 12 is at least one electrically erasable memory 14

intended. In the electrically erasable memory 14 applications 20, 20.1, 20.n are stored. These are programs that perform certain functions that are particularly associated with a motor vehicle. So it is a variety of applications 20.1, 20.n, 20.x such as a program for a central locking, a

 Terminal control, a door control, a heating control, a

Immobilizer or similar. The corresponding applications 20 run in the control unit 10. The control unit 10 is connected, for example via a bus system 17 with other components 19. These components are, for example, vehicle components, which depend on the

Applications 20 are controlled such as the

Central locking, corresponding terminals (ignition on / off, etc.), actuators for door control, air conditioning, etc. In the microcontroller 12, a program 16 for at least partially deleting and writing the electrically erasable memory 14 is also provided, hereinafter referred to as flash bootloader 16. The Flashbootloader 16 is used for deleting and / or new

Describe software specific programs as outlined below. In addition, a basic software 26, an operating system 28 and a driver 30 (CDD Complex Device Driver) are stored in the electrically erasable memory 14.

As stated in the prior art, it has hitherto been customary to stop all applications 20 when updating the software of an application 20.x, then update it and then start it again. To ensure that certain, in particular for vehicle functions important

Functionalities continue to be available during the flash process, a specially designed Flashbootloader 16 is provided. This is also like the other applications 20 in electrically erasable memory 14. The flash boot loader 16 is now able to selectively update certain applications 20.x or the associated software, associated data, etc., while preferably particularly important application 20.1, 20 . n, continue to be executed. For this purpose, management data 33 are now arranged in the electrically erasable memory 14. This management data 33 enables the flash boot loader 16 to recognize the dependencies and the exact location in the memory 14 of the applications 20 to be executed. For this purpose, for example, 33 function pointers are stored in the administration data, which point to the applications 20 or software of the applications 20 to be executed.

For example, in the form of tables, these dependencies are known after creation of the complete program and mapped in the management data 33. Here, 20 associated management data 33 are preferably stored on the electrically erasable memory 14 for each application. These management data 33 are also generated for the base software 26 and / or the operating system 28 and / or the driver 30 and stored in the electrically erasable memory 14.

FIG. 2 shows by way of example the course of the updating of a

updating application 20.x. A master 23 for the flash process sends in a step 101 a corresponding session change command to an application 20, preferably to such an application 20, which usually handles the diagnostic communication. This command requires a change of the operating mode. The application 20 starts the flash boot loader 16, possibly as part of a restart, step 103. The flash boot loader 16 receives the corresponding restart command of the application 20. The flash boot loader 16 returns its operational readiness to the master 23 in a step 105. Thereafter, a program sequence 106 is executed. Part of this program sequence 106 is the communication of the Flashbootloaders 16 to another application 20.1, 20, 20 n, this further, step 107. This is done by resorting to the associated management data 33, in which the corresponding program sequences are stored as described. The execution of the function of the application 20 by the flash boot loader 16 is performed cyclically. In addition, certain will continue below

described functions such as clearing the memory (step

1 1 1), describe the memory (step 125) and further executed. While At this time, the functions of the application 20 must continue to be executed by the flash boot loader 16.

Optionally, a response of the application 20 to the

Flashbootloader 16. The master 23 then sends a delete command to the

Flashbootloader 16, step 109. The Flashbootloader executes the

Delete the application 20.x or parts of the application 20.x to be updated, step 1 1 1. In parallel, program sequence 1 13 will continue

As described in connection with program sequence 106, the execution of the application 20.1, 20 which is still to be executed includes execution of corresponding communication between the flash boot loader 16 and the corresponding application 20.

After successful deletion of the application 20.x to be updated, the flash boot loader 16 returns a positive feedback to the master 23.

 Furthermore, a program sequence 1 19 is executed which continues to carry out the desired application 20, optionally with communication between the flash boot loader 16 and the application 20, step 121 or by resorting to the corresponding administration data 33. The master 23 then transmits the data to be stored to the Flashbootloader 16, step 123.

The Flashbootloader 16 writes the transmitted data for the

updating application 20.x into the electrically erasable memory 14, step 125. This is followed by the next program sequence 127, in which the transfer of the function to the application 20 takes place and furthermore the

Applications 20 are executed. For this the Flashbootloader communicates

16 with the application 20, step 129. Optionally, the application 20 receives a positive response to the flash boot loader 16. After receiving the feedback, the flash boot loader 16 gives a corresponding positive

Feedback to the master 23, step 131. Thereupon, the master 23 causes a change of the operating mode, for example, in the default mode, step

133. For this purpose, the master 23 sends a corresponding command to the

Flash boot loader 16, step 133. Thereupon, the flash boot loader 16 sends a corresponding command in step 135 to the applications 20, which causes a start of the applications 20. Thereafter, the application 20 returns a response signal to the master 23, step 137. Furthermore, the application 20 itself executes the corresponding application software, step 139. The master 23 can be, for example, a diagnostic tester that is used in the workshop. Alternatively, however, it could also be other control devices that record wirelessly with the control unit 10, for example.

The exemplary embodiment according to FIG. 3 clarifies the steps already explained in connection with FIG. In addition, Figure 3 shows schematically the different hardware or. Software layers. A corresponding

Hardware 32 includes, for example, the microcontroller 12 with electrically erasable memory 14. It runs a base software 26, via which the execution using the Flashbootloaders 16 of the applications 20. n, 20.1 takes place, optionally via the driver 30. In addition, a

Real-time environment 24 is provided, on which the applications 20 can be operated in quasi real-time. Schematically represented are still a

Operating system 28 and the driver 30, via the alternative

 Control options as back-up would be possible. The continuous arrows 35 symbolize which of the components shown are executed. Thus, the flash boot loader 16 causes the basic software 26 to be executed. For the base software 26, not all shares need to be executed. If appropriate, it may also be possible via the management data 33 to control that only a part or parts of the basic software 26 are executed.

Furthermore, the application 20.1 and the application 20.n are also executed. This is done by resorting to the indicated in Figure 1 management data 33, the corresponding sequence of execution of the corresponding

Make program parts available to the Flashbootloader 16. in the

Embodiment according to Figure 3, the application 20.x is to be updated. During the update, however, applications 20.1 and 20.n should continue to run. The update is in the lower image of the figure

As already described in connection with FIG. 2, the updating of the application 20.x and at least partial execution of the communication with the master 23 by the flash boot loader 16 takes place. The flash boot loader 16 furthermore controls the updating of the application 20. x. The Flashbootloader 16 continues to take over the

 Execution of the available during the update

Applications 20.1, 20. n. FIG. 4 shows, by way of example, the structure and assignment of the electrically erasable memory 14. In this example, four partitions 40, 41, 42, 43 are provided, a plurality of blocks 45 are located in one partition. A block 45 is the smallest erasable unit of the electrically erasable memory 14. Auf

Blocks 45 of a partition 40-43 can not be accessed (execute code, read data) if during this partition 40-43 an erase or write operation is executed. This has the consequence that a meaningful division of the applications 20 with associated management data 33 must be made to the available partitions 40-43 to ensure that no code is executed in one of the partitions 40-43 to be programmed or updated lies. Exchangeability of individual software components or applications 20, while other applications 20 are executed, depends on the distribution of the software components or applications.

Applications 20 on the individual partitions 40-43. Software shares or

Applications 20 residing in equal partitions 40-43 can not be executed while an update is performed in that partition. With reference to FIG. 3, an update of the application 20.x can thus be carried out with simultaneous execution of the further applications 20 1, 20. N, since these are arranged in different partitions 40, 41.

By way of example, two flash bootloaders 16, 16.1, 16.2, preferably on different partitions, could also be located on the partitions 40, 41. As an alternative to the variant with two Flashbootloadern 16.1, 16.2, however, the provision of only a single Flashbootloaders 16 would be equally possible. Of the

Flash boot loader 16 could also be located outside of electrically erasable memory 14.

As described, the flash boot loader 16 is capable of handling the requirements for diagnostic communication with the master 23 and / or the applications 20. As described, it is capable of starting a delete operation or writing data. He is also able to stop applications 20 to replace the software part to be replaced or the application 20 (delete, write) and then start again. Furthermore, the Flashbootloader 16 is capable of other applications

20.1, 20. n execute. This is done as described with reference to the respective administrative data 33 to the correct sequence or program parts of the Applications 20 to use, which might otherwise be managed by the operating system 28.

The method with the associated device preferably finds application in the updating of software of a control device, in particular for

Motor vehicles, while ensuring that certain applications 20 continue to run during the update of the software or other applications. This update could either be via a

Diagnostic tester example, in the workshop or wirelessly be initiated by a remote control function remotely as the master 23.

Claims

claims Method for updating software of a control unit (10), in particular for motor vehicles, wherein the control device (10) comprises at least one microcontroller (12) with at least one electrically erasable memory (14), wherein the microcontroller (12) has different application (20; 20.1, 20. n), wherein at least one program (16), in particular a flashbootloader, is provided for the at least partial erasure and writing of an electrically erasable memory (14), characterized in that the program (16) comprises at least parts of an application (20, 20.1, 20, n) while the program (16) is updating at least one application (20.x). Method according to one of the preceding claims, characterized in that at least management data (33) are provided for at least one application (20) to which the program (16) accesses at least one application (20, 20.1, 20 n). Method according to one of the preceding claims, characterized in that the management data (33) a position at least parts of the application (20) and / or a dependency at least parts of the application (20) in the electrically erasable memory (14) and / or the sequence at least Specify parts of the application (20) to be executed. Method according to one of the preceding claims, characterized in that as administration data (33) at least one function pointer is used which points to the application (20) to be executed or parts of the application (20) to be executed. Method according to one of the preceding claims, characterized in that the program (16) communicates with at least one master (23) with respect to an update of at least one application (20.x), and / or that the program (16) at least the application to be updated (20.x) stops, and / or that the program (16) receives at least one delete command, and / or that the program (16) thereupon at least parts of the updating application (20.x), and / or that the program (16) updates updated data from the master (23) for the application (20.x) to be updated. receives, and / or that the program (16) writes the received data in the electrically writable memory (14), and / or that the program (16) starts at least one stopped application (20.x,). 6. The method according to any one of the preceding claims, characterized in that the electrically erasable memory (14) comprises a plurality of partitions (40-43), wherein at least the application to be updated (20. x) is stored on another partition (40) the partition (41) on which at least one further application to be executed (20.1, 20. n) is located. 7. The method according to any one of the preceding claims, characterized in that the application to be updated (20) with at least one master (23) communicates, via which the update of the application to be updated (20) is initiated. 8. The method according to any one of the preceding claims, characterized in that the program (16) of at least one application (20) receives a command to start the program (16). 9. The method according to any one of the preceding claims, characterized in that for a basic software (26) and / or an operating system (28) and / or a driver (30) associated management data (33) in particular on the electrically erasable memory (14) are deposited , 10. Computer program, characterized in that the computer program is set up for a method according to one of claims 1 to 9  perform. 1 1. Computer program, characterized in that the computer program is set up for a method according to one of claims 1 to 9  perform. 12. An electrical storage medium with a computer program according to claim 1 1. 13. Control unit, which is adapted to a method according to one of  Perform claims 1 to 9.