Method and device for performing OTA updating on vehicle

Abstract

Methods and apparatus for performing OTA updates to a vehicle are disclosed herein. According to one aspect of the present disclosure, there is provided a method for performing OTA update on a vehicle in which a non-volatile memory of a vehicle control unit is divided into a plurality of blocks including a CB block, an ASW block, a DS block, an ASW backup block corresponding to the ASW block, and a DS backup block corresponding to the DS block, the method comprises the following steps: resetting an existing backup success mark aiming at a CB block in response to a detected request for erasing the CB block; backing up a first boot program stored in the CB block by using at least one of the ASW backup block and the DS backup block; after the backup is completed, setting a backup success mark for the CB block; and erasing the CB block and writing a second boot program different from the first boot program into the CB block.

Description

Technical Field

[0001] The present disclosure relates generally to vehicle technology, and more particularly, to a method and apparatus for performing OTA (Over-the-Air) updates on a vehicle. Background Art

[0002] The evolution of vehicle technology is inseparable from the rapid development of electronic information technology in recent decades. More and more vehicle driving-related components and subsystems rely on software to control their operation. At the same time, modern vehicles are also providing more infotainment and other functions, which are also based on corresponding software. With the improvement of the level of automobile intelligence, various advanced driver assistance systems (ADAS) are also equipped in vehicles, relying on the cooperation of software and hardware to reduce the burden on drivers and improve driving safety.

[0003] With the introduction of a large amount of software in various control units of the vehicle (including but not limited to vehicle control unit (VCU), electronic control unit (ECU), fuel cell control unit (FCCU), battery management system (BMS), etc.), how to update these software conveniently and quickly becomes a problem. The traditional solution requires the vehicle to return to the maintenance station and use special tools to upgrade the software of the vehicle control unit. This method consumes a lot of manpower and material resources, and it is difficult to ensure timely response after the discovery of software defects / software failures for a large number of individual vehicles.

[0004] Vehicle OTA update refers to the vehicle manufacturer providing upgrades for software (including firmware) and related data to the vehicle through wireless means. OTA updates are sent through wireless connections and automatically installed on the vehicle. The introduction of this technology effectively reduces after-sales service costs, responds to software defects / failures more quickly and conveniently, and greatly improves the user experience.

[0005] The software to be run by the vehicle control unit and the corresponding data to be used are usually stored in the non-volatile memory (e.g., flash memory) of the control unit. Updating means replacing the old version of the software / data stored in the non-volatile memory with the new version of the software / data. Efficient use of the limited storage space of the memory during the update process will effectively reduce the hardware cost of the vehicle control unit and improve the adaptability of the update. Summary of the invention

[0006] In the summary section, some selected concepts are introduced in a simplified form, which will be further described in the detailed description section below. This summary section is not intended to identify any key features or essential features of the claimed subject matter, nor is it intended to be used to help determine the scope of the claimed subject matter.

[0007] According to one aspect of the present disclosure, a method for OTA updating of a vehicle is provided, wherein a non-volatile memory of a vehicle control unit is divided into a plurality of blocks, the plurality of blocks including a customer boot program (CB) block, an application program (ASW) block, a data set (DS) block, an ASW backup block corresponding to the ASW block, and a DS backup block corresponding to the DS block, the method comprising: in response to detecting a request to erase the CB block, resetting an existing backup success flag for the CB block; backing up a first boot program stored in the CB block using at least one of the ASW backup block and the DS backup block; after the backup is completed, setting a backup success flag for the CB block; and erasing the CB block and writing a second boot program different from the first boot program into the CB block.

[0008] According to another aspect of the present disclosure, a device for OTA updating of a vehicle is provided, wherein a non-volatile memory of a vehicle control unit is divided into a plurality of blocks, the plurality of blocks including a customer boot program (CB) block, an application program (ASW) block, a data set (DS) block, an ASW backup block corresponding to the ASW block, and a DS backup block corresponding to the DS block, the device comprising: a unit for resetting an existing backup success flag for the CB block in response to detecting a request to erase the CB block; a unit for backing up a first boot program stored in the CB block using at least one of the ASW backup block and the DS backup block; a unit for setting a backup success flag for the CB block after the backup is completed; and a unit for erasing the CB block and writing a second boot program different from the first boot program into the CB block.

[0009] According to another aspect of the present disclosure, a computing device is provided, comprising: at least one processor; and a memory coupled to the at least one processor and used to store instructions, wherein the instructions, when executed by the at least one processor, cause the at least one processor to perform the method described in the present disclosure.

[0010] According to yet another aspect of the present disclosure, a computer-readable storage medium is provided, on which instructions are stored. When the instructions are executed by at least one processor, the at least one processor executes the method described in the present disclosure.

[0011] According to another aspect of the present disclosure, a computer program product is provided, which includes instructions. When the instructions are executed by at least one processor, the at least one processor performs the method described in the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Implementations of the present disclosure are illustrated by way of example and not limitation in the accompanying drawings in which like reference numerals designate the same or similar parts and in which:

[0013] Figure 1 It is a schematic diagram of the storage space division of the non-volatile memory of the vehicle control unit in the prior art;

[0014] Figure 2A A flowchart illustrating an exemplary method according to some implementations of the present disclosure is shown;

[0015] Figure 2B A flowchart illustrating an exemplary method according to some implementations of the present disclosure is shown;

[0016] Figure 3 is a schematic diagram of the storage space division of a non-volatile memory of a vehicle control unit according to some implementations of the present disclosure;

[0017] Figures 4A-4C An example of the use of storage space of a non-volatile memory of a vehicle control unit according to some implementations of the present disclosure is shown;

[0018] Figure 5 A block diagram illustrating an exemplary apparatus according to some implementations of the present disclosure is shown;

[0019] Figure 6 A block diagram of an exemplary computing device according to some implementations of the present disclosure is shown.

[0020] List of reference numerals:

[0021] 110: CB block 120: ASW block 130: DS block

[0022] 140: CB backup block 150: ASW backup block 160: DS backup block

[0023] 210: Reset the existing backup success flag for the CB block

[0024] 220: Back up the first boot program stored in the CB block using at least one of the ASW backup block and the DS backup block

[0025] 230: Set the backup success flag for the CB block

[0026] 240: Erase the CB block and write a second boot program different from the first boot program into the CB block

[0027] 260: In the event that a failure is determined during erase or write, check whether the backup success flag for the CB block is valid

[0028] 270: Re-erase the CB block and write the first boot program backed up by at least one of the ASW backup block and the DS backup block back to the CB block

[0029] 310: CB block 320: ASW block 330: DS block

[0030] 350: ASW backup block 360: DS backup block

[0031] 510-540: Unit 610: Processor 620: Memory DETAILED DESCRIPTION

[0032] In the following description, a large number of specific details are set forth for the purpose of explanation. However, it should be understood that the implementation of the present disclosure can be implemented without these specific details. In other examples, well-known circuits, structures, and techniques are not shown in detail to avoid affecting the understanding of the description.

[0033] References throughout the specification to "an implementation," "implementation," "exemplary implementations," "some implementations," "various implementations," etc., indicate that the implementations of the present disclosure described may include specific features, structures, or characteristics, however, it does not mean that every implementation must include these specific features, structures, or characteristics. In addition, some implementations may have some, all, or none of the features described for other implementations.

[0034] In a manner that is most helpful for understanding the claimed subject matter, various operations may be described as multiple discrete actions or operations in sequence. However, the order of description should not be interpreted as implying that these operations are necessarily order-dependent. On the contrary, these operations may not be performed in the order presented. In other implementations, various other operations may also be performed, and / or various operations that have been described may be ignored.

[0035] In the specification and claims, the phrase "A and / or B" may appear to mean one of the following: (A), (B), (A and B). Similarly, the phrase "A, B and / or C" may appear to mean one of the following: (A), (B), (C), (A and B), (A and C), (B and C), (A and B and C).

[0036] In the specification and claims, the terms "coupled" and "connected" and their derivatives may be used. It should be understood that these terms are not intended as synonyms for each other. Instead, in a particular implementation, "connected" is used to indicate that two or more components are in direct physical or electrical contact with each other, while "coupled" is used to indicate that two or more components cooperate or interact with each other, but they may or may not be in direct physical or electrical contact.

[0037] Modern vehicles are equipped with a large number of control units, including control units for various driving-related controls, as well as control units for various in-vehicle infotainment systems, etc. The control unit is typically based on a processor architecture, and implements the control process by running / using corresponding software / data. The software and related data used by the vehicle control unit are stored in the non-volatile memory of the control unit (e.g., located inside the control unit), and the non-volatile memory may include but is not limited to flash memory.

[0038] For ease of operation and management, the storage space of the non-volatile memory of the vehicle control unit is usually divided into multiple blocks, typically including a consumer bootloader (CB) block, an application software (ASW) block, and a dataset (DS) block, wherein the CB block is used to store the bootloader, the ASW block is used to store the application, and the DS block is used to store application-related data and calibration data, etc. Vehicle OTA updates may therefore involve updating the content of one or more of the CB block, ASW block, and DS block in the non-volatile memory of the control unit.

[0039] A basic feature of today's vehicle OTA updates is to ensure that rollback can be achieved in the event of a failure during the update process, that is, if the previous version of the software / data is not successfully updated to the new version, it should be ensured that the previous version of the software / data can be restored to avoid affecting the normal use of the vehicle. To support rollback, the content in the block to be updated needs to be backed up during the update process. Therefore, in addition to the above-mentioned CB block, ASW block, and DS block, the non-volatile memory of the vehicle control unit should typically also include a CB backup block corresponding to the CB block, an ASW backup block corresponding to the ASW block, and a DS backup block corresponding to the DS block, which are respectively used to store the backup content of the corresponding blocks.

[0040] Figure 1 FIG. 1 is a schematic diagram of the storage space division of the non-volatile memory of the vehicle control unit in the prior art. Figure 1As shown, the storage space of the non-volatile memory of the control unit includes at least six blocks, namely: a CB block 110, an ASW block 120, a DS block 130, a CB backup block 140, an ASW backup block 150, and a DS backup block 160. Generally, the backup block has the same size as the original block, that is, the CB block 110 has the same size as the CB backup block 140, the ASW block 120 has the same size as the ASW backup block 150, and the DS block 130 has the same size as the DS backup block 160.

[0041] Although the backup / rollback mechanism of OTA update is supported, the provision of corresponding backup blocks of at least the same size for the CB block 110, the ASW block 120, and the DS block 130 means that a larger capacity of non-volatile memory is required, which will lead to a higher control unit cost. In addition, although there is also an update demand, the frequency of updating the CB block 110 may be relatively low compared with the ASW block 120 and the DS block 130. In this case, always maintaining a CB backup block 140 of at least the same size as the CB block 110 will, to a certain extent, make the storage space unable to be fully utilized, and OTA updates may not be applicable to vehicle control units that only have relatively small non-volatile memories.

[0042] The present disclosure proposes a mechanism for performing OTA update on a vehicle, wherein at least one of an ASW backup block corresponding to an ASW block and a DS backup block corresponding to a DS block in a non-volatile memory of a vehicle control unit is used as a backup space for a CB block, without setting a separate CB backup block for the CB block in the non-volatile memory (e.g., Figure 1 The CB backup block 140 in the OTA update can effectively reduce the hardware cost of the vehicle control unit while supporting the backup / rollback mechanism of the OTA update, and at the same time enhance the adaptability of the OTA update.

[0043] Reference below Figure 2A , which shows a flow chart of an exemplary method 200 according to some implementations of the present disclosure. The exemplary method 200 may be performed by a control unit of a vehicle to implement the mechanism described herein for performing OTA updates on the vehicle.

[0044] According to some implementations of the present disclosure, the storage space of the non-volatile memory of the vehicle control unit is divided into a plurality of blocks, including a CB block, an ASW block, a DS block, an ASW backup block corresponding to the ASW block, and a DS backup block corresponding to the DS block. In some implementations, the ASW backup block has at least the same size as the ASW block, and the DS backup block has at least the same size as the DS block.

[0045] Go to Figure 3 , which shows a schematic diagram of the storage space division of the non-volatile memory of the vehicle control unit according to some implementations of the present disclosure. Figure 3 As shown, in some implementations according to the present disclosure, the non-volatile memory of the control unit includes at least five blocks, namely: a CB block 310, an ASW block 320, a DS block 330, an ASW backup block 350, and a DS backup block 360, which can be respectively Figure 1 The CB block 110, ASW block 120, DS block 130, ASW backup block 150, and DS backup block 160 correspond to each other.

[0046] like Figure 2A As shown, the exemplary method 200 starts at step 210, in which, in response to detecting a request to erase the CB block, the existing backup success flag for the CB block is reset.

[0047] In some implementations of the present disclosure, if the update package received via OTA indicates a request to erase the CB block 310, for example, the update package includes an erase instruction, which specifies that the CB block 310 is to be erased, then it means that the CB block 310 in the non-volatile memory of the vehicle control unit is to be updated. After the control unit detects such a request, it does not immediately erase the CB block 310 in response to the request, but first resets / clears the existing backup success flag for the CB block 310. According to some implementations of the present disclosure, the existing / existing backup success flag for the CB block 310 indicates that the content originally stored in the CB block 310 (i.e., the previous version of the boot program relative to the first boot program currently stored in the CB block 310) has been successfully backed up in an update before this update. Therefore, before erasing the content currently stored in the CB block 310, the existing backup success flag should be reset first. In some implementations, the backup success flag may be a flag bit stored in a specific location (e.g., at the head of the CB block) in the non-volatile memory of the vehicle control unit. As an example, the flag bit may be a single bit, wherein a bit value of 1 indicates that a backup for the CB block already exists in the non-volatile memory (i.e., the backup is valid), and a bit value of 0 indicates that there is no backup for the CB block (i.e., the backup is invalid). Accordingly, in the above example, resetting the backup success flag means setting the bit value to 0. It should be understood that the backup success flag for the CB block 310 may be represented in other forms, and the manner of resetting / setting the backup success flag may be correspondingly different.

[0048] The method 200 then proceeds to step 220, in which at least one of the ASW backup block and the DS backup block is used to back up the first boot program stored in the CB block. Figure 1 The CB backup block 140 shown in FIG. 1 is that in some implementations according to the present disclosure, at least one of the ASW backup block 350 and the DS backup block 360 is used to serve as a backup space for the CB block 310, and a copy of the first boot program currently stored in the CB block 310 (i.e., the old version of the boot program to be updated) is saved here as a backup when performing a backup.

[0049] In some implementations, backing up the first boot program stored in the CB block using at least one of the ASW backup block and the DS backup block in step 220 may include backing up the first boot program in the ASW backup block. That is, the ASW backup block 350 may be used as a backup space for the CB block 310. As an example, Figure 4A As shown, during the update of the CB block 310 , a portion of the space in the ASW backup block 350 (shown by diagonal shading) is used to back up the content in the CB block 310 .

[0050] Alternatively, in some implementations, step 220 may include backing up the first boot program in the DS backup block. That is, the DS backup block 360 may be used as a backup space for the CB block 310. Figure 4B As shown, during the process of updating the CB block 310 , a portion of the space in the DS backup block 360 (shown by diagonal hatching) is used to back up the content in the CB block 310 .

[0051] Alternatively, in some implementations, step 220 may include backing up the first boot program across the ASW backup block and the DS backup block. That is, both the ASW backup block 350 and the DS backup block 360 may be used as backup space for the CB block 310. As an example, Figure 4C As shown, during the update of the CB block 310, the backup of the content in the CB block 310 may occupy a portion of the space of the ASW backup block 350 and the DS backup block 360 (shown by diagonal shading).

[0052] and Figure 1 Compared with the storage space division of the prior art shown in FIG. 1 , according to some implementations of the present disclosure, a separate CB backup block (such as CB block 310) corresponding to the CB block 310 does not need to be set in the non-volatile memory of the vehicle control unit. Figure 1Instead of the CB backup block 140 shown in the figure, at least one of the ASW backup block 350 and the DS backup block 360 can be borrowed, thereby effectively improving the storage space utilization of the non-volatile memory of the vehicle control unit and reducing the cost of the vehicle control unit.

[0053] Back to Figure 2A After the backup operation in step 220 is completed, the method 200 proceeds to step 230, in which a backup success flag for the CB block is set. Continuing with the previous example in which the backup success flag is a single-bit flag, the flag can be set to 1 here to indicate that the backup for the CB block 310 is successfully completed (i.e., the backup is valid).

[0054] In some implementations according to the present disclosure, the method 200 may further include checking the data integrity of the backup content. For example, the checksum of the first boot program stored in the CB block 310 and the checksum of the copy of the first boot program stored in at least one of the ASW backup block 350 and the DS backup block 360 in step 220 may be calculated to determine whether the two are equal to ensure the data integrity of the backup content. In addition, in some implementations, the method 200 may further include recording the starting address and length of the backup content located in at least one of the ASW backup block 350 and the DS backup block 360 to facilitate locating the backup content when needed later.

[0055] After completing the backup of the content of the CB block (here, the first boot program) (step 220) and setting the corresponding backup success flag (step 230), the method 200 starts to execute step 240, in which the CB block is erased and the second boot program different from the first boot program is written into the CB block. The erase operation is a precursor to the write operation. Through the write operation, the old version of the first boot program in the CB block 310 is replaced by the new version of the second boot program. According to the above process, the update of the CB block 310 is realized, and at the same time, the backup of the previous content in the CB block 310 is completed in a way of reducing the storage space occupied in the process, so that once a problem occurs in the update, it can still be rolled back based on the backup.

[0056] In addition, in some implementations according to the present disclosure, the method 200 may further include: resetting the existing validity flag for the CB block before performing the erase operation of step 240, and setting the validity flag for the CB block after the write operation of step 240 is completed. The validity flag is used to indicate the data integrity of the content written to the CB block 310 through the OTA update. In some implementations, the validity flag can be a flag bit stored in a specific location (e.g., at the head of the CB block) in the non-volatile memory of the vehicle control unit, but the present disclosure is not limited to this.

[0057] In addition, in some implementations according to the present disclosure, the method 200 may also include at the beginning: determining whether the current condition of the vehicle is suitable for OTA update; and in response to determining that the current condition of the vehicle is suitable for OTA update, determining whether a request to erase the CB block is detected. As an example, although it is permissible to download an update package via OTA while the vehicle is driving, it is not allowed to run the downloaded update package to perform the update process while the vehicle is driving. In addition, there are many other conditions in the vehicle that are not suitable for OTA update, including but not limited to the vehicle engine being in the starting state. Therefore, in some implementations according to the present disclosure, it is first necessary to determine whether the current condition of the vehicle is suitable for OTA update. If not, the exemplary method 200 given in the present disclosure will not be continued. On the other hand, if it is determined that the current condition of the vehicle is suitable for OTA update, it can be determined whether a request to erase the CB block is detected. If the determination result is yes, for example, as described above, it is detected that the update package received via OTA contains an erase instruction that specifies to erase the CB block, then the method 200 can start to execute step 210, that is, reset the existing backup success flag for the CB block.

[0058] Combined with the above Figure 2A An exemplary process of updating the CB block according to some implementations of the present disclosure is described. It is understood that if the update package downloaded via OTA includes updates to the contents of the ASW block and / or DS block in addition to the updates to the contents of the CB block, then after executing the combined Figure 2A After the related operations described, the contents of the ASW block and / or DS block continue to be updated, and the corresponding process will not be repeated here.

[0059] On the other hand, according to some implementations of the present disclosure, if a failure is encountered during the erase operation or write operation in the aforementioned step 240, it is possible to jump to the execution Figure 2B The flow of the exemplary method 250 shown is to implement rollback. In some implementations, the method 250 may also be considered as a part of the method 200.

[0060] like Figure 2B As shown, the exemplary method 250 may include step 260, in which, in the case where it is determined that a fault is encountered during the erasing or the writing, it is checked whether the backup success flag for the CB block is valid. As previously described, in the process of updating the CB block, the first boot program stored in the CB block is backed up using at least one of the ASW backup block and the DS backup block (step 220), and after the backup is completed, the backup success flag for the CB block is set (step 230). Therefore, in the case where the backup is successfully performed in the above manner, it will be determined in step 260 that the backup success flag is valid (for example, the flag value is 1). On the contrary, if it is determined in step 260 that the backup success flag is invalid (for example, the flag value is 0), it indicates that the process of updating the CB block is abnormal, and the execution of the method is exited. This means that the vehicle may need to return to the maintenance site and / or rely on professionals to troubleshoot the problem.

[0061] If it is determined in step 260 that the backup success flag is valid, then the process may proceed to step 270, in which the CB block is erased again and the first boot program backed up using at least one of the ASW backup block and the DS backup block is written back to the CB block. As an example, the operation of step 270 may include reading the backed-up first boot program from the ASW backup block 350 and / or the DS backup block 360 (for example, reading based on the start address and length previously recorded for saving the backup content), and rewriting the read first boot program to the erased CB block 310. Thus, the rollback of the content in the CB block is achieved.

[0062] In addition, in some implementations according to the present disclosure, determining in step 260 that a fault is encountered during the erasing or writing may include: determining that the vehicle control unit cannot boot to the ASW block within a preset time during the startup process, and the inability to boot is not caused by the received specified instruction. In some implementations, if the vehicle control unit exceeds the preset time (e.g., 5 seconds) during the startup process during the OTA update and still cannot boot to the ASW block 320, this may imply that the second boot program newly stored in the CB block 310 may not be able to continue to execute due to a fault or other reasons. In this case, in some implementations, it will be further determined whether this inability to boot is caused by receiving a specified instruction. As an example, if this inability to boot is due to receiving other update instructions from the host computer, it means that a fault is not really encountered during the erasing or writing. On the other hand, if it is determined that the inability to boot is not caused by the received specified instruction, it means that a fault is encountered during the erasing or writing, and accordingly, the check operation of step 260 and the re-erase and write-back operation of step 270 need to be performed to achieve rollback.

[0063] In addition, in some implementations according to the present disclosure, determining in step 260 that a failure is encountered during the erasing or the writing may also include: determining that the validity mark for the CB block is invalid. As mentioned above, in some implementations, after the writing operation of step 240 is completed, the validity mark for the CB block is set to indicate the data integrity of the content of the updated CB block. If the validity mark is found to be invalid, it means that a failure is encountered during the erasing or the writing of the aforementioned step 240, and therefore a rollback is required through steps 260 and 270.

[0064] In addition, in some implementations according to the present disclosure, method 250 may further include setting a validity mark for the CB block after the writeback is completed in step 260. In this case, the validity mark is used to indicate the data integrity of the content of the rolled back CB block.

[0065] With the aid of the mechanism for OTA updating of the vehicle proposed in the present disclosure, corresponding backup and rollback in the event of a failure can be supported during the updating of the CB block, without the need to set a separate CB backup block for the CB block in the non-volatile memory of the vehicle control unit, thereby effectively reducing the hardware cost of the vehicle control unit and enhancing the adaptability of OTA updates.

[0066] Reference below Figure 5, which shows a block diagram of an exemplary apparatus 500 according to some implementations of the present disclosure. The apparatus 500 may be implemented, for example, in a control unit of a vehicle to implement the mechanism described herein for performing OTA updates on the vehicle.

[0067] like Figure 5 As shown, the device 500 may include a unit 510, which is used to reset the existing backup success flag for the CB block in response to detecting a request to erase the CB block. The device 500 may also include a unit 520, which is used to use at least one of the ASW backup block and the DS backup block to back up the first boot program stored in the CB block. The device 500 may also include a unit 530, which is used to set the backup success flag for the CB block after the backup is completed. In addition, the device 500 may also include a unit 540, which is used to erase the CB block and write a second boot program different from the first boot program into the CB block.

[0068] In some implementations, the apparatus 500 may further include additional units for performing other operations described in the specification, such as combining Figure 2A , 2B The operations described in the flowchart of the exemplary method and its variations are shown in FIG. 5 . In addition, in some implementations, the various units of the device 500 may be combined or split depending on actual needs. It will be appreciated by those skilled in the art that the exemplary device 500 may be implemented using software, hardware, firmware, or any combination thereof.

[0069] Figure 6 A block diagram of an exemplary computing device 600 according to some implementations of the present disclosure is shown. The computing device 600 may be implemented, for example, in a control unit of a vehicle to implement the mechanism described herein for performing OTA updates on the vehicle.

[0070] like Figure 6 As shown, the computing device 600 may include at least one processor 610. The processor 610 may include any type of general-purpose processing unit, special-purpose processing unit, core, circuit, controller, etc. In addition, the computing device 600 may also include a memory 620. The memory 620 may include any type of medium that can be used to store data. In some implementations, the memory 620 is configured to store instructions that, when executed, cause the at least one processor 610 to perform the operations described herein, for example, in conjunction with Figure 2A , 2B The operations are described in conjunction with flowcharts of exemplary methods and variations thereof.

[0071] Furthermore, in some implementations, the computing device 600 is also equipped with a communication interface, which can support various types of wired / wireless communication protocols to communicate with a communication network.

[0072] Those skilled in the art will appreciate that the above description of the structure of the computing device 600 is merely exemplary and not restrictive, and devices with other structures are also feasible as long as they can be used to implement the functions described herein.

[0073] Various implementations of the present disclosure may include or operate multiple components, parts, units, modules, instances or mechanisms, which may be implemented in hardware, software, firmware, or any combination thereof. Examples of hardware may include, but are not limited to: devices, processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), storage units, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software may include, but are not limited to: software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, software modules, routines, subroutines, functions, methods, processes, software interfaces, application programming interfaces (APIs), instruction sets, computer codes, computer code segments, words, values, symbols, or any combination thereof. Determining whether an implementation is implemented using hardware, software, and / or firmware can vary depending on a variety of factors, such as desired computational rates, power levels, thermal tolerances, processing cycle budgets, input data rates, output data rates, memory resources, data bus speeds, and other design or performance constraints as desired for a given implementation.

[0074] Some implementations described herein may include articles of manufacture. Articles of manufacture may include storage media. Examples of storage media may include volatile and non-volatile, removable and non-removable media implemented by any method or technology to store information (e.g., computer-readable instructions, data structures, program modules, or other data). Storage media may include, but are not limited to: random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk (CD), digital versatile disk (DVD) or other optical storage, cassette, tape, disk storage or other magnetic storage device, or any other medium capable of storing information. In some implementations, articles of manufacture may store executable computer program instructions that, when executed by one or more processing units, cause the processing units to perform the operations described herein. Executable computer program instructions may include any suitable type of code, for example, source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. Executable computer program instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0075] Some exemplary implementations of the present disclosure are described below.

[0076] Example 1 may include a method for OTA updating a vehicle, wherein a non-volatile memory of a vehicle control unit is divided into a plurality of blocks, the plurality of blocks including a customer boot program (CB) block, an application program (ASW) block, a data set (DS) block, an ASW backup block corresponding to the ASW block, and a DS backup block corresponding to the DS block, the method comprising: in response to detecting a request to erase the CB block, resetting an existing backup success flag for the CB block; backing up a first boot program stored in the CB block using at least one of the ASW backup block and the DS backup block; after the backup is completed, setting a backup success flag for the CB block; and erasing the CB block and writing a second boot program different from the first boot program into the CB block.

[0077] Example 2 may include the subject matter described in Example 1, wherein the method further comprises: resetting an existing validity flag for the CB block before performing the erasing; and setting a validity flag for the CB block after the writing is completed.

[0078] Example 3 may include the subject matter of any one of Examples 1-2, wherein backing up the first boot program stored in the CB block using at least one of the ASW backup block and the DS backup block includes: backing up the first boot program within the ASW backup block; or backing up the first boot program within the DS backup block; or backing up the first boot program across the ASW backup block and the DS backup block.

[0079] Example 4 may include the subject matter of any one of Examples 1-3, wherein the method further comprises: in a case where it is determined that a failure is encountered during the erasing or the writing, checking whether a backup success flag for the CB block is valid; and in response to the backup success flag for the CB block being valid, re-erasing the CB block and writing the first boot program backed up using at least one of the ASW backup block and the DS backup block back to the CB block.

[0080] Example 5 may include the subject matter of any one of Examples 1-4, wherein determining that a failure is encountered during the erasing or the writing includes: determining that the vehicle control unit cannot boot to the ASW block within a preset time period during startup and the inability to boot is not caused by receiving a specified instruction.

[0081] Example 6 may include the subject matter of any one of Examples 1-5, wherein determining that a failure is encountered during the erasing or the writing further includes determining that a validity mark for the CB block is invalid, and the method further includes setting a validity mark for the CB block after the write back is completed.

[0082] Example 7 may include the subject matter of any one of Examples 1-6, wherein the method further includes: determining whether the current condition of the vehicle is suitable for OTA update; and in response to determining that the current condition of the vehicle is suitable for OTA update, determining whether a request to erase the CB block is detected.

[0083] Example 8 may include the subject matter of any one of Examples 1-7, wherein the backup success flag is a flag bit stored in the header of the CB block, and wherein the ASW backup block and the DS backup block have at least the same size as the corresponding ASW block and the DS block, respectively.

[0084] Example 9 may include an apparatus for performing OTA updates on a vehicle, wherein a non-volatile memory of a vehicle control unit is divided into a plurality of blocks, the plurality of blocks including a customer boot program (CB) block, an application program (ASW) block, a data set (DS) block, an ASW backup block corresponding to the ASW block, and a DS backup block corresponding to the DS block, the apparatus including: a unit for resetting an existing backup success flag for the CB block in response to detecting a request to erase the CB block; a unit for backing up a first boot program stored in the CB block using at least one of the ASW backup block and the DS backup block; a unit for setting a backup success flag for the CB block after the backup is completed; and a unit for erasing the CB block and writing a second boot program different from the first boot program into the CB block.

[0085] Example 10 may include the subject matter described in Example 9, wherein the device further includes: a unit for resetting an existing validity mark for the CB block before performing the erasing; and a unit for setting the validity mark for the CB block after the writing is completed.

[0086] Example 11 may include the subject matter of any one of Examples 9-10, wherein backing up the first boot program stored in the CB block using at least one of the ASW backup block and the DS backup block includes: backing up the first boot program within the ASW backup block; or backing up the first boot program within the DS backup block; or backing up the first boot program across the ASW backup block and the DS backup block.

[0087] Example 12 may include the subject matter of any one of Examples 9-11, wherein the device further includes: a unit for checking whether a backup success flag for the CB block is valid when it is determined that a failure is encountered during the erasing or the writing; and a unit for re-erasing the CB block and writing the first boot program backed up using at least one of the ASW backup block and the DS backup block back to the CB block in response to the backup success flag for the CB block being valid.

[0088] Example 13 may include the subject matter of any one of Examples 9-12, wherein determining that a failure is encountered during the erasing or the writing includes: determining that the vehicle control unit cannot boot to the ASW block within a preset time period during startup and the inability to boot is not caused by receiving a specified instruction.

[0089] Example 14 may include the subject matter of any of Examples 9-13, wherein determining that a failure is encountered during the erasing or the writing further includes determining that a validity mark for the CB block is invalid, and the device further includes a unit for setting the validity mark for the CB block after the write back is completed.

[0090] Example 15 may include the subject matter of any one of Examples 9-14, wherein the device further includes: a unit for determining whether the current condition of the vehicle is suitable for OTA update; and a unit for determining whether a request to erase the CB block is detected in response to determining that the current condition of the vehicle is suitable for OTA update.

[0091] Example 16 may include the subject matter of any one of Examples 9-15, wherein the backup success flag is a flag bit stored in the header of the CB block, and wherein the ASW backup block and the DS backup block have at least the same size as the corresponding ASW block and the DS block, respectively.

[0092] Example 17 may include a computing device comprising: at least one processor; and a memory coupled to the at least one processor and used to store instructions, wherein the instructions, when executed by the at least one processor, cause the at least one processor to perform the method described in any one of the aforementioned Examples 1-8.

[0093] Example 18 may include a computer-readable storage medium having instructions stored thereon, which, when executed by at least one processor, cause the at least one processor to perform the method described in any one of the foregoing Examples 1-8.

[0094] Example 19 may include a computer program product comprising instructions that, when executed by at least one processor, cause the at least one processor to perform the method of any of the foregoing Examples 1-8.

[0095] What has been described above includes examples of the disclosed architecture. It is certainly not possible to describe every conceivable combination of components and / or methods, but those skilled in the art will appreciate that many other combinations and permutations are possible. Therefore, the novel architecture is intended to encompass all such substitutions, modifications, and variations that fall within the spirit and scope of the appended claims.

Claims

1. A method for performing OTA updates on a vehicle, in, The non-volatile memory of the vehicle control unit is divided into a plurality of blocks, the plurality of blocks including a customer boot program (CB) block, an application program (ASW) block, a data set (DS) block, an ASW backup block corresponding to the ASW block, and a DS backup block corresponding to the DS block, the method comprising: In response to detecting a request to erase the CB block, resetting an existing backup success flag for the CB block; Backing up the first boot program stored in the CB block using at least one of the ASW backup block and the DS backup block; After the backup is completed, setting a backup success flag for the CB block; and The CB block is erased and a second boot program different from the first boot program is written into the CB block.

2. The method according to claim 1, further comprising: include: Before performing the erasing, resetting the existing validity flag for the CB block; as well as After the write is completed, the validity flag for the CB block is set.

3. The method according to claim 2, in, Backing up the first boot program stored in the CB block by using at least one of the ASW backup block and the DS backup block includes: backing up the first boot program in the ASW backup block; or backing up the first boot program in the DS backup block; or The first boot program is backed up across the ASW backup block and the DS backup block.

4. The method according to claim 3, further comprising: include: In case it is determined that a failure is encountered during the erasing or the writing, checking whether a backup success flag for the CB block is valid; as well as In response to the backup success flag for the CB block being valid, the CB block is re-erased and the first boot program backed up by using at least one of the ASW backup block and the DS backup block is written back to the CB block.

5. The method according to claim 4, in, Determining that a failure is encountered during the erasing or the writing includes: It is determined that the vehicle control unit cannot boot to the ASW block within a preset time period during startup and the failure to boot is not caused by receiving a specified instruction.

6. The method according to claim 5, in, Determining that a failure is encountered during the erasing or the writing further includes determining that a validity flag for the CB block is invalid, and the method further includes setting a validity flag for the CB block after the write-back is completed.

7. The method according to any one of claims 1 to 6, further comprising: include: Determining whether a current condition of the vehicle is suitable for OTA update; as well as In response to determining that the current condition of the vehicle is suitable for OTA update, it is determined whether a request to erase the CB block is detected.

8. The method according to any one of claims 1 to 6, in, The backup success flag is a flag bit stored in the header of the CB block, and wherein the ASW backup block and the DS backup block have at least the same size as the corresponding ASW block and the DS block respectively.

9. A device for performing OTA updates on a vehicle, in, The non-volatile memory of the vehicle control unit is divided into a plurality of blocks, the plurality of blocks including a customer boot program (CB) block, an application program (ASW) block, a data set (DS) block, an ASW backup block corresponding to the ASW block, and a DS backup block corresponding to the DS block, the device comprising: A unit for resetting an existing backup success flag for the CB block in response to detecting a request to erase the CB block; a unit for backing up the first boot program stored in the CB block using at least one of the ASW backup block and the DS backup block; a unit for setting a backup success flag for the CB block after the backup is completed; and A unit for erasing the CB block and writing a second boot program different from the first boot program into the CB block.

10. A computer-readable storage medium having instructions stored thereon, wherein when the instructions are executed by at least one processor, the at least one processor executes the method according to any one of claims 1-8.

Images