Incremental rollback method, device and equipment after vehicle OTA upgrade failure

Abstract

The embodiment of the invention relates to the technical field of vehicles, and discloses an incremental rollback method, device and equipment after vehicle OTA upgrade failure. The method comprises the following steps: at least responding to a user to confirm to start the OTA upgrade of the IVI system, and creating an initial snapshot for the IVI system; after OTA upgrading is started, a file operation behavior in the IVI system is detected in a preset calling mode, and a corresponding behavior tracking operation is executed based on the file operation behavior; in the OTA upgrading process, at least executing periodic inspection on the OTA upgrading progress so as to judge that the vehicle OTA upgrading fails when the OTA upgrading progress meets a preset threshold condition, and then interrupting an OTA upgrading program and triggering an increment rollback process; and in response to triggering of the incremental rollback process, executing an incremental rollback operation. According to the embodiment of the invention, the storage space occupation can be reduced through the incremental rollback mode, the rollback speed is improved, useful data can be reserved, and the vehicle use experience of a user can be improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, and in particular to an incremental rollback method, apparatus, and equipment for vehicle OTA upgrade failure. Background Technology

[0002] With the rapid development of intelligent and connected vehicles, OTA (Over-The-Air) upgrade technology has become a key means to achieve vehicle function iteration, vulnerability patching, and performance optimization. Through OTA technology, automakers can remotely upgrade the vehicle's electronic control unit (ECU) software, in-vehicle operating system, and related applications without requiring users to drive their vehicles to a dealership, greatly improving service efficiency and user experience.

[0003] However, over-the-air (OTA) vehicle upgrades are not absolutely reliable and can fail due to various factors. For example, network interruptions during the upgrade process can result in incomplete upgrade data packet transmission; unexpected power outages during the upgrade process can force its termination; and the upgrade files themselves may be defective or incompatible with the vehicle's hardware. When an OTA upgrade fails, the vehicle's software system may be in an unstable state, or even experience serious problems such as functional failure or inability to boot, affecting not only normal user operation but also potentially posing a threat to driving safety.

[0004] To address the system recovery issue following an OTA upgrade failure, existing technologies typically employ a full rollback approach. This involves pre-backing up the complete system image of the vehicle before the upgrade, and then rewriting the backed-up complete system image into the vehicle's storage unit when the upgrade fails, thereby restoring the system to its normal state before the upgrade.

[0005] However, this full rollback method has significant drawbacks. On the one hand, the complete system image typically has a large data volume, and the backup and storage process requires a significant amount of storage space, increasing the vehicle's hardware costs. On the other hand, the rollback process requires transferring and writing the complete system image, which is time-consuming and can render the vehicle unusable for extended periods, degrading the user experience. Furthermore, a full rollback can overwrite potentially useful data generated during the upgrade process, resulting in a waste of data resources.

[0006] Therefore, there is an urgent need for a vehicle OTA upgrade failure rollback technology that has a small storage space footprint, fast rollback speed, and can retain as much useful data as possible, in order to overcome the shortcomings of existing full rollback technologies. Summary of the Invention

[0007] The purpose of this invention is to provide an incremental rollback method, apparatus, and device for vehicle OTA upgrade failures. This invention can at least alleviate the technical problems of large storage space occupation, slow rollback speed, and easy waste of useful data that exist in the existing full rollback technology after vehicle OTA upgrade failures. It can reduce storage space occupation, improve rollback speed, and help retain useful data and improve the user's driving experience.

[0008] To address the aforementioned technical problems, in a first aspect, the present invention provides an incremental rollback method for vehicle OTA upgrade failure, comprising at least:

[0009] At least in response to user confirmation to initiate an OTA upgrade of the IVI system, an initial snapshot is created for the IVI system;

[0010] After the OTA upgrade begins, file operation behavior in the IVI system is detected through a preset calling method, and corresponding behavior tracking operations are performed based on the file operation behavior.

[0011] During the OTA upgrade process, the OTA upgrade progress is checked periodically at least once. When the OTA upgrade progress meets the preset threshold conditions, the vehicle OTA upgrade is determined to have failed, thereby interrupting the OTA upgrade program and triggering the incremental rollback process.

[0012] In response to the triggering of the incremental rollback process, an incremental rollback operation is performed.

[0013] Optionally, the step of creating an initial snapshot of the IVI system in response to user confirmation of initiating an OTA upgrade of the IVI system specifically includes at least:

[0014] At least in response to user confirmation to initiate IVI system OTA upgrade, scan all files in the IVI system and collect metadata information for each file, including at least file path, file size, modification time, and storage location index;

[0015] Establish the reference relationship between file data and storage location to obtain the data reference relationship, and record the data block distribution of each file;

[0016] The metadata information and the data reference relationship are encoded according to a preset format, and the checksum of the entire initial snapshot is calculated. The initial snapshot and the checksum are then stored in the snapshot storage area.

[0017] Optionally, the step of detecting file operation behavior in the IVI system through a preset invocation method after the OTA upgrade begins, and performing corresponding behavior tracking operations based on the file operation behavior, specifically includes at least the following:

[0018] After the OTA upgrade begins, the file operation behavior in the IVI system is detected using the preset invocation method;

[0019] When the file operation is that the upgrade program modifies the first preset file, the modification status of data blocks within the physical sector address range corresponding to the first preset file is captured, and at least the identifier of the changed data block, the change type and the hash value of the data before the change are recorded, and then the original data of the corresponding data block is read from the backup storage area for backup.

[0020] When the file operation is an upgrade program adding to the second preset file, at least the identifier of the added data block, the change type, and the hash value of the changed data should be recorded.

[0021] When the file operation is that the upgrade program deletes a third preset file, at least the identifier, change type, and hash value of the data block corresponding to the deleted file are recorded;

[0022] All changed data block information is written to a temporary change log, and then a checksum is calculated for each record before they are stored together.

[0023] Optionally, the step of performing an incremental rollback operation in response to the triggering of the incremental rollback process specifically includes at least:

[0024] In response to the triggering of the incremental rollback process, the initial snapshot in the snapshot storage area is read, and the integrity of the initial snapshot is verified at least according to the checksum. Then, the baseline state of the IVI system before the OTA upgrade is determined at least by parsing the metadata information and data reference relationships in the initial snapshot.

[0025] Optionally, the step of performing an incremental rollback operation in response to the triggering of the incremental rollback process may specifically include at least:

[0026] Read the temporary change log and verify the checksum of each record to at least remove records that fail the checksum, and then classify the valid records according to the change type.

[0027] Optionally, the step of performing an incremental rollback operation in response to the triggering of the incremental rollback process may specifically include at least:

[0028] For valid modification records, at least the corresponding original data is read from the backup storage area according to the data block identifier in each record, and the original data is written to the original storage location of the IVI system to overwrite the data blocks modified during the upgrade process;

[0029] For valid new records, at least one erase command is sent to the eMMC based on the new data block identifier in each record to delete the new data block in the corresponding sector;

[0030] For valid deletion records, the corresponding original data blocks are read from the backup storage area based on the metadata information of the deleted files recorded in the initial snapshot, and the deleted files and data blocks are recreated in the eMMC according to the storage location information in the initial snapshot.

[0031] Optionally, after performing the incremental rollback operation in response to the triggering of the incremental rollback process, the method further includes:

[0032] For each data block that has completed the incremental rollback operation, the hash value of the rolled-back data block is calculated at least, and the hash value of the rolled-back data block is compared with the hash value of the corresponding data block recorded in the initial snapshot.

[0033] When the hash values ​​of all rolled-back data blocks are consistent with the hash values ​​in the initial snapshot, the rollback is considered successful and a successful rollback operation is performed.

[0034] Based on the same concept, in a second aspect, the present invention also provides an incremental rollback device for vehicle OTA upgrade failure, used to execute the incremental rollback method for vehicle OTA upgrade failure as described in any of the first aspects.

[0035] The incremental rollback device for vehicle OTA upgrade failure includes at least:

[0036] The snapshot creation module is used, at least in response to user confirmation of initiating an OTA upgrade of the IVI system, to create an initial snapshot of the IVI system;

[0037] The detection and tracking module is used to detect file operation behavior in the IVI system through a preset calling method after the OTA upgrade begins, and to perform corresponding behavior tracking operations based on the file operation behavior.

[0038] The rollback trigger module is used to perform periodic checks on the OTA upgrade progress at least during the OTA upgrade process, so as to determine that the vehicle OTA upgrade has failed when the OTA upgrade progress meets the preset threshold conditions, thereby interrupting the OTA upgrade program and triggering the incremental rollback process.

[0039] The rollback operation module is used to execute an incremental rollback operation in response to the triggering of the incremental rollback process.

[0040] Based on the same concept, in a third aspect, the present invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program executable on the processor, and the processor executes the program to implement the steps of the incremental rollback method for vehicle OTA upgrade failure according to any one of the first aspects.

[0041] Based on the same concept, in a fourth aspect, the present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the incremental rollback method for vehicle OTA upgrade failure as described in any of the first aspects.

[0042] The technical solution provided by this invention firstly creates an initial snapshot of the IVI system in response to user confirmation of initiating an OTA upgrade. Further, after the OTA upgrade begins, file operation behavior in the IVI system is detected through a preset invocation method, and corresponding behavior tracking operations are performed based on the file operation behavior. Further, during the OTA upgrade process, the OTA upgrade progress is periodically checked, and if the OTA upgrade progress meets a preset threshold condition, the vehicle OTA upgrade is determined to have failed, thereby interrupting the OTA upgrade program and triggering an incremental rollback process. Finally, in response to the triggering of the incremental rollback process, an incremental rollback operation is performed. Therefore, this invention, through incremental rollback, can alleviate the technical problems of large storage space occupation, slow rollback speed, and easy waste of useful data that exist in existing full rollback technology after a failed vehicle OTA upgrade. It can reduce storage space occupation, improve rollback speed, and help retain useful data and improve the user's driving experience. Attached Figure Description

[0043] Figure 1 This is a flowchart of an incremental rollback method for a vehicle OTA upgrade failure provided in an embodiment of the present invention;

[0044] Figure 2 This is a flowchart of another incremental rollback method for vehicle OTA upgrade failure provided by an embodiment of the present invention;

[0045] Figure 3 This is a schematic diagram of an incremental rollback device for a vehicle OTA upgrade failure provided in an embodiment of the present invention;

[0046] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0048] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “said,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms, and “multiple” generally includes at least two unless the context clearly indicates otherwise.

[0049] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0050] It should be understood that although the terms first, second, third, etc., may be used in the embodiments of this application, these descriptions should not be limited to these terms. These terms are only used to distinguish the descriptions. For example, first may also be referred to as second without departing from the scope of the embodiments of this application, and similarly, second may also be referred to as first.

[0051] Depending on the context, the words “if” or “suppose” as used here can be interpreted as “when” or “in response to determination” or “in response to detection.” Similarly, depending on the context, the phrases “if determination” or “if detection (of the stated condition or event)” can be interpreted as “when determination” or “in response to determination” or “when detection (of the stated condition or event)” or “in response to detection (of the stated condition or event).”

[0052] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that an article or device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such an article or device. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the article or device that includes said element.

[0053] It should be noted that any symbols and / or numbers present in the specification that are not marked in the accompanying drawings are not reference numerals.

[0054] Figure 1This is a flowchart of an incremental rollback method for a vehicle OTA upgrade failure provided by an embodiment of the present invention. This embodiment is applicable to system recovery scenarios after an OTA upgrade failure in at least any vehicle. This incremental rollback method for a vehicle OTA upgrade failure can be executed, but is not limited to, by the incremental rollback device for a vehicle OTA upgrade failure provided in this embodiment of the present invention. This execution entity can be implemented in software and / or hardware. Figure 1 As shown, the incremental rollback method after a vehicle OTA upgrade failure includes at least the following steps:

[0055] S1. At least in response to user confirmation to initiate the IVI system OTA upgrade, create an initial snapshot of the IVI system.

[0056] In this embodiment, the application object can be the in-vehicle infotainment system (IVI system) of a certain brand of intelligent electric vehicle. The IVI system to be upgraded may include an operating system (such as an operating system based on the Linux kernel), navigation application, multimedia playback application and vehicle networking service application, etc. The total data volume of the system can be 8GB. The vehicle's storage unit can adopt eMMC (embedded multimedia card) with a storage capacity of 64GB. A 2GB snapshot storage area and a 5GB backup storage area can be divided to support the incremental rollback function of this embodiment.

[0057] In one specific implementation, optionally, the aforementioned step S1 specifically includes at least:

[0058] (1-1) At least in response to user confirmation to start the IVI system OTA upgrade, scan all files in the IVI system and collect metadata information for each file. The metadata information shall include at least the file path, file size, modification time and storage location index.

[0059] (1-2) Establish the reference relationship between file data and storage location to obtain the data reference relationship, and record the data block distribution of each file;

[0060] (1-3) Encode the metadata information and data reference relationships according to the preset format, calculate the checksum of the entire initial snapshot, and store the initial snapshot and checksum in the snapshot storage area.

[0061] More specifically, users can confirm the initiation of the IVI system OTA upgrade via the in-vehicle screen. In response to user confirmation, the process first scans all files in the IVI system and collects metadata information for each file, including but not limited to file path (e.g., " / usr / app / navigation / "), file size (e.g., the main file size of the navigation application is 1.2GB), modification time (e.g., May 10, 2024, 14:30:20), and storage location index (e.g., the physical sector address range in the corresponding eMMC). Then, a reference relationship between file data and storage location is established, recording the data block distribution of each file. Finally, the collected metadata information and data reference relationships are encoded according to a preset binary format (i.e., the aforementioned preset format), and the checksum of the entire initial snapshot is calculated (e.g., using the SHA-256 algorithm). The initial snapshot and checksum are then stored in the snapshot storage area. In a real-vehicle test, the entire snapshot creation process in this embodiment took approximately 8 seconds, and the generated initial snapshot data size was approximately 500MB, far less than the total 8GB data size of the IVI system.

[0062] S2. After the OTA upgrade begins, file operation behavior in the IVI system is detected by a preset calling method, and corresponding behavior tracking operations are performed based on the file operation behavior.

[0063] The default calling method can be a hook system call.

[0064] In another specific implementation, optionally, the aforementioned step S2 specifically includes at least:

[0065] (2-1) After the OTA upgrade begins, detect file operation behavior in the IVI system using a preset calling method;

[0066] (2-2) When the file operation behavior is that the upgrade program modifies the first preset file, the modification status of the data blocks within the physical sector address range corresponding to the first preset file is captured, and at least the identifier of the changed data block, the change type and the hash value of the data before the change are recorded, and then the original data of the corresponding data block is read from the backup storage area for backup.

[0067] (2-3) When the file operation is that the upgrade program adds new data to the second preset file, at least the identifier of the new data block, the change type, and the hash value of the changed data should be recorded;

[0068] (2-4) When the file operation is that the upgrade program deletes the third preset file, at least the identifier, change type and hash value of the data block corresponding to the deleted file should be recorded;

[0069] (2-5) Write all changed data block information into a temporary change log, and then calculate the checksum for each record and store them together.

[0070] More specifically, after the OTA upgrade begins, file operations in the IVI system can be monitored in real time by hooking system calls.

[0071] When the upgrade program modifies the file " / usr / app / navigation / main.exe" (i.e., the aforementioned first preset file), if it detects that a data block within the physical sector address range (e.g., 0x12000-0x12FFF) corresponding to that file has been modified, it immediately records the identifier of the changed data block (e.g., sector address range), the change type (e.g., modification), and the SHA-256 hash value of the data before the change (e.g., 0xABCDEF1234567890...), and reads the original data of the data block from the backup storage area for backup (backup can be performed only when the data block is modified for the first time; if it is modified again subsequently, the original data will not be backed up again).

[0072] When the upgrade program adds a new file " / usr / app / multimedia / new_plugin.so" (i.e., the aforementioned second preset file), it can record the identifier of the new data block (such as the newly allocated sector address range 0x15000-0x155FF), the change type (such as new), and the SHA-256 hash value of the changed data.

[0073] When the upgrade program deletes the file " / usr / app / old_service.dll" (i.e. the aforementioned third preset file), it can record the identifier of the data block corresponding to the deleted file (such as the sector address range 0x10000-0x10FFF), the change type (such as deletion), and the SHA-256 hash value of the data before the change.

[0074] All the aforementioned changed data block information (i.e., the identifier, change type, and SHA-256 hash value of the data before the change, the identifier, change type, and SHA-256 hash value of the data after the change, the identifier, change type, and SHA-256 hash value of the data block corresponding to the deleted file, etc.) can be written to the temporary change log in real time. A checksum is calculated for each record (for example, the CRC32 algorithm can be used) and stored together. The temporary change log can be stored in the temporary storage partition of the eMMC.

[0075] S3. During the OTA upgrade process, periodic checks are performed on the OTA upgrade progress. When the OTA upgrade progress meets the preset threshold conditions, the vehicle OTA upgrade is determined to have failed, thereby interrupting the OTA upgrade program and triggering the incremental rollback process.

[0076] The preset threshold conditions can be adaptively adjusted according to the actual vehicle usage scenario, but this embodiment does not limit this.

[0077] In yet another specific implementation, step S3 can be specifically described as follows:

[0078] During the OTA upgrade process, the upgrade progress is checked every 30 seconds. If the upgrade progress reaches 40% and does not change within 10 minutes, it is determined that the upgrade is stuck and has failed. The current OTA upgrade program is immediately stopped and the incremental rollback process is triggered. At the same time, the user can be displayed a message on the vehicle screen that reads "Upgrade failed, system is being restored, please wait..."

[0079] S4. In response to the triggering of the incremental rollback process, perform the incremental rollback operation.

[0080] There are several ways to implement incremental rollback operations.

[0081] In yet another specific implementation, step S4 may optionally include at least the following:

[0082] (4-1) In response to the triggering of the incremental rollback process, read the initial snapshot in the snapshot storage area and verify the integrity of the initial snapshot at least according to the checksum, and then determine the baseline state of the IVI system before the OTA upgrade by parsing the metadata information and data reference relationships in the initial snapshot.

[0083] In yet another specific implementation, step S4 may optionally include at least the following:

[0084] (4-2) Read the temporary change log and verify the checksum of each record to at least remove records that fail the checksum, and then classify the valid records according to the change type.

[0085] In yet another specific implementation, step S4 may optionally include at least the following:

[0086] (4-3) For valid modification records, at least the original data corresponding to each record should be read from the backup storage area according to the data block identifier in each record, and the original data should be written to the original storage location of the IVI system to overwrite the data blocks modified during the upgrade process;

[0087] (4-4) For valid new records, at least send an erase command to the eMMC based on the new data block identifier in each record to delete the new data block in the corresponding sector;

[0088] (4-5) For valid deletion records, at least the original data blocks corresponding to the deleted files recorded in the initial snapshot are read from the backup storage area, and the deleted files and data blocks are recreated in the eMMC according to the storage location information in the initial snapshot.

[0089] More specifically,

[0090] 1. Snapshot parsing: It can read the initial snapshot in the snapshot storage area and verify the integrity of the initial snapshot through checksum (e.g., calculate the SHA-256 hash value of the read initial snapshot, compare it with the stored checksum, and continue after confirming that there are no errors); then, it parses the metadata information and data reference relationships in the initial snapshot to determine the baseline state of the IVI system before the upgrade. For example, it determines the storage location and original data hash value of the file " / usr / app / navigation / main.exe" before the upgrade, and the existence status and data information of the file " / usr / app / old_service.dll" before the upgrade.

[0091] 2. Change Log Processing: Temporary change logs can be read. First, the checksum of each record is verified, and records that fail the verification are removed (if they exist). Then, valid records are categorized into three types based on the change type: "Modified," "Added," and "Deleted." For example, statistics show that the temporary change log contains 120 "Modified" records, 30 "Added" records, and 15 "Deleted" records.

[0092] 3. Data rollback execution:

[0093] (1) For the 120 "Modified" type records, the corresponding original data block is read from the backup storage area according to the data block identifier (sector address range) in each record. Then, the original data block is written to the original storage location of the IVI system (i.e., the corresponding sector address range) to overwrite the data block modified during the upgrade process. For example, for the sector address range 0x12000-0x12FFF corresponding to the file " / usr / app / navigation / main.exe", the original data of this sector is read from the backup storage area and written to the 0x12000-0x12FFF sector to restore the original data of the file.

[0094] (2) For 30 “new” type records, send an erase command directly to eMMC according to the new data block identifier (sector address range) in each record to delete the new data blocks in these sectors, such as erasing the data in sectors 0x15000-0x155FF and deleting the file “ / usr / app / multimedia / new_plugin.so”.

[0095] (3) For the 15 "deleted" records, based on the metadata information of the deleted files recorded in the initial snapshot (such as file path, size, and data reference relationships), the corresponding original data blocks are read from the backup storage area, and the deleted files and data blocks are recreated in the eMMC according to the storage location information in the initial snapshot. For example, the file " / usr / app / old_service.dll" is recreated, and the backed-up original data blocks are written to the sector address range 0x10000-0x10FFF corresponding to that file.

[0096] The technical solution provided in this embodiment firstly creates an initial snapshot of the IVI system in response to user confirmation of initiating the IVI system OTA upgrade; further, after the OTA upgrade begins, file operation behavior in the IVI system is detected through a preset invocation method, and corresponding behavior tracking operations are performed based on the file operation behavior; further, during the OTA upgrade process, the OTA upgrade progress is periodically checked, and if the OTA upgrade progress meets a preset threshold condition, the vehicle OTA upgrade is determined to have failed, thereby interrupting the OTA upgrade program and triggering an incremental rollback process; finally, in response to the triggering of the incremental rollback process, an incremental rollback operation is performed. Therefore, this embodiment, through incremental rollback, can alleviate the technical problems of large storage space occupation, slow rollback speed, and easy waste of useful data that exist in existing full rollback technology after vehicle OTA upgrade failure. It can reduce storage space occupation, improve rollback speed, and help retain useful data and improve the user's driving experience.

[0097] Based on real-vehicle testing, compared with existing technologies, this embodiment can achieve at least the following quantifiable beneficial effects:

[0098] 1. Significantly reduced storage space usage: This embodiment avoids backing up the complete system image during a full rollback by creating an initial snapshot that only records metadata and data reference relationships. The data volume of the initial snapshot is only 5%-10% of that of the complete system image. At the same time, the backup storage area only stores the original data of the data blocks modified during the upgrade process, further reducing storage space consumption and lowering vehicle hardware costs.

[0099] 2. Significantly improved rollback speed: Incremental rollback only operates on the data blocks that have changed during the upgrade process, without the need to transfer and write the complete system image. The rollback time is reduced by 60%-80% compared to full rollback. For example, for a system with 5GB of data, full rollback may take 30-60 minutes, while the incremental rollback of this invention only takes 5-15 minutes, greatly reducing the time that the vehicle is not usable and improving the user experience.

[0100] 3. Effectively preserve useful data: During incremental rollback, only the data blocks related to the upgrade are rolled back. Other data not involved in the upgrade process (such as user personalization settings, navigation history, multimedia files, etc.) will not be affected, thus avoiding the waste of useful data and further improving user satisfaction.

[0101] Based on the above embodiments or implementation methods Figure 2 This is a flowchart of another incremental rollback method for vehicle OTA upgrade failure provided by an embodiment of the present invention, as shown below. Figure 2 As shown, the incremental rollback method after a vehicle OTA upgrade failure includes at least the following steps:

[0102] S1. At least in response to user confirmation to initiate the IVI system OTA upgrade, create an initial snapshot of the IVI system.

[0103] In yet another specific implementation, step S1 may further be:

[0104] Before initiating the vehicle OTA upgrade process, an initial snapshot is created on the target system to be upgraded (including the target ECU software, vehicle operating system, and related applications). This initial snapshot is not a complete system image, but rather records only the metadata information of each file in the target system (such as file path, size, modification time, storage location index, etc.) and the differences in file data references. In this way, the initial snapshot can quickly record the state of the target system before the upgrade with a very small amount of data, significantly reducing the storage space occupied during snapshot creation. The creation time can be controlled within seconds, avoiding any impact on normal vehicle use.

[0105] S2. After the OTA upgrade begins, file operation behavior in the IVI system is detected by a preset calling method, and corresponding behavior tracking operations are performed based on the file operation behavior.

[0106] In yet another specific implementation, step S2 may further be:

[0107] During vehicle OTA upgrades, information on changed data blocks in the target system is tracked and recorded in real time. Specifically, when the upgrade program modifies, adds, or deletes files in the target system, the location, size, and change type (modification, addition, deletion) of the operated data blocks are captured in real time. This changed data block information is then stored in a temporary change log according to a preset format (such as data block identifier, hash value before change, hash value after change, storage address, etc.). Simultaneously, to ensure the reliability of the changed data, each record in the temporary change log is checked and calculated, and the checksum is stored along with the record to prevent data corruption or tampering during the recording process.

[0108] S3. During the OTA upgrade process, periodic checks are performed on the OTA upgrade progress. When the OTA upgrade progress meets the preset threshold conditions, the vehicle OTA upgrade is determined to have failed, thereby interrupting the OTA upgrade program and triggering the incremental rollback process.

[0109] In yet another specific implementation, step S3 may further be:

[0110] During and after the OTA upgrade process, a pre-defined upgrade status detection mechanism is used to assess the upgrade result. This mechanism includes real-time monitoring of the upgrade progress, verification of the integrity of the upgrade files, and preliminary testing of the system's functionality after the upgrade. An incremental rollback process is triggered when any of the following upgrade failure conditions are detected:

[0111] 1. If the upgrade progress does not change within the preset time, it is determined that the upgrade is stuck;

[0112] 2. During the upgrade file verification process, if the calculated file hash value is inconsistent with the standard hash value provided by the server, the upgrade file is determined to be corrupted.

[0113] 3. After the upgrade was completed, system function testing revealed that key functions (such as power control, steering control, braking control, and other functions related to driving safety) could not work properly, which was determined to be a system malfunction after the upgrade.

[0114] S4. In response to the triggering of the incremental rollback process, perform the incremental rollback operation.

[0115] In yet another specific implementation, step S4 may further be specifically described as follows:

[0116] After triggering the incremental rollback process, based on the previously created initial snapshot and temporary change log, the incremental rollback operation is performed, specifically including:

[0117] 1. Read the metadata information and data reference relationships of each file of the target system recorded in the initial snapshot to determine the baseline state of the target system before the upgrade;

[0118] 2. Parse the temporary change log, extract information on all changed data blocks during the upgrade process, and classify the changed data blocks according to the change type;

[0119] 3. For "modified" type change data blocks, based on the data reference relationship before the change recorded in the initial snapshot, read the corresponding original data block from the vehicle's backup storage area (this area is used to store the original data of each data block when the initial snapshot is created, and backup is only performed when the data block is modified for the first time; unmodified data blocks do not need to be backed up) and write it back to the original storage location of the target system, overwriting the data blocks modified during the upgrade process;

[0120] 4. For "new" type change data blocks, delete these new data blocks directly according to the storage address of the new data blocks recorded in the temporary change log, so as to restore the system to a state without new files;

[0121] 5. For data blocks of type "deleted", based on the metadata information and data reference relationships of the deleted files recorded in the initial snapshot, the corresponding original data blocks are read from the backup storage area, and the deleted files and data blocks are recreated according to the storage location information in the initial snapshot to restore the original structure and data of the files;

[0122] 6. During the rollback process, each data block that has completed the rollback operation is verified. The hash value of the data block is calculated and compared with the corresponding hash value recorded in the initial snapshot to ensure that the rolled-back data block is consistent with the original data block before the upgrade. If the verification fails, the rollback operation for that data block is re-executed until the verification passes.

[0123] S5. Verify each data block that has completed the incremental rollback operation, at least calculate the hash value of the rolled-back data block, and compare the hash value of the rolled-back data block with the hash value of the corresponding data block recorded in the initial snapshot.

[0124] S6. When the hash values ​​of all rolled-back data blocks are consistent with the hash values ​​in the initial snapshot, the rollback is determined to be successful and the rollback success operation is executed.

[0125] Specifically, steps S5 to S6 can be described as follows:

[0126] Each data block that has completed the rollback operation is verified. The SHA-256 hash value of the rolled-back data block is calculated and compared with the hash value of the corresponding data block recorded in the initial snapshot. If the verification shows that the hash values ​​of all rolled-back data blocks match the hash values ​​in the initial snapshot, the rollback is considered successful. After the rollback is complete, a rollback success signal can be sent to the vehicle control system to restart the IVI system. The IVI system will then return to its normal state before the upgrade, and the in-vehicle screen will display a message stating "System recovery complete, ready for normal use."

[0127] In summary, this embodiment involves at least the following key technical points:

[0128] 1. Lightweight initial snapshot building technology

[0129] Breaking away from the traditional full-image backup approach, the initial snapshot only records the metadata (path, size, storage index, etc.) and data reference relationships of the system files to be upgraded, rather than the complete data content. This lightweight "metadata + reference" design achieves a snapshot data volume of only 5%-10% of the full system image, with creation time controlled in the seconds range. This solves the problems of large storage space consumption and long processing time associated with traditional backups, and is a fundamental prerequisite for subsequent incremental rollbacks.

[0130] 2. Refined data tracking technology during the upgrade process

[0131] Based on the data change monitoring unit built into the storage management module, a real-time monitoring method using "hooking system calls" is employed to accurately capture three types of change behaviors in data blocks during the upgrade: "modification / addition / deletion". Simultaneously, the data block identifier, hash value, and checksum are stored synchronously for each change record, forming a structured temporary change log to ensure the integrity and traceability of the changed data, providing data support for subsequent accurate rollback.

[0132] 3. Multi-dimensional upgrade failure judgment technology

[0133] A three-dimensional failure detection mechanism is constructed, comprising "progress monitoring + file verification + functional testing": Real-time monitoring of the upgrade progress determines if an upgrade freeze has occurred; comparison of the local hash value of the upgrade file with the server's standard hash value verifies file corruption; and testing of key functions such as power control and steering control detects system anomalies. This multi-dimensional approach ensures comprehensive identification of upgrade failure scenarios, avoiding misjudgments or omissions due to a single detection method.

[0134] 4. Layered incremental rollback technology based on snapshots and change logs

[0135] The rollback process consists of four layers: snapshot parsing, log processing, data rollback, and verification. First, an initial snapshot is used to determine the system's baseline state. Then, logs are processed according to change type, and differentiated operations are performed for different change types: "restore modified data blocks," "delete newly added data blocks," and "rebuild deleted data blocks." Finally, hash verification ensures that the rollback data is consistent with the original state. This layered operation achieves precise processing of only changed data, rather than full overwrite, and is the core technology for improving rollback speed and preserving useful data.

[0136] Based on real-vehicle testing, compared with existing technologies, this embodiment can achieve at least the following quantifiable beneficial effects:

[0137] 1. Significantly reduced storage space usage: This embodiment avoids backing up the complete system image during a full rollback by creating an initial snapshot that only records metadata and data reference relationships. The data volume of the initial snapshot is only 5%-10% of that of the complete system image. At the same time, the backup storage area only stores the original data of the data blocks modified during the upgrade process, further reducing storage space consumption and lowering vehicle hardware costs.

[0138] 2. Significantly improved rollback speed: Incremental rollback only operates on the data blocks that have changed during the upgrade process, without the need to transfer and write the complete system image. The rollback time is reduced by 60%-80% compared to full rollback. For example, for a system with 5GB of data, full rollback may take 30-60 minutes, while the incremental rollback of this invention only takes 5-15 minutes, greatly reducing the time that the vehicle is not usable and improving the user experience.

[0139] 3. Effectively preserve useful data: During incremental rollback, only the data blocks related to the upgrade are rolled back. Other data not involved in the upgrade process (such as user personalization settings, navigation history, multimedia files, etc.) will not be affected, thus avoiding the waste of useful data and further improving user satisfaction.

[0140] 4. Improve rollback reliability: By verifying and protecting change logs during data tracing and performing hash verification on rolled-back data blocks during the rollback process, the integrity and correctness of data during the rollback process are ensured, the risk of rollback failure is reduced, and the vehicle system can be stably restored to its normal state before the upgrade.

[0141] Figure 3 This is a schematic diagram of an incremental rollback device for a vehicle OTA upgrade failure provided in an embodiment of the present invention. This embodiment is applicable to system recovery scenarios after an OTA upgrade failure in at least any vehicle. The incremental rollback device for a vehicle OTA upgrade failure can be implemented using software and / or hardware. Figure 3 As shown, the incremental rollback device after a vehicle OTA upgrade failure is used to execute the incremental rollback method after a vehicle OTA upgrade failure in any of the aforementioned embodiments or implementations.

[0142] The incremental rollback mechanism for vehicle OTA upgrade failures includes at least the following:

[0143] The snapshot creation module 110 is used at least to create an initial snapshot of the IVI system in response to user confirmation of initiating an OTA upgrade of the IVI system.

[0144] The detection and tracking module 120 is used to detect file operation behavior in the IVI system through a preset calling method after the OTA upgrade begins, and to perform corresponding behavior tracking operations based on the file operation behavior.

[0145] The rollback trigger module 130 is used to perform periodic checks on the OTA upgrade progress at least during the OTA upgrade process, so that when the OTA upgrade progress meets the preset threshold conditions, the vehicle OTA upgrade is determined to have failed, thereby interrupting the OTA upgrade program and triggering the incremental rollback process.

[0146] The rollback operation module 140 is used to execute incremental rollback operations in response to the triggering of the incremental rollback process.

[0147] Optionally, the snapshot creation module 110 is specifically used for at least:

[0148] At least in response to user confirmation to initiate IVI system OTA upgrade, scan all files in the IVI system and collect metadata information for each file. The metadata information includes at least the file path, file size, modification time, and storage location index.

[0149] Establish the reference relationship between file data and storage location to obtain the data reference relationship, and record the data block distribution of each file;

[0150] The metadata information and data reference relationships are encoded according to a preset format, and the checksum of the entire initial snapshot is calculated. The initial snapshot and checksum are then stored in the snapshot storage area.

[0151] Optionally, the detection and tracking module 120 is specifically used for at least:

[0152] After the OTA upgrade begins, file operation behavior in the IVI system is detected using a preset invocation method;

[0153] When the file operation is that the upgrade program modifies the first preset file, the modification status of the data blocks within the physical sector address range corresponding to the first preset file is captured, and at least the identifier of the changed data block, the change type and the hash value of the data before the change are recorded. Then, the original data of the corresponding data block is read from the backup storage area for backup.

[0154] When the file operation is for the upgrade program to add to the second preset file, at least the identifier of the added data block, the change type, and the hash value of the changed data should be recorded.

[0155] When the file operation is that the upgrade program deletes a third preset file, at least the identifier, change type, and hash value of the data block corresponding to the deleted file should be recorded;

[0156] All changed data block information is written to a temporary change log, and then a checksum is calculated for each record before they are stored together.

[0157] Optionally, the rollback operation module 140 is specifically used for at least:

[0158] In response to the triggering of the incremental rollback process, the initial snapshot in the snapshot storage area is read, and the integrity of the initial snapshot is verified at least based on the checksum. Then, the baseline state of the IVI system before the OTA upgrade is determined at least by parsing the metadata information and data reference relationships in the initial snapshot.

[0159] Optionally, the rollback operation module 140 is also specifically used for at least:

[0160] Read the temporary change log and verify the checksum of each record to at least remove records that fail the checksum, and then classify the valid records according to the change type.

[0161] Optionally, the rollback operation module 140 is also specifically used for at least:

[0162] For valid modification records, at least the corresponding original data is read from the backup storage area based on the data block identifier in each record, and the original data is written to the original storage location of the IVI system to overwrite the data blocks modified during the upgrade process;

[0163] For valid new records, at least one erase command is sent to the eMMC based on the new data block identifier in each record to delete the new data block in the corresponding sector;

[0164] For valid deletion records, the corresponding original data blocks are read from the backup storage area based on the metadata information of the deleted files recorded in the initial snapshot, and the deleted files and data blocks are recreated in the eMMC according to the storage location information in the initial snapshot.

[0165] Optionally, the incremental rollback mechanism after a vehicle OTA upgrade failure includes at least the following:

[0166] The calculation and comparison module 150 is used to verify each data block that has completed the incremental rollback operation, at least calculate the hash value of the rolled-back data block, and compare the hash value of the rolled-back data block with the hash value of the corresponding data block recorded in the initial snapshot.

[0167] The successful operation module 160 is used to determine that the rollback is successful and execute the successful rollback operation when the hash values ​​of all rolled-back data blocks are consistent with the hash values ​​in the initial snapshot.

[0168] The technical solution provided in this embodiment, firstly, in response to user confirmation of initiating the IVI system OTA upgrade, creates an initial snapshot for the IVI system through the snapshot creation module; further, after the OTA upgrade begins, the detection and tracking module detects file operation behavior in the IVI system through a preset calling method, and performs corresponding behavior tracking operations based on the file operation behavior; further, during the OTA upgrade process, the rollback trigger module performs periodic checks on the OTA upgrade progress, and when the OTA upgrade progress meets a preset threshold condition, determines that the vehicle OTA upgrade has failed, thereby interrupting the OTA upgrade program and triggering an incremental rollback process; finally, in response to the triggering of the incremental rollback process, the rollback operation module performs an incremental rollback operation. Therefore, this embodiment, through incremental rollback, can alleviate the technical problems of large storage space occupation, slow rollback speed, and easy waste of useful data that exist in existing full rollback technology after vehicle OTA upgrade failure. It can reduce storage space occupation, improve rollback speed, and help retain useful data and improve the user's driving experience.

[0169] This embodiment provides an electronic device. Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. See also: Figure 4 The electronic device 1000 includes a processor 1001 and a memory 1002. The memory 1002 stores computer-readable instructions. When the computer-readable instructions are executed by the processor 1001, the steps in any of the above incremental rollback methods after a vehicle OTA upgrade failure are performed. Through the above technical solution, the processor 1001 and the memory 1002 are interconnected and communicate with each other through a communication bus and / or other forms of connection mechanism (not shown). The memory 1002 stores a computer program that can be executed by the processor. When the electronic device 1000 is running, the processor 1001 executes the computer program to execute the incremental rollback method after the vehicle OTA upgrade fails in any optional implementation of the above embodiments, so as to at least achieve the following functions: at least in response to the user confirming the start of the IVI system OTA upgrade, create an initial snapshot for the IVI system; after the OTA upgrade starts, detect the file operation behavior in the IVI system through a preset calling method, and perform corresponding behavior tracking operations based on the file operation behavior; during the OTA upgrade process, at least perform periodic checks on the OTA upgrade progress, and determine that the vehicle OTA upgrade has failed when the OTA upgrade progress meets the preset threshold conditions, thereby interrupting the OTA upgrade program and triggering the incremental rollback process; in response to the triggering of the incremental rollback process, execute the incremental rollback operation.

[0170] This embodiment provides a computer-readable storage medium storing a computer program. When executed by a processor, the program implements the incremental rollback method for vehicle OTA upgrade failure as provided in all embodiments of this application: at least in response to user confirmation of starting IVI system OTA upgrade, an initial snapshot is created for the IVI system; after the OTA upgrade begins, file operation behavior in the IVI system is detected through a preset calling method, and corresponding behavior tracking operations are performed based on the file operation behavior; during the OTA upgrade process, the OTA upgrade progress is periodically checked, and when the OTA upgrade progress meets a preset threshold condition, the vehicle OTA upgrade is determined to have failed, thereby interrupting the OTA upgrade program and triggering the incremental rollback process; in response to the triggering of the incremental rollback process, an incremental rollback operation is performed.

[0171] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0172] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including—but not limited to—electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0173] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0174] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—as well as conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0175] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for incremental rollback after a vehicle OTA upgrade failure, characterized in that, At least including: At least in response to user confirmation to initiate an OTA upgrade of the IVI system, an initial snapshot is created for the IVI system; After the OTA upgrade begins, file operation behavior in the IVI system is detected through a preset calling method, and corresponding behavior tracking operations are performed based on the file operation behavior. During the OTA upgrade process, the OTA upgrade progress is checked periodically at least once. When the OTA upgrade progress meets the preset threshold conditions, the vehicle OTA upgrade is determined to have failed, thereby interrupting the OTA upgrade program and triggering the incremental rollback process. In response to the triggering of the incremental rollback process, an incremental rollback operation is performed.

2. The incremental rollback method for vehicle OTA upgrade failure according to claim 1, characterized in that, The step of creating an initial snapshot of the IVI system in response to user confirmation of initiating an IVI system OTA upgrade includes at least the following: At least in response to user confirmation to initiate IVI system OTA upgrade, scan all files in the IVI system and collect metadata information for each file, including at least file path, file size, modification time, and storage location index; Establish the reference relationship between file data and storage location to obtain the data reference relationship, and record the data block distribution of each file; The metadata information and the data reference relationship are encoded according to a preset format, and the checksum of the entire initial snapshot is calculated. The initial snapshot and the checksum are then stored in the snapshot storage area.

3. The incremental rollback method for vehicle OTA upgrade failure according to claim 1, characterized in that, After the OTA upgrade begins, the process of detecting file operation behavior in the IVI system using a preset invocation method, and then performing corresponding behavior tracking operations based on the file operation behavior, specifically includes at least the following: After the OTA upgrade begins, the file operation behavior in the IVI system is detected using the preset invocation method; When the file operation is that the upgrade program modifies the first preset file, the modification status of data blocks within the physical sector address range corresponding to the first preset file is captured, and at least the identifier of the changed data block, the change type and the hash value of the data before the change are recorded, and then the original data of the corresponding data block is read from the backup storage area for backup. When the file operation is an upgrade program adding to the second preset file, at least the identifier of the added data block, the change type, and the hash value of the changed data should be recorded. When the file operation is that the upgrade program deletes a third preset file, at least the identifier, change type, and hash value of the data block corresponding to the deleted file are recorded; All changed data block information is written to a temporary change log, and then a checksum is calculated for each record before they are stored together.

4. The incremental rollback method for vehicle OTA upgrade failure according to claim 1, characterized in that, The incremental rollback operation, performed in response to the triggering of the incremental rollback process, specifically includes at least the following: In response to the triggering of the incremental rollback process, the initial snapshot in the snapshot storage area is read, and the integrity of the initial snapshot is verified at least according to the checksum. Then, the baseline state of the IVI system before the OTA upgrade is determined at least by parsing the metadata information and data reference relationships in the initial snapshot.

5. The incremental rollback method for vehicle OTA upgrade failure according to claim 4, characterized in that, The step of performing an incremental rollback operation in response to the triggering of the incremental rollback process specifically includes at least the following: Read the temporary change log and verify the checksum of each record to at least remove records that fail the checksum, and then classify the valid records according to the change type.

6. The incremental rollback method for vehicle OTA upgrade failure according to claim 5, characterized in that, The step of performing an incremental rollback operation in response to the triggering of the incremental rollback process specifically includes at least the following: For valid modification records, at least the corresponding original data is read from the backup storage area according to the data block identifier in each record, and the original data is written to the original storage location of the IVI system to overwrite the data blocks modified during the upgrade process; For valid new records, at least one erase command is sent to the eMMC based on the new data block identifier in each record to delete the new data block in the corresponding sector; For valid deletion records, the corresponding original data blocks are read from the backup storage area based on the metadata information of the deleted files recorded in the initial snapshot, and the deleted files and data blocks are recreated in the eMMC according to the storage location information in the initial snapshot.

7. The incremental rollback method for vehicle OTA upgrade failure according to claim 1, characterized in that, After the incremental rollback operation is executed in response to the triggering of the incremental rollback process, the method further includes: For each data block that has completed the incremental rollback operation, the hash value of the rolled-back data block is calculated at least, and the hash value of the rolled-back data block is compared with the hash value of the corresponding data block recorded in the initial snapshot. When the hash values ​​of all rolled-back data blocks are consistent with the hash values ​​in the initial snapshot, the rollback is considered successful and a successful rollback operation is performed.

8. An incremental rollback device for vehicle OTA upgrade failure, characterized in that, Used to perform the incremental rollback method after a vehicle OTA upgrade failure as described in any one of claims 1-7; The incremental rollback device for vehicle OTA upgrade failure includes at least: The snapshot creation module is used, at least in response to user confirmation of initiating an OTA upgrade of the IVI system, to create an initial snapshot of the IVI system; The detection and tracking module is used to detect file operation behavior in the IVI system through a preset calling method after the OTA upgrade begins, and to perform corresponding behavior tracking operations based on the file operation behavior. The rollback trigger module is used to perform periodic checks on the OTA upgrade progress at least during the OTA upgrade process, so as to determine that the vehicle OTA upgrade has failed when the OTA upgrade progress meets the preset threshold conditions, thereby interrupting the OTA upgrade program and triggering the incremental rollback process. The rollback operation module is used to execute an incremental rollback operation in response to the triggering of the incremental rollback process.

9. An electronic device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the incremental rollback method for vehicle OTA upgrade failure as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps in the incremental rollback method for vehicle OTA upgrade failure as described in any one of claims 1 to 7.

Images