OTA cross-version incremental synthesis upgrading method and system based on version graph

Abstract

The application discloses an OTA cross-version incremental synthesis upgrading method and system based on a version graph, and belongs to the field of vehicle OTA upgrading. The method comprises the following steps: step S1, acquiring upgrade package metadata of all versions to construct a version dependency graph; step S2, synthesizing an incremental package according to a current vehicle version, a target version and the version dependency graph; and step S3, performing OTA upgrading on the vehicle through the incremental package. The application solves the problem of intermediate change loss during cross-version upgrading by constructing a version dependency graph and dynamically synthesizing a differential package.

Description

Technical Field

[0001] This invention belongs to the field of vehicle OTA upgrades. Specifically, this invention relates to an OTA cross-version incremental synthesis upgrade method and system based on version graphs. Background Technology

[0002] OTA (Over-The-Air) updates provide comprehensive vehicle maintenance, including preventing hacker attacks by fixing system vulnerabilities; improving vehicle acceleration, braking, and range; enhancing user experience by remotely pushing new features; reducing the need for offline maintenance; and ensuring the vehicle is always in optimal condition.

[0003] However, traditional OTA upgrades use a linear upgrade process (V1→V2→V3), and when upgrading across versions (V1→V3), critical changes from V2 (such as security patches and configuration parameter updates) may be lost. Furthermore, intermediate versions have dependencies (e.g., V3 depends on a certain interface definition from V2), and directly upgrading across versions can lead to system crashes.

[0004] Publication No. CN112000347A, published on November 27, 2020, entitled "A Method for Updating the Version of a Distributed File System and its Components," provides a method for updating the version of a distributed file system and its components. In this method, the object storage device (OSD) component of the distributed file system receives a first incremental synchronization message carrying an incremental graph and a non-verification indicator; the object storage device component calculates a non-verified object storage device graph based on the incremental graph carried in the first incremental synchronization message; and updates the version of the object storage device graph. However, this publication only compares the differences between the current version and the target version, ignoring intermediate version dependency chains. Furthermore, existing OTA upgrade methods suffer from wasted bandwidth and inability to retain user-customized configurations. Therefore, this invention proposes an OTA cross-version incremental synthesis upgrade method and system based on version graph. Summary of the Invention

[0005] This invention aims to overcome the shortcomings of existing technologies and proposes an OTA cross-version incremental synthesis upgrade method and system based on version graphs to achieve the following objectives: by constructing a version dependency graph and dynamically synthesizing difference packages, the problem of intermediate change loss during cross-version upgrades can be solved.

[0006] To achieve the above objectives, the technical solution adopted by this invention is: an OTA cross-version incremental synthesis upgrade method based on version graphs, the method comprising the following steps: Step S1: Obtain the metadata of all versions of the upgrade package to build a version dependency graph; Step S2: Synthesize incremental packages based on the current vehicle version, the target version, and the version dependency graph; Step S3: Perform an OTA upgrade on the vehicle using the incremental package.

[0007] Preferably, step S1 includes: Step S11: Extract the manifest.json file for each version and identify hard and soft dependencies; Step S12: Based on the hard and soft dependencies, construct a version dependency graph based on a directed acyclic graph, where nodes represent versions and edges represent the dependency relationships between versions. Step S13: For each branch of the version dependency graph, compare the change files of multiple versions contained in each branch, and identify and mark the conflict items.

[0008] Preferably, step S2 includes: Step S21: Based on the version dependency graph, determine all upgrade paths between the current vehicle version and the target version using a topology sorting algorithm; Step S22: Obtain the change files of multiple versions contained in all upgrade paths and merge them to obtain a recombined upgrade package. At the same time, filter out conflicting files and generate multiple version options for users or system policies to choose from. Step S23: Combine the recombined upgrade package and the multiple version options into an incremental package.

[0009] Preferably, in step S22, the rsync algorithm is used to merge the changed files.

[0010] Preferably, vehicle OTA upgrades are implemented through atomic upgrade operations, including: Obtain all target modules to be upgraded and their upgrade patches from the incremental package; Each target module is patched independently, and each patch is an atomic operation. Additionally, a rollback script is configured for each atomic operation to restore the old state of the target module.

[0011] Preferably, in step S3, after the vehicle downloads the incremental package, a temporary sandbox environment is set up to load the incremental package to simulate the OTA upgrade process for security verification.

[0012] Preferably, the security verification method includes: During the incremental packet generation phase, the SHA-256 algorithm is used to calculate its complete hash value, and the incremental packet is signed with the private key; During the simulated OTA upgrade process, the incremental packet signature is extracted, and the complete hash value of the incremental packet is obtained by decryption using the public key as the expected hash value. Calculate the hash value of the incremental packet loaded into the sandbox in real time and compare it with the expected hash value; If the hash does not match, an alarm will be triggered and the OTA upgrade will be terminated.

[0013] Preferably, for multiple version options in the incremental package, during the vehicle OTA upgrade process, the options are displayed to the user through the in-vehicle central control screen or a pre-bound mobile terminal, allowing the user to select the configuration of the conflicting items.

[0014] Preferably, if the user does not select the multiple version option within a preset time, the selection of the multiple version option will be performed automatically according to the following method: If a conflicting item in the multi-version options is in the user's preset whitelist, then the conflicting item will be selected for configuration; otherwise, the conflicting item with the latest timestamp in the multi-version options will be selected for configuration.

[0015] This application also proposes an OTA cross-version incremental synthesis upgrade system based on version graphs. Using the above-mentioned OTA cross-version incremental synthesis upgrade method based on version graphs, the system includes a cloud server, a vehicle controller, a central control screen, a TBOX, and a mobile terminal. The vehicle controller is connected to the cloud server and the mobile terminal through the TBOX; the central control screen is connected to the vehicle controller. The cloud server is used to synthesize incremental packets and send them to the vehicle controller via the TBOX; The vehicle-side controller is used to perform OTA upgrades based on the incremental package. The central control screen and mobile terminal are used to provide a user interface during the upgrade process; The TBOX is used to establish remote communication between the vehicle-mounted controller and the cloud server and mobile terminal.

[0016] The technical effects of this invention are as follows: This invention utilizes a version dependency graph constructed from a directed acyclic graph (DAG), explicitly showing the dependencies and conflicts between different versions, facilitating subsequent OTA upgrades. The incremental packages dynamically integrate all configuration changes from different versions by recombining upgrade packages, preserving all configuration changes during cross-version upgrades and preventing system crashes caused by the loss of critical changes. Simultaneously, conflicting items are retained in the incremental packages and transformed into multiple version options for user selection, enabling personalized configuration. The incremental package-based OTA upgrade method also saves bandwidth and improves data transmission speed, thereby increasing system upgrade efficiency. During OTA upgrades, atomic upgrade operations improve stability, security, and efficiency. Furthermore, OTA upgrade security is further enhanced by constructing a temporary sandbox environment for OTA simulation. The conflict resolution strategy during OTA upgrades fully respects user wishes, improving user experience. Additionally, a preset timeout mechanism ensures that the upgrade process does not stall indefinitely when the user is unresponsive, but can continue automatically, further improving system upgrade efficiency. Attached Figure Description

[0017] Figure 1 A flowchart of the OTA cross-version incremental synthesis upgrade method based on version graph provided in an embodiment of the present invention. Detailed Implementation

[0018] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. This is to help those skilled in the art to have a more complete, accurate, and in-depth understanding of the inventive concept and technical solutions of the present invention, and to facilitate its implementation. It should be noted that the terms "first," "second," etc., used in this application are only for the convenience of describing the technical solutions and to distinguish components; the corresponding component configurations may be the same or different, and are not intended to limit the scope of this application. To make the technical solutions of the present invention clearer, the present invention will be explained and illustrated through the following embodiments.

[0019] This embodiment provides an OTA cross-version incremental synthesis upgrade method based on version graphs, such as... Figure 1 As shown, the method includes the following steps: Step S1: Obtain the metadata of all versions of the upgrade package to build a version dependency graph; Step S2: Synthesize incremental packages based on the current vehicle version, the target version, and the version dependency graph; Step S3: Perform an OTA upgrade on the vehicle using the incremental package.

[0020] Specifically, in step S1, the metadata of all versions of the upgrade package is obtained to construct the version dependency graph. The metadata of each version's upgrade package includes information such as the version number, a list of changed files, and dependency declarations. Based on this, the method for constructing the version dependency graph is as follows: Step S11: Extract the manifest.json file for each version and identify hard and soft dependencies.

[0021] Hard dependencies are changes that must be installed in sequence; soft dependencies are independent changes that can be merged. These dependencies can be identified through the manifest.json file for each version. For example, the system permissions required for the application to run, declared in the "permissions" field of manifest.json, are a type of hard dependency.

[0022] Step S12: Based on the hard and soft dependencies, construct a version dependency graph based on a directed acyclic graph (DAG), where nodes represent versions and edges represent dependencies between versions.

[0023] Step S13: For each branch of the version dependency graph, compare the change files of multiple versions contained in each branch, identify and mark conflict items. For example, if version V2.1 and version V2.5 modify the same configuration, the configuration files corresponding to the two versions are conflict items.

[0024] This application presents a version dependency graph constructed based on a directed acyclic graph (DAG), which explicitly shows the dependencies and conflicts between different versions, facilitating subsequent OTA upgrades. In practice, the version dependency graph is output in JSON format and can be stored using a Neo4j database. Neo4j supports graph traversal queries, making the management of the version dependency graph easier.

[0025] After the version dependency graph is constructed, it can be used to synthesize incremental packages. In step S2 of this embodiment, the incremental package is synthesized based on the current vehicle version, the target version, and the version dependency graph, specifically including the following steps S21 to S23.

[0026] Step S21: Based on the version dependency graph, determine all upgrade paths between the current vehicle version and the target version using a topology sorting algorithm.

[0027] Topological sorting is a sorting algorithm for directed acyclic graphs (DAGs) that ensures that for every directed edge from vertex u to vertex v, vertex u always precedes vertex v. In this embodiment, the topological sorting algorithm aims to obtain all directed edges where the current vehicle version precedes the target version.

[0028] The principle of the topological sorting algorithm used in this embodiment is as follows: Construct an in-degree table for all nodes, which records the number of times each node is pointed to by other nodes. For example, for node A, the in-degree of node A is incremented by 1 for each other node that points to node A. Nodes with an in-degree of 0 in the in-degree table are added to the result set as the starting point of the topology sequence. In the version dependency graph, all neighboring nodes of the starting point are traversed, i.e. all nodes pointed to by the starting point. The in-degree of all neighboring nodes is decremented by 1 and the in-degree table is updated accordingly. When the in-degree of a neighboring node becomes 0, the node is added to the result set. Repeat the above process until the in-degree table is empty. Finally, the result set will show all upgrade paths between the current vehicle version and the target version.

[0029] Step S22: Obtain the change files of multiple versions contained in all upgrade paths and merge them to obtain a recombined upgrade package.

[0030] In this embodiment, the rsync algorithm is used to merge the changed files. Specifically, after detecting the differences between different versions of the changed files, the rsync algorithm packages all the differences into a reassembled upgrade package. The difference detection method based on the rsync algorithm is as follows: Divide the change files for each version into fixed-size blocks, such as 500 to 1000 bytes; Two hash values ​​are calculated for each block: Weak hash (rolling hash): a 32-bit lightweight hash used for fast matching; Strong hash: a 128-bit or higher high-strength hash used to confirm the exact consistency of block content. For each block in different versions of the change file, the same blocks and different blocks are identified by comparing the two hash values ​​mentioned above; finally, all the different blocks are summarized to form a reorganized upgrade package.

[0031] Meanwhile, in step S22, for conflicting items in the version dependency graph, this embodiment further filters them out according to the markers in the version dependency graph and generates multiple version options for users or system policies to choose from, fully respecting user wishes and improving user experience.

[0032] Step S23: Combine the recombined upgrade package and the multiple version options into an incremental package.

[0033] The incremental package in this embodiment integrates all changed configurations by reorganizing the upgrade package, thus retaining all changed configurations during cross-version upgrades and avoiding system crashes caused by the loss of some critical changes. Simultaneously, conflicting items are retained in the incremental package and converted into multiple version options that users can choose, enabling personalized configuration. The OTA upgrade method based on incremental packages also saves bandwidth, improves data transmission speed, and thus enhances system upgrade efficiency.

[0034] In addition, during implementation, incremental packets are transmitted to the vehicle via HTTPS encryption to ensure data security.

[0035] Once the vehicle receives the incremental upgrade package, it can perform an OTA upgrade. In this embodiment, the vehicle OTA upgrade is implemented through atomic upgrade operations, including: Obtain all target modules to be upgraded and their upgrade patches from the incremental package; Each target module is patched independently, and each patch is an atomic operation. Simultaneously, a rollback script is configured for each atomic operation to restore the target module's old state. This facilitates recovery of the original target module state in the event of an upgrade failure, improving system stability. In practice, the results of each atomic operation are logged, and the rollback script is triggered to achieve precise rollback upon failure.

[0036] Atomic upgrade operations enable independent updates to different target modules on the vehicle (such as the central control screen, window controls, navigation services, etc.). These isolated modules avoid the safety risks associated with OTA upgrades where different modules interfere with each other (for example, in traditional methods, upgrading only the window control module requires pausing the powertrain). Furthermore, unlike traditional full updates, each atomic operation is independent and rollbackable. If a step fails, only the current atomic operation needs to be rolled back, eliminating the need to redo the entire process and improving upgrade efficiency.

[0037] Meanwhile, to ensure the security of vehicle OTA upgrades, in step S3 of this embodiment, after the vehicle downloads the incremental package, a temporary sandbox environment is built to load the incremental package, which is used to simulate the OTA upgrade process for security verification. In specific implementation, the temporary sandbox environment can be implemented through a QNX Hypervisor environment built by an onboard security chip (such as Infineon AURIX, NXP S32G, etc.).

[0038] In a temporary sandbox environment, simulated OTA upgrades are performed to verify the security of OTA upgrades, thereby promptly identifying and isolating OTA upgrade risks. Specific security verification methods include: During the incremental packet generation phase, the SHA-256 algorithm is used to calculate its complete hash value, and the incremental packet is signed with the private key; During the simulated OTA upgrade process, the incremental packet signature is extracted, and the complete hash value of the incremental packet is obtained by decryption using the public key as the expected hash value. Calculate the hash value of the incremental packet loaded into the sandbox in real time and compare it with the expected hash value; If the hash does not match, an alarm will be triggered and the OTA upgrade will be terminated.

[0039] Furthermore, regarding the multiple version options in the incremental package, the corresponding atomic operations during the vehicle OTA upgrade process also include: displaying the multiple version options to the user (such as "Keep current configuration" or "Apply new version configuration") via the in-vehicle central control screen or a pre-bound mobile terminal (such as a mobile phone or tablet), allowing the user to select the configuration of the conflicting item. After the user makes a selection, they can still reselect the conflicting item via the in-vehicle central control screen or the pre-bound mobile terminal.

[0040] If the user does not select the multiple version option within the preset time, the selection of the multiple version option will be performed automatically in the following manner: If a conflicting item in the multi-version options is in the user's default whitelist, then that conflicting item will be selected for configuration; otherwise, the conflicting item with the latest timestamp in the multi-version options will be selected for configuration, because the latest version is more likely to contain important bug fixes and security patches.

[0041] The incremental package multi-version option processing method in this embodiment, on the one hand, proactively displays options to the user in the event of configuration conflicts, respecting the user's preferences and right to choose; on the other hand, it also solves the decision-making blockage problem when the user does not respond. OTA upgrades usually need to be performed under specific conditions (such as parking or sufficient battery power), and users may not be able to make a choice in time or may forget to do so. The preset timeout mechanism ensures that the upgrade process will not be indefinitely stalled when the user is unresponsive, but can continue to complete automatically; at the same time, the system policy after the timeout, triggered from the perspective of whitelists and time, also provides the most reasonable update option based on respecting the user's wishes.

[0042] This embodiment also proposes an OTA cross-version incremental synthesis upgrade system based on version graphs. Using the above-mentioned OTA cross-version incremental synthesis upgrade method based on version graphs, the system includes a cloud server, a vehicle controller, a central control screen, a TBOX, and a mobile terminal. The vehicle controller is connected to the cloud server and the mobile terminal through the TBOX; the central control screen is connected to the vehicle controller. The cloud server is used to synthesize incremental packets and send them to the vehicle controller via the TBOX; the vehicle controller is used to perform OTA upgrades based on the incremental packets. The central control screen and mobile terminal are used to provide a user interface during the upgrade process; The TBOX is used to establish remote communication between the vehicle-mounted controller and the cloud server and mobile terminal.

[0043] The present invention has been described above by way of example with reference to the accompanying drawings. Obviously, the specific implementation of the present invention is not limited to the above-described manner. Any non-substantial improvements made using the inventive concept and technical solution; or the direct application of the inventive concept and technical solution to other situations without modification, are all within the protection scope of the present invention.

Claims

1. An OTA cross-version incremental synthesis upgrade method based on version graph, characterized in that: The method includes the following steps: Step S1: Obtain the metadata of all versions of the upgrade package to build a version dependency graph; Step S2: Synthesize incremental packages based on the current vehicle version, the target version, and the version dependency graph; Step S3: Perform an OTA upgrade on the vehicle using the incremental package.

2. The OTA cross-version incremental synthesis upgrade method based on version graph as described in claim 1, characterized in that: Step S1 includes: Step S11: Extract the manifest.json file for each version and identify hard and soft dependencies; Step S12: Based on the hard and soft dependencies, construct a version dependency graph based on a directed acyclic graph, where nodes represent versions and edges represent the dependency relationships between versions. Step S13: For each branch of the version dependency graph, compare the change files of multiple versions contained in each branch, and identify and mark the conflict items.

3. The OTA cross-version incremental synthesis upgrade method based on version graph as described in claim 2, characterized in that: Step S2 includes: Step S21: Based on the version dependency graph, determine all upgrade paths between the current vehicle version and the target version using a topology sorting algorithm; Step S22: Obtain the change files of multiple versions contained in all upgrade paths and merge them to obtain a recombined upgrade package. At the same time, filter out conflicting files and generate multiple version options for users or system policies to choose from. Step S23: Combine the recombined upgrade package and the multiple version options into an incremental package.

4. The OTA cross-version incremental synthesis upgrade method based on version graph as described in claim 3, characterized in that: In step S22, the rsync algorithm is used to merge the changed files.

5. The OTA cross-version incremental synthesis upgrade method based on version graph according to claim 3 or 4, characterized in that: Vehicle OTA upgrades are implemented through atomic upgrade operations, including: Obtain all target modules to be upgraded and their upgrade patches from the incremental package; Each target module is patched independently, and each patch is an atomic operation. Additionally, a rollback script is configured for each atomic operation to restore the old state of the target module.

6. The OTA cross-version incremental synthesis upgrade method based on version graph as described in claim 5, characterized in that: In step S3, after the vehicle downloads the incremental package, a temporary sandbox environment is set up to load the incremental package to simulate the OTA upgrade process for security verification.

7. The OTA cross-version incremental synthesis upgrade method based on version graph as described in claim 6, characterized in that: The security verification method includes: During the incremental packet generation phase, the SHA-256 algorithm is used to calculate its complete hash value, and the incremental packet is signed with the private key; During the simulated OTA upgrade process, the incremental packet signature is extracted, and the complete hash value of the incremental packet is obtained by decryption using the public key as the expected hash value. Calculate the hash value of the incremental packet loaded into the sandbox in real time and compare it with the expected hash value; If the hash does not match, an alarm will be triggered and the OTA upgrade will be terminated.

8. The OTA cross-version incremental synthesis upgrade method based on version graph according to claim 3 or 4, characterized in that: For the multiple version options in the incremental package, during the vehicle OTA upgrade process, they are displayed to the user through the in-vehicle central control screen or a pre-bound mobile terminal, allowing the user to select the configuration of the conflicting items.

9. The OTA cross-version incremental synthesis upgrade method based on version graph as described in claim 8, characterized in that: If the user does not select the multiple version option within the preset time, the selection of the multiple version option will be performed automatically in the following manner: If a conflicting item in the multi-version options is in the user's preset whitelist, then the conflicting item will be selected for configuration; otherwise, the conflicting item with the latest timestamp in the multi-version options will be selected for configuration.

10. An OTA cross-version incremental synthesis upgrade system based on version graphs, using the OTA cross-version incremental synthesis upgrade method based on version graphs according to any one of claims 1-9, characterized in that: The system includes a cloud server, a vehicle controller, a central control screen, a TBOX, and a mobile terminal. The vehicle controller is connected to the cloud server and the mobile terminal through the TBOX; the central control screen is connected to the vehicle controller. The cloud server is used to synthesize incremental packets and send them to the vehicle controller via the TBOX; The vehicle-side controller is used to perform OTA upgrades based on the incremental package. The central control screen and mobile terminal are used to provide a user interface during the upgrade process; The TBOX is used to establish remote communication between the vehicle-mounted controller and the cloud server and mobile terminal.

Images