Electronic control unit program backup and recovery method and device, equipment and medium

Abstract

The invention provides an electronic control unit program backup and recovery method and device, equipment and a medium, and relates to the technical field of vehicle control. The method comprises the following steps: setting an information header and a block index table at an initial position of a second region of the memory; before the first area is updated, performing block compression on codes of the first area to obtain compressed data, and writing the compressed data, the information header and the block index table into the second area for data backup to form backup data; in response to a flash event, executing the data backup operation before erasing the first area; under the condition that data backup succeeds, flashing operation is executed on the first area, and the updated codes of the first area are run after flashing succeeds; and decompressing and restoring the compressed data blocks of the second area to the first area according to the information header and the block index table under the condition that flashing fails. By adopting the method, resource waste can be reduced, and safety can be improved.

Description

Technical Field

[0001] This disclosure relates to the field of vehicle control technology, and in particular to a method, apparatus, device and medium for backing up and restoring electronic control unit programs. Background Technology

[0002] With the continuous development of electric vehicles and intelligent driving technologies, software plays an increasingly important role in vehicle control. During ECU (Electronic Control Unit) flashing, to ensure vehicle domain information security and the smooth progress of the flashing process, and to prevent ECU bricking or other more serious safety incidents caused by flashing interruptions, data corruption, or software defects, an AB backup mechanism is typically adopted. Area A stores the currently running software version, while area B serves as a backup and update area. When selecting an ECU, a main control chip with sufficient FLASH (flash memory) resources is usually chosen, or a chip with memory address mapping redirection capabilities is selected at a higher cost. This requires at least twice the backup area CFLASH (code flash memory) space resources, with half of the resources wasted storing older versions of the program that are not needed, resulting in resource waste. Summary of the Invention

[0003] This disclosure provides a method, apparatus, device, and medium for backing up and restoring electronic control unit programs.

[0004] According to a first aspect of this disclosure, a method for backing up and restoring electronic control unit programs is provided, comprising: An information header and a block index table are set at the beginning of the second area of ​​the memory; wherein, the block index table includes compressed block information; Before performing the first zone update, the code in the first zone is compressed into blocks to obtain compressed data. The compressed data, along with the information header and the block index table, is written into the second zone for data backup to form backup data. In response to a write event, the data backup operation is performed before erasing the first area; If the data backup is successful, perform a flash operation on the first region, and run the updated code for the first region after the flash is successful. In the event of a failed write operation, the compressed data of the second region is decompressed and restored to the first region in blocks according to the information header and the block index table.

[0005] According to a second aspect of this disclosure, an electronic control unit program backup and recovery device is provided, comprising: The setting module is used to set an information header and a block index table at the beginning of the second area of ​​the memory; wherein the block index table includes compressed block information; The backup module is used to compress the code in the first area into blocks before performing the update of the first area to obtain compressed data, and write the compressed data, the information header, and the block index table into the second area for data backup to form backup data; The write module is used to perform the data backup operation in response to a write event before erasing the first area; The update module is used to perform a flash operation on the first zone when the data backup is successful, and to run the updated code of the first zone after the flash is successful. The rollback module is used to decompress and restore the compressed data of the second area to the first area in the event of a flash failure, based on the information header and the block index table.

[0006] According to a third aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method described in the first aspect above.

[0007] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are configured to cause the computer to perform the method described in the first aspect above.

[0008] According to a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0009] In embodiments of this disclosure, an information header and a block index table are set at the beginning of the second region of the memory; wherein the block index table includes compressed block information; before performing an update of the first region, the code in the first region is compressed into blocks to obtain compressed data, and the compressed data, the information header, and the block index table are written into the second region for data backup to form backup data; in response to a flash event, the data backup operation is performed before erasing the first region; if the data backup is successful, a flash operation is performed on the first region, and the updated code in the first region is run after a successful flash; if the flash fails, the compressed data in the second region is decompressed and restored to the first region in blocks according to the information header and the block index table. In this way, by forcibly compressing the backup before updating the first zone and solidifying the metadata in the second zone, a strong binding between version information and backup content can be achieved, avoiding version inconsistencies. Moreover, by using a combination of header-based segmented indexing and segmented compression, the backup space requirement can be effectively reduced, saving FLASH resources and reducing resource waste. Furthermore, by using backup before flashing and automatic rollback in case of failure, a double insurance can be formed, ensuring that even if the flashing fails, it can be restored to a usable state, thereby improving the security of OTA upgrades.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 A flowchart illustrating an electronic control unit program backup and recovery method provided in this embodiment of the disclosure; Figure 2 A schematic diagram of memory allocation for a system for performing the methods of the embodiments of this disclosure is provided for the purposes of this disclosure. Figure 3 A flowchart illustrating another method for backing up and restoring electronic control unit programs provided in this embodiment of the present disclosure; Figure 4 This is a schematic diagram of the structure of an electronic control unit program backup and recovery device provided in an embodiment of this disclosure. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] As the background technology shows, drive-by-wire chassis products are increasingly used in vehicle design, and software plays an increasingly important role in vehicle control. When vehicle software needs to be upgraded or optimized, ECU remapping is usually used. For example, during ECU remapping, especially during OTA (Over-The-Air) downloads, to ensure vehicle domain information security and the smooth progress of the remapping process, and to prevent ECU bricking or other more serious safety incidents caused by remapping interruptions, data corruption, or software defects, an AB backup mechanism is typically adopted. The AB backup mechanism divides the ECU's non-volatile memory into two or more logically independent areas: area A and area B. Area A stores the currently running software version, while area B serves as a backup and update area. The AB backup mechanism ensures that at any given time, there is always a usable and complete software version in the system, improving system robustness. In practical applications, areas A and B are usually designed to be of equal size and mirror-symmetric, and the two areas are often required to operate alternately.

[0014] Therefore, when selecting an ECU, a common approach is to choose a main control chip with sufficient FLASH resources, or to increase costs by selecting a chip with memory address mapping redirection functionality. This approach presents at least the following technical problems: it requires at least twice the backup CFLASH (Code Flash) space, with half of the resources wasted storing older, unused versions of the program; if only a software solution is used to implement A / B area swapping, a complex version management storage record process and comparison strategies are required, and the most common application of A / B partitioning—automatic backup and automatic rollback—increases the risk of version strategy errors, and repeated updates to the version storage area reduce its FLASH lifespan; a hardware solution simplifies version management but requires a chip with memory address mapping redirection functionality.

[0015] Based on this, this disclosure provides a method for backing up and restoring an electronic control unit program. An information header and a block index table can be added at the beginning of area B (second area). The block index table records block information during compression for use in block decompression; the information header records information such as version, content verification, and data length. To avoid version management issues and reduce FLASH write cycles, all data (including the area B information header, block index table, and compressed data) is written uniformly during area B backup. This prevents discrepancies between version information and backup content; during rollback, the compressed data can be restored to the correct address in blocks based on the fixed-length header and block index table; finally, the entire content can be verified, and the valid flag bit of area A (first area) can be updated.

[0016] The following description, with reference to the accompanying drawings, outlines a method, apparatus, device, and medium for backing up and restoring electronic control unit programs according to embodiments of the present disclosure.

[0017] Figure 1 This is a flowchart illustrating an electronic control unit program backup and recovery method provided in an embodiment of this disclosure. Figure 1 As shown, the electronic control unit program backup and recovery method may include the following steps: Step 101: Set an information header and a block index table at the beginning of the second area of ​​the memory; wherein the block index table includes compressed block information.

[0018] In the embodiments of this disclosure, the header and block index table can be configured first. For example, the header and block index table can be permanently configured at the starting address of the second region (such as region B). The header can be a fixed-length structure, containing: version information, recording the version number of the currently backed-up program; verification information, storing the cyclic redundancy check code of the backup data; and data length, indicating the total number of bytes of the compressed data. The block index table can be a dynamically lengthened array, where each index entry can record the original starting address, compressed length, and block check value of the corresponding compressed block. It is understood that the header and block index table configuration can be established during the initial partition formatting, and subsequent backup operations only update their contents without changing their storage location.

[0019] Step 102: Before performing the update of the first area, the code in the first area is compressed into blocks to obtain compressed data. The compressed data, along with the information header and the block index table, is written into the second area for data backup to form backup data.

[0020] In the embodiments of this disclosure, before executing the program update of the first region (e.g., region A), the BOOT program can start the compression engine to compress the complete code image of region A using a block compression algorithm to obtain compressed data. For example, the compression process can read region A data block by block according to a fixed block size (e.g., 4KB), generate compressed blocks, and write them sequentially to the data field of region B. Simultaneously, the information header and the block index table can be synchronously updated to the beginning position of region B to ensure that all three can be written uniformly, avoiding inconsistencies between metadata and backup content.

[0021] Step 103: In response to the write event, perform a data backup operation before erasing the first partition.

[0022] In the embodiments of this disclosure, a pre-backup can be performed before flashing. For example, when the BOOT program receives a flash event (such as a 0x34 service request), it can trigger a data backup operation before calling the underlying driver to erase area A. If the backup fails, the backup process is repeated until it succeeds or the cumulative number of failures reaches a preset threshold (such as 3 times). If the flashing event still fails after reaching the threshold, the flashing event is terminated, and a negative response code is returned via the UDS protocol to prevent unsafe flashing behavior.

[0023] Step 104: If the data backup is successful, perform a flash operation on the first zone, and run the updated code for the first zone after the flash is successful.

[0024] In the embodiments disclosed herein, if the data backup is successful, the BOOT program allows the execution of the normal A-zone flashing process, writing the received new program image to A-zone. Understandably, after flashing is complete, a hardware reset can be performed, jumping to the A-zone entry address to run the updated code. At this time, the old version backup retained in B-zone serves as redundancy protection and will not be accessed during normal system operation.

[0025] Step 105: In the event of a failed write operation, the compressed data of the second region is decompressed and restored to the first region according to the information header and the block index table.

[0026] In the embodiments of this disclosure, if a flashing failure occurs during the flashing process (such as a verification error, write timeout, etc.), and after a reset it is detected that the valid flag for area A is invalid while the valid flag for area B is valid, a rollback process can be triggered. For example, the BOOT program can read the header information of area B to obtain version information and verification information, and according to the address mapping relationship in the block index table, decompress the compressed data block by block and restore it to the original address space of area A, thus completing the rollback.

[0027] In embodiments of this disclosure, an information header and a block index table are set at the beginning of the second region of the memory; wherein the block index table includes compressed block information; before performing an update of the first region, the code in the first region is compressed into blocks to obtain compressed data, and the compressed data, the information header, and the block index table are written into the second region for data backup to form backup data; in response to a flash event, the data backup operation is performed before erasing the first region; if the data backup is successful, a flash operation is performed on the first region, and the updated code in the first region is run after a successful flash; if the flash fails, the compressed data in the second region is decompressed and restored to the first region in blocks according to the information header and the block index table. In this way, by forcibly compressing the backup before updating the first zone and solidifying the metadata in the second zone, a strong binding between version information and backup content can be achieved, avoiding version inconsistencies. Moreover, by using a combination of header-based segmented indexing and segmented compression, the backup space requirement can be effectively reduced, saving FLASH resources and reducing resource waste. Furthermore, by using backup before flashing and automatic rollback in case of failure, a double insurance can be formed, ensuring that even if the flashing fails, it can be restored to a usable state, thereby improving the security of OTA upgrades.

[0028] In some possible implementations, a data backup operation is performed before erasing the first region, including: If data backup fails, re-execute the data backup operation; If the number of data backup attempts is greater than or equal to the preset number and the data backup operation still fails, the write event will be terminated and a backup failure message will be output.

[0029] In the embodiments of this disclosure, after the BOOT program responds to the write event and initiates the data backup process, the execution status of the backup operation can be monitored in real time. If the data backup fails (e.g., compression process error, data read verification failure after writing to the second area, or timeout in writing the header and block index table), the BOOT program can automatically trigger a retry mechanism. For example, some backup data already written to the second area can be erased to prevent dirty data residue; then the compression and writing process can be re-executed. It is understood that for each retry, the failure count counter can be incremented by 1 to accumulate the number of retries. If the number of data backups performed is greater than or equal to a preset number and the backup still fails, the write event can be terminated. For example, if the number of data backups performed is greater than or equal to a preset number and the backup still fails, it can be determined as a persistent hardware failure or memory damage, and the write event can be terminated. For example, terminating the write event may include: stopping the UDS diagnostic session, releasing the write buffer, and setting an error status code in the DFLASH. Simultaneously, it can also provide feedback on backup failures. For example, it can send a negative response code to the host computer via the UDS (Unified Diagnostic Service) protocol, indicating "backup failure," causing the host computer to stop the subsequent flashing process and prompt the operator to troubleshoot hardware problems. Thus, through a closed-loop control of "failure detection - automatic retry - threshold termination," the fault tolerance of backup operations can be significantly improved. Moreover, the retry mechanism can effectively filter out occasional failures caused by transient interference, and threshold control can prevent infinite loops under persistent faults, thereby balancing reliability and system response efficiency. Furthermore, outputting clear failure information makes the flashing process traceable, facilitating after-sales diagnosis and quality analysis.

[0030] In some possible implementations, the header includes at least one of version information, verification information, and data length; In the event of a write failure, the compressed data in the second region is decompressed and restored to the first region in blocks based on the header and block index table, including: In the event of a failed flash, retrieve the version information and verification information from the header. Based on the compressed block information in the block index table, the compressed data in the second area is decompressed and restored to the first area; After decompressing and restoring the compressed data from the second region to the first region in blocks, the decompressed data from the first region is verified based on the verification information. If the data verification after decompression passes, update the valid flag of the first area to a valid running status to achieve rollback.

[0031] In the embodiments of this disclosure, when the write operation fails (e.g., the first zone validity flag is not set, CRC check mismatch, or write timeout), the BOOT program can immediately enter the rollback recovery process. For example, the header can be read from the beginning of the second zone, extracting the version information and verification information (such as CRC (Cyclic Redundancy Check)). The version information can be used to confirm the consistency between the backup data version number and the target version to be rolled back, preventing rollback to an incorrect version due to data corruption in the backup zone; the verification information can serve as a benchmark value for subsequent data integrity verification. Then, compressed block information can be obtained from the block index table. This compressed block information may include, for example, the original starting address of the compressed block, its compressed length, and the offset within the block. Each compressed block data is then read from the second zone, and the decompression algorithm is called to decompress it block by block. The decompressed data is written to the corresponding position in the first zone strictly according to the original address information recorded in the index table. After all blocks have been decompressed and restored, the cyclic redundancy check code can be recalculated for the complete data range of the first zone, and the calculation result can be compared with the verification information. If the calculated cyclic redundancy check (CRC) code matches the verification information, it proves that no bit flips or data corruption occurred during the storage and recovery process, and the rollback data is complete and reliable. At this point, the valid flag in the first area can be updated to "valid running status," and the rollback flag in the second area can be cleared, indicating that the rollback process has been successfully completed. Conversely, if the verification fails, meaning the calculated CRC code does not match the verification information, it can be determined that the backup data is corrupted, and the rollback aborts. In this case, the system can remain in BOOT mode awaiting further instructions to prevent the execution of corrupted code from causing security risks. Thus, by enabling automatic and safe recovery after a failed flash, vehicle function loss or system paralysis caused by a flash failure can be avoided, thereby improving the security of vehicle software updates and the user experience.

[0032] In some possible implementations, it also includes: In the absence of a write event, receive active commands; wherein, active commands include at least one of active rollback commands and active backup commands; In response to an active command, a target operation is executed; wherein the target operation includes at least one of a rollback operation and a data backup operation.

[0033] In the embodiments of this disclosure, when the system is in normal operation and no write event occurs (i.e., no UDS protocol 0x34 service request is received), the BOOT program can continue to listen to the UDS diagnostic channel, waiting to receive active commands from the host computer diagnostic instrument. For example, active commands may include active rollback commands and active backup commands. In response to the received active command, the BOOT program can perform the corresponding rollback operation or data backup operation. For example, if the active command is an active rollback command, a rollback operation can be triggered, such as reading the header and index table of area B, decompressing the compressed data in blocks and restoring it to area A, activating the valid flag of area A after passing CRC verification, and realizing version rollback. If the active command is an active backup command, a data backup operation can be triggered, such as compressing the current code in area A and writing it to area B, updating the header and index table. Thus, by opening the active command interface when there is no write event, the system version status can be actively controlled, thereby shortening the time for troubleshooting and version repair.

[0034] In some possible implementations, active commands and write events are handled through a unified diagnostic service. Using the UDS protocol to uniformly carry write events and active commands enables integrated diagnostic functionality, eliminating the need to develop separate proprietary protocols for backup and rollback functions, thereby reducing system complexity and development costs.

[0035] In some possible implementations, the code in the first region is compressed in blocks to obtain compressed data, including: The code in the first section is compressed using a block compression algorithm to obtain compressed data.

[0036] In the embodiments of this disclosure, the compression of the first region code can be implemented using a block compression algorithm. For example, the first region can be divided into fixed-size compression units based on the total length of the first region code image and the available RAM (Random Access Memory) buffer size; then, a compression algorithm (such as LZ77 or a Huffman coding variant) is independently called for each data block to generate variable-length compressed blocks. During compression, the CRC check value of each block is calculated synchronously, and the original starting address, original length, and compressed length are recorded in a temporary cache. Afterwards, all compressed blocks can be sequentially and continuously written into the data field of the second region, immediately following the header and the block index table. The block index table can establish an entry for each compressed block, and the entry mapping relationship can be: original address → offset and length of the compressed block in the second region. Thus, using a block compression algorithm can significantly reduce the backup storage space requirements, thereby further reducing resource consumption.

[0037] In some possible implementations, the decompressed data of the first region is verified based on verification information, including: Calculate the cyclic redundancy check code of the decompressed data in the first region; If the cyclic redundancy check code matches the check information in the header, the data after decompression of the first block is confirmed to have passed the check.

[0038] In the embodiments of this disclosure, when verifying the decompressed data of the first region based on the verification information, the same algorithm used during data backup can be employed to calculate the cyclic redundancy check (CRC) code of the complete data range of the first region (from the starting address to the data length recorded in the header) byte by byte to obtain the CRC code of the decompressed data of the first region. Then, the CRC checksum (verification information) pre-stored during backup can be read from the header of the second region. The calculated CRC code of the decompressed data of the first region is then compared bit-by-bit with the CRC checksum pre-stored during backup read from the header of the second region. If the CRC code is the same as the verification information in the header (i.e., the XOR result is 0), it is determined that they are the same, indicating that no data corruption occurred during the decompression and writing process, and the verification of the decompressed data of the first region is confirmed to have passed. If the CRC code is different from the verification information in the header (i.e., the XOR result is not 0), it is marked as a verification failure. Thus, through the verification comparison mechanism, the consistency between the code restored to the first region and the original code during backup can be further improved.

[0039] To make the methods provided in this disclosure clearer, the following examples will be used for illustration.

[0040] like Figure 2 As shown, the memory allocation of the system used to perform the methods of the embodiments of this disclosure can be found in [reference needed]. Figure 2 On the left, an information header and a block index table (as shown in Table 1) can be added at the beginning of area B. The block index table can be used to record the block information during compression for block decompression. The information header can be used to record information such as version, content verification, and data length. To avoid version management policy issues and reduce the number of FLASH erase / write cycles, all data (area B information header, block index table, and compressed data) is written uniformly during backup of area B (i.e., area two). There will be no mismatch between version information and backup content. During rollback, the data in the compressed area is restored to the correct address in blocks according to the fixed-length header and block index table. Finally, the entire content is verified and the valid flag bit of area A (i.e., area one) is updated.

[0041] Table 1

[0042] See Figure 3 , Figure 3 This is a flowchart illustrating another method for backing up and restoring electronic control unit programs provided in an embodiment of this disclosure. Figure 3 As shown, the specific implementation flow of the BOOT program can be as follows: First, the hardware used in BOOT is initialized to determine if there is a flashing requirement.

[0043] If a data flashing process is required, a data backup must be performed before the host computer sends the UDS protocol erase step. If the backup fails, multiple attempts should be made (maximum number of attempts, e.g., 3). If backups consistently fail, the failure result should be reported to the host computer to stop the flashing process. If the backup is successful, normal flashing can proceed. If the flashing is successful, a reset and restart can be performed. At this point, if no other active commands are received, the updated code for area A can be executed. If the flashing fails, the update process can be exited, and after a timeout reset, it can be determined whether area A is marked as invalid and area B as valid. If area A is marked as invalid and area B as valid, an automatic rollback can be performed, or an active rollback command can be received to execute the rollback program, restoring the compressed file from area B to area A.

[0044] If there is no need to flash the firmware, it also supports setting corresponding flags through active rollback and active backup commands to make the program actively enter the corresponding rollback or backup strategy.

[0045] Thus, on the one hand, block compression can effectively reduce the size of the backup area; on the other hand, writing the information header, block index table and compressed data content into area B can effectively reduce the number of times the A and B areas are alternately updated, ensuring that the program content corresponds to the version; furthermore, it can avoid the hardware limitations of supporting address mapping redirection function, reducing costs; at the same time, it can also optimize the execution life of FLASH operations.

[0046] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0047] According to embodiments of this disclosure, this disclosure also provides an electronic control unit program backup and recovery device. Figure 4 This is a schematic diagram of an electronic control unit program backup and recovery device provided in an embodiment of the present disclosure. The electronic control unit program backup and recovery device 400 includes: The setting module 410 is used to set an information header and a block index table at the beginning of the second area of ​​the memory; wherein the block index table includes compressed block information; Backup module 420 is used to compress the code in the first area into blocks before performing the first area update, and write the compressed data, the information header, and the block index table into the second area for data backup to form backup data; The write module 430 is used to perform the data backup operation in response to a write event before erasing the first area; The update module 440 is used to perform a flash operation on the first zone when the data backup is successful, and to run the updated code of the first zone after the flash is successful. The rollback module 450 is used to decompress and restore the compressed data of the second area to the first area in the event of a flash failure, based on the information header and the block index table.

[0048] Furthermore, the writing module 430 is used for: If data backup fails, re-execute the data backup operation; If the number of data backup attempts is greater than or equal to the preset number and the data backup operation still fails, the write event is terminated and a backup failure message is output.

[0049] Furthermore, the header contains at least one of version information, verification information, and data length; The rollback module 450 is used for: In the event of a failed flash, retrieve the version information and verification information from the header. According to the compressed block information in the block index table, the compressed data of the second area is decompressed and restored to the first area in blocks; After decompressing and restoring the compressed data from the second region to the first region in blocks, the decompressed data from the first region is verified based on the verification information. If the data verification after decompression passes, the valid flag of the first area is updated to a valid running state to achieve rollback.

[0050] Furthermore, it also includes an active operation module for: In the absence of a write event, receive an active instruction; wherein the active instruction includes at least one of an active rollback instruction and an active backup instruction; In response to the active instruction, a target operation is executed; wherein the target operation includes at least one of a rollback operation and a data backup operation.

[0051] Furthermore, the active commands and the write events are implemented through a unified diagnostic service.

[0052] Furthermore, the backup module 420 is used for: The code in the first section is compressed using a block compression algorithm to obtain compressed data.

[0053] Furthermore, the rollback module 450 is also used for: Calculate the cyclic redundancy check code of the decompressed data in the first region; If the cyclic redundancy check code is the same as the check information in the header, it is determined that the data after decompression of the first block has passed the check.

[0054] It should be noted that the description of the features in the embodiment corresponding to the electronic control unit program backup and recovery device can be found in the relevant description of the embodiment corresponding to the electronic control unit program backup and recovery method, and will not be repeated here.

[0055] Embodiments of this disclosure also provide an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.

[0056] Embodiments of this disclosure also provide a computer-readable storage medium storing a computer program configured to perform the steps in any of the above method embodiments when executed.

[0057] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0058] Embodiments of this disclosure also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0059] Embodiments of this disclosure also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0060] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0061] The above provides a detailed description of an electronic control unit program backup and recovery method. Specific examples have been used to illustrate the principles and implementation methods of this disclosure. The descriptions of the embodiments are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this disclosure without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this disclosure.

Claims

1. A method for backing up and restoring electronic control unit programs, characterized in that, include: An information header and a block index table are set at the beginning of the second area of ​​the memory; wherein, the block index table includes compressed block information; Before performing the first zone update, the code in the first zone is compressed into blocks to obtain compressed data. The compressed data, along with the information header and the block index table, is written into the second zone for data backup to form backup data. In response to a write event, perform a data backup operation before erasing the first region; If the data backup is successful, perform a flash operation on the first region, and run the updated code for the first region after the flash is successful. In the event of a failed write operation, the compressed data of the second region is decompressed and restored to the first region in blocks according to the information header and the block index table.

2. The method for backing up and restoring electronic control unit programs according to claim 1, characterized in that, Performing the data backup operation before erasing the first area includes: If data backup fails, re-execute the data backup operation; If the number of data backup attempts is greater than or equal to the preset number and the data backup operation still fails, the write event is terminated and a backup failure message is output.

3. The method for backing up and restoring electronic control unit programs according to claim 1, characterized in that, in, The header contains at least one of version information, verification information, and data length. In the event of a write failure, the compressed data of the second region is decompressed and restored to the first region in blocks according to the information header and the block index table, including: In the event of a failed flash, retrieve the version information and verification information from the header. According to the compressed block information in the block index table, the compressed data of the second area is decompressed and restored to the first area in blocks; After decompressing and restoring the compressed data from the second region to the first region in blocks, the decompressed data from the first region is verified based on the verification information. If the data verification after decompression passes, the valid flag of the first area is updated to a valid running state to achieve rollback.

4. The method for backing up and restoring electronic control unit programs according to claim 1, characterized in that, Also includes: In the absence of a write event, receive an active instruction; wherein the active instruction includes at least one of an active rollback instruction and an active backup instruction; In response to the active instruction, a target operation is executed; wherein the target operation includes at least one of a rollback operation and a data backup operation.

5. The method for backing up and restoring electronic control unit programs according to claim 4, characterized in that, The active commands and the write events are implemented through a unified diagnostic service.

6. The method for backing up and restoring electronic control unit programs according to claim 4, characterized in that, The step of dividing and compressing the code in the first region to obtain compressed data includes: The code in the first section is compressed using a block compression algorithm to obtain compressed data.

7. The method for backing up and restoring electronic control unit programs according to claim 3, characterized in that, The verification of the decompressed data in the first region based on the verification information includes: Calculate the cyclic redundancy check code of the decompressed data in the first region; If the cyclic redundancy check code is the same as the check information in the header, it is determined that the data after decompression of the first block has passed the check.

8. An electronic control unit program backup and recovery device, characterized in that, include: The setting module is used to set an information header and a block index table at the beginning of the second area of ​​the memory; wherein the block index table includes compressed block information; The backup module is used to compress the code in the first area into blocks before performing the update of the first area to obtain compressed data, and write the compressed data, the information header, and the block index table into the second area for data backup to form backup data; The write module is used to perform a data backup operation in response to a write event before erasing the first area; The update module is used to perform a flash operation on the first zone when the data backup is successful, and to run the updated code of the first zone after the flash is successful. The rollback module is used to decompress and restore the compressed data of the second area to the first area in the event of a flash failure, based on the information header and the block index table.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method described in any one of claims 1-7.

Images