An OTA installation preparation method, system, processor and storage medium

Abstract

The application belongs to the technical field of vehicle OTA, and discloses an OTA installation preparation method, system, processor and storage medium: after OTA installation triggering, a UC-Master program module acquires an upgrade strategy file stored locally, judges whether a vehicle satisfies a vehicle upgrade precondition; when yes, sends a to-be-installed task validity check request to an OTA server; when the to-be-installed task is valid, the UC-Master program module judges whether actual version information of a to-be-upgraded part is consistent with source version information of the to-be-upgraded part; when yes, the UC-Master program module signs a downloaded target version software package and a current source version software package; after the signing passes, the encrypted target software package is decrypted; after the decryption succeeds, the UC-Master judges again whether the vehicle satisfies the vehicle upgrade precondition, and performs secondary check; after the secondary check passes, the OTA mode is entered. The application solves the problems of poor reliability and low safety of OTA upgrade.

Description

Technical Field

[0001] This invention belongs to the field of vehicle OTA technology, specifically relating to an OTA installation preparation method, system, processor, and storage medium. Background Technology

[0002] With the increasing application of OTA (Over-The-Air) technology for vehicle ECUs, the reliability and security of OTA upgrades are issues that urgently need to be addressed. Generally, a highly reliable upgrade strategy is designed during the OTA process, but the preparation work before installation is often too simple, which can easily lead to problems with the security and reliability of the upgrade.

[0003] Therefore, providing an OTA installation preparation method, system, processor, and storage medium to ensure that vehicle upgrades are in a safe and stable environment and provide users with a high-quality experience is an urgent problem to be solved. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention provides an OTA installation preparation method, system, processor, and storage medium.

[0005] In a first aspect, the present invention provides an OTA installation preparation method, the method comprising:

[0006] Step 1: After the OTA installation is triggered, the vehicle owner agrees to the disclaimer and confirms the upgrade. The UC-Master program module then obtains the upgrade strategy file stored locally and determines whether the vehicle meets the prerequisites for the upgrade based on the upgrade strategy file.

[0007] Step 2: When the vehicle upgrade prerequisites are met, the UC-Master program module sends a task validity verification request to the OTA server to determine whether the task to be installed is valid.

[0008] Step 3: When the installation task is valid, the UC-Master program module determines whether the actual version information of the part to be upgraded is consistent with the source version information of the part to be upgraded based on the source version information of the part to be upgraded in the upgrade strategy file.

[0009] Step 4: When the version information is consistent, the UC-Master program module verifies the signature of the downloaded target version software package and the current source version software package;

[0010] Step 5: After the signature verification is successful, the UC-Master program module decrypts the encrypted target version software package;

[0011] Step 6: After successful decryption, repeat step 1 for a second verification;

[0012] Step 7: After the secondary verification is passed, enter OTA mode.

[0013] Specifically, step 1 includes:

[0014] Step 11: The UC-Master program module reads the vehicle upgrade prerequisites from the upgrade strategy file and sends the vehicle upgrade prerequisites to the TBOX-SYS system module;

[0015] Step 12: The TBOX-SYS system module obtains the vehicle upgrade prerequisites from the vehicle and feeds them back to the UC-Master program module. The vehicle upgrade prerequisites include the current vehicle status, which includes vehicle speed and gear.

[0016] Step 13: The UC-Master program module determines whether the current state of the vehicle meets all the preset conditions. If all the preset conditions are met, the vehicle meets the prerequisites for vehicle upgrade.

[0017] Specifically, step 2 includes:

[0018] Step 21: The UC-Master program module obtains the task ID of the task to be installed in the upgrade strategy file and sends the verification request to the OTA server. The verification request includes the task ID.

[0019] Step 22: The OTA server determines whether the task to be installed corresponding to the task ID is valid, and feeds back the determination result to the UC-Master program module;

[0020] Step 23: If the UC-Master program module does not receive the judgment result, it waits for a first preset time and then resends the verification request. If it does not receive the judgment result within a second preset time, it determines that the task to be installed is valid and proceeds to step 3. If the UC-Master program module receives the judgment result as valid, it proceeds to step 3.

[0021] Specifically, step 3 includes:

[0022] Step 31: The UC-Master program module reads the source version information of the part to be upgraded and sends a request to the TBOX-SYS system module to obtain the actual version information of the part to be upgraded;

[0023] Step 32: If the TBOX-SYS system module fails to obtain the actual version information of the part to be upgraded, then exit the installation; if the TBOX-SYS system module successfully obtains the actual version information of the part to be upgraded, then feed back the actual version information of the part to be upgraded to the UC-Master program module.

[0024] Step 33: After receiving the actual version information of the part to be upgraded, the UC-Master program module determines whether the actual version information of the part to be upgraded is consistent with the source version information of the part to be upgraded.

[0025] Specifically, step 4 includes:

[0026] Step 41: The UC-Master program module reads the target version package digest dstPkgHash from the target version package, and then calculates the target version package digest realPkgHash through the Security module to determine whether dstPkgHash and realPkgHash are consistent.

[0027] Step 42: When they match, the UC-Master program module reads the target version software package signature file digest dstSignFileHash from the target version software package, and then calculates the target version software package signature file digest realSignFileHash through the Security module to determine whether dstSignFileHash and realSignFileHash are consistent.

[0028] Step 43: When they match, the UC-Master program module reads the currently used source version package digest srcPkgHash, and then calculates the source version package digest realscrPkgHash through the Security module to determine whether srcPkgHash and realscrPkgHash are consistent.

[0029] Step 44: When they match, the UC-Master program module reads the digest srcSignFileHash of the currently used source version software package signature file, and then calculates the realsrcSignFileHash of the source version software package signature file through the Security module, and determines whether srcSignFileHash and realSignFileHash are consistent.

[0030] Step 45: When they match, the UC-Master program module reads the target version software package signature file digest dstSignFileHash and the target version software package signature file dstSignFile, and sends them to the signature verification interface provided by PKI to verify the correctness of the target version software package signature.

[0031] Step 46: Signature verification successful. The UC-Master program module reads the source version software package signature file digest srcSignFileHash and the source version software package signature file srcSignFile, and sends them to the signature verification interface provided by PKI to verify the correctness of the source version software package signature.

[0032] Step 47: Signature verification successful. Proceed to the next ECU verification. Verification is complete when all ECU software packages have been successfully verified.

[0033] Specifically, step 5 includes:

[0034] Step 51: Determine whether the software package is encrypted using the isEncrypt encryption judgment module. If it is not encrypted, proceed to step 6.

[0035] Step 52: If encrypted, obtain the encryption factor of the software package through the upgrade strategy file;

[0036] Step 53: Based on the encryption factor, use a preset decryption method to restore the data and write it into the decrypted file oriFile;

[0037] Step 54: After successful writing, the Security module calculates the realOriHash digest of the file oriFile and determines whether readOriHash is consistent with the original packet digest oriHash. If they are consistent, decryption is successful.

[0038] Specifically, the UC-Master program module is integrated into the vehicle-to-everything (V2X) intelligent terminal TBOX.

[0039] Secondly, the present invention also provides an OTA installation preparation system, the system comprising:

[0040] The vehicle upgrade prerequisite condition judgment module: After OTA installation is triggered, the UC-Master program module obtains the upgrade strategy file stored locally and determines whether the vehicle meets the vehicle upgrade prerequisite conditions based on the upgrade strategy file.

[0041] When the vehicle upgrade prerequisites are met, the UC-Master program module sends a task validity verification request to the OTA server to determine whether the task to be installed is valid.

[0042] The version determination module, when the installation task is valid, the UC-Master program module determines whether the actual version information of the part to be upgraded is consistent with the source version information of the part to be upgraded based on the source version information of the part to be upgraded in the upgrade strategy file.

[0043] The software package verification module verifies the signatures of the downloaded target version software package and the current source version software package when the version information matches.

[0044] After successful signature verification, the UC-Master program module decrypts the encrypted target version software package.

[0045] After successful decryption, the secondary verification module calls the function of the vehicle upgrade precondition judgment module to perform secondary verification. After the secondary verification passes, the system enters OTA mode.

[0046] Thirdly, the present invention provides a processor for running a program, wherein the program executes any of the above-mentioned OTA installation preparation methods during runtime.

[0047] Fourthly, the present invention provides a computer storage medium storing program instructions, wherein the program instructions, when executed, control the device where the computer storage medium is located to execute any of the above-mentioned OTA installation preparation methods.

[0048] This invention discloses an OTA installation preparation method, system, processor, and storage medium. Before performing an OTA upgrade, the UC-Master program module obtains the stored upgrade strategy file, judges the vehicle status, and if the vehicle meets the preconditions for vehicle upgrade, it sends a task validity verification request to the OTA server to verify whether the task to be installed is valid. If the task to be installed is valid, it further judges whether the actual version information of the part to be upgraded is consistent with the source version information of the part to be upgraded, and verifies and decrypts the software package. Finally, a second verification is performed to ensure that the vehicle is in a safe and stable environment when performing an OTA upgrade, bringing a high-quality experience to the user. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0050] Figure 1A flowchart of an OTA installation preparation method according to the present invention;

[0051] Figure 2 This is a flowchart illustrating the vehicle upgrade prerequisite verification process in an embodiment of the present invention;

[0052] Figure 3 This is a flowchart illustrating the validity verification of the task to be installed in an embodiment of the present invention;

[0053] Figure 4 This is a flowchart illustrating the part version information verification process in an embodiment of the present invention;

[0054] Figure 5 This is a flowchart illustrating the software package signature verification process in an embodiment of the present invention;

[0055] Figure 6 This is a flowchart illustrating software package decryption in an embodiment of the present invention;

[0056] Figure 7 This is a schematic diagram of the structure of an OTA installation preparation system according to the present invention. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. Obviously, the specific embodiments described herein are merely illustrative of the invention and represent only a portion, not all, of the embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention.

[0058] It should be noted that if the embodiments of the present invention involve descriptions such as "first" and "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" and "second" may explicitly or implicitly include at least one of those features. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0059] Figure 1 The diagram shown is a flowchart of an embodiment of an OTA installation preparation method provided by the present invention. The flowchart specifically includes:

[0060] Step 1: After the OTA installation is triggered, the vehicle owner agrees to the disclaimer and confirms the upgrade. The UC-Master program module then obtains the upgrade strategy file stored locally and determines whether the vehicle meets the prerequisites for the upgrade based on the upgrade strategy file.

[0061] The UC-Master program module is the core program for vehicle OTA upgrades. It implements the main control logic for OTA, enabling business communication with the server and software package downloads. Once the upgrade package is downloaded, the user actively clicks "Install" to trigger the installation process. After installation is triggered, the vehicle owner needs to agree to the disclaimer and confirm the upgrade before the OTA installation preparation process begins.

[0062] Specifically, step 1 includes:

[0063] Step 11: The UC-Master program module reads the vehicle upgrade prerequisites from the upgrade strategy file and sends the vehicle upgrade prerequisites to the TBOX-SYS system module.

[0064] Step 12: The TBOX-SYS system module obtains the vehicle upgrade prerequisites from the vehicle and feeds them back to the UC-Master program module. The vehicle upgrade prerequisites include the current vehicle status, which includes vehicle speed and gear position.

[0065] Step 13: The UC-Master program module determines whether the current state of the vehicle meets all the preset conditions. If all the preset conditions are met, the vehicle meets the prerequisites for vehicle upgrade.

[0066] The preset conditions are the conditions that the vehicle status needs to meet when the vehicle is upgraded via OTA. They are set based on the experience of those skilled in the art or according to the actual application scenario. This application embodiment does not limit this.

[0067] If some conditions are not met, the user will be informed that the vehicle status is not met, and the installation prerequisites and the actual vehicle status will be presented to the user, requesting the user to change the vehicle status. If all conditions are met after comparison, the task validity verification process will begin.

[0068] The flowchart for vehicle upgrade prerequisite verification is as follows: Figure 2 As shown.

[0069] Step 2: When the vehicle upgrade prerequisites are met, the UC-Master program module sends a task validity verification request to the OTA server to determine whether the task to be installed is valid.

[0070] Specifically, step 2 includes:

[0071] Step 21: The UC-Master program module obtains the task ID of the task to be installed in the upgrade strategy file and sends the verification request to the OTA server. The verification request includes the task ID.

[0072] Step 22: The OTA server determines whether the task to be installed corresponding to the task ID is valid, and feeds back the determination result to the UC-Master program module.

[0073] Step 23: If the UC-Master program module does not receive the judgment result, it waits for a first preset time and then resends the verification request. If it does not receive the judgment result within a second preset time, it determines that the task to be installed is valid and proceeds to step 3. If the UC-Master program module receives the judgment result as valid, it proceeds to step 3.

[0074] When the UC-Master program module fails to receive a message from the OTA server, it waits for a preset time (e.g., 10 / 20 / 30s) and then requests a response again. If it still cannot receive a negative response from the server regarding this task, the task is considered to be still valid and the next step is performed.

[0075] If the task is invalid, the HMI will display the message "Task has failed, please wait for subsequent update push," and the installation will be terminated. The server will then be notified that the installation is complete.

[0076] HMI is the display interface for the vehicle's infotainment system.

[0077] The flowchart for verifying the validity of the installation task is as follows: Figure 3 As shown.

[0078] Step 3: When the installation task is valid, the UC-Master program module determines whether the actual version information of the part to be upgraded is consistent with the source version information of the part to be upgraded based on the source version information of the part to be upgraded in the upgrade strategy file.

[0079] Specifically, step 3 includes:

[0080] Step 31: The UC-Master program module reads the source version information of the part to be upgraded and sends a request to the TBOX-SYS system module to obtain the actual version information of the part to be upgraded.

[0081] Step 32: If the TBOX-SYS system module fails to obtain the actual version information of the part to be upgraded, it exits the installation process; if the TBOX-SYS system module successfully obtains the actual version information of the part to be upgraded, it feeds back the actual version information of the part to be upgraded to the UC-Master program module.

[0082] Step 33: After receiving the actual version information of the part to be upgraded, the UC-Master program module determines whether the actual version information of the part to be upgraded is consistent with the source version information of the part to be upgraded.

[0083] If the TBOX-SYS system module fails to obtain part version information (repeated 3 times, with an interval of 3 / 5 / 8 seconds each time), the installation will exit and the HMI will report "Failed to prepare for environment upgrade, please try again later" and the installation will be reported to the server.

[0084] If the actual version information of the part to be upgraded is inconsistent with the source version information of the part to be upgraded, the HMI will display "Failed to prepare for upgrade environment, please try again later", and the installation will be exited and reported to the server that the installation is complete.

[0085] The flowchart for verifying part version information is as follows: Figure 4 As shown.

[0086] Step 4: When the version information is consistent, the UC-Master program module verifies the signature of the downloaded target version software package and the current source version software package.

[0087] Specifically, step 4 includes:

[0088] Step 41: The UC-Master program module reads the target version package digest dstPkgHash from the target version package, and then calculates the target version package digest realPkgHash through the Security module to determine whether dstPkgHash and realPkgHash are consistent.

[0089] Step 42: When they match, the UC-Master program module reads the target version software package signature file digest dstSignFileHash from the target version software package, and then calculates the target version software package signature file digest realSignFileHash through the Security module to determine whether dstSignFileHash and realSignFileHash are consistent.

[0090] Step 43: When they match, the UC-Master program module reads the currently used source version package digest srcPkgHash, and then calculates the source version package digest realscrPkgHash through the Security module to determine whether srcPkgHash and realscrPkgHash are consistent.

[0091] Step 44: When they match, the UC-Master program module reads the digest srcSignFileHash of the currently used source version software package signature file, and then calculates the realsrcSignFileHash of the source version software package signature file through the Security module, and determines whether srcSignFileHash and realSignFileHash are consistent.

[0092] Step 45: When they match, the UC-Master program module reads the target version software package signature digest dstSignFileHash and the target version software package signature file dstSignFile, and sends them to the signature verification interface provided by PKI to verify the correctness of the target version software package signature.

[0093] The contents of the target version package signing file are the target version package signing data and public key.

[0094] Step 46: Signature verification successful. The UC-Master program module reads the source version software package signature file digest srcSignFileHash and the source version software package signature file srcSignFile, and sends them to the signature verification interface provided by PKI to verify the correctness of the source version software package signature.

[0095] The contents of the source version package signing file are the source version package signing data and public key.

[0096] Step 47: Signature verification successful. Proceed to the next ECU verification. Verification is complete when all ECU software packages have been successfully verified.

[0097] If the UC-Master program module downloads software packages for multiple ECUs, the UC-Master program module needs to verify the signatures of the target version software packages for all downloaded ECUs and the source version software packages currently in use. If the first ECU's signature verification is successful, the next ECU will be verified. If all ECU software packages are successfully verified, the verification is complete.

[0098] If the ECU software package verification fails, delete the downloaded software package and report to the HMI "Environment preparation failed: upgrade package is untrusted, please try updating again", then exit the installation and report the installation completion to the server.

[0099] The flowchart for package verification is as follows: Figure 5 As shown.

[0100] Step 5: After the signature verification is successful, the UC-Master program module decrypts the encrypted target version software package.

[0101] Specifically, step 5 includes:

[0102] Step 51: Determine whether the software package is encrypted using the isEncrypt encryption judgment module. If it is not encrypted, proceed to step 6.

[0103] Step 52: If encrypted, obtain the encryption factor of the software package through the upgrade strategy file.

[0104] Step 53: Based on the encryption factor, use a preset decryption method to restore the data and write it into the decrypted file oriFIle.

[0105] Step 54: After successful writing, the Security module calculates the realOriHash digest of the file oriFile and determines whether readOriHash is consistent with the original packet digest oriHash. If they are consistent, decryption is successful.

[0106] Preferably, the AES256 decryption method corresponding to the platform is used.

[0107] If the ECU software package decryption fails, delete the downloaded software package and report to the HMI "Environment preparation failed: upgrade package decryption failed, please try again", then exit the installation and report the installation completion to the server.

[0108] The flowchart for package decryption is as follows: Figure 6 As shown.

[0109] Step 6: After successful decryption, repeat step 1 for a second verification.

[0110] Step 7: After the secondary verification is passed, enter OTA mode.

[0111] Once the comparison is complete, the comparison results will be synchronized to the HMI. If any conditions are not met, the HMI will be notified of "Environment preparation failed: Vehicle conditions are not met. Please try again later," and the installation will exit, reporting the installation completion to the server. If all conditions are met after the comparison, the system will enter OTA mode.

[0112] Specifically, the UC-Master program module is integrated into the vehicle-to-everything (V2X) intelligent terminal TBOX.

[0113] Figure 7 The diagram shown is a structural schematic of an embodiment of an OTA installation preparation system provided by the present invention. Figure 7 As shown, the system includes:

[0114] The vehicle upgrade prerequisite judgment module, after OTA installation is triggered, the UC-Master program module obtains the upgrade strategy file stored locally, and determines whether the vehicle meets the vehicle upgrade prerequisites based on the upgrade strategy file.

[0115] When the vehicle upgrade prerequisites are met, the UC-Master program module sends a task validity verification request to the OTA server to determine whether the task to be installed is valid.

[0116] In the version determination module, when the task to be installed is valid, the UC-Master program module determines whether the actual version information of the part to be upgraded is consistent with the source version information of the part to be upgraded based on the source version information of the part to be upgraded in the upgrade strategy file.

[0117] When the version information matches, the UC-Master program module verifies the signature of the downloaded target version software package and the current source version software package.

[0118] After successful signature verification, the UC-Master program module decrypts the encrypted target version software package.

[0119] After successful decryption, the secondary verification module calls the function of the vehicle upgrade precondition judgment module to perform secondary verification. After the secondary verification passes, the system enters OTA mode.

[0120] The system includes TBOX, which stands for Telematics-BOX, or vehicle-mounted T-BOX for short. The UC-Master program module is integrated into TBOX.

[0121] According to another aspect of the present invention, a computer storage medium is provided, which stores program instructions, wherein the program instructions, when executed, control the device where the computer storage medium is located to execute any of the above-described OTA installation preparation methods.

[0122] According to another aspect of the present invention, a processor is provided for running a program, wherein the program executes the OTA installation preparation method described above during runtime.

[0123] The above-described embodiments merely illustrate preferred embodiments of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. An OTA installation preparation method, characterized in that, Includes the following steps: Step 1: After the OTA installation is triggered, the vehicle owner agrees to the disclaimer and confirms the upgrade. The UC-Master program module then obtains the upgrade strategy file stored locally and determines whether the vehicle meets the prerequisites for the upgrade based on the upgrade strategy file. Step 2: When the vehicle upgrade prerequisites are met, the UC-Master program module sends a task validity verification request to the OTA server to determine whether the task to be installed is valid. Step 2 includes: Step 21: The UC-Master program module obtains the task ID of the task to be installed in the upgrade strategy file and sends the verification request to the OTA server, the verification request including the task ID; Step 22: The OTA server determines whether the task to be installed corresponding to the task ID is valid and feeds back the determination result to the UC-Master program module; Step 23: If the UC-Master program module does not receive the determination result, it waits for a first preset time and then resends the verification request. If it does not receive the determination result within a second preset time, it determines that the task to be installed is valid and proceeds to Step 3; If the UC-Master program module receives the determination result as valid, it proceeds to Step 3. Step 3: When the installation task is valid, the UC-Master program module determines whether the actual version information of the part to be upgraded is consistent with the source version information of the part to be upgraded based on the source version information of the part to be upgraded in the upgrade strategy file. Step 4: When the version information is consistent, the UC-Master program module verifies the signature of the downloaded target version software package and the current source version software package. Step 4 includes: Step 41: The UC-Master program module reads the target version software package digest dstPkgHash from the target version software package, and then calculates the target version software package digest realPkgHash through the Security module, and determines whether dstPkgHash and realPkgHash are consistent; Step 42: If consistent, the UC-Master program module reads the target version software package signature file digest dstSignFileHash from the target version software package, and then calculates the target version software package signature file digest realSignFileHash through the Security module, and determines whether dstSignFileHash and realSignFileHash are consistent; Step 43: If consistent, the UC-Master program module reads the currently used source version software package digest srcPkgHash, and then calculates the source version software package digest realscrPkgHash through the Security module, and determines whether srcPkgHash is consistent. Step 44: If they match, the UC-Master program module reads the current source version software package signature file digest srcSignFileHash, and then calculates the source version software package signature file realsrcSignFileHash through the Security module to determine if srcSignFileHash matches realSignFileHash; Step 45: If they match, the UC-Master program module reads the target version software package signature file digest dstSignFileHash and the target version software package signature file dstSignFile, and sends them to the signature verification interface provided by the PKI to verify the correctness of the target version software package signature; Step 46: If the signature verification is successful, the UC-Master program module reads the source version software package signature file digest srcSignFileHash and the source version software package signature file srcSignFile, and sends them to the signature verification interface provided by the PKI to verify the correctness of the source version software package signature; Step 47: If the signature verification is successful, proceed to the next ECU verification. When all ECU software packages have been successfully verified, the verification is complete. In step S47, if the ECU software package verification fails, the downloaded software package is deleted and the HMI is notified that "Environment preparation failed: the upgrade package is untrusted, please try updating again". At the same time, the installation is exited and the server is reported that the installation is complete. Step 5: After the signature verification is successful, the UC-Master program module decrypts the encrypted target version software package; Step 6: After successful decryption, repeat step 1 for a second verification; Step 7: After the secondary verification is passed, enter OTA mode.

2. The OTA installation preparation method according to claim 1, characterized in that, Step 1 includes: Step 11: The UC-Master program module reads the vehicle upgrade prerequisites from the upgrade strategy file and sends the vehicle upgrade prerequisites to the TBOX-SYS system module; Step 12: The TBOX-SYS system module obtains the vehicle upgrade prerequisites from the vehicle and feeds them back to the UC-Master program module. The vehicle upgrade prerequisites include the current vehicle status, which includes vehicle speed and gear. Step 13: The UC-Master program module determines whether the current state of the vehicle meets all preset conditions. If all preset conditions are met, the vehicle meets the prerequisites for vehicle upgrade.

3. The OTA installation preparation method according to claim 2, characterized in that, Step 3 includes: Step 31: The UC-Master program module reads the source version information of the part to be upgraded and sends a request to the TBOX-SYS system module to obtain the actual version information of the part to be upgraded; Step 32: If the TBOX-SYS system module fails to obtain the actual version information of the part to be upgraded, then exit the installation; if the TBOX-SYS system module successfully obtains the actual version information of the part to be upgraded, then feed back the actual version information of the part to be upgraded to the UC-Master program module. Step 33: After receiving the actual version information of the part to be upgraded, the UC-Master program module determines whether the actual version information of the part to be upgraded is consistent with the source version information of the part to be upgraded.

4. The OTA installation preparation method according to claim 3, characterized in that, Step 5 includes: Step 51: Determine whether the software package is encrypted using the isEncrypt encryption judgment module. If it is not encrypted, proceed to step 6. Step 52: If encrypted, obtain the encryption factor of the software package through the upgrade strategy file; Step 53: Based on the encryption factor, use a preset decryption method to restore the data and write it into the decrypted file oriFile; Step 54: After successful writing, the Security module calculates the realOriHash digest of the file oriFile and determines whether readOriHash is consistent with the original packet digest oriHash. If they are consistent, decryption is successful.

5. The OTA installation preparation method according to claim 1, characterized in that, The UC-Master program module is integrated into the vehicle-to-everything (V2X) intelligent terminal TBOX.

6. An OTA installation preparation system, used to implement the method as described in any one of claims 1-5, characterized in that, include: The vehicle upgrade prerequisite condition judgment module: After OTA installation is triggered, the UC-Master program module obtains the upgrade strategy file stored locally and determines whether the vehicle meets the vehicle upgrade prerequisite conditions based on the upgrade strategy file. When the vehicle upgrade prerequisites are met, the UC-Master program module sends a task validity verification request to the OTA server to determine whether the task to be installed is valid. The version determination module, when the installation task is valid, the UC-Master program module determines whether the actual version information of the part to be upgraded is consistent with the source version information of the part to be upgraded based on the source version information of the part to be upgraded in the upgrade strategy file. The software package verification module verifies the signatures of the downloaded target version software package and the current source version software package when the version information matches. After successful signature verification, the UC-Master program module decrypts the encrypted target version software package. After successful decryption, the secondary verification module calls the function of the vehicle upgrade precondition judgment module to perform secondary verification. After the secondary verification passes, the system enters OTA mode.

7. A processor, characterized in that, The processor is used to run a program, wherein the program executes the OTA installation preparation method according to any one of claims 1 to 5 when it runs.

8. A computer storage medium, characterized in that, The computer storage medium stores program instructions, wherein when the program instructions are executed, they control the device where the computer storage medium is located to execute the OTA installation preparation method according to any one of claims 1 to 5.

Images