METHOD FOR UPDATING A SOFTWARE COMPONENT ON A MICROCONTROLLER, UPDATE SYSTEM AND VEHICLE

Description

[0001] The invention relates to a method for updating a software component on a microcontroller according to the preamble of claim 1, an update system suitable for carrying out the method according to the preamble of claim 8 and a vehicle with such an update system.

[0002] Microcontrollers are used in a wide variety of technical fields to perform various tasks. For example, microcontrollers can be integrated as embedded systems in household appliances such as washing machines or in vehicles such as cars to perform control functions. Furthermore, microcontrollers can be embedded in higher-level computer systems, such as network devices like switches.

[0003] It may be necessary to update a software component of a microcontroller. The microcontroller's non-volatile memory can be divided into a primary partition and a backup partition. The primary partition can contain firmware, which is initialized by a bootloader to boot the microcontroller. A copy of the firmware is stored in the backup partition so that, should the firmware in the primary partition become corrupted, the microcontroller can be booted from the backup partition. To detect faulty firmware in the primary partition, the bootloader performs a hash-based integrity check of the primary partition's memory contents. For this, a hash value is generated from the program code stored in the primary partition and compared to a reference hash value. If both hash values ​​match, this means that the firmware program code corresponds to the intended state.If the two hash values ​​differ, this means that the firmware's program code is corrupted. In this case, the bootloader accesses the backup partition to boot. The bootloader's program code itself is typically unchangeable, also known as "hardcoded." Therefore, the boot process cannot be customized to individual needs.

[0004] Furthermore, microcontrollers are known in which the primary and backup partitions of the non-volatile memory are each subdivided into several logical blocks. The firmware can be stored in the first logical block of each partition, and the program code of an additional program, such as the rule set for a firewall, in a second logical block. It may be necessary for the firmware to access the program code of the additional program for it to function correctly.

[0005] The software components of a microcontroller are updated block by block. First, the program code of the first logical block is replaced or modified, followed by the program code of the second logical block, and so on. During the software update process, unexpected errors can occur, such as the microcontroller shutting down or restarting, for example, due to a power supply failure. This can result in the data written to the respective logical blocks being corrupted or incomplete, thus corrupting the memory content.

[0006] This can lead to a specific problem scenario. The memory contents of the first logical block might be successfully updated, whereas, for example due to a power outage, the memory contents of only the second logical block become corrupted. The bootloader's hash-based integrity check is applied exclusively to the firmware stored in the first logical block. Since the firmware corresponds to the intended state, the integrity check also passes. However, the program code in the second logical block is faulty. This can cause the microcontroller's boot process to become trapped in an endless boot loop because the firmware cannot be correctly initialized, and the bootloader does not switch to the backup partition. This renders the microcontroller unusable, also known as "bricked." This must be avoided.

[0007] From EP 2 339 494 A1, an automated, modular, and secure update method for boot firmware is known. The document describes the use of a firmware divided into modules, instead of a monolithic firmware. During the update process, individual firmware modules can be updated. If an error occurs, a backup copy of the firmware can be read from memory and used for the boot process. The bootable system in this way could be, for example, a supercomputer, minicomputer, server, PC, laptop, tablet computer, smartphone, or similar device.

[0008] CN 116 755 737 A discloses a method for over-the-air (OTA) software updates for vehicles, in which the vehicle's memory is pre-divided into a first and a second partition. During an upgrade, the OTA application determines a valid partition from these two, which is then used to perform the software update.

[0009] EP 4 141 651 A1 describes a method for updating operating system data on an electronic device. After startup, the device loads data from a base partition, a first static partition, and a dynamic partition to run an initial operating system. A patch package is then obtained, and the second static partition is updated based on it. A reboot then occurs, with the boot sequence starting from the second static partition. Finally, data is loaded from the base partition, the second static partition, and the dynamic partition to run the operating system with the updated static data.

[0010] The present invention is based on the objective of providing an improved method for updating a software component on a microcontroller, the execution of which reliably prevents a microcontroller whose boot process requires loading data from at least a first logical block and a subsequent second logical block from being rendered unusable in the event of an unexpected error during an update process.

[0011] According to the invention, this problem is solved by a method for updating a software component on a microcontroller with the features of claim 1. Advantageous embodiments and further developments, as well as an update system for carrying out the method and a vehicle with such an update system, are described in the dependent claims.

[0012] A generic method for updating a software component on a microcontroller, wherein the microcontroller comprises a bootloader and non-volatile memory, subdivided into at least one primary partition and a backup partition, each comprising at least one first and one second logical block, wherein the first logical block contains the program code of a firmware, the second logical block contains the program code of an auxiliary program, and the backup partition holds a backup copy of the memory contents of the primary partition, and wherein, in a boot process, the bootloader accesses the first logical block on the primary partition to initialize the firmware, wherein the bootloader performs a hash-based integrity check of the memory contents, and wherein the bootloader proceeds with the initialization of the firmware.If the integrity check yields a positive result, or accesses the first logical block of the backup partition to initiate the copy of the firmware program code, or if the integrity check yields a negative result, the process is further developed according to the invention by the following method steps: Changing the hash value used for integrity checking of the first logical block of the primary partition from a first output value to a first transition value before updating the software component; updating the software component in at least one of the logical blocks on the primary partition; wherein, if the memory contents of the first and second logical blocks are changed, first the memory contents of the first logical block are changed, then the newly obtained hash value of the first logical block is changed from a second output value to a second transition value, then the memory contents of the second logical block are changed, and then the hash value of the first logical block is changed from the second transition value back to the second output value; or, if only the memory contents of the first logical block are changed, the newly obtained hash value of the first logical block is left as the second output value;or if only the memory contents of the second logical block are changed, the memory contents of the second logical block are changed, and then the hash value of the first logical block is changed from the first transition value back to the first output value; and the microcontroller is restarted.

[0013] The inventive method is based on the idea of ​​modifying the hash value of the first logical block of the primary partition to trick the bootloader into believing that the program code in the first logical block is corrupted. This means that if an unexpected error occurs during the update of the software components in the second logical block of the primary partition, corrupting the memory contents of the second logical block, the bootloader would access the backup partition to load the software components stored there for firmware initialization, even though the firmware program code in the first logical block of the primary partition is actually intact. This reliably prevents the microcontroller from being rendered unusable by such an unexpected error during the update of the software component.

[0014] It is important to distinguish between three different use cases. The software component may need to be updated exclusively in the second logical block, exclusively in the first logical block, or in both the first and second logical blocks on the primary partition.

[0015] Updating the software component in the first logical block inevitably results in a new hash value being generated for the first logical block, since the program code on which the calculation of the hash value is based changes.

[0016] Initially, it is not yet clear which logical blocks should be updated. Therefore, as a precaution, the existing hash value of the first logical block of the primary partition is changed from the initial value to the first transition value. This transition value can take on any conceivable value different from the initial value. The exact value of the transition value is irrelevant as long as it differs from the initial value. Various techniques can be used to determine the respective transition values. For example, the first transition value can be recalculated as needed, generated from the initial value, or read from a predefined list of initially calculated alternative transition values.

[0017] If only the memory contents of the first logical block of the primary partition are modified, a new hash value is automatically provided for integrity checking. The hash value corresponding to the first transition value is replaced by a hash value corresponding to the second output value. In such a case, no further special measures are required, as the memory contents of the second logical block remain unchanged. After successful updating of the memory contents of the first logical block, the microcontroller can therefore be restarted and the boot process performed based on the updated firmware.If an error occurred during the update of the memory contents of the first logical block of the primary partition, the hash value calculated for the integrity check would not match the newly obtained second output value. Therefore, the bootloader would automatically access the firmware in the first logical block of the backup partition. Thus, a reliable boot process would be possible despite an error during the update.

[0018] More effort is required if, however, the memory contents of the second logical block need to be updated. If only the memory contents of the second logical block on the primary partition are updated, but not the memory contents of the first logical block, the hash value of the first logical block will only change back from the first transition value to the first output value after the memory contents of the second logical block have been successfully updated. The microcontroller can then be restarted. If the update is successful, the firmware can be successfully initialized by the bootloader reading the blocks of the primary partition. However, if an unexpected error occurs during the update of the memory contents of the second logical block of the primary partition, the corresponding program code would be corrupted.According to the prior art, this can cause the bootloader to get stuck in an infinite loop because the memory contents of the second logical block cannot be read correctly. However, since, according to the invention, the hash value for the first logical block of the primary partition corresponds to the first transition value and not the first output value, a corresponding hash-value-based integrity check for the first logical block yields a negative result. As a consequence, the bootloader would access the backup partition and read the respective intact software components from the first and second logical blocks. This would allow for another successful boot process. After a successful update of the memory contents of the second logical block, the first transition value is then changed back to the first output value, so that the boot process can proceed as before.

[0019] If the memory contents of both the first and second logical blocks on the primary partition are updated, the hash value of the first logical block must be changed again. As mentioned earlier, changing the memory contents of the first logical block also generates a new hash value for integrity checking. This is called the second output value. Before the memory contents of the second logical block can be updated, the second output value of the hash value of the first logical block must be changed to the second transition value. Only then is it possible to prevent the system from getting stuck in a boot loop. Now the memory contents of the second logical block can be updated, and after a successful update, the second transition value can be changed back to the second output value.The microcontroller can then be restarted.

[0020] An advantageous embodiment of the method according to the invention provides that, to modify a respective hash value, a bitwise operator is applied to at least a part of the hash value, in particular in the form of bitwise NOT or bit shift. With the aid of bitwise operators, it is possible to modify hash values ​​reproducibly with minimal computational effort. Each digit of a hash value is digitally encoded as ones and zeros. By applying bitwise NOT, all zeros are converted to ones and all ones to zeros. This ensures that the transition value differs from the respective initial value. Furthermore, the hash values ​​can be converted into one another particularly easily by simply swapping the respective ones and zeros. Instead of bitwise NOT, a bit shift can also be performed. For this purpose, the digits or characters of the hash value, the bits encoding them, are shifted left or right in their position.This can involve, for example, a so-called arithmetic shift, logical shift, or circular shift. Modifying hash values ​​in this way is particularly computationally efficient and therefore does not increase the latency when carrying out the method according to the invention. The entire hash value can be changed, or only parts of it, for example, the first byte of a particular hash value.

[0021] According to a further advantageous embodiment of the method according to the invention, after the microcontroller has successfully restarted and booted from the firmware stored on the primary partition, the memory contents of the primary partition are copied to the backup partition. This makes it possible to keep the memory contents of the backup partition up to date. The memory contents of the backup partition may only be modified after it has been ensured that the integrity of the memory contents of the primary partition is maintained. Should an error occur subsequently, preventing booting based on the memory contents of the primary partition, a successful boot from the backup partition can be performed. Since the respective software components have also been updated here, it is ensured that no outdated program version is loaded.

[0022] A further advantageous embodiment of the method according to the invention further provides that, before changing the hash value of the first logical block on the primary partition from the first output value to the first transition value, it is checked whether the primary partition and the backup partition have the same memory content, wherein: If booting from the primary partition is not possible, the memory contents of the primary partition are replaced by the memory contents of the backup partition; or if booting from the primary partition is possible and the memory contents of the primary partition differ from those of the backup partition, the memory contents of the primary partition are copied to the backup partition.

[0023] In other words, this ensures that at least one of the partitions contains a bootable program version. If such a bootable program version is not present on the primary partition, it can be obtained from the backup partition. If, however, booting based on the memory contents of the primary partition is possible, it can be checked whether the memory contents of the backup partition match those of the primary partition. If so, no further action is necessary. If, however, the memory contents of the backup partition differ from those of the primary partition, the memory contents of the primary partition can be transferred to the backup partition. This check is performed before updating the software components on the primary partition to provide the microcontroller with a stable initial state for the update process.

[0024] According to a further advantageous embodiment of the method according to the invention, it is further provided that, before the software component is updated, a memory content matching flag, describing whether the primary partition and the backup partition have the same memory content, is set from TRUE to FALSE, and that the memory content matching flag is set from FALSE to TRUE after the software component has been updated. The memory content matching flag informs electronic components or software components whether the memory content of the primary partition and the backup partition match or not. The memory content matching flag is set to FALSE before the update is performed because the update creates a difference between the respective memory contents.After the successful update and after copying the successfully updated memory contents of the primary partition to the backup partition, the memory content matching flag can then be set back from FALSE to TRUE.

[0025] A further advantageous embodiment of the method according to the invention provides that a software component is updated on a microcontroller implemented as a switch. This is a particularly relevant application.

[0026] Preferably, a firewall rule set is updated as the memory content of the second logical block. This is also a particularly relevant use case. The microcontroller, implemented as a switch, can be used to forward and monitor network traffic. The switch can provide firewall functionality, which can be integrated into the switch's firmware. To configure the firewall, the aforementioned rule set is requested. If the rule set cannot be read from the second logical block, the switch cannot be fully started. However, the method according to the invention ensures that even if the rule set stored in the second logical block is corrupted by an error during an update process, the switch can still start. Thus, the safe operation of the switch is guaranteed.

[0027] In an update system comprising a first and a second interconnected microcontroller, the invention provides that the first microcontroller stores a computer program product in a storage medium. This program product, when executed by a processor of the first microcontroller, enables the first microcontroller to update a software component of the second microcontroller according to a method described above. A suitable program code, referred to here as a computer program product, for providing the process steps described by the method according to the invention can thus be provided and executed by a first microcontroller. In this way, the first microcontroller can update the second microcontroller. In particular, the second microcontroller is a switch.The first microcontroller can receive the corresponding update data from an external source, such as an internet server, a USB dongle, or the like, before controlling the second microcontroller.

[0028] According to the invention, a vehicle includes such an update system. By providing such an update system, the vehicle can be operated with particular reliability. The vehicle can be, in particular, a road vehicle such as a car, truck, van, bus, or the like. Generally, it can also be a rail vehicle, watercraft, or aircraft.

[0029] Further advantageous embodiments of the inventive method for updating a software component on a microcontroller also result from the exemplary embodiments which are described in more detail below with reference to the figures.

[0030] This shows: Fig. 1 a schematic representation of a bootloader and non-volatile memory of a microcontroller to be updated according to the prior art; Fig. 2 a schematic representation of a microcontroller to be updated whose memory partitions are each divided into a first and a second logical block, according to the prior art; Fig. 3 two tables illustrating the sequence of an update process known from the prior art in the event of an error; Fig. 4 a flowchart of a method according to the invention for updating a software component on the microcontroller; Fig. 5 a table illustrating the sequence of the update process according to the invention; and Fig. 6 a schematic view of a vehicle according to the invention.

[0031] Based on Figure 1The boot process of a microcontroller 1 is described. The microcontroller 1 comprises a bootloader 2 and non-volatile memory 3, divided into a primary partition 4 and a backup partition 5. In the Figure 1 In the illustrated embodiment, the primary partition 4 and the backup partition 5 are each subdivided into a first logical block LB1. The firmware program code is stored in the first logical block LB1. Before the firmware of the microcontroller 1 is initialized, the bootloader 2 performs a hash-based integrity check. For this purpose, a comparison hash 11 is stored in each first logical block LB1. The bootloader 2 calculates a corresponding hash value from the program code read from the first logical block LB1 and compares the resulting hash value with the comparison hash 11.

[0032] How Figure 1As shown, two cases can occur. If both hash values ​​match, indicated by arrow 101, the integrity check is successful and the boot process can proceed on the firmware stored in primary partition 4. If, however, the two hash values ​​differ, bootloader 2 accesses the firmware program code stored in backup partition 5, indicated by arrow 102.

[0033] For example, the firmware stored in primary partition 4 can be updated. During such an update, an unexpected error may occur, causing, for example, a power failure of microcontroller 1, requiring a restart of microcontroller 1. In this case, the firmware program code may become corrupted, necessitating the aforementioned firmware initialization from backup partition 5.

[0034] Figure 2Figure 1 shows an alternative microcontroller 1 in which the respective primary partition 4 and backup partition 5 are each subdivided into at least one first logical block LB1 and one second logical block LB2. The firmware program code is stored in the first logical block LB1, and the program code of an additional program, for example, a rule set for a firewall, is stored in the second logical block LB2. Successful firmware initialization requires access to the data stored in the second logical block LB2.

[0035] The hash-based integration check, which is hard-coded into bootloader 2, is based solely on comparing the comparison hash 11 of the first logical block LB1 with a hash value calculated for the program code contained in the first logical block LB1. How Figure 2aAs shown in the diagram, there are again two possible cases. If the two hash values ​​match, the boot process can be based on the memory contents of the first and second logical blocks LB1 and LB2 of the primary partition 4 – see arrow 201. If, however, the memory contents of the first logical block LB1 of the primary partition 4 are corrupted, the bootloader 2 accesses the backup partition 5 and loads the firmware program code stored in the first logical block LB1 of the backup partition 5, and then the memory contents of the second logical block LB2 – see arrow 202.

[0036] If an unexpected error occurs during the update of the respective software components of the second logical block LB2 of primary partition 4, only the memory contents of the second logical block LB2 of primary partition 4 will be corrupted. In this case, the integrity check for the first logical block LB1 will be successful, so bootloader 2 will not access the backup partition 5. This is in Figure 2bThe boot process cannot be completed successfully because the memory content of the second logical block LB2 is corrupted, preventing the firmware from being configured correctly. Bootloader 2 cannot detect this error. However, the firmware requires access to the memory contents of the second logical block LB2 for it to function correctly. Therefore, microcontroller 1 cannot operate properly. In this case, microcontroller 1 can be colloquially referred to as "bricked," as there are no subsequent remedial measures available.

[0037] For example, the microcontroller 1 can be integrated into a control unit 12 of a system in Figure 6 The vehicle shown (10) is integrated, which also prevents the aforementioned control unit (12) from functioning correctly. In the worst case, this will also "brick" control unit (12).

[0038] Figure 3This illustrates the process of an update campaign. Sub-figures 3a) and 3b) show, as the update progresses, which version of a corresponding software component is stored as memory content in a respective logical block LB1, LB2, and from which partition 4, 5 the system boots in case of an error. The moment when an unexpected error occurs, causing the corruption of the respective program code sections, is indicated by hatching.

[0039] For example, an original program version is designated V1.0 and an updated version V2.0. The second column of each table shows the initial state of the memory contents of the respective logical blocks LB1 and LB2 of the primary partition 4 and the backup partition 5. The third column shows the update process for the first block LB1 of the primary partition 4. The fourth column shows the update process for the second logical block LB2 of the primary partition 4. The fifth column shows the update process for the first logical block LB1 of the backup partition 5. The last column of each table shows the update process for the second logical block LB2 of the backup partition 5. The last row of each table shows which part of the program code is loaded by bootloader 2 to perform a successful boot process.In the tables, the primary partition 4 is designated as "P1" and the backup partition 5 as "P2".

[0040] Figure 3a This shows the case where a functional copy of the corresponding program code parts is kept in backup partition 5. The in Figure 3b The table shown shows that non-executable program code ("corrupt") is stored on backup partition 5 in the respective logical blocks LB1, LB2 of backup partition 5.

[0041] Figure 3 This illustrates that if the memory content of the first or second logical block LB1, LB2 of the primary partition 4 is not successfully completed, the microcontroller 1 can be rendered unusable.

[0042] This can be prevented by means of a method according to the invention for updating the software component on a microcontroller 1, the execution of which in an advantageous embodiment is Figure 4 The process is shown. In step 401, the procedure starts. In step 402, it is checked whether booting from primary partition 4 is possible. If this is not possible, the contents of backup partition 5 are written to primary partition 4 according to step 403. If, however, booting successfully from primary partition 4 is possible, step 404 checks whether the contents of primary partition 4 and backup partition 5 are identical. If this is not the case, the contents of primary partition 4 are written to backup partition 5 in step 405.

[0043] Step 406 verifies whether copying the memory contents to backup partition 5 was successful. If not, step 407 indicates an error and the update process is aborted. However, if the data transfer was successful, step 408 sets the memory content matching flag 8 to FALSE. Although the respective memory contents currently match, an update process will now occur, after which the respective memory contents will differ again.

[0044] In step 409, the comparison hash 11 used for the integrity check of the first logical block LB1 of the primary partition 4 is changed from a first initial value 6.1 to a first transition value 7.1. Specifically, this is achieved by applying a bitwise operator to at least part of the hash value, for example, a bitwise NOT operation. This inverts the respective bits of the hash value. Alternatively, a so-called bit shift could be performed. Other methods for changing the hash value are also possible. However, the application of bitwise operators is particularly computationally efficient. This prevents an increase in latency during the execution of the method according to the invention.

[0045] Changing the initial output value 6.1 to the initial transition value 7.1 prevents the bootloader 2 from running as described in Figure 2b ) shown that in case of an error, it does not access backup partition 5.

[0046] Thus, bootloader 2 cannot successfully perform an integrity check of the memory contents of the first logical block LB1 of the primary partition 4, so that in case of an error, bootloader 2 would automatically jump to the backup partition 5.

[0047] The memory contents of at least one of the logical blocks LB1, LB2 of primary partition 4 are then updated. For this, a case distinction must be made as to whether only the memory contents of the first logical block LB1, only the second logical block LB2, or the memory contents of both logical blocks LB1 and LB2 should be updated.

[0048] Step 410 checks whether the memory contents of both the first logical block LB1 and the second logical block LB2 should be updated. Step 411 checks whether only the memory contents of the first logical block LB1 should be updated.

[0049] If only the memory contents of the first logical block LB1 of primary partition 4 need to be updated, no further separate measures are required to maintain the bootability of microcontroller 1. In step 412, the memory contents of the first logical block LB1 of primary partition 4 can be updated. In step 413, microcontroller 1 can be restarted. If an error were to occur in step 412, resulting in the corruption of the memory contents of the first logical block LB1 of primary partition 4, the aforementioned hash-based integrity check would automatically fail, meaning that bootloader 2 would access the backup partition 5 anyway.

[0050] In step 412, new program code is written to the first logical block LB1 of primary partition 4, automatically generating a new comparison hash 11 for the integrity check. Therefore, the hash value changed in step 409 does not need to be restored.

[0051] If, however, only the memory contents of the second logical block LB2 of primary partition 4 are updated, this occurs in step 414. In step 415, the hash value of the first logical block LB1 is then changed from the initial transition value of 7.1 back to the initial value of 6.1. If an unexpected error were to occur in step 414, corrupting the memory contents of the second logical block LB2 of primary partition 4, bootloader 2 would still be unable to successfully perform the integrity check for the first logical block LB1 of primary partition 4, because the initial transition value of 7.1 would not match a currently calculated hash value for the memory contents of the first logical block LB1 of primary partition 4. Therefore, bootloader 2 would again jump to the backup partition 5. This ensures a reliable boot process even in the event of an error.

[0052] After resetting the hash value for the first logical block LB1 of the primary partition 4 in step 415, step 413 can follow to restart the microcontroller 1.

[0053] If, however, it is necessary to update the memory contents of both the first logical block LB1 and the second logical block LB2 of primary partition 4, then in step 416, a comparison hash 11, calculated for the newly implemented program code, is first changed from the second initial value 6.2 to a second transition value 7.2. The procedure for changing this hash value can be performed analogously to step 409. Since updating the memory contents of the first logical block LB1 of primary partition 4 has changed the program code, the hash value calculated for the integrity check also changes. Therefore, changing the hash value for comparison is necessary again.

[0054] Then, in step 417, the memory contents of the second logical block LB2 of primary partition 4 can be updated. In step 418, after the memory contents of the first and second logical blocks LB1 and LB2 of primary partition 4 have been successfully updated, the second transition value 7.2 can be changed back to the second initial value 6.2. Now, step 413 can be performed and microcontroller 1 can be restarted.

[0055] Changing the corresponding hash values, also known as "bitwise inversion" or "hash reverse," is computationally efficient. The runtime of the corresponding update increases only marginally or not at all. However, to avoid executing step 409 when both the memory contents of the first logical block LB1 and the second logical block LB2 of primary partition 4 are updated, it would also be possible (not shown) to first check which logical blocks LB1 and LB2 need to be updated, so that potentially no hash value is changed at all, or at most one hash value needs to be changed.

[0056] After updating the memory contents of microcontroller 1, step 419 checks whether bootloader 2 can boot from primary partition 4. If not, an error occurs again according to step 407. If, however, booting is successful, step 420 copies the memory contents of primary partition 4 to backup partition 5. This ensures that the current and executable program version is also transferred to backup partition 5. In step 421, the aforementioned memory content matching flag 8 can be changed back from FALSE to TRUE. Step 422 concludes the successfully completed update procedure.

[0057] Figure 5 shows, analogous to Figure 3The table describes the process of the update campaign based on the method according to the invention. As can be seen from the table, it is possible for each update step, despite an error (indicated by hatching), to read a working program version from the primary partition 4 or the backup partition 5 and to successfully execute a corresponding boot process via the bootloader 2. This increases the reliability of the microcontroller 1.

[0058] Corrupted program code is abbreviated with a "K" in the table. Times when a given hash value (initial value 6.1, 6.2) is replaced by a transition value (7.1, 7.2) are indicated in the table by the label "HASH". The third column of the table shows step 405, i.e., the replacement of the memory contents of backup partition 5 with the executable memory contents of primary partition 4. The fourth column shows step 409, i.e., the activation of the bootloader 2 function to jump to backup partition 5 (BOOT Stop). Starting with column seven, this function is terminated by resetting the hash value (BOOT OK).

[0059] Figure 6Figure 1 shows a top view of a schematic vehicle 10 according to the invention. The vehicle 10 according to the invention comprises an update system 9 according to the invention. The update system 9 comprises at least a first microcontroller 1.1 and a second microcontroller 1.2. The first microcontroller 1.1 serves to execute the update method according to the invention. The second microcontroller 1.2 is updated in this process. The update system 9 can, in particular, be the control unit 12 of a vehicle subsystem. The second microcontroller 1.2 is preferably implemented as a switch.

Claims

1. Method for updating a software component on a microcontroller (1), the microcontroller (1) comprising a bootloader (2) and a non-volatile memory (3) subdivided into at least a primary partition (4) and a backup partition (5), each in turn having at least a first logical block (LB1) and a second logical block (LB2), the program code of firmware being stored in the first logical block (LB1), the program code of an add-on program being stored in the second logical block (LB2), and a backup copy of the memory contents of the primary partition (4) being held on the backup partition (5), and the bootloader (2) accessing, during a boot process, the first logical block (LB1) on the primary partition (4) in order to initiate the firmware, the bootloader (2) carrying out a hash-value-based integrity check of the memory contents, and the bootloader (2) proceeding with the initialization of the firmware if the integrity check yields a positive result, or accessing the first logical block (LB1) of the backup partition (5) to initiate the copy of the program code of the firmware if the integrity check yields a negative result, characterized by the following method steps: - changing the hash value used for the integrity check of the first logical block (LB1) of the primary partition (4) from a first starting value (6.1) to a first transition value (7.1) before updating the software component; - updating the software component in at least one of the logical blocks (LB1, LB2) on the primary partition (4); - if the memory contents of the first and the second logical block (LB1, LB2) are changed, the memory contents of the first logical block (LB1) being changed first, then the newly obtained hash value of the first logical block (LB1) being changed from a second starting value (6.2) to a second transition value (7.2), then the memory contents of the second logical block (LB2) being changed, and then the hash value of the first logical block (LB1) being changed from the second transition value (7.2) back to the second starting value (6.2); or - if the memory contents of only the first logical block (LB1) are changed, the newly obtained hash value of the first logical block (LB1) being left as the second starting value (6.2); or - if the memory contents of only the second logical block (LB2) are changed, the memory contents of the second logical block (LB2) being changed and then the hash value of the first logical block (LB1) being changed from the first transition value (7.1) back to the first starting value (6.1); and - restarting the microcontroller (1).

2. Method according to claim 1, characterized in that in order to change a relevant hash value, a bitwise operator, in particular in the form of bitwise NOT or bit shift, is applied to at least a part of the hash value.

3. Method according to claim 1 or 2, characterized in that after the microcontroller (1) has been successfully restarted and booted from the firmware held on the primary partition (4), the memory contents of the primary partition (4) are copied to the backup partition (5).

4. Method according to any of claims 1 to 3, characterized in that before changing the hash value of the first logical block (LB1) on the primary partition (4) from the first starting value (6.1) to the first transition value (7.1), it is checked whether the primary partition (4) and the backup partition (5) have the same memory contents: - if booting from the primary partition (4) is not possible, the memory contents of the primary partition (4) being replaced by the memory contents of the backup partition (5); or - if booting from the primary partition (4) is possible and the memory contents of the primary partition (4) differ from the backup partition (5), the memory contents of the primary partition (4) being copied to the backup partition (5).

5. Method according to claim 3 and 4, characterized in that before updating the software component, a memory contents match flag (8) describing whether the primary partition (4) and the backup partition (5) have the same memory contents is set from TRUE to FALSE, and the memory contents match flag (8) is set from FALSE to TRUE after the software component has been updated.

6. Method according to any of claims 1 to 5, characterized in that a software component on a microcontroller (1) designed as a switch is updated.

7. Method according to claim 6, characterized in that a rule set of a firewall is updated as memory contents of the second logical block (LB2).

8. Update system (9) comprising a first microcontroller (1.1) and a second microcontroller (1.2) connected to one another, characterized in that the first microcontroller (1.1) provides a computer program product in a storage medium, which computer program product, when executed by a processor of the first microcontroller (1.1), allows the first microcontroller (1.1) to update a software component of the second microcontroller (1.2) according to a method according to any of claims 1 to 7.

9. Vehicle (10) characterized by an update system (9) according to claim 8.