Terminal upgrading method and device based on traceability and result verification, and terminal equipment

Abstract

The application provides a terminal upgrading method and device based on traceability and result verification and a terminal device, relates to the technical field of power distribution Internet of Things, and the method comprises the following steps: in the case that an external storage device passes identity verification, performing an upgrading operation on at least one target to be upgraded of a current terminal through the external storage device, and generating upgrading result information of each target to be upgraded; if it is determined that the current target to be upgraded fails to upgrade, determining upgrading feature information based on the upgrading result information of the current target to be upgraded, inputting the current upgrading feature information, and generating a retry success probability of the current target to be upgraded through a preset retry prediction model; if the retry success probability is higher than a preset threshold, performing an upgrading retry operation on the current target to be upgraded, otherwise, terminating the upgrading retry operation, updating the upgrading result information of the current target to be upgraded and storing the upgrading result information into the external storage device. The application can effectively improve the security of the terminal device and improve the success rate of the upgrading retry operation.

Description

Technical Field

[0001] This application relates to the field of power distribution Internet of Things (IoT) technology, specifically to a terminal upgrade method based on traceability and result verification, a terminal upgrade device based on traceability and result verification, a machine-readable storage medium, and a terminal device. Background Technology

[0002] In the operation and maintenance system of the Internet of Things for power distribution, the software and firmware upgrades of core equipment such as transformer area power terminals and power distribution monitoring terminals are key links to ensure the iteration of equipment functions, performance optimization and security vulnerability repair. The evolution of its technical path is deeply adapted to the special characteristics of power distribution scenarios, and upgrading the terminals is an important means to improve their performance, fix vulnerabilities and add new functions.

[0003] Currently, common upgrade methods for smart terminals mainly include online network upgrades and local storage media upgrades. While online network upgrades are convenient, they are susceptible to network fluctuations and cyberattacks in power distribution scenarios with unstable network environments or high security requirements. For example, in some remote power distribution stations with poor network signal coverage, frequent upgrade interruptions not only prevent the completion of the upgrade task but may also lead to terminal malfunctions. Furthermore, cyberattacks may tamper with the upgrade package content, posing serious security risks to terminal operation.

[0004] Upgrading local storage media, such as using USB devices, while avoiding network-related issues to some extent, also has several shortcomings. Firstly, current technology lacks an effective security access detection mechanism for USB devices; any USB device can be connected to the terminal for upgrade operations. This allows malicious users to implant malicious upgrade programs, damaging the terminal system and affecting the stable operation of the entire power distribution IoT. Secondly, existing local upgrade processes lack effective recording and feedback mechanisms for upgrade results, making it difficult to quickly and accurately track the upgrade status of all terminals within the distribution area. This hinders maintenance personnel from promptly identifying and addressing upgrade anomalies.

[0005] Furthermore, existing terminal upgrade scripts are relatively simple in their functionality, failing to comprehensively cover the upgrade needs of various components of the terminal system (such as system patches, file systems, kernels, and apps), and lacking in flexibility and intelligence in the upgrade process. For example, existing scripts struggle to effectively handle complex upgrade scenarios, such as upgrades involving different versions of different components.

[0006] In summary, existing terminal upgrade technologies have significant shortcomings in terms of security, upgrade result feedback, and the comprehensiveness and flexibility of the upgrade process, and there is an urgent need for a more secure, efficient, and intelligent upgrade solution. Summary of the Invention

[0007] The purpose of this application is to provide a terminal upgrade method based on tracing and result verification, a terminal upgrade device based on tracing and result verification, a machine-readable storage medium, and a terminal device to solve the above-mentioned problems.

[0008] To achieve the above objectives, the first aspect of this application provides a terminal upgrade method based on tracing and result verification, comprising:

[0009] In response to an access operation of an external storage device, the external storage device is authenticated.

[0010] When the external storage device is authenticated, an upgrade operation is performed on at least one target to be upgraded on the current terminal through the external storage device, and upgrade result information for each target to be upgraded is generated;

[0011] If it is determined that the current target to be upgraded has failed, upgrade feature information is determined based on the upgrade result information of the current target to be upgraded. Using the current upgrade feature information as input, the retry success probability of the current target to be upgraded is generated by the preset retry prediction model.

[0012] If the retry success probability is higher than a preset threshold, an upgrade retry operation is performed on the current target to be upgraded; otherwise, the upgrade retry operation is terminated, the upgrade result information of the current target to be upgraded is updated, and it is stored in the external storage device.

[0013] Optionally, authenticating the external storage device includes:

[0014] The current device serial number of the external storage device is read, and pre-stored authentication information is obtained from the external storage device. The authentication information is obtained by encrypting the actual device serial number using a public key generated in advance based on the actual device serial number of the external storage device through an asymmetric encryption algorithm.

[0015] The authentication information is decrypted using the private key corresponding to the public key to obtain the actual device serial number. If the current device serial number matches the actual device serial number, the external storage device is determined to be authenticated. The private key is generated by the asymmetric encryption algorithm based on the actual device serial number.

[0016] Optionally, before authenticating the external storage device, the method further includes:

[0017] For each external storage device:

[0018] Generate a first random string of a specified length as the binding key for the current external storage device;

[0019] Obtain the first authentication data of the current external storage device, and perform encryption operation on the first authentication data of the current external storage device using a preset encryption algorithm to obtain the identity commitment data of the current external storage device;

[0020] Based on the binding key and the identity commitment data, a verification key for the current external storage device is generated through a preset key derivation function;

[0021] Get the device serial number of the current external storage device;

[0022] The device serial number of the current external storage device is associated with the binding key, identity commitment data and verification key of the current external storage device and then stored.

[0023] The device serial number of the current external storage device is encrypted using the verification key of the current external storage device to obtain the verification token data of the current external storage device, and the verification token of the current external storage device is stored in the authentication information storage area of ​​the current external storage device.

[0024] The initial authentication data for the current external storage device is generated through the following steps:

[0025] Generate a second random string of the specified length as the first authentication data of the current external storage device, and store the first authentication data of the current external storage device in the authentication information storage area of ​​the current external storage device.

[0026] Optionally, authenticating the external storage device includes:

[0027] Read the first authentication data and authentication token data of the external storage device from the authentication information storage area of ​​the external storage device;

[0028] The first verification data of the external storage device is encrypted using the preset encryption algorithm to obtain the actual identity commitment data of the external storage device.

[0029] Read the device serial number of the external storage device to obtain the binding key corresponding to the device serial number of the external storage device;

[0030] Based on the obtained binding key and the actual identity commitment data of the external storage device, the actual verification key of the external storage device is generated through the preset key derivation function;

[0031] The specified encryption operation is performed on the device serial number of the external storage device using the actual verification key to obtain the actual verification token data of the external storage device. The actual verification token data is compared with the obtained verification token data. If the two match, it is determined that the external storage device has passed the authentication.

[0032] Optionally, performing an upgrade operation on at least one target device of the current terminal via the external storage device includes:

[0033] Read the target upgrade script file from the external storage device and obtain the version number of the target upgrade script file;

[0034] Obtain the version number of the current upgrade script file of the current terminal, and compare the version number of the target upgrade script file with the version number of the current upgrade script file of the current terminal;

[0035] If the version number of the target upgrade script file is newer than the version number of the current upgrade script file on the current terminal, the current upgrade script file on the current terminal is replaced with the target upgrade script file, and an upgrade operation is performed on at least one target to be upgraded on the current terminal based on the target upgrade script file; otherwise, the upgrade operation on at least one target to be upgraded on the current terminal is terminated.

[0036] Optionally, performing an upgrade operation on at least one target device of the current terminal via the external storage device includes:

[0037] Check if a patch installation manifest file exists in the external storage device;

[0038] If a patch manifest file exists, the corresponding patch files are retrieved from the external storage device sequentially according to the patch installation order in the patch manifest file, and the patch installation operation is performed accordingly; otherwise...

[0039] If no patch installation manifest file exists, determine whether there are multiple patch files in the external storage device. If yes, terminate the patch installation operation; otherwise, obtain the corresponding patch file and perform the patch installation operation.

[0040] Optionally, performing an upgrade operation on at least one target device of the current terminal via the external storage device includes:

[0041] Check if a file system upgrade file exists in the external storage device;

[0042] If the file system upgrade file exists in the external storage device, determine whether there are multiple file system upgrade files. If yes, terminate the file system upgrade operation; otherwise, perform the file system upgrade operation based on the file system upgrade file.

[0043] Check if a kernel upgrade file exists in the external storage device;

[0044] If the kernel upgrade file exists in the external storage device, obtain the number of the kernel upgrade files and the file extension of the kernel upgrade files;

[0045] If the number of kernel upgrade files is not multiple, and the file extension of the kernel upgrade files is a preset file extension, perform the kernel upgrade operation based on the kernel upgrade files; otherwise, terminate the kernel upgrade operation; or

[0046] Check if a combined upgrade file exists in the external storage device, the combined upgrade file consisting of the file system upgrade file and the kernel upgrade file;

[0047] If the combined upgrade file exists in the external storage device, determine whether there are multiple combined upgrade files. If yes, terminate the file system and kernel upgrade operation; otherwise, perform the file system and kernel upgrade operation based on the combined upgrade file.

[0048] Optionally, performing an upgrade operation on at least one target device of the current terminal via the external storage device includes:

[0049] Check if system tool upgrade files exist in the external storage device;

[0050] If the system tool upgrade file exists in the external storage device, the current terminal's file system is mounted as read-write, a system tool upgrade operation is performed based on the system tool upgrade file, and after the system tool upgrade operation is completed, the current terminal's file system is reset to read-only; or

[0051] Check if the external storage device contains application update files;

[0052] If the application upgrade file exists in the external storage device, determine whether the filename of the application upgrade file is any one of a preset plurality of base application filenames;

[0053] If the filename of the application upgrade file is any one of a plurality of preset base application filenames, the application upgrade file is obtained, and the application upgrade operation is performed based on the application upgrade file.

[0054] Optionally, the upgrade feature information includes at least one upgrade failure feature factor, and the process of constructing the retry prediction model includes:

[0055] During the historical upgrade process of different terminals, the upgrade characteristic information of different targets to be upgraded on each terminal in the upgrade failure state and the corresponding upgrade retry operation results of the targets to be upgraded;

[0056] Among all the obtained upgrade feature information, the corresponding upgrade retry operation result is the total number of successful retry operations. The total number of upgrade retry operations corresponding to all upgrade feature information is determined. The ratio of the total number of successful retry operations to the total number of upgrade retry operations is used to construct the basic probability of successful retry. The basic probability of failed retry is determined based on the basic probability of successful retry.

[0057] In the upgrade feature information where all upgrade retry operations result in a successful retry, the retry success probability corresponding to each upgrade failure feature factor is the retry success conditional probability of the current upgrade failure feature factor, and the retry failure conditional probability of each upgrade failure feature factor is determined based on the retry success conditional probability of each upgrade failure feature factor.

[0058] A first prediction model is constructed by the product of the retry success conditional probability and the retry success base probability of each upgrade failure feature factor in the feature information, and a second prediction model is constructed by the product of the retry failure conditional probability and the retry failure base probability of each upgrade failure feature factor in the feature information.

[0059] The retry prediction model is constructed using the ratio of the first prediction model to the second prediction model.

[0060] Optionally, the retry success probability corresponding to each upgrade failure feature factor is determined through the following steps:

[0061] Determine the first number of each upgrade failure feature factor among all upgrade feature information where the corresponding upgrade retry operation result is a successful retry;

[0062] For each upgrade failure characteristic factor:

[0063] The ratio of the first number of current upgrade failure feature factors to the total number of successful retries is used as the retry success probability corresponding to the current upgrade failure feature factor.

[0064] Optionally, the process of constructing the retry prediction model further includes:

[0065] A retry probability table is established based on the retry success conditional probability of each upgrade failure feature factor, the retry failure conditional probability of each upgrade failure feature factor, the retry success base probability, and the retry failure base probability.

[0066] Using the current upgrade feature information as input, a pre-defined retry prediction model generates the retry success probability of the current target to be upgraded, including:

[0067] Identify each upgrade failure feature factor in the current upgrade feature information;

[0068] Based on the retry probability table, obtain the retry success conditional probability and retry success failure probability corresponding to each upgrade failure feature factor in the current upgrade feature information, and obtain the retry success base probability and retry failure base probability based on the retry probability table.

[0069] If the current upgrade feature information contains an upgrade failure feature factor that is not present in the retry probability table, the number of successful retryes corresponding to the upgrade failure feature factor after smoothing is determined by a pre-determined smoothing coefficient.

[0070] The smoothing term is the product of the smoothing coefficient and the total number of categories of upgrade failure feature factors. The total number of successful retries after smoothing is the sum of the smoothing term and the total number of successful retries.

[0071] The ratio of the number of successful retries after smoothing to the total number of successful retries after smoothing is used as the conditional probability of successful retries for this upgrade failure characteristic factor.

[0072] Using the retry success conditional probability, retry success failure probability, retry success base probability, and retry failure base probability of each upgrade failure feature factor in the current upgrade feature information as input, the retry success probability of the current target to be upgraded is generated by a preset retry prediction model.

[0073] A second aspect of this application provides a terminal upgrade device based on source tracing and result verification. Applying the aforementioned terminal upgrade method based on source tracing and result verification, the device includes:

[0074] An authentication module is configured to authenticate the external storage device in response to an access operation of the external storage device.

[0075] The upgrade operation module is configured to perform an upgrade operation on at least one target to be upgraded on the current terminal through the external storage device when the external storage device is authenticated, and generate upgrade result information for each target to be upgraded;

[0076] The retry prediction module is configured to determine upgrade feature information based on the upgrade result information of the current target to be upgraded if it is determined that the upgrade has failed. Using the current upgrade feature information as input, the module generates the retry success probability of the current target to be upgraded through a preset retry prediction model.

[0077] The upgrade retry module is configured to perform an upgrade retry operation on the current target to be upgraded if the retry success probability is higher than a preset threshold; otherwise, it terminates the upgrade retry operation, updates the upgrade result information of the current target to be upgraded, and stores it in the external storage device.

[0078] In a third aspect, this application provides a machine-readable storage medium storing instructions that, when executed by a processor, configure the processor to perform the terminal upgrade method based on tracing and result verification as described above.

[0079] In a fourth aspect, this application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the terminal upgrade method based on tracing and result verification as described above.

[0080] This application effectively improves the security of terminal devices by performing authentication operations on the accessed external storage devices. By generating upgrade result information corresponding to each upgrade operation and storing the upgrade result information in the external storage device, the source and verification of upgrade operations can be realized. At the same time, if it is determined that the upgrade operation has failed, upgrade feature information is extracted from the upgrade result information of the corresponding upgrade operation. Using the upgrade feature information as input, a pre-built prediction model is used to predict the success probability of retrying the corresponding upgrade operation. Based on the prediction result, it is dynamically determined whether to execute the upgrade retry operation, thereby effectively improving the success rate of upgrade retry operations and avoiding waste of resources.

[0081] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0082] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings:

[0083] Figure 1 A flowchart of a terminal upgrade method based on tracing and result verification provided in a preferred embodiment of this application;

[0084] Figure 2 An authentication flowchart provided for a preferred embodiment of this application;

[0085] Figure 3 The upgrade script execution flowchart is provided for a preferred embodiment of this application;

[0086] Figure 4 A flowchart illustrating the upgrade result feedback provided in a preferred embodiment of this application;

[0087] Figure 5 A schematic diagram of a terminal upgrade device based on traceability and result verification provided in a preferred embodiment of this application;

[0088] Figure 6 A schematic diagram of a terminal device provided for a preferred embodiment of this application.

[0089] Explanation of reference numerals in the attached figures

[0090] 10 - Terminal device, 100 - Processor, 101 - Memory, 102 - Computer program. Detailed Implementation

[0091] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0092] It should be noted that the technical solutions of the various embodiments of this application can be combined with each other, but only if they are based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by this application.

[0093] While current terminal upgrade solutions based on storage media in the power distribution IoT field can meet basic upgrade needs in offline scenarios, they still have the following drawbacks: lack of USB device access verification and no traceability system; upgrade results cannot be reliably verified, as the status of upgraded devices is usually only reflected through simple interface prompts (such as indicator lights, screen text) or brief local logs, making it impossible to confirm whether the new firmware is functionally complete or to quickly statistically analyze the upgrade status; upgrade scripts have limited functionality, lacking flexibility and intelligence. Therefore, there is an urgent need for a method that can maintain the convenience of offline upgrades while enabling traceability and result verification of upgrade operations.

[0094] To solve the above problems, such as Figure 1As shown, the first aspect of this application provides a terminal upgrade method based on tracing and result verification, including:

[0095] S100: In response to an access operation of an external storage device, authenticate the external storage device;

[0096] S200: When the external storage device is authenticated, perform an upgrade operation on at least one target to be upgraded on the current terminal through the external storage device, and generate upgrade result information for each target to be upgraded.

[0097] S300. If it is determined that the current target to be upgraded has failed to upgrade, upgrade feature information is determined based on the upgrade result information of the current target to be upgraded. The retry success probability of the current target to be upgraded is generated by the preset retry prediction model using the current upgrade feature information as input.

[0098] S400. If the success rate of the retry is higher than the preset threshold, perform an upgrade retry operation on the current target to be upgraded; otherwise, terminate the upgrade retry operation, update the upgrade result information of the current target to be upgraded, and store it in an external storage device.

[0099] This application effectively improves the security of terminal devices by performing authentication operations on the accessed external storage devices. By generating upgrade result information corresponding to each upgrade operation and storing the upgrade result information in the external storage device, the source and verification of upgrade operations can be realized. At the same time, if it is determined that the upgrade operation has failed, upgrade feature information is extracted from the upgrade result information of the corresponding upgrade operation. Using the upgrade feature information as input, a pre-built prediction model is used to predict the success probability of retrying the corresponding upgrade operation. Based on the prediction result, it is dynamically determined whether to execute the upgrade retry operation, thereby effectively improving the success rate of upgrade retry operations and avoiding waste of resources.

[0100] Understandably, external storage devices can be USB flash drives. For example, all USB flash drives can be pre-numbered and their serial numbers recorded. The management system can then link the USB flash drive serial numbers with the user's information to establish a management ledger. For instance, if Zhang San uses a USB flash drive with serial number "001", this correspondence can be recorded in the management system through the management ledger.

[0101] like Figure 2 As shown, in step S100, in one specific embodiment, authentication of the external storage device includes:

[0102] S110. Read the current device serial number of the external storage device and retrieve pre-stored authentication information from the external storage device. The authentication information is obtained by encrypting the actual device serial number using a public key generated in advance based on the actual device serial number of the external storage device through an asymmetric encryption algorithm. For example, during the USB flash drive initialization phase, the serial number of the USB flash drive is read through a specific software program. An asymmetric key pair is generated in advance based on the serial number of the USB flash drive using an asymmetric key generation algorithm. The public key is bound to the USB flash drive serial number and written to the USB flash drive. For example, the USB flash drive serial number is encrypted using the public key to obtain the authentication information of the USB flash drive and stored in the USB flash drive, while the private key is stored in the secure storage area of ​​the smart terminal. When the USB flash drive is inserted into the smart terminal, the terminal first reads the authentication information from the USB flash drive and then decrypts the authentication information using its own stored private key.

[0103] S120. Decrypt the authentication information using the private key corresponding to the public key to obtain the actual device serial number. If the current device serial number matches the actual device serial number, the external storage device is confirmed to have passed authentication. The private key is generated by an asymmetric encryption algorithm based on the actual device serial number. Specifically, after successful decryption with the private key, the USB flash drive serial number in the authentication information is obtained and compared with the serial number actually read from the USB flash drive. If they match, the USB flash drive is considered a legitimate access device, and subsequent upgrade operations are allowed; if they do not match, it is determined to be an illegitimate USB flash drive, the upgrade is rejected, and relevant information such as insertion time, illegitimate USB flash drive serial number, and reason for decryption failure is recorded for subsequent auditing.

[0104] In step S100, in another specific embodiment, before authenticating the external storage device, the method further includes:

[0105] For each external storage device, the first step is to register each external storage device. The specific process is as follows:

[0106] The current terminal or remote server generates a first random string of a specified length as the binding key for the current external storage device. For example, the current terminal generates a 32-byte random string locally as the exclusive binding key for the current USB flash drive. Understandably, each terminal can bind multiple USB flash drives.

[0107] Obtain the first authentication data of the current external storage device, and perform encryption operation on the first authentication data of the current external storage device using a preset encryption algorithm such as SHA-256 hash algorithm to obtain the identity commitment data of the current external storage device. Understandably, in order to reduce the amount of computation, the first N characters of the calculation result can be taken as the identity commitment data of the current external storage device.

[0108] The initial authentication data for the current external storage device is generated through the following steps:

[0109] Each external storage device is pre-divided into an authentication information storage area and a variable information storage area. For example, a hidden folder is created in each USB flash drive as the authentication information storage area. A second random string of a specified length, such as 32 bytes, is pre-generated through the current terminal or a remote server as the first authentication data of the current external storage device. The first authentication data of the current external storage device is stored in the authentication information storage area of ​​the current external storage device.

[0110] Based on the binding key and identity commitment data, a verification key for the current external storage device is generated through a preset key derivation function. For example, for the current terminal device, the binding key and identity commitment data of the current USB flash drive are concatenated into a 64-bit string, and the concatenated string is input into a preset key derivation function such as HKDF (HMAC-based Extract-and-Expand Key Derivation Function) to generate a 32-byte verification key.

[0111] Obtain the device serial number of the current external storage device, associate the device serial number of the current external storage device with the binding key, identity commitment data and verification key of the current external storage device and store it. It can be understood that for each terminal device, it stores a mapping table of device serial numbers of multiple registered USB flash drives with corresponding binding keys, identity commitment data and verification keys.

[0112] Perform a specified encryption operation on the device serial number of the current external storage device using the verification key of the current external storage device, such as performing an HMAC-SHA256 operation, to obtain the verification token data of the current external storage device, and store the verification token of the current external storage device in the authentication information storage area of ​​the current external storage device.

[0113] When an external storage device, such as USB flash drive A, is inserted into the current terminal device, the current terminal device first reads the first verification data and verification token data of the external storage device from the authentication information storage area of ​​USB flash drive A; it then encrypts the first verification data of USB flash drive A using the SHA-256 hash algorithm to obtain the actual identity commitment data of USB flash drive A; it reads the device serial number of USB flash drive A and obtains the binding key corresponding to the device serial number of the external storage device from the local mapping table; it concatenates the obtained binding key and the actual identity commitment data of USB flash drive A and inputs them into HKDF to generate the actual verification key of USB flash drive A; it then performs HMAC-SHA256 operation on the device serial number of USB flash drive A using the actual verification key to obtain the actual verification token data of USB flash drive A; it compares the actual verification token data with the obtained verification token data. If they match, it means that the identity information of USB flash drive A has not been tampered with, and USB flash drive A has passed authentication; otherwise, it means that the identity information of USB flash drive A has been tampered with, and access to USB flash drive A is denied. In this way, the authentication information of each USB flash drive is generated from the initial interaction with each terminal device or remote server, without relying on the physical attributes of each device. At the same time, it can effectively identify scenarios such as malicious tampering of USB flash drive serial numbers, thereby improving device security.

[0114] like Figure 3 As shown, in step S200, an upgrade operation is performed on at least one target device of the current terminal through an external storage device, including:

[0115] S210. Read the target upgrade script file from the external storage device and obtain the version number of the target upgrade script file. Specifically, before the script starts executing, perform initialization settings in advance, for example, set the version number attribute to "V1.0.0.0", and define a global variable "restart" with an initial value of 0. This variable is used to control whether the terminal needs to be restarted after completing certain upgrade operations.

[0116] S211. Obtain the version number of the current upgrade script file on the current terminal and compare it with the version number of the target upgrade script file. Specifically, during the script version check phase, the script checks whether a target upgrade script file named "upgrade_sc.sh" exists in the " / media / cxm / U / " directory of the USB drive. If it exists, it reads the version number of that file and compares it with the version number of the current script itself.

[0117] S212. If the version number of the target upgrade script file is newer than the version number of the current upgrade script file on the current terminal, replace the current upgrade script file on the current terminal with the target upgrade script file, and perform an upgrade operation on at least one target to be upgraded on the current terminal based on the target upgrade script file; otherwise, terminate the upgrade operation on at least one target to be upgraded on the current terminal. During the script update phase, if the external script version number is updated, replace the current script with the updated version to ensure that the upgrade script is always up-to-date to support new upgrade functions and fix known issues. After the upgrade operation is completed, regardless of whether the upgrade operation is successful or not, relevant information about the upgrade operation, such as the upgrade operation result, detailed upgrade operation content, upgrade operation time, USB flash drive serial number, terminal serial number, and terminal type, is recorded in the upgrade result information.

[0118] In step S200, performing an upgrade operation on at least one target device to be upgraded on the current terminal via an external storage device may further include:

[0119] S220. Check if a patch installation manifest file exists on the external storage device. For example, if the patch installation manifest file is stored in the "patchs" folder under the " / media / cxm / U / " directory of the USB drive, when the system checks for patches, it first checks if the "patchs" folder exists under the " / media / cxm / U / " directory of the USB drive. If it exists, it further checks if the folder contains a "patchslist.txt" file, which is the patch installation manifest file.

[0120] S221. If a patch installation manifest file exists, the script retrieves the corresponding patch files from the external storage device sequentially according to the patch installation order in the manifest file and performs the patch installation operation. If the "patchslist.txt" file is found, the script reads the patch file installation list recorded in it and searches for the corresponding patch file in the "patchs" folder according to the list order. After finding the corresponding patch file, the script executes the command "update -p filename" to install the patch files sequentially according to the list order.

[0121] S222. If the patch list file does not exist, determine if there are multiple patch files on the external storage device. If yes, terminate the patch installation operation; otherwise, retrieve the corresponding patch file and execute the patch installation operation. If the "patchslist.txt" file is not found, count the number of files in the "patchs" folder. If the count is 1, directly execute the "update -p filename" command to install the patch file; if the count is 0, it means there are no patch files in the folder, and the patch installation operation is not executed; if the count is multiple, to prevent accidental installation, the patch installation operation is not executed. After the patch installation operation is completed, write relevant information such as patch installation order, patch file name, and patch file installation result into the upgrade result information.

[0122] In step S200, performing an upgrade operation on at least one target device to be upgraded on the current terminal via an external storage device may further include:

[0123] S230. Check if a file system upgrade file exists on the external storage device. If a file system upgrade file exists on the external storage device, determine if there are multiple file system upgrade files. If yes, terminate the file system upgrade operation; otherwise, perform the file system upgrade operation based on the file system upgrade file. For example, the file system upgrade file is pre-stored in the "filesystem" folder under the " / media / cxm / U / " directory on the USB drive. When checking the file system upgrade conditions, first check if the "filesystem" folder exists under the " / media / cxm / U / " directory on the USB drive. If it exists, count the number of files in that folder. If the count is 1, execute the "update -fs filename" command to upgrade the file system of the smart terminal, ensuring the integrity and performance optimization of the file system. If the count is 0, it means that there is no file system upgrade file, and the file system upgrade operation is terminated. If there are multiple files, to prevent accidental installation, the file system upgrade operation is not performed at this time. After the file system upgrade operation is completed, write the relevant information of the file system upgrade operation, such as the file name of the file system upgrade file and the installation result of the file system upgrade file, into the upgrade result information.

[0124] S231, or, check if the kernel upgrade file exists on the external storage device; if the kernel upgrade file exists on the external storage device, obtain the number of kernel upgrade files and their file extensions; if the number of kernel upgrade files is not multiple, and the file extension is a preset extension, perform the kernel upgrade operation based on the kernel upgrade file; otherwise, terminate the kernel upgrade operation. For example, the kernel upgrade file is pre-stored in the "kernel" folder under the " / media / cxm / U / " directory on the USB drive. When checking the kernel upgrade conditions, first check if the "kernel" folder exists under the " / media / cxm / U / " directory. If it exists, count the number of files in the folder and determine if the file extension is a pre-specified preset extension, such as "img". If the number of files in the "kernel" folder is 1 and the extension meets the requirements, execute the "update -k filename" command to complete the kernel upgrade operation and improve the stability and performance of the terminal system; otherwise, do not perform the kernel upgrade operation. Similarly, after the kernel upgrade operation is completed, relevant information such as the file name of the kernel upgrade file and the installation result of the kernel upgrade file will be written into the upgrade result information.

[0125] S232. Alternatively, check if a combined upgrade file exists on the external storage device. This combined upgrade file consists of a file system upgrade file and a kernel upgrade file. If a combined upgrade file exists on the external storage device, determine if there are multiple such files. If so, terminate the file system and kernel upgrade operations; otherwise, perform the file system and kernel upgrade operations based on the combined upgrade file. For example, the file system upgrade file and kernel upgrade file are pre-associated and stored in a folder named "kfs" under the directory " / media / cxm / U / " on a USB drive. When checking the conditions for a combined kernel and file system upgrade, first check if a folder named "kfs" exists under the directory " / media / cxm / U / ". If it exists, count the number of files in that folder. If the count is 1, execute the command "update -a filename" to achieve a combined upgrade of the kernel and file system using the associated file system upgrade file and kernel upgrade file, ensuring compatibility and collaborative working capabilities between the two. Similarly, after the combined upgrade operation is completed, relevant information such as the filename of the combined upgrade file and the installation result of the combined upgrade file are written into the upgrade result information. Understandably, in practice, the priority of joint upgrades can be set to be higher than that of file system upgrades and kernel upgrades. That is, when performing an upgrade operation, it is first determined whether to perform a joint upgrade. If the conditions are not met, then it is determined whether to perform a file system upgrade or a kernel upgrade.

[0126] In step S200, performing an upgrade operation on at least one target device to be upgraded on the current terminal via an external storage device may further include:

[0127] S240. Check if the system tool upgrade file exists on the external storage device. For example, if the system tool upgrade file is stored in the "tools" folder under the " / media / cxm / U / " directory of the USB drive, when performing the upgrade operation, first check if the "tools" folder exists under the " / media / cxm / U / " directory.

[0128] S241. If a system tool upgrade file exists on an external storage device, mount the current terminal's file system as read-write, perform a system tool upgrade operation based on the upgrade file, and reset the current terminal's file system to read-only after the upgrade operation is complete. If a "tools" folder is detected under the " / media / cxm / U / " directory, count the number of files in the folder and determine if the file extension is a preset extension such as "tar.gz". If the quantity is 1 and the file extension meets the requirements, first use the "tar -xvf" command to decompress the file package; then, remount the file system to a read-write state by executing the "mount -o remount,rw / " command; next, locate and enter the folder containing the system tool upgrade file "update_to_filesystem.sh", and execute the update command " / update_to_filesystem.sh -r / -c / custom / -l / log / " to perform the system tool upgrade operation; after that, set the system environment variable "reload_docker" to 1, and finally restore the file system to a read-only state by executing the "mount -o remount,ro / " command, and set the script global variable "restart" to 1 to mark the system as needing to restart to apply the upgraded tool configuration.

[0129] S242. Alternatively, check if the application update file exists on the external storage device. For example, check if the "apps" folder exists in the " / media / cxm / U / " directory of the USB drive.

[0130] S243. If an application upgrade file exists on an external storage device, determine whether the filename of the application upgrade file is any one of a set of preset base application filenames. For example, count the number of files in the "apps" folder and determine the number of apps to be installed. For each app file, determine whether its filename contains any one of the preset base application filenames such as "secResManager, smiOS, secReinf, desktopGui, wirelessDCM, uartManager, acMeter, scsMonitor, rspSample, btManager, iotManager, mapManager, comMonitor, unisdk, epri_sec_proxy, dbCenter, ccoRouter, comScheduler".

[0131] S244. If the application upgrade file is named after any of the preset base application file names, obtain the application upgrade file and perform the application upgrade operation based on the application upgrade file. If the file in the "apps" folder is named after any of the preset base application file names, it is considered a base APP, and it is copied to the " / usr / local / extapps" directory in the terminal. If a file with the same name already exists in this directory, it is overwritten. Whenever a base APP is installed or updated, the value of the script global variable "restart" is set to 1.

[0132] For scenarios where any component in the above process, i.e., the target to be upgraded (system patch, file system, kernel, APP, etc.), fails to upgrade, this application predicts the probability of successful retry for each scenario based on failure log analysis. In this application, the upgrade feature information includes at least one upgrade failure feature factor, which can be the failure type (F1 file verification failure / F2 insufficient memory / F3 hardware incompatibility, F4, etc.), terminal model T, upgrade component type C (C1, kernel / C2, APP / C3, component / C4, others), memory usage R at the time of failure, etc. Step S300, the process of constructing the retry prediction model, includes:

[0133] S310. Obtain upgrade characteristic information of different upgrade targets of different terminals in the historical upgrade process of different terminals, and the upgrade retry operation results of the corresponding upgrade targets in the upgrade failure state.

[0134] In this application, the input to the prediction model is defined as the feature set of the current upgrade failure log (failure type, terminal model, upgrade component type, and resource status at the time of failure); the output is defined as the success probability of retrying the upgrade in this scenario. This paper assumes that the features of the failure logs are conditionally independent. Understandably, the accuracy of the prediction model depends on historical data; therefore, this application preprocesses the data on the management side to generate a probability table that can be directly loaded on the terminal side. Specifically, historical data is first collected and labeled, collecting "upgrade failure-retry" records for different upgrade operations on different terminals. Each record includes the failure type (F1 file verification failure / F2 insufficient memory / F3 hardware incompatibility, F4, etc.), terminal model T, upgrade component type C (C1, kernel / C2, APP / C3, component / C4, others), memory usage at failure R, and retry result Y (success / failure), etc.

[0135] S311. Determine the total number of successful retries for the corresponding upgrade retry operation result among all obtained upgrade feature information, and determine the total number of upgrade retry operations corresponding to all upgrade feature information. Construct the basic probability of successful retries based on the ratio of the total number of successful retries to the total number of upgrade retry operations, and determine the basic probability of failed retries based on the basic probability of successful retries.

[0136] In this application, after obtaining historical data, all features are first converted into discrete categorical values ​​to avoid processing continuous data on the terminal side. For example, R is divided into three intervals (≤50%=R1, 51%-80%=R2, >80%=R3), and the enumerated values ​​of failure type F are (F1=file verification failure, F2=insufficient memory, F3=hardware incompatibility). Based on the data processing results, a "feature-result" mapping table is constructed. The management end counts the number of successes / total number of each feature combination in the historical data, i.e., each upgrade feature information, to generate basic probability data, i.e., the basic probability of retry success. It can be understood that the basic probability of retry failure is 1 - the basic probability of retry success.

[0137] S312. Among all upgrade retry operation results that are successful, the retry success probability corresponding to each upgrade failure feature factor is the retry success conditional probability of the current upgrade failure feature factor, and the retry failure conditional probability of each upgrade failure feature factor is determined based on the retry success conditional probability of each upgrade failure feature factor.

[0138] The retry success probability corresponding to each upgrade failure feature factor is determined through the following steps: First, determine the first quantity of each upgrade failure feature factor among all upgrade feature information where the retry operation result is a successful retry. For example, in the historical data obtained, the first quantity is the number of each upgrade failure feature factor appearing in all historical feature combinations where the retry result is a successful retry. For each upgrade failure feature factor: the ratio of the first quantity of the current upgrade failure feature factor to the total number of successful retryes is used as the retry success probability corresponding to the current upgrade failure feature factor. It can be understood that the retry failure conditional probability is 1 - the retry success conditional probability. A retry probability table is established based on the retry success conditional probability, the retry failure conditional probability, the retry success base probability, and the retry failure base probability of each upgrade failure feature factor. That is, the retry probability table includes not only the mapping relationship between failure type (F1 file verification failure / F2 insufficient memory / F3 hardware incompatibility, F4, etc.), terminal model T, upgrade component type C (C1, kernel / C2, APP / C3, component / C4, others), memory usage R when failing, and retry result Y (success / failure), but also the pre-determined retry success conditional probability of each upgrade failure feature factor, the retry failure conditional probability of each upgrade failure feature factor, the base probability of retry success, and the base probability of retry failure.

[0139] S313. Construct a first prediction model by the product of the retry success conditional probability and the retry success base probability of each upgrade failure feature factor in the feature information, and construct a second prediction model by the product of the retry failure conditional probability and the retry failure base probability of each upgrade failure feature factor in the feature information.

[0140] Specifically, in this application, the current upgrade feature information, i.e., the feature set of the current failure log, is... Its retry success probability The calculation is as follows:

[0141]

[0142] Based on the characteristic conditional independence assumption, we have:

[0143] P ( X / Y =1)= P ( F = f / Y =1) P ( T = t / Y =1) P ( C =c / Y =1) P ( R = r / Y =1)

[0144] in, This is the prior probability, which is the base probability of a successful retry in all failure scenarios without considering any features. P ( X / Y =1) represents the probability of the current failure log feature set X appearing under the condition that the retry is successful, i.e. (Y=1);

[0145] The target probability is the probability of a successful retry (Y=1) when the current failed feature combination is X.

[0146] It is the conditional probability (the probability of failure type f in historical "successful retry" data).

[0147] It represents the conditional probability (the probability of failure type t in historical "successful retry" data).

[0148] It represents the conditional probability (the probability of failure type c in historical "successful retry" data).

[0149] It represents the conditional probability (the probability of failure type r in historical "successful retry" data).

[0150] As evidence factors (under all possible outcomes) The sum of these is used for normalization.

[0151] Similarly, ,in, This represents the probability that the retry will fail (Y=0) when the current failure feature combination is X; This represents the base probability of a retry failing; P ( X / Y =0)= P ( F = f / Y =0) P ( T = t / Y =0) P (C = c / Y =0) P ( R = r / Y =0), P ( F = f / Y =0) P ( T = t / Y =0) P ( C = c / Y =0) P ( R = r / Y =0) is the conditional probability, representing the probability that the failure characteristics are f, t, c, and r in the historical "failed retry" data.

[0152] Therefore, in this application, the first prediction model is: The second prediction model is .

[0153] S314. Construct a retry prediction model using the ratio of the first prediction model to the second prediction model. Specifically, this application does not calculate complex evidence factors. Instead of determining the success rate threshold through probability ratios, the retry prediction model of this application can be expressed as:

[0154]

[0155] If the success rate is greater than a certain threshold, a retry is triggered; if the success rate is less than a certain threshold, the retry is terminated and manual intervention is marked.

[0156] Based on the retry prediction model of this application, in step S300, the current upgrade feature information is used as input, and the retry success probability of the current target to be upgraded is generated by the preset retry prediction model, including:

[0157] S320. Determine each upgrade failure feature factor in the current upgrade feature information.

[0158] S321. Based on the retry probability table, obtain the retry success conditional probability and retry success / failure probability corresponding to each upgrade failure feature factor in the current upgrade feature information, and obtain the retry success base probability and retry failure base probability based on the retry probability table.

[0159] S322. If the current upgrade feature information contains an upgrade failure feature factor that is not present in the retry probability table, a pre-determined smoothing coefficient is used as the number of successful retryes corresponding to that upgrade failure feature factor after smoothing. For example, the combination of failure features in the current upgrade feature information is (F1, T, C2, C3, R1), but the feature C3 is not present in the pre-constructed retry probability table. That is, there is no failure feature factor C3 in the historical data of successful retryes, so the conditional probability of C3 needs to be smoothed. For example, a smoothing coefficient α is pre-determined, where the value of α can be determined according to the actual situation. In this application, α=1. In this application, the number of successful retryes corresponding to upgrade failure feature factors that are not present in the retry probability table is defined as the number of times Y=1 and F=f in the history + α, where f is the upgrade failure feature factor that is not present in the retry probability table. Taking C3 as an example, since C3 is not present in the retry probability table, the number of successful retryes with failure feature factor C3 is 0, that is, the number of successful retryes for C3 is α.

[0160] S323. The smoothing term is the product of the smoothing coefficient and the total number of categories of the upgrade failure feature factors. The total number of successful retries after smoothing is the sum of the smoothing term and the total number of successful retries. For example, let K be the total number of categories of the upgrade failure feature factors. F If the total number of failure types F is given by the smoothed total number of successful retries, then the total number of successful retries after smoothing is the historical data, which is the total number of times Y=1 in the retry probability table plus αK. F .

[0161] S324. The ratio of the smoothed number of successful retries to the smoothed total number of successful retries is used as the conditional probability of retry success for this upgrade failure feature factor. Specifically, the formula for calculating the conditional probability of retry success for upgrade failure feature factors not present in the retry probability table can be expressed as:

[0162]

[0163] Similarly, for the failure feature factors t, c, and r, the formula for calculating the conditional probability of successful retry after smoothing can be expressed as:

[0164]

[0165]

[0166]

[0167] S325. Using the retry success conditional probability, retry success failure probability, retry success base probability, and retry failure base probability of each upgrade failure feature factor in the current upgrade feature information as input, the retry success probability of the current target to be upgraded is generated through a preset retry prediction model.

[0168] In this application, after the probability table generation and smoothed probability calculation are completed on the management side, two core files are output and stored on a USB drive. The management side updates the probability table monthly based on newly added terminal failure-retry records to optimize model accuracy, and synchronizes the new version of the probability table to each terminal via the USB drive. Upon the first startup of a terminal, the probability table is loaded into local Flash permanent storage; subsequent upgrades only verify the version of the probability table on the USB drive, without requiring reloading. The model deployed on the terminal side can automatically parse failure logs and extract specific feature combinations through a keyword matching script. The terminal reads the synchronized prior probability table and conditional probability table from local Flash, calculates the probability ratio, and makes retry decisions.

[0169] like Figure 4 As shown, after all upgrade operations are completed, the smart terminal generates an upgrade result file, which records the upgrade status of each component during the upgrade process, such as whether it was successful, the reason for failure, and other detailed information. This upgrade result file is then stored in reverse on a USB drive. After all terminals within the area have completed the upgrade, maintenance personnel can read the upgrade result file to perform statistical analysis on the upgrade status of all terminals, intuitively understand which terminals upgraded successfully, which terminals failed and the reasons for failure, and make decisions accordingly for timely and targeted handling.

[0170] In summary, this application constructs a secure access and upgrade operation traceability architecture for storage media. When problems occur during the upgrade process, the specific responsible party can be quickly identified, providing crucial support for timely problem resolution and preventing escalation, significantly increasing security. It also improves upgrade result feedback; after the upgrade is completed, the terminal upgrade result file is reverse-stored to the storage device. Using specific tools, the upgrade status of all terminals can be quickly and comprehensively analyzed, enabling timely detection and handling of upgrade anomalies, improving operational efficiency, and achieving rapid statistical analysis of upgrade results. Simultaneously, the terminal upgrade process is optimized to cover all key components of the smart terminal system, including system patches, file systems, kernels, and various apps. For upgrade failure scenarios, failure log analysis is used to predict the probability of successful retry. The management side preprocesses historical data to generate a probability table, and the terminal side calculates retry based on log characteristics and the probability table, ensuring that all terminal components receive timely and effective upgrades. This enhances upgrade flexibility and intelligence to adapt to various complex upgrade scenarios, guaranteeing the smooth progress of the upgrade process and the compatibility and collaborative working capabilities of the upgraded components.

[0171] like Figure 5 As shown, in a second aspect, this application provides a terminal upgrade device based on traceability and result verification, which applies the terminal upgrade method based on traceability and result verification as described above. The device includes:

[0172] The authentication module is configured to authenticate the external storage device in response to an access operation.

[0173] The upgrade operation module is configured to perform an upgrade operation on at least one target to be upgraded on the current terminal through the external storage device after authentication, and generate upgrade result information for each target to be upgraded.

[0174] The retry prediction module is configured to determine upgrade feature information based on the upgrade result information of the current target to be upgraded if it is determined that the upgrade has failed. Using the current upgrade feature information as input, the module generates the retry success probability of the current target to be upgraded through a preset retry prediction model.

[0175] The upgrade retry module is configured to perform an upgrade retry operation on the current target to be upgraded if the success probability of the retry is higher than a preset threshold; otherwise, the upgrade retry operation is terminated, the upgrade result information of the current target to be upgraded is updated, and the result information is stored in an external storage device.

[0176] It is understood that those skilled in the art will clearly recognize that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0177] In a third aspect, this application provides a machine-readable storage medium storing instructions that, when executed by a processor, configure the processor to perform the terminal upgrade method based on tracing and result verification as described above.

[0178] In a fourth aspect, this application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the terminal upgrade method based on tracing and result verification as described above.

[0179] like Figure 6The diagram shown is a schematic representation of a terminal device provided in an embodiment of this application. Figure 6 As shown, the terminal device 10 of this embodiment includes a processor 100, a memory 101, and a computer program 102 stored in the memory 101 and executable on the processor 100. When the processor 100 executes the computer program 102, it implements the steps in the above method embodiments. Alternatively, when the processor 100 executes the computer program 102, it implements the functions of each module / unit in the above device embodiments.

[0180] For example, computer program 102 may be divided into one or more modules / units, one or more of which are stored in memory 101 and executed by processor 100 to complete this application. One or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 102 in terminal device 10.

[0181] Terminal device 10 may be a computing device such as a desktop computer, laptop, handheld computer, or cloud server. Terminal device 10 may include, but is not limited to, a processor 100 and a memory 101. Those skilled in the art will understand that... Figure 6 This is merely an example of terminal device 10 and does not constitute a limitation on terminal device 10. It may include more or fewer components than shown, or combine certain components, or different components. For example, terminal device may also include input / output devices, network access devices, buses, etc.

[0182] Processor 100 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0183] The memory 101 can be an internal storage unit of the terminal device 10, such as a hard disk or RAM of the terminal device 10. The memory 101 can also be an external storage device of the terminal device 10, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or FlashCard equipped on the terminal device 10. Furthermore, the memory 101 can include both internal and external storage units of the terminal device 10. The memory 101 is used to store computer programs and other programs and data required by the terminal device 10. The memory 101 can also be used to temporarily store data that has been output or will be output.

[0184] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

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

[0186] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A terminal upgrade method based on source tracing and result verification, characterized in that, include: In response to an access operation of an external storage device, the external storage device is authenticated. When the external storage device is authenticated, an upgrade operation is performed on at least one target to be upgraded on the current terminal through the external storage device, and upgrade result information for each target to be upgraded is generated; If it is determined that the current target to be upgraded has failed, upgrade feature information is determined based on the upgrade result information of the current target to be upgraded. Using the current upgrade feature information as input, the retry success probability of the current target to be upgraded is generated by the preset retry prediction model. If the retry success probability is higher than the preset threshold, an upgrade retry operation is performed on the current target to be upgraded; otherwise, the upgrade retry operation is terminated, the upgrade result information of the current target to be upgraded is updated and stored in the external storage device. The upgrade feature information includes at least one upgrade failure feature factor, and the construction process of the retry prediction model includes: During the historical upgrade process of different terminals, the upgrade characteristic information of different targets to be upgraded on each terminal in the upgrade failure state and the corresponding upgrade retry operation results of the targets to be upgraded; Among all the obtained upgrade feature information, the corresponding upgrade retry operation result is the total number of successful retry operations. The total number of upgrade retry operations corresponding to all upgrade feature information is determined. The ratio of the total number of successful retry operations to the total number of upgrade retry operations is used to construct the basic probability of successful retry. The basic probability of failed retry is determined based on the basic probability of successful retry. In the upgrade feature information where all upgrade retry operations result in a successful retry, the retry success probability corresponding to each upgrade failure feature factor is the retry success conditional probability of the current upgrade failure feature factor, and the retry failure conditional probability of each upgrade failure feature factor is determined based on the retry success conditional probability of each upgrade failure feature factor. A first prediction model is constructed by the product of the retry success conditional probability and the retry success base probability of each upgrade failure feature factor in the feature information, and a second prediction model is constructed by the product of the retry failure conditional probability and the retry failure base probability of each upgrade failure feature factor in the feature information. The retry prediction model is constructed using the ratio of the first prediction model to the second prediction model.

2. The terminal upgrade method based on source tracing and result verification according to claim 1, characterized in that, Authentication of the external storage device includes: The current device serial number of the external storage device is read, and pre-stored authentication information is obtained from the external storage device. The authentication information is obtained by encrypting the actual device serial number using a public key generated in advance based on the actual device serial number of the external storage device through an asymmetric encryption algorithm. The authentication information is decrypted using the private key corresponding to the public key to obtain the actual device serial number. If the current device serial number matches the actual device serial number, the external storage device is determined to be authenticated. The private key is generated by the asymmetric encryption algorithm based on the actual device serial number.

3. The terminal upgrade method based on source tracing and result verification according to claim 1, characterized in that, Before authenticating the external storage device, the method further includes: For each external storage device: Generate a first random string of a specified length as the binding key for the current external storage device; Obtain the first authentication data of the current external storage device, and perform encryption operation on the first authentication data of the current external storage device using a preset encryption algorithm to obtain the identity commitment data of the current external storage device; Based on the binding key and the identity commitment data, a verification key for the current external storage device is generated through a preset key derivation function; Get the device serial number of the current external storage device; The device serial number of the current external storage device is associated with the binding key, identity commitment data and verification key of the current external storage device and then stored. The device serial number of the current external storage device is encrypted using the verification key of the current external storage device to obtain the verification token data of the current external storage device, and the verification token of the current external storage device is stored in the authentication information storage area of ​​the current external storage device. The initial authentication data for the current external storage device is generated through the following steps: Generate a second random string of the specified length as the first authentication data of the current external storage device, and store the first authentication data of the current external storage device in the authentication information storage area of ​​the current external storage device.

4. The terminal upgrade method based on source tracing and result verification according to claim 3, characterized in that, Authentication of the external storage device includes: Read the first authentication data and authentication token data of the external storage device from the authentication information storage area of ​​the external storage device; The first verification data of the external storage device is encrypted using the preset encryption algorithm to obtain the actual identity commitment data of the external storage device. Read the device serial number of the external storage device to obtain the binding key corresponding to the device serial number of the external storage device; Based on the obtained binding key and the actual identity commitment data of the external storage device, the actual verification key of the external storage device is generated through the preset key derivation function; The specified encryption operation is performed on the device serial number of the external storage device using the actual verification key to obtain the actual verification token data of the external storage device. The actual verification token data is compared with the obtained verification token data. If the two match, it is determined that the external storage device has passed the authentication.

5. The terminal upgrade method based on source tracing and result verification according to claim 1, characterized in that, Performing an upgrade operation on at least one target device of the current terminal through the external storage device includes: Read the target upgrade script file from the external storage device and obtain the version number of the target upgrade script file; Obtain the version number of the current upgrade script file of the current terminal, and compare the version number of the target upgrade script file with the version number of the current upgrade script file of the current terminal; If the version number of the target upgrade script file is newer than the version number of the current upgrade script file on the current terminal, the current upgrade script file on the current terminal is replaced with the target upgrade script file, and an upgrade operation is performed on at least one target to be upgraded on the current terminal based on the target upgrade script file; otherwise, the upgrade operation on at least one target to be upgraded on the current terminal is terminated.

6. The terminal upgrade method based on source tracing and result verification according to claim 1, characterized in that, Performing an upgrade operation on at least one target device of the current terminal through the external storage device includes: Check if a patch installation manifest file exists in the external storage device; If a patch manifest file exists, the corresponding patch files are retrieved from the external storage device sequentially according to the patch installation order in the patch manifest file, and the patch installation operation is performed accordingly; otherwise... If no patch installation manifest file exists, determine whether there are multiple patch files in the external storage device. If yes, terminate the patch installation operation; otherwise, obtain the corresponding patch file and perform the patch installation operation.

7. The terminal upgrade method based on source tracing and result verification according to claim 1, characterized in that, Performing an upgrade operation on at least one target device of the current terminal through the external storage device includes: Check if a file system upgrade file exists in the external storage device; If the file system upgrade file exists in the external storage device, determine whether there are multiple file system upgrade files. If yes, terminate the file system upgrade operation; otherwise, perform the file system upgrade operation based on the file system upgrade file. Check if a kernel upgrade file exists in the external storage device; If the kernel upgrade file exists in the external storage device, obtain the number of the kernel upgrade files and the file extension of the kernel upgrade files; If the number of kernel upgrade files is not multiple, and the file extension of the kernel upgrade files is a preset file extension, perform the kernel upgrade operation based on the kernel upgrade files; otherwise, terminate the kernel upgrade operation; or Check if a combined upgrade file exists in the external storage device, the combined upgrade file consisting of the file system upgrade file and the kernel upgrade file; If the combined upgrade file exists in the external storage device, determine whether there are multiple combined upgrade files. If yes, terminate the file system and kernel upgrade operation; otherwise, perform the file system and kernel upgrade operation based on the combined upgrade file.

8. The terminal upgrade method based on source tracing and result verification according to claim 1, characterized in that, Performing an upgrade operation on at least one target device of the current terminal through the external storage device includes: Check if system tool upgrade files exist in the external storage device; If the system tool upgrade file exists in the external storage device, the current terminal's file system is mounted as read-write, a system tool upgrade operation is performed based on the system tool upgrade file, and after the system tool upgrade operation is completed, the current terminal's file system is reset to read-only; or Check if the external storage device contains application update files; If the application upgrade file exists in the external storage device, determine whether the filename of the application upgrade file is any one of a preset plurality of base application filenames; If the filename of the application upgrade file is any one of a plurality of preset base application filenames, the application upgrade file is obtained, and the application upgrade operation is performed based on the application upgrade file.

9. The terminal upgrade method based on source tracing and result verification according to claim 1, characterized in that, The probability of a successful retry for each upgrade failure characteristic factor is determined through the following steps: Determine the first number of each upgrade failure feature factor among all upgrade feature information where the corresponding upgrade retry operation result is a successful retry; For each upgrade failure characteristic factor: The ratio of the first number of current upgrade failure feature factors to the total number of successful retries is used as the retry success probability corresponding to the current upgrade failure feature factor.

10. The terminal upgrade method based on source tracing and result verification according to claim 1, characterized in that, The process of constructing the retry prediction model also includes: A retry probability table is established based on the retry success conditional probability of each upgrade failure feature factor, the retry failure conditional probability of each upgrade failure feature factor, the retry success base probability, and the retry failure base probability. Using the current upgrade feature information as input, a pre-defined retry prediction model generates the retry success probability of the current target to be upgraded, including: Identify each upgrade failure feature factor in the current upgrade feature information; Based on the retry probability table, obtain the retry success conditional probability and retry success failure probability corresponding to each upgrade failure feature factor in the current upgrade feature information, and obtain the retry success base probability and retry failure base probability based on the retry probability table. If the current upgrade feature information contains an upgrade failure feature factor that is not present in the retry probability table, the number of successful retryes corresponding to the upgrade failure feature factor after smoothing is determined by a pre-determined smoothing coefficient. The smoothing term is the product of the smoothing coefficient and the total number of categories of upgrade failure feature factors. The total number of successful retries after smoothing is the sum of the smoothing term and the total number of successful retries. The ratio of the number of successful retries after smoothing to the total number of successful retries after smoothing is used as the conditional probability of successful retries for this upgrade failure characteristic factor. Using the retry success conditional probability, retry success failure probability, retry success base probability, and retry failure base probability of each upgrade failure feature factor in the current upgrade feature information as input, the retry success probability of the current target to be upgraded is generated by a preset retry prediction model.

11. A terminal upgrade device based on source tracing and result verification, employing the terminal upgrade method based on source tracing and result verification as described in any one of claims 1-10, characterized in that, The device includes: An authentication module is configured to authenticate the external storage device in response to an access operation of the external storage device. The upgrade operation module is configured to perform an upgrade operation on at least one target to be upgraded on the current terminal through the external storage device when the external storage device is authenticated, and generate upgrade result information for each target to be upgraded; The retry prediction module is configured to determine upgrade feature information based on the upgrade result information of the current target to be upgraded if it is determined that the upgrade has failed. Using the current upgrade feature information as input, the module generates the retry success probability of the current target to be upgraded through a preset retry prediction model. The upgrade retry module is configured to perform an upgrade retry operation on the current target to be upgraded if the retry success probability is higher than a preset threshold; otherwise, it terminates the upgrade retry operation, updates the upgrade result information of the current target to be upgraded, and stores it in the external storage device.

12. A machine-readable storage medium storing instructions thereon, characterized in that, When executed by the processor, the instruction causes the processor to be configured to perform the terminal upgrade method based on tracing and result verification as described in any one of claims 1-10.

13. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the terminal upgrade method based on tracing and result verification as described in any one of claims 1-10.

Images