OTA upgrade state feedback method and system based on file name dynamic identification

Abstract

The invention relates to an OTA upgrading state feedback method and system based on file name dynamic recognition, and the method comprises the steps: obtaining an OTA upgrading file, and analyzing a device identifier, a target version number and a hash verification value from an initial file name of the OTA upgrading file; performing Hash calculation on the content of the OTA upgrade file to obtain a calculation result, and comparing the calculation result with the Hash check value in the initial file name; after the OTA upgrading file passes the legality verification, starting an OTA upgrading process, monitoring upgrading state information in the OTA upgrading process to obtain an upgrading result, and dynamically modifying a file name of the OTA upgrading file according to the upgrading result to obtain a renamed file name of the OTA upgrading file; and reading the renamed file name of the OTA upgrading file, and performing upgrading behavior judgment according to the state type and the parameter content in the renamed file name to obtain a judgment result. The method has the effect of improving the operation and maintenance convenience.

Description

Technical Field

[0001] The present application relates to the technical field of embedded device firmware upgrades, and in particular to an OTA upgrade status feedback method and system based on dynamic file name identification. Background Art

[0002] Currently, OTA (Over-The-Air) upgrade mechanisms are widely used in embedded platforms such as IoT devices, smart home terminals, and industrial controllers to achieve remote firmware updates. To ensure the controllability and reliability of the upgrade process, devices typically need to record status information during the upgrade process, including whether the upgrade was successful, interrupted, or if verification failed. This allows for features such as breakpoint resumption, exception rollback, and log tracing.

[0003] The mainstream approach currently is to record upgrade status by setting an upgrade flag in Flash, EEPROM, or a separate partition (such as the Misc partition). While this approach is practical in large embedded systems, it has significant limitations on resource-constrained platforms (such as MCUs like the STM32 and ESP32). First, the upgrade flag requires a fixed storage area, which incurs additional space costs. Second, if the device experiences an unexpected power outage or reboot during the upgrade process, the flag may not be written in time or may become corrupted. This can lead to the device being unable to accurately determine the current upgrade status, making it difficult to resume the interrupted process, and even causing firmware corruption and device "bricking."

[0004] The above-mentioned existing technical solutions have the following defects: the recording method of the upgrade status information relies on the underlying storage resources, the design is complex, and it is easily affected by factors such as power outages, resulting in status loss. Therefore, there is room for improvement. Summary of the Invention

[0005] In order to improve the convenience of operation and maintenance, the present application provides an OTA upgrade status feedback method and system based on dynamic file name identification.

[0006] The above-mentioned invention objective of this application is achieved through the following technical solutions: An OTA upgrade status feedback method based on dynamic file name identification, the OTA upgrade status feedback method based on dynamic file name identification comprising: Obtain an OTA upgrade file and parse the device identifier, target version number, and hash checksum from the initial file name of the OTA upgrade file; Performing a hash calculation on the contents of the OTA upgrade file to obtain a calculation result, and comparing the calculation result with the hash check value in the initial file name to determine whether the OTA upgrade file has been tampered with or damaged, thereby implementing a pre-upgrade legitimacy verification; After the OTA upgrade file passes the legitimacy check, the OTA upgrade process is started, upgrade status information is monitored during the OTA upgrade process to obtain an upgrade result, and the file name of the OTA upgrade file is dynamically modified according to the upgrade result to obtain the renamed file name of the OTA upgrade file; Read the renamed file name of the OTA upgrade file, perform upgrade behavior judgment based on the status type and parameter content in the renamed file name, and obtain a judgment result. When it is detected that the judgment result is an interrupted state, continue the upgrade process of the OTA upgrade file from the breakpoint position according to the progress information in the renamed file name.

[0007] By adopting the above technical solution, by parsing the device identifier, target version number and hash check value from the initial file name of the OTA upgrade file, the identity and integrity judgment basis of the upgrade file can be obtained without the help of additional metadata or partition storage, thereby improving the lightweight and deployment flexibility of the OTA upgrade process; by hashing the content of the OTA upgrade file and comparing it with the hash check value in the file name, it can be ensured that the upgrade file has not been tampered with or damaged during the transmission process, thereby improving the security and accuracy of the upgrade; by monitoring the upgrade status information during the upgrade process and dynamically modifying the file name of the OTA upgrade file according to the upgrade result, the file name can be used as a carrier to express the upgrade execution status, thereby avoiding reliance on traditional partition flags and improving the operability of interrupt recovery; by reading the renamed file name of the OTA upgrade file and determining whether it is in an interrupted state to decide whether to resume the transfer from the breakpoint, the device can automatically resume the upgrade process after a power outage or abnormal interruption, thereby improving the continuity and stability of the upgrade process.

[0008] In one example, the present application may be further configured as follows: parsing the device identifier, target version number, and hash check value from the initial file name of the OTA upgrade file includes: The initial file name of the OTA upgrade file adopts the structure format of "Device ID_Version Number_Hash Value.Extension", where the device ID is used to uniquely identify the upgrade target device, the version number is used to indicate the current upgrade target firmware version, and the hash value is a hash digest value used to verify the integrity of the file; By formatting the initial file name of the OTA upgrade file, the first field is the device identifier, the second field is the target version number, and the third field is the hash check value.

[0009] By adopting the above technical solution, by using the structural format of "device ID_version number_hash value.extension name" and splitting and extracting in field order, it is possible to achieve identity authentication and structured parsing of OTA upgrade files, thereby ensuring that each upgrade file can be uniquely identified and facilitate subsequent verification logic processing, thereby improving the system's adaptability and automated processing capabilities in a multi-terminal environment.

[0010] In one example, the present application may be further configured as follows: performing a hash calculation on the content of the OTA upgrade file to obtain a calculation result, and comparing the calculation result with the hash check value in the initial file name includes: Performing a full calculation on the binary content of the OTA upgrade file using a one-way hash algorithm to generate the calculation result; The calculation result is compared with the hash check value in the initial file name. If the comparison results are consistent, the file is marked as complete and legal. Otherwise, it is determined to be an illegal file and subsequent upgrade operations are prohibited.

[0011] By adopting the above technical solution, by using a one-way hash algorithm to fully calculate the binary content of the OTA upgrade file and comparing it with the hash value in the file name, it is possible to judge its integrity and legitimacy based on the file content itself, thereby preventing device damage or upgrade failure caused by data tampering, incompleteness or forgery, and improving the overall reliability of system upgrades.

[0012] In one example, the present application may be further configured as follows: dynamically modifying the file name of the OTA upgrade file according to the upgrade result includes: When the upgrade result is successful, the file name of the OTA upgrade file is modified to the format of success_target version number_timestamp to indicate the upgrade completion status; When the upgrade result is an upgrade failure, the file name of the OTA upgrade file is modified to the format of error_error code_timestamp, where the error code is used to indicate the cause of the failure; When the upgrade result is that the upgrade is interrupted, the file name of the OTA upgrade file is modified to the format of interrupt_progress percentage_timestamp, where the progress percentage is the ratio between the total amount of data written to the device and the total size of the OTA upgrade file.

[0013] By adopting the above technical solution, by modifying the file name of the OTA upgrade file to the format of success_version number, error_error code and interrupt_progress percentage according to the upgrade result, the upgrade status and stage information can be expressed in real time at the file level, thereby realizing upgrade progress tracking and result identification without relying on traditional status flags or log files, facilitating device self-diagnosis and remote operation and maintenance, and improving system availability and service efficiency.

[0014] In one example, the present application may be further configured as follows: the file name after the OTA upgrade file is renamed is read, and the upgrade behavior is judged according to the status type and parameter content in the renamed file name, and the judgment result includes: Parsing a status type field in the renamed file name of the OTA upgrade file to obtain a parsing result of the status type field, where the status type field includes at least one of a success flag, an error flag, and an interrupt flag, indicating a final status of the upgrade process; A behavior judgment is performed according to the parsing result of the status type field to obtain the judgment result.

[0015] By adopting the above technical solution, by parsing the status type field in the renamed file name of the OTA upgrade file and identifying the success, error or interrupt identifier therein, the current status of the upgrade task can be clearly determined; by making subsequent behavioral decisions based on the judgment result of the status type field, the process can be terminated when the upgrade is successful, record and wait when it fails, and enter the breakpoint recovery process when it is interrupted, thereby building a stable and reliable upgrade control strategy and enhancing the device's ability to cope with complex upgrade scenarios.

[0016] In one example, the present application may be further configured as follows: before initiating the OTA upgrade process, the OTA upgrade status feedback method based on dynamic file name identification further includes: Extract the signature field from the OTA upgrade file and use the device's local public key to perform decryption verification to determine whether the file is from a trusted source; After the signature verification is passed, the upgrade process and rename operation are allowed to be executed. If the verification fails, the upgrade is aborted and the file name is renamed to the format of error_error code_timestamp.

[0017] By adopting the above technical solution, by performing digital signature verification before starting the OTA upgrade process, and refusing to execute the upgrade process and marking the abnormal status when the verification fails, it is possible to ensure that the source of the OTA upgrade file is credible and the content has not been illegally tampered with, thereby greatly improving the security level of the OTA upgrade process and preventing illegal code injection from causing device paralysis or information leakage.

[0018] In one example, the present application may be further configured as follows: continuing the upgrade process of the OTA upgrade file from the breakpoint position according to the progress information in the renamed file name includes: Parsing the progress percentage field in the renamed file name to calculate the amount of data written to the OTA upgrade file, and determining the offset position of the breakpoint in the file based on this; Extract the remaining unwritten data content from the OTA upgrade file according to the offset position, and write the remaining unwritten data content to the target storage area of the device until the upgrade operation corresponding to the OTA upgrade file is completed, and rename the file name of the OTA upgrade file to success_version number_timestamp format.

[0019] By adopting the above technical solution, by parsing the progress percentage field in the renamed file name of the OTA upgrade file and calculating the offset position corresponding to the written data, the write breakpoint when the upgrade is interrupted can be accurately located; by extracting the remaining data from this position and continuing to write it to the target storage area, and renaming it to the success status after completion, a complete breakpoint resume function can be implemented, thereby effectively avoiding repeated writing, saving upgrade time, and improving the completion rate and fault tolerance of the upgrade in unstable networks or abnormal environments.

[0020] The second object of the present invention is achieved through the following technical solutions: An OTA upgrade status feedback system based on dynamic file name identification, the OTA upgrade status feedback system based on dynamic file name identification comprising: A parsing module is used to obtain an OTA upgrade file and parse the device identifier, target version number and hash check value from the initial file name of the OTA upgrade file; a comparison module, configured to perform a hash calculation on the contents of the OTA upgrade file to obtain a calculation result, and compare the calculation result with the hash check value in the initial file name to determine whether the OTA upgrade file has been tampered with or damaged, thereby implementing a pre-upgrade legitimacy verification; a verification module, configured to initiate an OTA upgrade process after the OTA upgrade file passes a validity check, monitor upgrade status information during the OTA upgrade process, obtain an upgrade result, and dynamically modify the file name of the OTA upgrade file based on the upgrade result to obtain a renamed file name of the OTA upgrade file; A judgment module is used to read the renamed file name of the OTA upgrade file, perform upgrade behavior judgment based on the status type and parameter content in the renamed file name, and obtain a judgment result. When it is detected that the judgment result is an interrupted state, continue the upgrade process of the OTA upgrade file from the breakpoint position according to the progress information in the renamed file name.

[0021] By adopting the above technical solution, by setting up a parsing module, a comparison module, a verification module and a judgment module to respectively complete the structural information extraction, integrity verification, upgrade execution and status writing of the upgrade file, as well as upgrade status identification and breakpoint recovery control, the file name-based status feedback mechanism can be implemented as a system component in the form of a functional module, thereby improving the integration capability, deployment efficiency and maintainability of this method on the embedded platform, and is suitable for remote upgrades and batch operation and maintenance scenarios of resource-constrained devices.

[0022] In summary, this application has the following beneficial technical effects: 1. By parsing the device identifier, target version number, and hash checksum from the initial OTA upgrade file name, the identity and integrity of the upgrade file can be determined without the need for additional metadata or partitioned storage, thereby improving the lightweight and flexible deployment of the OTA upgrade process. 2. By hashing the contents of the OTA upgrade file and comparing it with the hash checksum in the file name, it can ensure that the upgrade file has not been tampered with or damaged during transmission, thereby improving the security and accuracy of the upgrade. By monitoring the upgrade status information during the upgrade process and dynamically modifying the OTA upgrade file name based on the upgrade results, the upgrade execution status can be expressed in the file name, thereby avoiding reliance on traditional partition flags and improving the operability of interrupt recovery. By reading the renamed file name of the OTA upgrade file and determining whether it is in an interrupted state to decide whether to resume the download, the device can automatically resume the upgrade process after a power outage or abnormal interruption, thereby improving the continuity and stability of the upgrade process. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 This is a flow chart of an OTA upgrade status feedback method based on dynamic file name identification in one embodiment of the present application; Figure 2 This is a flowchart for implementing step S10 in an OTA upgrade status feedback method based on dynamic file name identification in one embodiment of the present application; Figure 3 This is a flowchart for implementing step S20 in an OTA upgrade status feedback method based on dynamic file name identification in one embodiment of the present application; Figure 4This is a flowchart for implementing step S30 in an OTA upgrade status feedback method based on dynamic file name identification in one embodiment of the present application; Figure 5 This is a flowchart for implementing step S40 in an OTA upgrade status feedback method based on dynamic file name identification in one embodiment of the present application; Figure 6 This is a flowchart for implementing step S30 in an OTA upgrade status feedback method based on dynamic file name identification in one embodiment of the present application; Figure 7 This is another implementation flowchart of step S40 in an OTA upgrade status feedback method based on dynamic file name identification in one embodiment of the present application; Figure 8 This is a principle block diagram of an OTA upgrade status feedback system based on dynamic file name identification in one embodiment of the present application. DETAILED DESCRIPTION

[0024] The present application is further described in detail below with reference to the accompanying drawings.

[0025] In one embodiment, if Figure 1 As shown, the present application discloses an OTA upgrade status feedback method based on dynamic file name identification, which specifically includes the following steps: S10: Obtain the OTA upgrade file, and parse the device identifier, target version number, and hash check value from the initial file name of the OTA upgrade file.

[0026] Specifically, the OTA upgrade file with the extension ".bin" is scanned from the designated upgrade directory of the file system, and the field content with "_" as the separator in the OTA upgrade file name is intercepted through string reading. The first field is extracted as the device identifier, the second field as the target version number, and the third field as the hash check value. The device identifier is used to match the unique number of the current device, the target version number is used to compare the version with the currently running firmware to determine whether an upgrade is required, and the hash check value is used for subsequent consistency verification with the calculated check result to confirm whether the file is valid. After field extraction, the three parameters are temporarily stored in the memory variable for subsequent logical processing.

[0027] S20: Perform hash calculation on the contents of the OTA upgrade file to obtain a calculation result, and compare the calculation result with the hash check value in the initial file name to determine whether the OTA upgrade file has been tampered with or damaged, so as to implement legitimacy verification before upgrading.

[0028] Specifically, after opening the OTA upgrade file, the file data content is read block by block in binary stream mode, and the entire file data is continuously calculated through a preset hash algorithm module (such as SHA-256) until all data traversal is completed to generate a final hash summary value. The hash summary value is then converted into a readable string format and compared with the hash check value parsed from the file name in step S10. When the two are consistent, the OTA upgrade file is marked as a legal file and allowed to enter the upgrade process. When the comparison fails, the upgrade operation is marked as illegally terminated and relevant log information is recorded for prompting or uploading to the platform to determine the reason for the upgrade failure.

[0029] S30: After the OTA upgrade file passes the legitimacy check, the OTA upgrade process is started. During the OTA upgrade process, the upgrade status information is monitored to obtain the upgrade result. The file name of the OTA upgrade file is dynamically modified according to the upgrade result to obtain the renamed file name of the OTA upgrade file.

[0030] Specifically, after completing the legitimacy verification, the OTA upgrade file content is written to the designated upgrade write area in the device in a fixed block length. During the writing process, the amount of data written is recorded periodically to generate the current upgrade progress percentage. At the same time, it is monitored whether there are write anomalies, verification failures, user interruptions, and other states. When it is detected that the upgrade data writing is completed and the firmware verification passes, the original OTA file is renamed to a file name in the format of success_version number_current system timestamp. When it is detected that the upgrade process is abnormally terminated or manually interrupted by the user, the OTA file is renamed to a file name in the format of interrupt_current progress percentage_current system timestamp. When an unexpected error event occurs during the upgrade process, such as flash memory write failure or verification failure, the OTA file is renamed to a file name in the format of error_error code_current system timestamp.

[0031] S40: Read the renamed file name of the OTA upgrade file, judge the upgrade behavior according to the status type and parameter content in the renamed file name, and obtain the judgment result. When the judgment result is detected as an interrupted state, continue the upgrade process of the OTA upgrade file from the breakpoint position according to the progress information in the renamed file name.

[0032] Specifically, the currently renamed OTA file is traversed from the upgrade directory and its file name content is obtained. The status type field in the file name is identified through string parsing. When the status field is success or error, it is determined that the upgrade process has been completed and does not need to be executed again. When the status field is interrupt, the progress percentage value recorded in the file name is further extracted, and the value is converted into a byte offset as the breakpoint position. When the upgrade process is restarted, the completed part is skipped and the remaining data of the OTA file is continued to be read from the breakpoint position and written to the upgrade area until all data is written. After the resumed upload is completed, the OTA file is renamed to a file name in the format of success_version number_current system timestamp to mark the completion of the upgrade process.

[0033] By adopting the above technical solution, by parsing the device identifier, target version number and hash check value from the initial file name of the OTA upgrade file, the identity and integrity judgment basis of the upgrade file can be obtained without the help of additional metadata or partition storage, thereby improving the lightweight and deployment flexibility of the OTA upgrade process; by hashing the content of the OTA upgrade file and comparing it with the hash check value in the file name, it can be ensured that the upgrade file has not been tampered with or damaged during the transmission process, thereby improving the security and accuracy of the upgrade; by monitoring the upgrade status information during the upgrade process and dynamically modifying the file name of the OTA upgrade file according to the upgrade result, the file name can be used as a carrier to express the upgrade execution status, thereby avoiding reliance on traditional partition flags and improving the operability of interrupt recovery; by reading the renamed file name of the OTA upgrade file and determining whether it is in an interrupted state to decide whether to resume the transfer from the breakpoint, the device can automatically resume the upgrade process after a power outage or abnormal interruption, thereby improving the continuity and stability of the upgrade process.

[0034] In one embodiment, if Figure 2 As shown, in step S10, the device identifier, target version number and hash check value are parsed from the initial file name of the OTA upgrade file, specifically including: S11: The initial file name of the OTA upgrade file adopts the structure format of "device ID_version number_hash value.extension", where the device ID is used to uniquely identify the upgrade target device, the version number is used to indicate the current upgrade target firmware version, and the hash value is the hash digest value used to verify the integrity of the file.

[0035] Specifically, the obtained OTA upgrade file name is preliminarily split according to the separator "." between the file name and the extension. After obtaining the main file name part, the underscore "_" is continued as the split mark, and the three field contents are read in sequence from the main file name. The first section is the device identification field, which is used for subsequent comparison with the local device identification to confirm the consistency of the upgrade target. The second section is the version number field, which is used to compare with the local firmware version to determine whether an upgrade operation is required. The third section is the hash field, which is used to compare with the subsequently calculated file content hash value to verify whether the file has been tampered with. After the field splitting is completed, the three field results are stored in the corresponding memory variables for subsequent processing and calling.

[0036] S12: By splitting the format of the initial file name of the OTA upgrade file, extracting in sequence the first field as the device identifier, the second field as the target version number, and the third field as the hash check value.

[0037] Specifically, the string processing method is called on the OTA upgrade file name to generate a field array with the separator "_" as the split point. The first element in the array is extracted as the device identifier and cached to the device ID temporary variable. The second field is extracted as the version number and pre-compared with the local version number to determine whether it meets the upgrade conditions. The third field is extracted as a hash string and saved in the hash comparison variable for use in subsequent hash verification steps. If the number of fields does not meet expectations during the field splitting process, the file structure is directly judged to be illegal and the upgrade process is terminated.

[0038] In one embodiment, if Figure 3 As shown, in step S20, a hash calculation is performed on the content of the OTA upgrade file to obtain a calculation result, and the calculation result is compared with the hash check value in the initial file name, specifically including: S21: Use a one-way hash algorithm to perform full calculation on the binary content of the OTA upgrade file to generate a calculation result.

[0039] Specifically, the OTA upgrade file is opened in read-only mode and a file stream input channel is established. A fixed-length data buffer is set to read the file content in blocks. Each time a block of data is read, the hash processing function is called for incremental calculation. The reading is looped until the entire file content is read and calculated. Finally, a complete hash summary is generated and output as a hexadecimal string as the calculation result for comparison. The hash algorithm can be SHA-256 or SHA-1, etc. No byte content is skipped during the calculation process to ensure consistency and integrity.

[0040] S22: The calculation result is compared with the hash check value in the initial file name. If the comparison results are consistent, the file is marked as complete and legal. Otherwise, it is judged as an illegal file and subsequent upgrade operations are prohibited.

[0041] Specifically, the hash result obtained through step S21 is compared character by character with the hash field parsed in S12. When the comparison results are completely consistent, the upgrade valid flag is set to true and the upgrade process is allowed to execute. When there is any character inconsistency in the comparison result, the upgrade valid flag is set to false, and the error log is recorded and the upgrade process is blocked from entering the upgrade execution stage. At the same time, it is prompted that the file may have been tampered with or damaged during the download or transmission process. If there is an abnormality reporting mechanism in the upper layer, the comparison result can be uploaded to the remote server for recording.

[0042] In one embodiment, if Figure 4 As shown, in step S30, the file name of the OTA upgrade file is dynamically modified according to the upgrade result, specifically including: S31: When the upgrade result is successful, the file name of the OTA upgrade file is modified to the format of success_target version number_timestamp to indicate the upgrade completion status.

[0043] Specifically, after completing all data writing and confirming that the upgrade data has been successfully written to the target area through the firmware verification mechanism, the current device time is obtained in the format of year, month, day, hour, minute, and second to generate an upgrade timestamp string, and the original OTA file name is renamed to a new file name consisting of the prefix "success" plus the target version number and the upgrade timestamp. The renaming operation calls the atomic rename function provided by the file system to ensure the integrity and consistency of the operation. After the file name is modified, the original file content remains unchanged, but the flag status has been updated to facilitate subsequent programs or users to identify and manage it. S32: When the upgrade result is upgrade failure, the file name of the OTA upgrade file is modified to the format of error_error code_timestamp, where the error code is used to indicate the cause of the failure.

[0044] Specifically, if data verification failure, write exception, power outage or other unrecoverable upgrade errors are detected during the upgrade process, the upgrade will be marked as failed, and the error code generation function will be called to generate corresponding error codes such as E01, E02, etc. to identify the specific cause of failure. At the same time, the current device timestamp is obtained and combined to form a new file name in the format of "error_error code_timestamp". Then, the file rename operation is called to rename the original file to the error status flag name. This file will be used by the subsequent operation and maintenance system to analyze the cause of failure or prompt the user to retry the upgrade operation.

[0045] S33: When the upgrade result is that the upgrade is interrupted, the file name of the OTA upgrade file is modified to the format of interrupt_progress percentage_timestamp, where the progress percentage is the ratio between the total amount of data written to the device and the total size of the OTA upgrade file.

[0046] Specifically, if an abort command is received or a system abnormality is detected during the upgrade process, the interrupt protection logic is triggered. The cumulative number of data bytes currently written is read and the ratio is calculated with the total byte length of the OTA upgrade file to generate an upgrade progress percentage string. The progress percentage is rounded to one decimal place and converted into a string and concatenated to the prefix "interrupt". At the same time, the current timestamp is appended to form a complete file name in the format of "interrupt_progress percentage_timestamp". The file rename operation is immediately performed to save the status when the upgrade was interrupted for the breakpoint resumption recovery logic after the device is restarted.

[0047] In one embodiment, if Figure 5 As shown, in step S40, the renamed file name of the OTA upgrade file is read, and the upgrade behavior is judged according to the status type and parameter content in the renamed file name to obtain a judgment result, which specifically includes: S41: Parse the status type field in the renamed file name of the OTA upgrade file to obtain the parsing result of the status type field. The status type field includes at least one of a success flag, an error flag, and an interrupt flag, which is used to indicate the final status of the upgrade process.

[0048] Specifically, after the device is started, the renamed OTA upgrade file is searched by traversing the directory where the upgrade file is located. After obtaining the file name, the string processing function is called to split the file name field with "_" as the separator, and the first field is extracted as the status type field. The field is matched with the preset identifier "success", "error" or "interrupt". A successful match determines the status type field parsing result, which is used for subsequent execution of the corresponding upgrade behavior decision logic.

[0049] S42: Perform behavior judgment based on the parsing result of the status type field to obtain a judgment result.

[0050] Specifically, the behavior is judged based on the parsing result of the status type field. When the status type is success, the upgrade process is terminated and the current firmware is marked as the latest version. When the status type is error, the error information is recorded and the next upgrade trigger is waited for. When the status type is interrupt, the progress parameters are extracted and the breakpoint resume operation is started. When the parsing result of the status type field is success, the upgrade process is immediately skipped and the current firmware of the device is marked as updated. When the parsing result is error, the error log is recorded and a prompt is given that the upgrade failed and the user can wait for the next upgrade request to be triggered. When the parsing result is interrupt, the interrupt recovery judgment process is entered. The judgment result flag is set to indicate that the breakpoint resume operation should be executed to resume the unfinished upgrade process. The judgment result is used for branch path selection.

[0051] In one embodiment, if Figure 6 As shown, before step S30, that is, before starting the OTA upgrade process, the OTA upgrade status feedback method based on dynamic file name identification further includes: S301: Extract the signature field from the OTA upgrade file and use the local public key of the device to perform decryption verification to determine whether the file is from a trusted source.

[0052] Specifically, after opening the OTA upgrade file, a fixed-length data segment is read at the end of the file or at an agreed position as the digital signature field. After caching the signature field, the local preset public key is called to perform asymmetric encryption and decryption processes such as RSA or ECC to restore the signature summary information. At the same time, the summary calculation is re-executed on the file content itself and compared with the signature decryption result. When the comparison is consistent, the OTA upgrade file is judged to be a trusted source. If the comparison fails, it is marked as an untrusted file and prohibited from entering the upgrade process.

[0053] S302: After the signature verification is passed, the upgrade process and rename operation are allowed to be executed. If the verification fails, the upgrade is aborted and the file name is renamed to the format of error_error code_timestamp.

[0054] Specifically, on the premise that the signature verification result in step S301 is passed, continue to perform the upgrade write operation and record the upgrade status in real time for use in subsequent renaming operations. When the signature verification fails, the upgrade process is immediately terminated and the reason for the failure is recorded. The error code generation function is called to generate an error identifier indicating that the signature verification failed, obtain the current system timestamp and construct a new file name in the format of "error_error code_timestamp", and then perform the renaming operation to mark the current OTA file as a verification failure state.

[0055] In one embodiment, if Figure 7 As shown, in step S40, the upgrade process of the OTA upgrade file is continued from the breakpoint position according to the progress information in the renamed file name, specifically including: S43: Parse the progress percentage field in the renamed file name, calculate the amount of data that has been written to the OTA upgrade file, and determine the offset position of the breakpoint in the file based on the calculated data.

[0056] Specifically, after obtaining the renamed OTA upgrade file name, the field is split by "_" and the field containing the percentage sign "%" is extracted as the progress percentage field. The percentage part in the field is parsed into numerical data and divided by 100 to obtain the relative proportion. Then the total byte length of the OTA upgrade file is obtained and multiplied by the proportion to obtain the amount of data that has been written. Finally, this data amount is used as the offset position of the file breakpoint for the starting address of subsequent resume operations.

[0057] S44: Extract the remaining unwritten data content from the OTA upgrade file according to the offset position, and write the remaining unwritten data content to the target storage area of the device until the upgrade operation corresponding to the OTA upgrade file is completed, and rename the file name of the OTA upgrade file to success_version number_timestamp format.

[0058] Specifically, by calling the file reading function, the data before the offset position is skipped from the OTA upgrade file, and the remaining content is read starting from the offset position. The data blocks are written into the target storage area of the device in sequence until the entire OTA file data is written. During the writing process, the status record is kept and whether the writing is successful is monitored. When it is confirmed that all data has been written, the upgrade result status is updated, and the rename function is called to change the current file to a file name format that starts with "success" and concatenates the version number and the current system timestamp to indicate that the upgrade process has been completed.

[0059] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0060] In one embodiment, an OTA upgrade status feedback system based on dynamic file name identification is provided, and the OTA upgrade status feedback system based on dynamic file name identification corresponds one-to-one to the OTA upgrade status feedback method based on dynamic file name identification in the above embodiment. Figure 8 As shown in the figure, the OTA upgrade status feedback system based on dynamic file name recognition includes a parsing module, a comparison module, a verification module and a judgment module. The detailed description of each functional module is as follows: A parsing module is used to obtain the OTA upgrade file and parse the device identifier, target version number and hash check value from the initial file name of the OTA upgrade file; The comparison module is used to perform hash calculation on the contents of the OTA upgrade file, obtain the calculation result, and compare the calculation result with the hash check value in the initial file name to determine whether the OTA upgrade file has been tampered with or damaged, thereby implementing legitimacy verification before the upgrade; The verification module is used to start the OTA upgrade process after the OTA upgrade file passes the legitimacy check, monitor the upgrade status information during the OTA upgrade process, obtain the upgrade result, and dynamically modify the file name of the OTA upgrade file based on the upgrade result to obtain the renamed file name of the OTA upgrade file; The judgment module is used to read the renamed file name of the OTA upgrade file, judge the upgrade behavior according to the status type and parameter content in the renamed file name, and obtain a judgment result. When the judgment result is detected as an interrupted state, the upgrade process of the OTA upgrade file is continued from the breakpoint position according to the progress information in the renamed file name.

[0061] Optionally, parsing modules include: The format parsing submodule uses the structure format of "device ID_version number_hash value.extension" for the initial file name of the OTA upgrade file, where the device ID is used to uniquely identify the upgrade target device, the version number is used to indicate the current upgrade target firmware version, and the hash value is a hash digest value used to verify file integrity; The format splitting submodule is used to split the format of the initial file name of the OTA upgrade file, and extract the first field as the device identifier, the second field as the target version number, and the third field as the hash check value in sequence.

[0062] Optional comparison modules include: The full calculation submodule is used to perform full calculation on the binary content of the OTA upgrade file using a one-way hash algorithm to generate the calculation results; The comparison and analysis submodule is used to compare the calculation result with the hash check value in the initial file name. If the comparison result is consistent, the file is marked as complete and legal. Otherwise, it is judged as an illegal file and subsequent upgrade operations are prohibited.

[0063] Optionally, the verification module includes: The upgrade success submodule is used to modify the file name of the OTA upgrade file to the format of success_target version number_timestamp when the upgrade result is successful, to indicate the upgrade completion status; The upgrade failure submodule is used to modify the file name of the OTA upgrade file to the format of error_error code_timestamp when the upgrade result is upgrade failure. The error code is used to indicate the reason for the failure. The upgrade interrupt submodule is used to modify the file name of the OTA upgrade file to the format of interrupt_progress percentage_timestamp when the upgrade result is an upgrade interrupt. The progress percentage is the ratio between the total amount of data written to the device and the total size of the OTA upgrade file.

[0064] Optionally, the judgment module includes: A status determination submodule is configured to parse the status type field in the renamed file name of the OTA upgrade file to obtain a parsed result of the status type field. The status type field includes at least one of a success flag, an error flag, and an interrupt flag, indicating the final status of the upgrade process. The result generation submodule is used to make behavioral judgments based on the parsing results of the status type field and obtain the judgment results.

[0065] The offset calculation submodule is used to parse the progress percentage field in the renamed file name, calculate the amount of data written to the OTA upgrade file, and use this to determine the offset position of the breakpoint in the file. The re-upgrade submodule is used to extract the remaining unwritten data content from the OTA upgrade file according to the offset position, and write the remaining unwritten data content to the target storage area of the device until the upgrade operation corresponding to the OTA upgrade file is completed, and rename the file name of the OTA upgrade file to success_version number_timestamp format.

[0066] Optionally, the OTA upgrade status feedback system based on dynamic file name identification further includes: The signature verification module is used to extract the signature field from the OTA upgrade file and use the device's local public key to decrypt and verify whether the file is from a trusted source; The verification feedback module is used to allow the upgrade process and rename operation to be executed after the signature verification is passed. If the verification fails, the upgrade is aborted and the file name is renamed to the format of error_error code_timestamp.

[0067] For the specific definition of an OTA upgrade status feedback system based on dynamic file name identification, please refer to the definition of an OTA upgrade status feedback method based on dynamic file name identification above, which will not be repeated here. The various modules in the above-mentioned OTA upgrade status feedback system based on dynamic file name identification can be implemented in whole or in part by software, hardware and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0068] Those skilled in the art will clearly understand that for the sake of convenience and brevity in description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above.

[0069] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A method for OTA upgrade status feedback based on dynamic file name identification, characterized in that: The OTA upgrade status feedback method based on dynamic file name identification includes: Obtain an OTA upgrade file and parse the device identifier, target version number, and hash checksum from the initial file name of the OTA upgrade file; Performing a hash calculation on the contents of the OTA upgrade file to obtain a calculation result, and comparing the calculation result with the hash check value in the initial file name to determine whether the OTA upgrade file has been tampered with or damaged, thereby implementing a pre-upgrade legitimacy verification; After the OTA upgrade file passes the legitimacy check, the OTA upgrade process is started, upgrade status information is monitored during the OTA upgrade process to obtain an upgrade result, and the file name of the OTA upgrade file is dynamically modified according to the upgrade result to obtain the renamed file name of the OTA upgrade file; Read the renamed file name of the OTA upgrade file, perform upgrade behavior judgment based on the status type and parameter content in the renamed file name, and obtain a judgment result. When it is detected that the judgment result is an interrupted state, continue the upgrade process of the OTA upgrade file from the breakpoint position according to the progress information in the renamed file name.

2. The OTA upgrade status feedback method based on dynamic file name identification according to claim 1, characterized in that: Parsing the device identifier, target version number, and hash check value from the initial file name of the OTA upgrade file includes: The initial file name of the OTA upgrade file adopts the structure format of "device ID_version number_hash value.extension", where the device ID is used to uniquely identify the upgrade target device, the version number is used to indicate the current upgrade target firmware version, and the hash value is a hash digest value used to verify the integrity of the file; By formatting the initial file name of the OTA upgrade file, the first field is the device identifier, the second field is the target version number, and the third field is the hash check value.

3. The OTA upgrade status feedback method based on dynamic file name identification according to claim 1, characterized in that: The performing hash calculation on the content of the OTA upgrade file to obtain a calculation result, and comparing the calculation result with the hash check value in the initial file name includes: Performing a full calculation on the binary content of the OTA upgrade file using a one-way hash algorithm to generate the calculation result; The calculation result is compared with the hash check value in the initial file name. If the comparison results are consistent, the file is marked as complete and legal. Otherwise, it is determined to be an illegal file and subsequent upgrade operations are prohibited.

4. The OTA upgrade status feedback method based on dynamic file name identification according to claim 1, characterized in that: Dynamically modifying the file name of the OTA upgrade file according to the upgrade result includes: When the upgrade result is successful, the file name of the OTA upgrade file is modified to the format of success_target version number_timestamp to indicate the upgrade completion status; When the upgrade result is an upgrade failure, the file name of the OTA upgrade file is modified to the format of error_error code_timestamp, where the error code is used to indicate the cause of the failure; When the upgrade result is that the upgrade is interrupted, the file name of the OTA upgrade file is modified to the format of interrupt_progress percentage_timestamp, where the progress percentage is the ratio between the total amount of data written to the device and the total size of the OTA upgrade file.

5. The OTA upgrade status feedback method based on dynamic file name identification according to claim 1, characterized in that: The reading of the renamed file name of the OTA upgrade file and the determination of the upgrade behavior according to the status type and parameter content in the renamed file name include: Parsing a status type field in the renamed file name of the OTA upgrade file to obtain a parsing result of the status type field, where the status type field includes at least one of a success flag, an error flag, and an interrupt flag, indicating a final status of the upgrade process; A behavior judgment is performed according to the parsing result of the status type field to obtain the judgment result.

6. The OTA upgrade status feedback method based on dynamic file name identification according to claim 1, characterized in that: Before starting the OTA upgrade process, the OTA upgrade status feedback method based on dynamic file name identification further includes: Extract the signature field from the OTA upgrade file and use the device's local public key to perform decryption verification to determine whether the file is from a trusted source; After the signature verification is passed, the upgrade process and rename operation are allowed to be executed. If the verification fails, the upgrade is aborted and the file name is renamed to the format of error_error code_timestamp.

7. The OTA upgrade status feedback method based on dynamic file name identification according to claim 1, characterized in that: The step of continuing to execute the upgrade process of the OTA upgrade file from the breakpoint position according to the progress information in the renamed file name includes: Parsing the progress percentage field in the renamed file name to calculate the amount of data written to the OTA upgrade file, and determining the offset position of the breakpoint in the file based on this; Extract the remaining unwritten data content from the OTA upgrade file according to the offset position, and write the remaining unwritten data content to the target storage area of the device until the upgrade operation corresponding to the OTA upgrade file is completed, and rename the file name of the OTA upgrade file to success_version number_timestamp format.

8. An OTA upgrade status feedback system based on dynamic file name identification, characterized in that: The OTA upgrade status feedback system based on dynamic file name identification includes: A parsing module is used to obtain an OTA upgrade file and parse the device identifier, target version number and hash check value from the initial file name of the OTA upgrade file; a comparison module, configured to perform a hash calculation on the contents of the OTA upgrade file to obtain a calculation result, and compare the calculation result with the hash check value in the initial file name to determine whether the OTA upgrade file has been tampered with or damaged, thereby implementing a pre-upgrade legitimacy verification; a verification module, configured to initiate an OTA upgrade process after the OTA upgrade file passes a validity check, monitor upgrade status information during the OTA upgrade process, obtain an upgrade result, and dynamically modify the file name of the OTA upgrade file based on the upgrade result to obtain a renamed file name of the OTA upgrade file; A judgment module is used to read the renamed file name of the OTA upgrade file, perform upgrade behavior judgment based on the status type and parameter content in the renamed file name, and obtain a judgment result. When it is detected that the judgment result is an interrupted state, continue the upgrade process of the OTA upgrade file from the breakpoint position according to the progress information in the renamed file name.

Images