Method for updating operating software on a control unit

Abstract

In a method for updating operating system software on a control unit with a microcontroller connected to two memory partitions, the new operating software is written to an inactive memory partition during the update, while the previous operating software continues to run on an active memory partition. For synchronization purposes, the new operating software is only written from the inactive to the active memory partition after a test phase and within a flexible timeframe.

Description

[0001] The invention relates to a method for updating operating software on a control unit via radio. State of the art

[0002] The article "Dual Banking for Smooth SOTA Updates," published on www.pressebox.de, describes a method for updating operating software on a control unit via radio. The control unit has a microcontroller with two memory partitions, a so-called "dual-bank memory." During the update, the new operating software is written to an inactive memory partition of the dual-bank memory, while the previous operating software continues to run on an active partition. After the update, synchronization occurs by transferring the new operating software from the inactive to the active memory partition.

[0003] US patent 108 34 207 B2 discloses a system and a method for updating software in a vehicle. The operating system software is updated wirelessly as firmware over-the-air (FOTA). In the case of a microcontroller with a dual-memory system and two memory partitions, the operating system software is installed on one of the memory partitions. Disclosure of the invention

[0004] Using the method according to the invention, operating software on an electronic control unit (ECU) can be updated, particularly with the aid of a bootloader. The method relates to ECUs with a microcontroller connected to two memory partitions, which are either part of the microcontroller (dual-bank memory) or implemented as external memory partitions. During the update, the new operating software is uploaded to a first memory partition, while the previous operating software continues to run on a second memory partition. This has the advantage that the ECU can continue to operate while the operating software is being uploaded.

[0005] For synchronization, the new operating system must be transferred to the second storage partition after being installed on the first. For security reasons, the new operating system undergoes a test phase before synchronization. During this test phase, the new operating system is activated and the previous operating system is deactivated. The test phase extends over a flexible period of time. Synchronization is only performed after the test phase has elapsed and the new operating system has run successfully and without interruption or errors during the test phase. The duration of this flexible period is determined using at least one validity criterion that characterizes the trustworthiness of the new operating system.The validity criterion ensures a high level of safety and, in particular, guarantees that the new operating software is only used when its functionality and reliability are ensured.

[0006] The method according to the invention enables both a short update time and the possibility of a rollback, in which the system reverts to a previous version of the operating software that is still stored on a memory partition during the test phase. The rollback is desirable, for example, for safety reasons in case an error occurs during the test phase.

[0007] Operating software can include, for example, comfort functions or safety-related functions that run on the control unit's microcontroller and are used to control a technical unit, particularly in a vehicle. For instance, it's possible to control braking, drive, steering, or damping functions in a vehicle using operating software. However, operating software can also be operating system software that is installed on the control unit and regulates its functions.

[0008] The operating software is preferably updated wirelessly (Firmware-over-the-Air - FOTA or Software-over-the-Air - SOTA). Alternatively, it is also possible to perform the update via cable instead of wirelessly.

[0009] Several criteria can be considered as validity criteria for determining the time period until synchronization is performed. According to a first preferred embodiment, uninterrupted operation is defined as error-free operation. In this case, the validity criterion is the error-free execution of the new operating software following the update, and the duration of the flexibly adjustable time period depends on the type of error that can typically occur in the operating software in question. For example, it may be advantageous to specify a longer time period for the uninterrupted running of the new operating software for validation purposes than for less safety-critical operating software.

[0010] The type of error can also be considered. This includes errors occurring during the initialization phase of the new operating software, as well as errors that occur during a self-test. Furthermore, the error can occur during a compatibility check. A degradation of the new operating software, where only some of its functions are executable, also constitutes an error.

[0011] According to another advantageous implementation, the validity criterion is implemented as a manual prompt for synchronization. In this case, the user sets the time interval, thus determining when, assuming uninterrupted operation, synchronization and therefore the transfer of the new operating software from the first to the second storage partition will occur. This implementation has the advantage that an authorized user can force synchronization in any case, for example, for testing purposes.

[0012] According to another advantageous embodiment, the validity criterion is the elapsed time of a defined, predetermined period. In this case, a specific time period is fixed, after which synchronization is performed. This is based on the assumption that a rollback is only necessary within a relatively short period after the update is installed. If this period has elapsed without interruption, it can be assumed that a rollback is no longer required, whereupon synchronization is performed.

[0013] According to another advantageous embodiment, the validity criterion is based on a defined number of power-on cycles of the control unit. Once the defined number of power-on cycles has been reached without interruption since the last update, it can be assumed that there is no error in the new operating software. In this case, no fixed time period is specified; rather, the time period is determined variably by the number of specified power-on cycles during which the new operating software must run without interruption. Synchronization is then performed. An interruption or error is considered to be, for example, a system reset caused by the new operating software.

[0014] The aforementioned validity criteria can be combined if necessary. In this case, for safety reasons, the time period is advantageously set to the longest duration that results from any one of the different validity criteria.

[0015] Another aspect of the invention relates to a control unit, in particular a vehicle control unit, which controls a technical component in a vehicle, for example a braking system, a drive system, a steering system, an airbag system, a driver assistance system, or a comfort function such as the climate control of the vehicle interior. The control unit contains means configured to carry out the method described above. These means comprise at least one storage unit, at least one microcontroller as a processing unit, a control unit input, and a control unit output.

[0016] The invention also relates to a vehicle, for example a passenger car, equipped with a control unit as described above. The control unit controls adjustable components of a technical assembly in the vehicle.

[0017] The invention further relates to a computer program product comprising program code designed to execute the aforementioned process steps. The computer program product runs in the aforementioned control unit.

[0018] Further advantages and practical designs can be found in the further claims, the figure description and the drawing, which schematically shows a flowchart for updating operating software on a control unit.

[0019] The process flowchart refers to an electronic control unit (ECU), particularly in a vehicle, where the ECU controls, for example, a technical component such as a braking system, a drive system, a steering system, or the like. The procedure allows updated operating software to be uploaded to the ECU. The ECU is equipped with a microcontroller with a dual-bank memory, which has two memory partitions. During the update, the new operating software is uploaded to an inactive memory partition, while the previous operating software continues to run on an active partition of the dual-bank memory. After the update, a test phase is performed during which the new operating software is activated and the previous operating software is deactivated.During the test phase, which extends over a flexible period of time, the uninterrupted operation of the new operating software can be tested.

[0020] In the flowchart shown, block V1 represents a storage partition on which the existing operating software runs. This continues until block V2, in which synchronization takes place if the test is successful.

[0021] The installation of new operating software (update) takes place in step V3 on the second storage partition, which is shown in block V4. The operating software update is preferably performed wirelessly (Firmware-over-the-Air - FOTA). During the update, the previous version of the operating software continues to run in block V1.

[0022] Blocks V5 and V6 represent a test phase for the new operating software. During this phase, the previous operating software in block V1 is deactivated, and the newly installed operating software in block V4 is activated. Blocks V5 and V6 contain queries to verify uninterrupted operation, after which synchronization between the memory partitions of the dual-bank memory can be performed in blocks V2 and V7.

[0023] In each block V5 and V6, the new operating system is tested for a specific time period corresponding to the respective block, the duration of which is determined using a validity criterion. If the new operating system runs without interruption in block V5 within this specific time period, the process advances to the next block V6, and potentially to further blocks, following the "Y" branch. During each of these blocks, the new operating system is tested for uninterrupted operation for a specific time period. The total duration of the test phase is determined by the longest specific time period found in blocks V5, V6, and any further blocks. For example, if the time period in block V6 is longer than in block V5, the additional test duration in block V6 is simply the time difference between the time periods of block V6 and block V5.If, on the other hand, a shorter time span results in block V6 than in block V5, one can immediately advance to another test block or to block V7, in which the test phase is ended and the synchronization between the memory partitions V2, V7 of the dual-bank memory is carried out by copying the new operating software to the memory partition with the previous operating software.

[0024] The progression from block V5 to block V6, and potentially further intermediate blocks, and finally to block V7 for the final synchronization, occurs if there are no interruptions in each block V5 and V6. For this purpose, a check is performed in each block V5 and V6 to determine if there are no interruptions; if so, the process advances to the next block following the "yes" branch. If, however, the check indicates an error, the process advances to block V8 following the "no" branch ("N"), in which an error signal is generated and output. In this case, no synchronization occurs, and the new operating system is not copied from the storage partition containing the new operating system to the other storage partition containing the previous operating system.The existing operating software is reactivated and remains in operation (Block V2), thus ensuring continued operation despite faulty new operating software.

[0025] In blocks V5, V6, etc., various validity criteria can be applied to determine the respective time period. This concerns, for example, the error-free execution of the new operating software for a defined period, which is determined depending on the type of error that can typically occur with the operating software in question. In the case of safety-relevant operating software, for instance, a longer time period can be specified than in the case of less or non-safety-relevant operating software.

[0026] Further validity criteria, which can be queried in blocks V5, V6, or other blocks, include, for example, a defined number of control unit activation cycles. In this case, no fixed time interval is specified; instead, the time interval depends on the number of activation cycles. Furthermore, other validity criteria can include, for example, specifying a fixed time interval regardless of the type of operating software, specifying a time interval that depends on the type of operating software, or requiring manual activation after a specific time interval. In all cases, the new operating software undergoes a test run, and within the considered time interval, a query is performed to verify uninterrupted and error-free execution. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] US 108 34 207 B2

[0003] Cited non-patent literature

[0000] Dual Banking for smooth SOTA updates”, published on www.pressebox.de

[0002]

Claims

[1] Method for updating operating software on an electronic control unit (ECU), wherein the ECU has a microcontroller connected to two memory partitions, wherein during the update the new operating software is uploaded to a first memory partition while the previous operating software runs on a second memory partition, wherein during a test phase the new operating software is activated and the previous operating software is deactivated, wherein for synchronization the new operating software is subsequently transferred from the first memory partition to the second memory partition after the test phase has elapsed after a flexibly adjustable period of time, provided that the new operating software runs without interruption during the test phase, wherein the flexible period of time is determined using at least one validity criterion. [2] Method according to claim 1, characterized by, that the validity criterion is a flawless execution of the new operating software following the update, the time period depending on the type of error that can typically occur with the operating software in question. [3] Method according to claim 1 or 2, characterized by that the error occurs during a self-test. [4] Method according to any one of claims 1 to 3, characterized by that the error occurs during a compatibility check. [5] Method according to any one of claims 1 to 4, characterized by , that the error is a degradation in the functionality of the operating software. [6] Method according to any one of claims 1 to 5, characterized by that the validity criterion is a manual request for synchronization. [7] Method according to any one of claims 1 to 6, characterized by that the validity criterion is the passage of a defined period of time. [8] Method according to any one of claims 1 to 7, characterized by that the validity criterion is a defined number of power-on cycles. [9] Method according to any one of claims 1 to 8, characterized by , that the validity criterion depends on the type of operating software, whereby in the case of non-safety-relevant operating software the validity criterion is the expiry of a defined period of time. [10] Method according to any one of claims 1 to 9, characterized by that the operating software is updated via radio (Firmware-over-the-Air-FOTA). [11] Control unit, in particular vehicle control unit, comprising means configured to carry out the method according to one or more of the preceding claims. [12] Vehicle with a control unit according to claim 11. [13] Computer program product comprising program code designed to perform steps of the method according to any one of claims 1 to 10 when the computer program product runs in a control unit according to claim 11.

Images