A vehicle cloud cooperative vehicle body domain controller remote upgrading method and system

Abstract

The application relates to the technical field of remote upgrading, in particular to a vehicle-cloud cooperative vehicle body domain controller remote upgrading method and system, which comprises the following steps: receiving an upgrading package acquisition request for a target vehicle body domain controller sent by a vehicle end safety module, and inquiring about the current equipment state of the target vehicle body domain controller; judging whether preset upgrading conditions are met according to the current equipment state, and constructing a target upgrading verification structure based on the upgrading package acquisition request and the current equipment state when the conditions are met; the target upgrading verification structure is a verification tree composed of a plurality of verification nodes, and each verification node is generated based on a sub-state of a vehicle for initialization. Through the cooperative work of the vehicle end safety module and the cloud platform management node, multiple security mechanisms such as encryption, hash value and digital signature are used to ensure the integrity and legality of the upgrading package, and malicious attacks and data tampering are effectively prevented.

Description

Technical Field

[0001] This invention relates to the field of remote upgrade technology, specifically to a method and system for remotely upgrading a vehicle domain controller in a vehicle-cloud collaborative manner. Background Technology

[0002] Currently, many traditional upgrade methods lack effective security mechanisms and are vulnerable to malicious attacks and data tampering. For example, unencrypted upgrade packages may be modified by hackers, resulting in damage to the vehicle system. Moreover, traditional methods usually upgrade at a predetermined time without considering the real-time status of the vehicle, which may lead to upgrades during peak vehicle usage periods, affecting user experience and increasing the risk of accidents. Furthermore, traditional methods often fail to dynamically generate verification nodes based on the actual situation of different vehicle subsystems, making it difficult to achieve efficient resource allocation and effective task execution when dealing with complex vehicle networks.

[0003] Furthermore, in traditional upgrades, if the upgrade fails, there is often a lack of rapid rollback capability, causing the vehicle to remain in an unstable state for a long time, leading to user dissatisfaction and safety hazards. Moreover, traditional methods may not allocate resources reasonably throughout the upgrade process, resulting in a long upgrade time. In addition, due to the failure to effectively utilize module resolution and storage structure, unnecessary resource waste may occur. Furthermore, many traditional upgrade methods lack real-time monitoring and logging functions throughout the process, making it difficult to trace the cause when problems occur and bringing difficulties to troubleshooting. Summary of the Invention

[0004] To achieve the above objectives, the present invention provides the following technical solution: a remote upgrade method for vehicle-cloud collaborative body domain controllers, applied to a cloud platform management node, wherein the cloud platform management node connects a vehicle-side security module and multiple body domain controllers, comprising:

[0005] Receive the upgrade package acquisition request for the target body domain controller sent by the vehicle-side security module, and query the current device status of the target body domain controller;

[0006] Based on the current device status, it is determined whether the preset upgrade conditions are met, and if the conditions are met, a target upgrade verification structure is constructed based on the upgrade package acquisition request and the current device status; the target upgrade verification structure is a verification tree composed of several verification nodes, and the verification nodes are generated based on the state of one of the vehicle's several subsystems used for initialization;

[0007] Send an upgrade ready response to the vehicle-side security module so that the vehicle-side security module can request the target upgrade package from the cloud platform management node;

[0008] The system receives an upgrade package download request sent by the vehicle-side security module, and generates a hash value and digital signature of the target upgrade package based on the verification information in the target upgrade verification structure; the system then sends the hash value and digital signature to the vehicle-side security module so that the vehicle-side security module can download the target upgrade package after successful verification.

[0009] The system receives an upgrade execution command and a decryption key for the target upgrade package sent by the vehicle-side security module after completing the download and verifying its integrity. Based on the upgrade execution command, the system forwards the decryption key and the target upgrade verification structure to the target vehicle domain controller, enabling the target vehicle domain controller to decrypt the upgrade package using the decryption key, perform the flashing process using the target upgrade verification structure, and provide feedback on the flashing result after completion.

[0010] The system receives the burning result from the target vehicle domain controller and forwards the burning result to the vehicle-side security module.

[0011] Preferably, forwarding the decryption key and the target upgrade verification structure to the target vehicle domain controller according to the upgrade execution instruction includes:

[0012] Determine the upgrade package version in the target upgrade package, and determine the target modules for the upgrade execution tasks corresponding to the several subsystems based on the target upgrade verification structure;

[0013] The upgrade package version is compared with the current version of the target module to generate difference data;

[0014] The difference data is traversed with the target upgrade verification structure to find the target verification node in the target upgrade verification structure that matches the difference data, and the corresponding search results are obtained.

[0015] If the search result indicates that a matching target verification node exists, then the verification information in the target verification node is extracted, and the integrity of the upgrade package is verified based on the verification information.

[0016] Based on the verification results, the target vehicle domain controller is controlled to perform the upgrade, and it is determined whether the upgrade is successful.

[0017] If the upgrade fails, the error code of the current module is recorded, and a rollback instruction is constructed based on the current module and the difference data. The rollback instruction is identified as new difference data, and the process jumps to the step of traversing the difference data and the target upgrade verification structure until the preset number of retries is reached or the upgrade is successful.

[0018] Once the upgrade is deemed successful, the target module after the upgrade is calculated based on the recorded error code and the current module status, and the flashing process is completed.

[0019] Preferably, the process involves determining whether preset upgrade conditions are met based on the current device status, and constructing a target upgrade verification structure based on the upgrade package acquisition request and the current device status when the conditions are met, including:

[0020] The vehicle driving status, battery power information, and historical upgrade records of the target vehicle domain controller are read respectively as the current device status;

[0021] If the vehicle is stationary, the battery level is greater than a preset threshold, and there are no unfinished upgrade tasks in the historical upgrade record, then the preset upgrade conditions are confirmed to be met.

[0022] Obtain the vehicle model identifier from the upgrade package acquisition request, and determine the module data structure array of the target vehicle domain controller based on the vehicle model identifier;

[0023] The number of verification nodes is determined based on the local vector module bit width, and the first verification node data structure of the independent verification node is defined.

[0024] Define the second verification node data structure of the target multi-branch verification node; the target multi-branch verification node is a combined verification node composed of a preset number of the independent verification nodes as child nodes;

[0025] Through the target subsystem of the vehicle, the target multi-fork verification node and the target data structure are defined as verification nodes, and the target upgrade verification structure is constructed based on the verification nodes, the first verification node data structure and the second verification node data structure.

[0026] Preferably, through the vehicle's target subsystem, the target multi-fork verification node and the target data structure are defined as verification nodes, and the target upgrade verification structure is constructed based on the verification nodes, the first verification node data structure, and the second verification node data structure, including:

[0027] Divide the module data structure array into the preset number of target subsets;

[0028] Construct corresponding verification nodes for the target subsets respectively, and store the verification nodes in the first target stack;

[0029] For the verification node in the first target stack, the operation of dividing it into the preset number of target subsets is performed recursively, and the operation of constructing corresponding verification nodes for the target subsets is performed respectively, until it is detected that the number of modules in the divided target subsets is not higher than the preset number, and the currently constructed verification node is determined as a leaf node;

[0030] The independent verification node is constructed based on the spatial coordinates of the module in the leaf node and the first verification node data structure, and the independent verification node is merged according to the second verification node data structure, so as to fill the leaf node with the constructed target multi-branch verification node to obtain the target upgrade verification structure containing the verification node.

[0031] Preferably, the method involves receiving an upgrade package download request sent by the vehicle-side security module and generating a hash value and digital signature of the target upgrade package based on the verification information in the target upgrade verification structure, including:

[0032] Determine the local preset storage structure and the module resolution of the target vehicle domain controller in the upgrade package information;

[0033] The cache hierarchy of the several subsystems is divided according to the preset storage structure and the module resolution, and the corresponding task allocation amount for each round is determined.

[0034] Obtain the subsystem number and the level number of the cache level to which each of the several subsystems is assigned, and determine the module space location corresponding to the module upgrade task to which each of the several subsystems is responsible based on the subsystem number and the level number.

[0035] Based on the spatial location of the module and the verification information in the target upgrade verification structure, the target upgrade package is divided into blocks to generate an upgrade package block list;

[0036] The upgrade package block list is signed using the private key of the cloud platform management node to obtain block signature information;

[0037] The target upgrade package, the upgrade package block list, and the block signature information are packaged as part of the hash value and digital signature of the target upgrade package.

[0038] Preferably, the cache hierarchy of the several subsystems is divided according to the preset storage structure and the module resolution, and the corresponding task allocation for each round is determined, including:

[0039] Determine whether the height or width of the resolution is a multiple of a preset reference value;

[0040] If it is determined that the height or width of the resolution is not a multiple of the reference value, then the irregular and regular parts in the target vehicle domain controller are identified.

[0041] For the rules section, based on the preset task allocation rules and the local preset storage structure, corresponding upgrade execution tasks are allocated to the several subsystems, and the initial task allocation amount is determined;

[0042] Accordingly, the step of dividing the target upgrade package into blocks based on the module's spatial location and the verification information in the target upgrade verification structure includes:

[0043] The upgrade package data of the rule section is divided into several rule blocks according to the initial task allocation amount;

[0044] The upgrade package data of the irregular portion is stored in a preset atomic task pool, and an independent check code is generated for each irregular block in the atomic task pool.

[0045] The verification information in the target upgrade verification structure is used to sign and encapsulate the rule blocks and irregular blocks respectively.

[0046] Preferably, the difference data is traversed along with the target upgrade verification structure to find the target verification node in the target upgrade verification structure that matches the difference data, and the corresponding search results are obtained, including:

[0047] The difference data is traversed with the initial node of the target upgrade verification structure, and during the traversal, the target child node that matches the difference data is saved to the second target stack.

[0048] Retrieve the target child node from the second target stack, and use the target child node as the initial node for the next recursion, and jump to the step of traversing the difference data and the initial node of the target upgrade verification structure until the second target stack is empty;

[0049] When traversing to a leaf node in the target upgrade verification structure, the module information in the leaf node is matched with the difference data. If it is determined that there is a match with the difference data, the leaf node that matches the difference data is determined as the matching point, and the priority of the matching point is compared with the priority of the currently recorded target verification node.

[0050] If the comparison result indicates that the priority of the matching point is higher than the priority of the currently recorded target verification node, then the matching point is determined as the target verification node, and the verification information in the target verification node is extracted.

[0051] Preferably, after receiving the programming result from the target vehicle domain controller and forwarding the programming result to the vehicle-side security module, the method further includes:

[0052] If the burning result is successful, the firmware version number in the device file of the target vehicle domain controller will be updated to the target version information.

[0053] The timestamp, upgrade package hash value, and upgrade result of this upgrade are recorded in the security log of the vehicle-side security module.

[0054] The updated device files are synchronized to the vehicle telematics platform so that the telematics platform can update the vehicle configuration status according to the new firmware version number.

[0055] Accordingly, the method further includes:

[0056] Receive the emergency rollback request sent by the vehicle-side safety module;

[0057] Query the historical firmware backup partition of the target vehicle domain controller to obtain the backup firmware package and backup check value of the previous version;

[0058] The backup firmware package and backup verification value are sent to the target vehicle domain controller.

[0059] Preferably, after sending the backup firmware package and backup verification value to the target vehicle domain controller, the method further includes:

[0060] Receive the rollback completion confirmation message from the target vehicle domain controller;

[0061] Based on the rollback completion confirmation message, the lock status of the target upgrade package is released;

[0062] If the rollback completion confirmation message is not received within the preset time window, the rollback operation is determined to have timed out.

[0063] Send a retry command to the vehicle-side security module so that the vehicle-side security module can reacquire the backup firmware package and resend it;

[0064] If the rollback completion confirmation message is not received after the preset limit of retries is reached, an upgrade accident alarm is generated and sent to the operation and maintenance terminal, and the remote upgrade permission of the target vehicle domain controller is locked.

[0065] A vehicle-cloud collaborative vehicle domain controller remote upgrade system, applicable to the aforementioned vehicle-cloud collaborative vehicle domain controller remote upgrade method, includes:

[0066] The status query unit is configured to receive an upgrade package acquisition request for the target body domain controller sent by the vehicle-side security module, and to query the current device status of the target body domain controller.

[0067] The verification construction unit is configured to determine whether the preset upgrade conditions are met based on the current device state, and construct a target upgrade verification structure based on the upgrade package acquisition request and the current device state when the conditions are met; the target upgrade verification structure is a verification tree composed of several verification nodes, and the verification nodes are generated based on the state of one of the vehicle's several subsystems used for initialization;

[0068] The upgrade response unit is configured to send an upgrade ready response to the vehicle-side security module, so that the vehicle-side security module requests the target upgrade package from the cloud platform management node.

[0069] The upgrade verification unit is configured to receive an upgrade package download request sent by the vehicle-side security module, and generate a hash value and digital signature of the target upgrade package based on the verification information in the target upgrade verification structure; and send the hash value and digital signature to the vehicle-side security module so that the vehicle-side security module can download the target upgrade package after successful verification.

[0070] The programming feedback unit is configured to receive an upgrade execution command and a decryption key for the target upgrade package sent by the vehicle-side security module after completing the download and verifying its integrity; and to forward the decryption key and the target upgrade verification structure to the target vehicle domain controller according to the upgrade execution command, so that the target vehicle domain controller can decrypt the upgrade package using the decryption key, perform programming using the target upgrade verification structure, and provide feedback on the programming result after programming is completed.

[0071] The result forwarding unit is configured to receive the burning result fed back by the target vehicle domain controller and forward the burning result to the vehicle-side security module.

[0072] Compared with the prior art, the beneficial effects of the present invention are:

[0073] (1) This invention uses multiple security mechanisms such as encryption, hash value and digital signature to ensure the integrity and legality of the upgrade package through the collaborative work of the vehicle-side security module and the cloud platform management node, effectively preventing malicious attacks and data tampering. By dynamically judging whether the upgrade conditions are met based on the current status of the vehicle, it ensures that the upgrade is carried out at the appropriate time, reducing the impact on the normal use of the vehicle.

[0074] (2) By utilizing the constructed target upgrade verification structure, this invention can generate suitable verification nodes for the states of different vehicle subsystems, thereby enhancing the flexibility and adaptability of the system. At the same time, it ensures that the upgrade tasks of each subsystem are effectively executed. Through the comparison of difference data and the construction of rollback instructions, it can quickly identify and handle upgrade failure issues, provide timely rollback capabilities, and ensure the safety and stability of the vehicle. By dividing the upgrade tasks according to the module resolution and storage structure, it achieves reasonable allocation of upgrade tasks, improves the resource utilization efficiency during the upgrade process, and reduces the upgrade time. Attached Figure Description

[0075] Figure 1 This is a schematic flowchart of the overall method in one embodiment of the present invention;

[0076] Figure 2 This is a schematic diagram of the overall system architecture in one embodiment of the present invention.

[0077] In the diagram: 1. Status query unit; 2. Verification construction unit; 3. Upgrade response unit; 4. Upgrade verification unit; 5. Burning feedback unit; 6. Result forwarding unit. Detailed Implementation

[0078] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0079] Example 1, please refer to Figure 1 This invention provides a technical solution: a remote upgrade method for vehicle-cloud collaborative vehicle domain controllers, applied to a cloud platform management node, the cloud platform management node connecting the vehicle-side security module and multiple vehicle domain controllers, including:

[0080] S1. Receive the upgrade package acquisition request for the target body domain controller sent by the vehicle-side security module, and query the current device status of the target body domain controller;

[0081] S2. Determine whether the preset upgrade conditions are met based on the current device status, and construct the target upgrade verification structure based on the upgrade package acquisition request and the current device status when the conditions are met; the target upgrade verification structure is a verification tree composed of several verification nodes, and the verification nodes are generated based on one of the several sub-states of the vehicle used for initialization;

[0082] S3. Send an upgrade readiness response to the vehicle-side security module so that the vehicle-side security module can request the target upgrade package from the cloud platform management node;

[0083] S4. Receive the upgrade package download request sent by the vehicle-side security module, and generate the hash value and digital signature of the target upgrade package according to the verification information in the target upgrade verification structure; send the hash value and digital signature to the vehicle-side security module so that the vehicle-side security module can download the target upgrade package after verification.

[0084] S5. Receive the upgrade execution command and the decryption key of the target upgrade package sent by the vehicle-side security module after completing the download and verifying its integrity; according to the upgrade execution command, forward the decryption key and the target upgrade verification structure to the target vehicle domain controller, so that the target vehicle domain controller can decrypt the upgrade package using the decryption key, perform the burning using the target upgrade verification structure, and provide feedback on the burning result after the burning is completed;

[0085] S6. Receive the burning result from the target vehicle domain controller and forward the burning result to the vehicle-side security module.

[0086] It should be noted that when the vehicle-side security module detects that a vehicle domain controller needs to be upgraded, it sends a request to the cloud platform management node to inquire about the required upgrade package. This is similar to a user clicking "Check for updates" on their mobile phone, and the device requesting the latest update file from the server. For example, suppose a vehicle's vehicle domain controller needs to be updated to fix a security vulnerability; the vehicle-side security module sends a request to the cloud platform to inquire whether there is an available upgrade package.

[0087] After receiving the request, the cloud platform management node will query the current status of the target vehicle domain controller, such as its version number and whether it is online. This step ensures that the upgrade will only continue if specific conditions are met. Example: The cloud platform finds that the version of the vehicle domain controller is 1.0, and it is currently online and running normally.

[0088] The cloud platform determines whether the preset upgrade conditions (such as version compatibility, device health status, etc.) are met based on the queried device status. If the conditions are met, the cloud platform will construct a target upgrade verification structure, which is a verification tree containing multiple verification nodes. Example: Because version 1.0 can be upgraded to version 1.1 and the device is in good condition, the cloud platform creates a verification tree, which includes different sub-nodes (such as power management, sensor status, etc.) as verification nodes.

[0089] Once the verification structure is built, the cloud platform will send an upgrade-ready response to the vehicle-side security module; this indicates that the cloud platform is ready to send the upgrade package; Example: The cloud platform notifies the vehicle-side security module: Ready to upgrade, please request the target upgrade package;

[0090] The vehicle-side security module will then request the target upgrade package from the cloud platform management node, along with information about the previously constructed verification structure; Example: The vehicle-side security module requests to download the new version of the upgrade package and provides verification tree information for verification;

[0091] After receiving a download request, the cloud platform generates a hash value and digital signature of the target upgrade package based on the information in the verification structure to ensure data integrity and security. Example: The cloud platform calculates the hash value of the upgrade package and generates a digital signature using the private key.

[0092] The cloud platform sends the hash value and digital signature to the vehicle-side security module. After receiving this information, the vehicle-side security module verifies it. If the verification is successful, the target upgrade package can be downloaded. Example: After the vehicle-side security module verifies the information, it starts downloading the target upgrade package from the cloud platform.

[0093] Once the download is complete and its integrity has been verified, the vehicle-side security module sends an upgrade execution command to the cloud platform and requests the decryption key for the target upgrade package. Upon receiving the request, the cloud platform forwards the decryption key and verification structure to the target vehicle domain controller. Example: The vehicle-side security module informs the cloud platform: Download complete, please send the decryption key and verification structure to begin the upgrade.

[0094] The target vehicle domain controller decrypts the upgrade package using the decryption key and performs the flashing operation according to the target upgrade verification structure. After flashing, the vehicle domain controller will report the flashing result. Example: The vehicle domain controller successfully decrypts and flashes the upgrade package, and then reports to the vehicle security module: Upgrade successful!

[0095] The cloud platform management node receives the burning result from the target vehicle domain controller and forwards it to the vehicle-side security module to complete the entire upgrade process. Example: The cloud platform transmits the burning success information back to the vehicle-side security module to confirm that the upgrade has been successfully completed.

[0096] In an optional embodiment, forwarding the decryption key and the target upgrade verification structure to the target vehicle domain controller according to the upgrade execution instruction includes:

[0097] Determine the upgrade package version in the target upgrade package, and based on the target upgrade verification structure, determine the target modules of several sub-upgrade execution tasks respectively;

[0098] The upgrade package version is compared with the current version of the target module to generate difference data;

[0099] The difference data and the target upgrade verification structure are traversed to find the target verification node in the target upgrade verification structure that matches the difference data, and the corresponding search results are obtained.

[0100] If the search results indicate that a matching target verification node exists, the verification information in the target verification node is retrieved, and the integrity of the upgrade package is verified based on the verification information.

[0101] Based on the verification results, control the target vehicle domain controller to perform the upgrade and determine whether the upgrade was successful;

[0102] If the upgrade fails, the error code of the current module is recorded, and a rollback instruction is constructed based on the current module and the difference data. The rollback instruction is identified as the new difference data, and the process jumps to the step of traversing the difference data and the target upgrade verification structure until the preset number of retries is reached or the upgrade is successful.

[0103] Once the upgrade is deemed successful, the target module after the upgrade is calculated based on the recorded error code and the current module status, and the flashing process is completed.

[0104] It should be noted that the target vehicle domain controller needs to determine the version information in the received upgrade package; this step is to understand what version is being upgraded to; for example, suppose the version of the target upgrade package is 1.1, which means that this is a new software version that includes some improvements and fixes;

[0105] Based on the target upgrade verification structure, several sub-modules related to the upgrade package are identified, and the target modules for the upgrade execution tasks corresponding to these sub-modules are found; for example, this may involve the body control module, power control module, etc.; Example: In this case, the target modules may include the power management module and the sensor control module; these modules need to be updated according to the requirements of the new version.

[0106] The upgrade package version will be compared with the current version of the target module to generate difference data; the difference data refers to the differences between the current version and the new upgrade version; for example, if the current power management module version is 1.0, compared with the new version 1.1, the difference data may include new features, bug fixes, etc.

[0107] Traverse the target upgrade verification structure to find target verification nodes that match the difference data; these nodes contain specific verification information for each module; for example, inspecting the verification structure reveals a node specifically for the upgrade of the power management module from version 1.0 to 1.1, and this node contains the corresponding verification information.

[0108] If a matching target verification node is found, the verification information in that node will be extracted and used to verify the integrity of the upgrade package to ensure that no data is lost or corrupted. Example: The extracted verification information shows that the hash value of the upgrade package is consistent with the expectation, indicating that the upgrade package is complete and has not been tampered with.

[0109] Based on the verification results, a decision is made on whether to control the target body domain controller to perform the upgrade. If the upgrade passes the verification, the formal upgrade operation is allowed. Example: If the verification is successful, a command will be sent to the target body domain controller to start the upgrade of the power management module.

[0110] During the upgrade process, the upgrade status will be monitored in real time. If the upgrade is successful, the new status of the module will be recorded. If the upgrade fails, the error code will be recorded. Example: The power management module is successfully upgraded to version 1.1. Record this status and mark it as a successful upgrade.

[0111] If a problem occurs during the upgrade process, an error code will be logged, and a rollback instruction will be constructed based on the current module state and difference data; this means that an attempt will be made to restore the module to its state before the upgrade; for example, suppose the power management module fails during the upgrade, the error code ERROR_01 is logged, and a rollback instruction is prepared to restore the module to version 1.0.

[0112] During the rollback process, the target upgrade verification structure is traversed again to confirm that it is safe to roll back to the previous version; this step is repeated until the preset number of retries is reached or the rollback is successful; Example: Try to perform the rollback three times, checking the verification structure each time to confirm the accuracy of the rollback data;

[0113] If the upgrade is ultimately determined to be successful, it will calculate the target module after the upgrade based on the previously recorded error codes and the current module status, and complete the flashing operation; Example: Since the power management module has been successfully upgraded, the new status is confirmed to be upgraded to 1.1, the flashing process is over, and the vehicle's power management function can now work normally.

[0114] In an optional embodiment, the system determines whether preset upgrade conditions are met based on the current device state, and if the conditions are met, constructs a target upgrade verification structure based on the upgrade package acquisition request and the current device state, including:

[0115] Read the vehicle driving status, battery power information and historical upgrade records of the target vehicle domain controller as the current device status;

[0116] If the vehicle is stationary, the battery level is greater than the preset threshold, and there are no unfinished upgrade tasks in the historical upgrade record, then the preset upgrade conditions are confirmed to be met.

[0117] Obtain the vehicle model identifier from the upgrade package request, and determine the module data structure array of the target vehicle domain controller based on the vehicle model identifier;

[0118] The number of verification nodes is determined based on the local vector module bit width, and the first verification node data structure of the independent verification node is defined.

[0119] Define the second verification node data structure of the target multi-branch verification node; the target multi-branch verification node is a combined verification node composed of a preset number of independent verification nodes as child nodes;

[0120] Using the vehicle's target sub-sub, a target multi-branch verification node and a target data structure are defined as verification nodes. Based on the verification nodes, the first verification node data structure, and the second verification node data structure, a target upgrade verification structure is constructed to obtain the target upgrade verification structure.

[0121] It should be noted that determining whether the device meets the upgrade requirements is based on its current status. This step involves reading several key pieces of information. For example, suppose the target vehicle domain controller is monitoring three important parameters: vehicle driving status: the vehicle is currently stationary; battery level: the battery level is 75%, higher than a preset threshold (e.g., 50%); and historical upgrade records: check the historical records to confirm that there are no incomplete upgrade tasks. If all three conditions are met, then the device status can be confirmed to meet the upgrade requirements.

[0122] After confirming that the vehicle is stationary, the battery is fully charged, and there are no unfinished upgrade tasks, the system will confirm that the preset upgrade conditions are met and prepare to proceed with the next steps; Example: Since the above conditions have all been met, a signal will be sent to confirm that the upgrade operation can proceed.

[0123] Extract the vehicle model identifier from the upgrade package request; the vehicle model identifier is important information used to determine which modules need to be upgraded; for example, assuming the vehicle model identifier is Sedan2023, this indicates that the control module of the 2023 sedan needs to be upgraded;

[0124] Based on the vehicle model identifier, a corresponding array of module data structures will be determined. These modules may be controllers for different functions, such as power and braking. For example, for Sedan2023, the following module data structures may be available: power control module; brake control module; power management module.

[0125] The required number of verification nodes is determined based on the local vector module bit width (e.g., the number of bits per module); these verification nodes are used to ensure that each module is effectively verified during upgrades; for example, assuming the vector module bit width is 32 bits, four independent verification nodes may be needed to process the relevant data.

[0126] Define the first verification node data structure for independent verification nodes; this structure contains basic information and parameters used for verification; example: the first verification node may contain the following information: module ID; current version number; upgrade version number;

[0127] Define the second verification node data structure of the target multi-branch verification node; this structure is a combined verification node, composed of multiple independent verification nodes; for example, suppose there are 4 independent verification nodes, these nodes will be combined into a multi-branch verification node; the structure of the multi-branch verification node may include: a list of child nodes (i.e., 4 independent verification nodes); combined verification information;

[0128] Using the vehicle's target sub-modules, the defined target multi-branch verification nodes and target data structures are used as verification nodes, and this information is used to construct the final target upgrade verification structure. For example, the previously defined independent verification nodes and multi-branch verification nodes are combined to form a complete verification structure to verify the upgrade that is about to be executed. For example, the target upgrade verification structure may contain verification information for all modules, as well as integrity verification of the upgrade package.

[0129] In an optional embodiment, a target multi-fork verification node and a target data structure are defined as verification nodes based on the vehicle's target sub-node. A target upgrade verification structure is then constructed based on the verification nodes, the first verification node data structure, and the second verification node data structure, including:

[0130] Divide the module data structure array into a predetermined number of target subsets;

[0131] Construct corresponding verification nodes for each target subset and store the verification nodes in the first target stack;

[0132] For the verification nodes in the first target stack, the operation of recursively dividing them into a preset number of target subsets and constructing corresponding verification nodes for each target subset is performed until the number of modules in the divided target subsets is not higher than the preset number, and the currently constructed verification node is determined as a leaf node.

[0133] Independent verification nodes are constructed based on the spatial coordinates of the modules in the leaf nodes and the data structure of the first verification node. The independent verification nodes are then merged according to the data structure of the second verification node. The constructed target multi-branch verification nodes are used to fill the leaf nodes, resulting in a target upgrade verification structure containing verification nodes.

[0134] It should be noted that the module data structure array is divided into a preset number of target subsets; these subsets will be used for subsequent verification. For example, suppose there is a data structure array containing 8 modules (e.g., power control, brake control, etc.), with a preset number of 2; these 8 modules will be divided into two subsets, each containing 4 modules; Target subset 1: Power control module, brake control module, steering control module, power management module; Target subset 2: Vehicle stability control module, tire pressure monitoring module, lighting control module, airbag control module;

[0135] Construct corresponding verification nodes for each target subset and store these nodes in the first target stack; Example: For target subset 1, a verification node will be created, containing basic information of all modules in the subset, such as version number and checksum, and stored in the first target stack; Verification node 1: contains information of all modules in target subset 1; Verification node 2: contains information of all modules in target subset 2;

[0136] The verification nodes in the first target stack are recursively partitioned until the number of modules in each target subset does not exceed a preset number. At this point, the currently constructed verification node is determined as a leaf node. Example: Assuming the preset number is 2, verification node 1 will be further partitioned: target subset 1 is further partitioned into: subset 1A: power control module, brake control module; subset 1B: steering control module, power management module; for subset 1A, a new verification node will be generated, and the partitioning will continue until each leaf node has only one module; leaf node 1: verification node of the power control module; leaf node 2: verification node of the brake control module; leaf node 3: verification node of the steering control module; leaf node 4: verification node of the power management module.

[0137] After the leaf nodes are determined, independent verification nodes are constructed based on the module spatial coordinates in the leaf nodes and the data structure of the first verification node. For example, for leaf node 1 (power control module), an independent verification node is created, which contains the module's spatial coordinates, current version, and upgrade version information. Independent verification node 1: spatial coordinates and version information of the power control module; Independent verification node 2: spatial coordinates and version information of the brake control module.

[0138] Based on the second verification node data structure, these independent verification nodes are merged to form a target multi-branch verification node. This multi-branch verification node combines multiple independent verification nodes for unified processing. Example: Assuming the second verification node data structure specifies the merging method, independent verification node 1 and independent verification node 2 are merged into a new multi-branch verification node. Target multi-branch verification node: contains independent verification node 1 (power control module) and independent verification node 2 (brake control module).

[0139] Fill the leaf nodes with the constructed target multi-branch verification nodes to form the final target upgrade verification structure; Example: Apply the constructed target multi-branch verification nodes to all leaf nodes to form a complete target upgrade verification structure, which contains the verification information and hierarchical structure of all modules; The final target upgrade verification structure contains the verification information of all leaf nodes and multi-branch verification nodes, with a clear structure that can support subsequent upgrade operations.

[0140] In an optional embodiment, receiving an upgrade package download request sent by the vehicle-side security module, and generating a hash value and digital signature of the target upgrade package based on the verification information in the target upgrade verification structure, includes:

[0141] Determine the module resolution of the target vehicle domain controller in the local preset storage structure and upgrade package information;

[0142] Based on the preset storage structure and module resolution, several sub-levels are divided into cache levels, and the corresponding task allocation amount for each round is determined.

[0143] Obtain the sub-number and the level number of the cache level to which each of the sub-subs is assigned, and determine the module space location corresponding to the module upgrade task that each of the sub-subs is responsible for based on the sub-number and the level number.

[0144] Based on the module spatial location and the verification information in the target upgrade verification structure, the target upgrade package is divided into blocks to generate an upgrade package block list.

[0145] The upgrade package block list is signed using the private key of the cloud platform management node to obtain the block signature information;

[0146] The target upgrade package, the list of upgrade package chunks, and the chunk signature information are packaged together as part of the target upgrade package's hash value and digital signature.

[0147] It should be noted that when the vehicle-side safety module sends an upgrade package download request, the validity of the request must first be verified. This request will contain information such as the module to be upgraded and its version number. For example, suppose the vehicle requests to upgrade the power control module to version 2.0; such a request will be accepted and enter the processing flow.

[0148] Determine the local preset storage structure and the resolution of the target module specified in the request; module resolution refers to the supported module versions or capacities; example: the local storage structure may include multiple partitions (such as software, firmware, etc.), while the power control module has a resolution of 512KB;

[0149] Based on the preset storage structure and module resolution, several sub-modules will be divided, cache levels will be set, and the allocation of tasks in each round will be determined. This means that the upgrade task will be processed in multiple batches to improve efficiency. Example: Suppose there are three sub-modules (A, B, and C), each responsible for a different module. Since the resolution of each module is 512KB, it is determined that each sub-module can process 128KB of data in one upgrade task. Then: Sub-module A: processes the power control module; Sub-module B: processes the brake control module; Sub-module C: processes the steering control module.

[0150] Obtain the sub-number and the level number of the corresponding cache level for each sub-module; based on this information, determine the spatial location of the module upgrade task that each sub-module is responsible for; Example: Sub-module A (sub-number 1, level number 2): responsible for the power control module, spatial location is / firmware / power_control / ; Sub-module B (sub-number 2, level number 2): responsible for the brake control module, spatial location is / firmware / brake_control / ; Sub-module C (sub-number 3, level number 2): responsible for the steering control module, spatial location is / firmware / steering_control / ;

[0151] Based on the spatial location of the modules and the verification information in the target upgrade verification structure, the target upgrade package is segmented. This process ensures data consistency and integrity during transmission and storage. Example: Assuming the target upgrade package size is 1.5MB, it is divided into multiple blocks, each 128KB, resulting in approximately 12 blocks. The last block may be smaller than 128KB. Block list: Packet 1 (128KB), Packet 2 (128KB), ..., Packet 11 (128KB), Packet 12 (64KB)

[0152] The generated upgrade package block list is signed using the private key of the cloud platform management node. This step ensures that the source of the package is trustworthy and can be verified during actual use. Example: Use the private key to generate corresponding signature information for each block, such as the signature of block 1, the signature of block 2, etc.

[0153] The target upgrade package, the list of upgrade package chunks, and the signature information of each chunk are packaged together as part of the hash value and digital signature; this process ensures the integrity and security of the entire upgrade package; Example: The final generated upgrade package contains the following: the complete target upgrade package (1.5MB); the list of upgrade package chunks (information on 12 chunks); and the signature information for each chunk.

[0154] In an optional embodiment, several sub-modules are divided into cache levels according to a preset storage structure and module resolution, and the corresponding task allocation amount for each round is determined, including:

[0155] Determine whether the height or width of the resolution is a multiple of the preset baseline value;

[0156] If the height or width of the resolution is not a multiple of the baseline value, then the irregular and regular parts in the target vehicle body domain controller are determined.

[0157] Regarding the rules section, based on the preset task allocation rules and the local preset storage structure, corresponding upgrade execution tasks are allocated to several sub-allocations, and the initial task allocation amount is determined.

[0158] Accordingly, based on the module's spatial location and the verification information in the target upgrade verification structure, the target upgrade package is divided into blocks, including:

[0159] The upgrade package data of the rules section is divided into several rule blocks based on the initial task allocation;

[0160] The irregular parts of the upgrade package data are stored in a preset atomic task pool, and an independent checksum is generated for each irregular block in the atomic task pool.

[0161] The verification information in the target upgrade verification structure is used to sign and encapsulate the regular blocks and irregular blocks respectively.

[0162] It should be noted that determining whether the target module's resolution, i.e., its height and width, are multiples of the preset baseline values ​​is helpful for subsequent task allocation and block processing. For example, assuming the preset baseline value is 128 pixels, if the target module's resolution is 640x480 pixels, then: the height (480) is a multiple of 128 (3.75 times), which meets the requirements; the width (640) is also a multiple of 128 (5 times), which meets the requirements; in this case, the module is considered a regular part.

[0163] If the result of the judgment is that the height or width is not a multiple of the preset baseline value, it is necessary to identify the irregular and regular parts from the target vehicle domain controller; Example: Assume that the resolution of the target module is 700x500 pixels: the height (500) is not a multiple of 128 (3.91 times), so this part is considered an irregular part; the width (700) is also not a multiple of 128 (5.47 times), so the entire module is regarded as an irregular part;

[0164] For the identified rule parts, use the preset task allocation rules to upgrade the execution tasks of several sub-assignments and determine the initial task allocation amount; since there are no rule parts in this example, this step can be skipped; Example: If a module has a resolution of 512x256 pixels and meets the rule conditions, it may be decided to divide it into two sub-assignments, each responsible for a 256x256 area.

[0165] Based on the initial task allocation, the upgrade package data of the regular part is divided into several regular blocks; the data of the irregular part is stored in the atomic task pool, and an independent checksum is generated for each irregular block; for example, for a regular part of 1MB in size, it can be divided into 8 blocks of 128KB; while for the irregular part, assuming its size is 300KB, it is stored in the atomic task pool, and two blocks (128KB and 172KB) may be generated and checksums are calculated separately.

[0166] Using the verification information in the target upgrade verification structure, regular blocks and irregular blocks are signed and encapsulated to ensure data integrity and security. For example, for regular blocks, each 128KB block is signed to generate corresponding signature information; for irregular blocks, each block (such as 128KB and 172KB) is also signed to ensure that its integrity can be verified during the upgrade process.

[0167] In an optional embodiment, the difference data is traversed against the target upgrade verification structure to find the target verification node in the target upgrade verification structure that matches the difference data, and the corresponding search results are obtained, including:

[0168] The difference data is traversed along with the initial nodes of the target upgrade verification structure, and during the traversal, the target child nodes that match the difference data are saved to the second target stack.

[0169] Retrieve the target child node from the second target stack, and use the target child node as the initial node for the next recursion, as well as the step of jumping to the initial node of the difference data and the target upgrade verification structure to traverse, until the second target stack is empty;

[0170] When traversing to a leaf node in the target upgrade verification structure, the module information in the leaf node is matched with the difference data. If it is determined that there is a match with the difference data, the leaf node that matches the difference data is determined as the matching point, and the priority of the matching point is compared with the priority of the target verification node currently recorded.

[0171] If the priority of the matching point is higher than the priority of the target verification node currently recorded, then the matching point is determined as the target verification node, and the verification information in the target verification node is extracted.

[0172] It should be noted that the target upgrade verification structure is traversed; assuming there is a target upgrade verification structure, it is a tree structure, and each node may contain module information, child nodes, and priority, etc.; in this structure, the root node is the initial node;

[0173] When traversing the initial nodes, if the module information of a child node matches the difference data, the child node is saved to the second target stack. This stack is used to manage all the matching child nodes found. For example, suppose that during the traversal, the module information in child node B matches the difference data module X. At this time, child node B is put into the second target stack.

[0174] Remove the target child node from the second target stack and use it as the initial node for the next recursive step, continuing the traversal; this process will continue until the second target stack is empty; Example: Remove child node B from the second target stack and use it as the new initial node for traversal; Assume that there are no more matches in this process, return to the second target stack, and find that it is empty;

[0175] When traversing to the leaf node of the target upgrade verification structure, it is necessary to match the module information in the leaf node with the difference data. If the match is found, the current leaf node can be identified as the matching point. Example: Suppose that during the traversal of child node B, leaf node B1 is reached, and the module information of this node matches the difference data module X. At this time, B1 is marked as the matching point.

[0176] After finding a matching point, the priority of the matching point needs to be compared with the priority of the target verification node of the current record. If the priority of the matching point is higher than the priority of the target verification node of the current record, the matching point is determined as the new target verification node, and the verification information in it is extracted. Example: Suppose the target verification node of the current record is child node A1 with a priority of 2, while the priority of the matching point B1 is 4. Since the priority of B1 is higher than that of A1, B1 is determined as the target verification node, and the verification information in B1 is extracted.

[0177] In an optional embodiment, after receiving the programming result from the target vehicle domain controller and forwarding the programming result to the vehicle-side security module, the method further includes:

[0178] If the burning result is successful, the firmware version number in the device file of the target vehicle domain controller will be updated to the target version information.

[0179] Record the timestamp, upgrade package hash value, and upgrade result of this upgrade in the security log of the vehicle-side security module;

[0180] The updated device files are synchronized to the vehicle telematics platform so that the telematics platform can update the vehicle configuration status according to the new firmware version number.

[0181] Correspondingly, the methods also include:

[0182] Receive an emergency rollback request sent by the vehicle-side safety module;

[0183] Query the historical firmware backup partition of the target vehicle domain controller to obtain the backup firmware package and backup check value of the previous version;

[0184] Send the backup firmware package and backup checksum to the target vehicle domain controller.

[0185] It should be noted that after the target vehicle domain controller completes the firmware flashing, it will return a flashing result; this result may be success or failure. For example, assuming the target vehicle domain controller returns a successful flashing result, the following steps need to be performed: update the firmware version number in the device file; assuming the current firmware version is 1.0 and the target version is 2.0, then the firmware version number in the device file will be updated to 2.0; this step ensures that the vehicle's device file always reflects the latest firmware information.

[0186] The security log of the vehicle-side security module records relevant information about this upgrade. This information includes the upgrade timestamp, the hash value of the upgrade package (used to verify data integrity), and the upgrade result. Example: Assuming this upgrade occurred on April 23, 2026, and the hash value of the upgrade package is abc123xyz, the security log will record the following information: Timestamp: April 23, 2026, 09:00; Upgrade package hash value: abc123xyz; Upgrade result: Successful. This is done to provide a basis for subsequent auditing and troubleshooting.

[0187] The updated device profile needs to be synchronized to the vehicle telematics platform. This operation enables the telematics platform to update the vehicle's configuration status based on the new firmware version number. For example, after receiving the updated device profile, the telematics platform will detect that the firmware version has been updated from 1.0 to 2.0. Based on this information, the platform will adjust the vehicle's configuration status to ensure that everything is compatible with the latest firmware version.

[0188] If an emergency rollback request is received from the vehicle-side safety module after an upgrade, it means that a problem has occurred in the new firmware and a revert to the previous version is required. For example, suppose a user reports that the vehicle is becoming unstable after upgrading to the new firmware; the vehicle-side safety module immediately sends an emergency rollback request.

[0189] Query the historical firmware backup partition of the target vehicle domain controller to obtain the backup firmware package of the previous version and its checksum; this step ensures that it can be restored to a known stable state; Example: In the historical backup partition, find the backup firmware package of the previous firmware version 1.0 and the corresponding checksum xyz789abc;

[0190] Send the backup firmware package and checksum back to the target vehicle domain controller to perform a rollback operation; Example: Send firmware package 1.0 and checksum xyz789abc to the target vehicle domain controller to instruct it to perform a rollback operation.

[0191] In an optional embodiment, after sending the backup firmware package and backup checksum to the target vehicle domain controller, the method further includes:

[0192] Receive the rollback completion confirmation message from the target vehicle domain controller;

[0193] Release the lock on the target upgrade package based on the rollback completion confirmation message;

[0194] If no rollback completion confirmation message is received within the preset time window, the rollback operation is deemed to have timed out.

[0195] Send a retry command to the vehicle-side safety module so that the vehicle-side safety module can reacquire the backup firmware package and resend it;

[0196] If the number of retries reaches the preset limit and no rollback completion confirmation message is received, an upgrade accident alarm will be generated and sent to the operation and maintenance terminal, and the remote upgrade permission of the target vehicle domain controller will be locked.

[0197] It should be noted that after sending the backup firmware package and checksum, the system will wait for a rollback completion confirmation message from the target body domain controller. This message indicates that the body domain controller has successfully restored to the previous firmware version. For example, suppose firmware package 1.0 and the corresponding checksum are sent to the target body domain controller. A few seconds later, the body domain controller sends a message: Rollback successful. After receiving this message, it can be confirmed that the rollback operation has been successfully completed.

[0198] Once the rollback is confirmed to be complete, the lock on the target upgrade package will be released; this means that subsequent firmware upgrades can continue without being affected by the previous rollback operation; for example: upon receiving a successful rollback message, the lock on the target upgrade package will be released immediately, allowing firmware upgrades to proceed again.

[0199] If no rollback completion confirmation message is received within the preset time window (e.g., 30 seconds), the rollback operation will be deemed to have timed out. Example: Suppose 30 seconds have passed but no rollback confirmation message has been received; this event will be recorded and marked as rollback timeout.

[0200] Upon detecting a rollback timeout, a retry command is sent to the vehicle-side security module. This command requires the vehicle-side security module to reacquire the backup firmware package and attempt to distribute it to the target vehicle domain controller again. Example: A retry command is issued, requiring the vehicle-side security module to reload firmware package 1.0 and resend it to the target vehicle domain controller. This is done to ensure that the rollback operation has a chance to be executed again to resolve the previous failure.

[0201] Set a maximum number of retries, such as 3 times. If the maximum number of retries is reached and no rollback completion confirmation message is received, an upgrade incident alert will be generated. Example: Suppose 3 retries were performed and no rollback confirmation was received each time. At this time, an alert message will be generated with the content "Upgrade incident: Rollback failed" and sent to the operation and maintenance terminal so that operation and maintenance personnel can intervene and handle it in a timely manner.

[0202] After generating an alert, remote upgrade permissions for the target vehicle domain controller will also be locked. This is to prevent firmware upgrades from continuing without resolving the issue, thus avoiding potentially more serious problems. Example: Automatically lock remote upgrade permissions for the target vehicle domain controller to ensure that firmware upgrades cannot be performed again until the issue is resolved.

[0203] Example 2, please refer to Figure 2 This invention provides a technical solution: a vehicle-cloud collaborative vehicle domain controller remote upgrade system, applicable to the aforementioned vehicle-cloud collaborative vehicle domain controller remote upgrade method, comprising:

[0204] Status query unit 1 is configured to receive an upgrade package acquisition request for the target body domain controller sent by the vehicle-side security module, and query the current device status of the target body domain controller.

[0205] Verification construction unit 2 is configured to determine whether the preset upgrade conditions are met based on the current device status, and construct a target upgrade verification structure based on the upgrade package acquisition request and the current device status when the conditions are met; the target upgrade verification structure is a verification tree composed of several verification nodes, and the verification nodes are generated based on the status of one of the subsystems used for initialization in several subsystems of the vehicle;

[0206] Upgrade response unit 3 is configured to send an upgrade ready response to the vehicle-side security module, so that the vehicle-side security module can request the target upgrade package from the cloud platform management node.

[0207] Upgrade verification unit 4 is configured to receive the upgrade package download request sent by the vehicle-side security module, and generate the hash value and digital signature of the target upgrade package according to the verification information in the target upgrade verification structure; send the hash value and digital signature to the vehicle-side security module so that the vehicle-side security module can download the target upgrade package after verification.

[0208] The programming feedback unit 5 is configured to receive the upgrade execution command and the decryption key of the target upgrade package sent by the vehicle-side security module after completing the download and verifying its integrity; according to the upgrade execution command, it forwards the decryption key and the target upgrade verification structure to the target vehicle domain controller, so that the target vehicle domain controller can decrypt the upgrade package using the decryption key, perform programming using the target upgrade verification structure, and provide feedback on the programming result after programming is completed;

[0209] Result forwarding unit 6 is configured to receive the burning result fed back by the target vehicle domain controller and forward the burning result to the vehicle-side security module.

[0210] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited thereto. Various changes can be made within the scope of knowledge possessed by those skilled in the art without departing from the spirit of the present invention.

Claims

1. A remote upgrade method for vehicle-cloud collaborative body domain controllers, applied to a cloud platform management node, wherein the cloud platform management node connects a vehicle-side security module and multiple body domain controllers, characterized in that, include: Receive the upgrade package acquisition request for the target body domain controller sent by the vehicle-side security module, and query the current device status of the target body domain controller; Based on the current device status, determine whether the preset upgrade conditions are met, and if the conditions are met, construct a target upgrade verification structure based on the upgrade package acquisition request and the current device status; The target upgrade verification structure is a verification tree composed of several verification nodes, and the verification nodes are generated based on the state of one of the vehicle's several subsystems used for initialization. Send an upgrade ready response to the vehicle-side security module so that the vehicle-side security module can request the target upgrade package from the cloud platform management node; The system receives an upgrade package download request sent by the vehicle-side security module, and generates a hash value and digital signature of the target upgrade package based on the verification information in the target upgrade verification structure; the system then sends the hash value and digital signature to the vehicle-side security module so that the vehicle-side security module can download the target upgrade package after successful verification. The system receives an upgrade execution command and a decryption key for the target upgrade package sent by the vehicle-side security module after completing the download and verifying its integrity. Based on the upgrade execution command, the system forwards the decryption key and the target upgrade verification structure to the target vehicle domain controller, enabling the target vehicle domain controller to decrypt the upgrade package using the decryption key, perform the flashing process using the target upgrade verification structure, and provide feedback on the flashing result after completion. The system receives the burning result from the target vehicle domain controller and forwards the burning result to the vehicle-side security module.

2. The method for remotely upgrading a vehicle domain controller in a vehicle-cloud collaborative manner according to claim 1, characterized in that, According to the upgrade execution instruction, the decryption key and the target upgrade verification structure are forwarded to the target vehicle domain controller, including: Determine the upgrade package version in the target upgrade package, and determine the target modules for the upgrade execution tasks corresponding to the several subsystems based on the target upgrade verification structure; The upgrade package version is compared with the current version of the target module to generate difference data; The difference data is traversed with the target upgrade verification structure to find the target verification node in the target upgrade verification structure that matches the difference data, and the corresponding search results are obtained. If the search result indicates that a matching target verification node exists, then the verification information in the target verification node is extracted, and the integrity of the upgrade package is verified based on the verification information. Based on the verification results, the target vehicle domain controller is controlled to perform the upgrade, and it is determined whether the upgrade is successful. If the upgrade fails, the error code of the current module is recorded, and a rollback instruction is constructed based on the current module and the difference data. The rollback instruction is identified as new difference data, and the process jumps to the step of traversing the difference data and the target upgrade verification structure until the preset number of retries is reached or the upgrade is successful. Once the upgrade is deemed successful, the target module after the upgrade is calculated based on the recorded error code and the current module status, and the flashing process is completed.

3. The method for remotely upgrading a vehicle domain controller in a vehicle-cloud collaborative manner according to claim 2, characterized in that, Based on the current device status, determine whether the preset upgrade conditions are met, and if the conditions are met, construct a target upgrade verification structure based on the upgrade package acquisition request and the current device status, including: The vehicle driving status, battery power information, and historical upgrade records of the target vehicle domain controller are read respectively as the current device status; If the vehicle is stationary, the battery level is greater than a preset threshold, and there are no unfinished upgrade tasks in the historical upgrade record, then the preset upgrade conditions are confirmed to be met. Obtain the vehicle model identifier from the upgrade package acquisition request, and determine the module data structure array of the target vehicle domain controller based on the vehicle model identifier; The number of verification nodes is determined based on the local vector module bit width, and the first verification node data structure of the independent verification node is defined. Define the second verification node data structure of the target multi-branch verification node; the target multi-branch verification node is a combined verification node composed of a preset number of the independent verification nodes as child nodes; Through the target subsystem of the vehicle, the target multi-fork verification node and the target data structure are defined as verification nodes, and the target upgrade verification structure is constructed based on the verification nodes, the first verification node data structure and the second verification node data structure.

4. The method for remotely upgrading a vehicle domain controller in a vehicle-cloud collaborative manner according to claim 3, characterized in that, Through the vehicle's target subsystem, the target multi-fork verification node and the target data structure are defined as verification nodes. Based on the verification nodes, the first verification node data structure, and the second verification node data structure, the target upgrade verification structure is constructed, including: Divide the module data structure array into the preset number of target subsets; Construct corresponding verification nodes for the target subsets respectively, and store the verification nodes in the first target stack; For the verification node in the first target stack, the operation of dividing it into the preset number of target subsets is performed recursively, and the operation of constructing corresponding verification nodes for the target subsets is performed respectively, until it is detected that the number of modules in the divided target subsets is not higher than the preset number, and the currently constructed verification node is determined as a leaf node; The independent verification node is constructed based on the spatial coordinates of the module in the leaf node and the first verification node data structure, and the independent verification node is merged according to the second verification node data structure, so as to fill the leaf node with the constructed target multi-branch verification node to obtain the target upgrade verification structure containing the verification node.

5. A method for remotely upgrading a vehicle domain controller in a vehicle-cloud collaborative manner according to claim 4, characterized in that, Receive the upgrade package download request sent by the vehicle-side security module, and generate the hash value and digital signature of the target upgrade package based on the verification information in the target upgrade verification structure, including: Determine the local preset storage structure and the module resolution of the target vehicle domain controller in the upgrade package information; The cache hierarchy of the several subsystems is divided according to the preset storage structure and the module resolution, and the corresponding task allocation amount for each round is determined. Obtain the subsystem number and the level number of the cache level to which each of the several subsystems is assigned, and determine the module space location corresponding to the module upgrade task to which each of the several subsystems is responsible based on the subsystem number and the level number. Based on the spatial location of the module and the verification information in the target upgrade verification structure, the target upgrade package is divided into blocks to generate an upgrade package block list; The upgrade package block list is signed using the private key of the cloud platform management node to obtain block signature information; The target upgrade package, the upgrade package block list, and the block signature information are packaged as part of the hash value and digital signature of the target upgrade package.

6. The method for remotely upgrading a vehicle domain controller in a vehicle-cloud collaborative manner according to claim 5, characterized in that, The cache hierarchy of the several subsystems is divided according to the preset storage structure and the module resolution, and the corresponding task allocation for each round is determined, including: Determine whether the height or width of the resolution is a multiple of a preset reference value; If it is determined that the height or width of the resolution is not a multiple of the reference value, then the irregular and regular parts in the target vehicle domain controller are identified. For the rules section, based on the preset task allocation rules and the local preset storage structure, corresponding upgrade execution tasks are allocated to the several subsystems, and the initial task allocation amount is determined; Accordingly, the step of dividing the target upgrade package into blocks based on the module's spatial location and the verification information in the target upgrade verification structure includes: The upgrade package data of the rule section is divided into several rule blocks according to the initial task allocation amount; The upgrade package data of the irregular portion is stored in a preset atomic task pool, and an independent check code is generated for each irregular block in the atomic task pool. The verification information in the target upgrade verification structure is used to sign and encapsulate the rule blocks and irregular blocks respectively.

7. A method for remotely upgrading a vehicle domain controller in a vehicle-cloud collaborative manner according to claim 6, characterized in that, The difference data is traversed against the target upgrade verification structure to find the target verification node in the target upgrade verification structure that matches the difference data, and the corresponding search results are obtained, including: The difference data is traversed with the initial node of the target upgrade verification structure, and during the traversal, the target child node that matches the difference data is saved to the second target stack. Retrieve the target child node from the second target stack, and use the target child node as the initial node for the next recursion, and jump to the step of traversing the difference data and the initial node of the target upgrade verification structure until the second target stack is empty; When traversing to a leaf node in the target upgrade verification structure, the module information in the leaf node is matched with the difference data. If it is determined that there is a match with the difference data, the leaf node that matches the difference data is determined as the matching point, and the priority of the matching point is compared with the priority of the currently recorded target verification node. If the comparison result indicates that the priority of the matching point is higher than the priority of the currently recorded target verification node, then the matching point is determined as the target verification node, and the verification information in the target verification node is extracted.

8. The method for remotely upgrading a vehicle domain controller in a vehicle-cloud collaborative manner according to claim 7, characterized in that, After receiving the programming result from the target vehicle domain controller and forwarding the programming result to the vehicle-side security module, the method further includes: If the burning result is successful, the firmware version number in the device file of the target vehicle domain controller will be updated to the target version information. The timestamp, upgrade package hash value, and upgrade result of this upgrade are recorded in the security log of the vehicle-side security module. The updated device files are synchronized to the vehicle telematics platform so that the telematics platform can update the vehicle configuration status according to the new firmware version number. Accordingly, the method further includes: Receive the emergency rollback request sent by the vehicle-side safety module; Query the historical firmware backup partition of the target vehicle domain controller to obtain the backup firmware package and backup check value of the previous version; The backup firmware package and backup verification value are sent to the target vehicle domain controller.

9. A method for remotely upgrading a vehicle domain controller in a vehicle-cloud collaborative manner according to claim 8, characterized in that, After sending the backup firmware package and backup verification value to the target vehicle domain controller, the method further includes: Receive the rollback completion confirmation message from the target vehicle domain controller; Based on the rollback completion confirmation message, the lock status of the target upgrade package is released; If the rollback completion confirmation message is not received within the preset time window, the rollback operation is determined to have timed out. Send a retry command to the vehicle-side security module so that the vehicle-side security module can reacquire the backup firmware package and resend it; If the rollback completion confirmation message is not received after the preset limit of retries is reached, an upgrade accident alarm is generated and sent to the operation and maintenance terminal, and the remote upgrade permission of the target vehicle domain controller is locked.

10. A vehicle-cloud collaborative vehicle domain controller remote upgrade system, applicable to the vehicle-cloud collaborative vehicle domain controller remote upgrade method according to any one of claims 1-9, characterized in that, include: The status query unit is configured to receive an upgrade package acquisition request for the target body domain controller sent by the vehicle-side security module, and to query the current device status of the target body domain controller. The verification construction unit is configured to determine whether the preset upgrade conditions are met based on the current device status, and construct a target upgrade verification structure based on the upgrade package acquisition request and the current device status when the conditions are met. The target upgrade verification structure is a verification tree composed of several verification nodes, and the verification nodes are generated based on the state of one of the vehicle's several subsystems used for initialization. The upgrade response unit is configured to send an upgrade ready response to the vehicle-side security module, so that the vehicle-side security module requests the target upgrade package from the cloud platform management node. The upgrade verification unit is configured to receive an upgrade package download request sent by the vehicle-side security module, and generate a hash value and digital signature of the target upgrade package based on the verification information in the target upgrade verification structure; and send the hash value and digital signature to the vehicle-side security module so that the vehicle-side security module can download the target upgrade package after successful verification. The programming feedback unit is configured to receive an upgrade execution command and a decryption key for the target upgrade package sent by the vehicle-side security module after completing the download and verifying its integrity; and to forward the decryption key and the target upgrade verification structure to the target vehicle domain controller according to the upgrade execution command, so that the target vehicle domain controller can decrypt the upgrade package using the decryption key, perform programming using the target upgrade verification structure, and provide feedback on the programming result after programming is completed. The result forwarding unit is configured to receive the burning result fed back by the target vehicle domain controller and forward the burning result to the vehicle-side security module.

Images