WO2017125182A1

WO2017125182A1 - Method for updating control device software, preferably for a motor vehicle

Info

Publication number: WO2017125182A1
Application number: PCT/EP2016/077996
Authority: WO
Inventors: Alexander Vensmer; Markus Petri; Gunnar Piel; Tom Schilli; Thomas Wendel; Michael Hauser; Uwe Heller
Original assignee: Robert Bosch Gmbh
Priority date: 2016-01-20
Filing date: 2016-11-17
Publication date: 2017-07-27
Also published as: DE102016200711A1

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, 20.x) that are stored in the electrically deletable memory (14); at least one flash application (22) that is stored in the electrically deletable memory (14) updates and/or actuates at least one application (20.x), which is to be updated, while at least one additional application (20.1) continues to be executed.

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 are not available because the corresponding software is not running. 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 flash application, which ensures communication with a master and more

Applications controls in such a way that at least one further application, preferably for basic functions, which should always be executed, continues to run stably. It is a process that supports applicative flashing (called flash application in the following text).

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 must be made on the available flash partitions 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 and a Flashbootloader. The Flashbootloader is used to update all parts of the software. The application software also includes a Flash application. This flash application is capable of processing the requirements with respect to the communication, for example with a master, preferably via the diagnostic communication, and for example a

Delete operation or write data. To do this, the Flash application stops the application to be updated, replaces it (delete, write) and then restarts it, if necessary after an initialization. During this process, other application functions can continue to run.

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. 1 shows the schematic structure of the control device with flash

Application;

FIG. 2 shows a sequence diagram of the flash application,

FIG. 3 Flash phases with flash application 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 are stored. These are programs that perform certain functions that are particularly associated with a motor vehicle. It is therefore a multiplicity 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, for example, via a bus system

17 connected to other components 19. These components 19 are, for example, vehicle components which are controlled as a function of the applications 20, such as, for example, the

Central locking, appropriate terminals (ignition on / off, etc.), actuators for door control, air conditioning, etc. In the microcontroller 12 also a so-called flash bootloader 16 is included. The Flashbootloader 16 is used for deleting and / or rewriting software specific programs or applications 20 as follows. As already stated in the prior art, it has been customary in a

Updating the software of an application 20.x stop all applications 20, then update and then restart. In order to ensure that certain functionalities that are particularly important, in particular for vehicle functions, are still available during the flash operation, a flash application 22 is provided. This is also like the other applications 20 in electrically erasable

Memory 14. This flash application 22 is now able to target certain applications 20. n, 20.x or to control and / or their software or

to update associated data, while particularly important functionalities, such as application 20.1, continue to be executed. The application

20.1 is therefore not stopped by the flash application 22. The application 20.1 will not be overwritten or updated. 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 a corresponding programming command to the flash application 22 in a step 101. In a step 103, the flash application 22 stops the application 20.x to be updated. In addition, will / will be the one

Application (s) 20. n located on the same partition 40 of the electrically erasable memory 14 as the application 20.x to be updated. However, application 20.1 is not stopped because it is an important application that should continue to run. These

Application 20.1 is also not located on the same partition 40 as the application 20. x. The stop command (step 103) corresponds to the continuous arrow 34 in FIG. 3. After a corresponding acknowledgment of the application 20.x to be updated to the flash application 22, the flash application 22 reports a corresponding response to the master 23 in step

107. Thereafter, the master 23 sends a delete command to the flash application 22 in a step 109. Subsequently, corresponding blocks in the electrically erasable memory 14, which are associated with the application 20.x to be updated, are deleted. The deletion takes place by means of the flash application 22. After successful completion of the deletion, the flash application 22 sends a corresponding response to the master 23, step 1. 13. The master 23 then transmits updated data or software to the flash application 22 , Step 1 14. The Flash application 22 describes or causes the

Overwriting of the blocks to be updated of the associated application 20.x with the data transmitted by the master 23, step 1 16. After completion

Overwriting the data gives the flash application 22 a positive

Feedback to the master 23, step 1 18. Erase and override according to the steps 1 1 1, 1 16 corresponds to the dot-dashed arrow 36 in Figure 3. Then, the master 23 sends a command to the flash application 22, in a default Mode, step 120. the default mode causes the

Flash application 22, an initialization command to the updated application 20.x, step 122 to send. After initialization, the updated application 20.x gives a corresponding feedback to the flash application 22, step 124. The flash application 22 then sends a corresponding start command to the stopped applications 20.x, 20.n, step 128. This

Start command corresponds to the dashed arrow 38 in Figure 3. After the start, the launched applications 20.x, 20. n give a corresponding Feedback to the flash application 22, step 128. The flash application 22 passes this positive feedback to the master 23. The

Update process for application 20.x is now complete.

During the update, however, the base application 20.1, for example, was not stopped, but continued to run.

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 basic software 26, via which the contact between the flash application 22 and the applications to be influenced 20. n, 20.x takes place. 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 an operating system 28 and a

Driver 30, via the alternative driving options would be possible as a back-up.

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 electrically erasable memory 14. 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 performed , This has the consequence that a meaningful division of the applications 20 on the available partitions 40-43

must be made to ensure that no code is executed which resides in one of the partitions 40-43 to be programmed or updated. According to FIG. 4, the flash application 22 is now located on the first partition 41 together with a so-called basic application 20.1, which is also to be executed when updating an application 20.x to be updated updated On the other hand, application 20.x is located on a different partition, for example the zeroth partition 40.

The basic software 26 could also be stored in the first partition 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. During operation of these flash bootloaders 16, however, all applications 20 in the electrically erasable memory 14 would have to be closed, as well as the

Basic application 20.1 and the base software 26 and / or the operating system 28.

In a flash operation using the flash boot loader 16, the corresponding flash program would be executed in RAM. In particular, an update of the flash application 22 and / or the base application 20.1 is still to be made via the Flashbootloader 16 in a known manner. For this purpose, however, all applications 20, including the

Basic application 20.1 or all programs stored on partitions 40-43 are closed. The same also applies to the basic software 26 or the operating system 28. As an alternative to the variant shown by way of example shown in FIG. 4 with two flash bootloaders 16.1, 16.2, however, the provision of only a single flash boot loader 16 would be equally possible.

As described, the flash application 22 is capable of accepting the requirements relating to diagnostic communication or communication with the master 23 and / or the applications 20. As described, it is capable of starting a delete operation and / or writing data. It is also able to stop applications 20 to be replaced

Software part or the application 20 to replace (delete, write) and then start again. During this process, other important applications 20.1 can continue to be executed.

For example, within the scope of a diagnostic connection with the control unit 10, it is possible to initiate the updating of certain data. The identification of the data to be updated takes place, for example, via an identifier. After the procedure already described, the stopping of all applications 20. n, which are located on the same partition 40 as the application 20.x to be updated, is stopped. The

Basic application 20.1, however, will continue to run. Subsequently, the so-called flash data on the already described interactive Procedure downloaded between Master 23 and Flash Application 22. Subsequently, the updated applications 20.x are initialized.

Subsequently, all stopped applications 20.x, 20.n are restarted. The communication of the flash application 22 with the other applications 20 takes place using the operating system 28 and / or the basic software 26 and / or the real-time environment 24. Thus, it is expedient that these too lie on the same partition 41 as the flash application 22 ,

Further, it may be necessary for the operating system 28 more

Add operating states, such as a so-called default mode and / or a flash mode. Depending on the mode, the scheduling is influenced and the respective application 20 is started or stopped. In addition, all applications 20 from the flash partition 40 to be updated are not executed during the flash process. In addition, each application 20 must satisfy at least one simple interface, via which it is driven by the flash application 22. These commands are initialization or activation 36 and / or starting 38 and / or stopping 34 (compare steps 103 - stop, step 122 - initialization, step 126 - start).

The method with the associated device preferably finds application in the updating of software of a control device, in particular for motor vehicles, wherein it must be ensured that certain applications 20 continue to be executed during the updating of the software or further 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), the microcontroller (12) having different applications (20; 20.1, 20 n, 20.x); in the electrically erasable memory (14) are stored, can perform, characterized in that at least one flash application (22) in the electrically erasable memory (14) is stored, wherein the flash application (22) at least one applications to be updated (20.x) is updated and / or activated while at least one further application (20.1) continues to be executed.

Method according to Claim 1, characterized in that the electrically erasable memory (14) comprises a plurality of partitions (40-43), at least the application (20.x) to be updated being stored on a different partition (40) than the partition (41 ), on which the flash application (22) is stored and / or the application (20.1) still to be executed is stored.

Method according to one of the preceding claims, characterized in that the flash application (22) communicates with at least one master (23) via which the update of the application (20.x) to be updated is initiated.

Method according to one of the preceding claims, characterized in that the flash application (22) at least one application (20), preferably the application to be updated (20.x) and / or the application (20. n), on the same partition (40) lies like the application (20.x) to be updated, stops and / or replaces, preferably at least partially deletes and describes and / or starts.

Method according to one of the preceding claims, characterized in that at least one program is provided, in particular a flash bootloader (16), for updating the flash application (22) and / or for updating at least one application (20.1) which is located on the same partition (16). 41) is like the Flash application (22). Method according to one of the preceding claims, characterized in that the flash application (22), in particular using a

Basic software (26) and / or a real-time environment (24) at least one application (20; 20.1, 20. n, 20. x) stops, then updates the application to be updated (20.x) and / or subsequently at least one application (20 ; 20.1, 20. n, 20.x) and / or subsequently at least one

Application (20; 20.1, 20. n, 20.x) starts.

Method according to one of the preceding claims, characterized in that the flash application (22) stops at least one application (20. n) which lies in the same partition (40) as the application (20.x) to be updated.

Method according to one of the preceding claims, characterized in that at least the basic software (26) is stored in the electrically erasable memory (14), in particular in the same partition (41) in which the flash application (22) is stored.

Method according to one of the preceding claims, characterized in that the flash application (22) with at least one master (23) with respect to an update of at least one application (20.x) communicates, and / or that the flash application (22) at least the application (20.x) to be updated stops, and / or that the flash application (22) receives at least one delete command (109), and / or that the flash application (22) thereupon at least parts of the application to be updated (20.x) deletes, and / or that the flash application (22) from the master (23) updated data for the

updating application (20.x) receives, and / or that the flash application (22) writes the received data in the electrically writable memory (14), and / or that the flash application (22) the now updated

Application (20.x) initialized (122) and / or that the flash application (22) at least one stopped application (20.x, 20. n) starts (126).

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.