Firmware upgrading method and device for optical module, equipment and storage medium

Abstract

The invention relates to the technical field of optical modules, and provides a firmware upgrading method, device and equipment for an optical module and a storage medium, and the method comprises the steps: after receiving a firmware upgrading request corresponding to the optical module, extracting a firmware version identifier and a check code, obtaining version information and an operation abstract of operating firmware in the optical module, and storing the version information and the operation abstract in the optical module; the version information and the operation abstract are compared with the firmware version identifier and the check code and analyzed and verified, a comparison result and an analysis result are obtained, if any one of the results is abnormal, the optical module is rolled back to an initial state and an error is reported, if the result is not abnormal, the optical module is subjected to multiple rounds of self-inspection, and if a preset threshold value is met, the optical module is subjected to self-inspection. If yes, the original version data in the optical module is cleared, and if the preset threshold value is not met, the optical module is recovered to the pre-upgrading state. Through a multi-round self-checking and conditional clearing mechanism, the fault recovery capability and the system stability are remarkably enhanced, and the problem of upgrading failure caused by weak checking mechanism and insufficient stability analysis in the firmware upgrading process of the existing optical module is solved.

Description

Technical Field

[0001] This application relates to the technical field of optical modules, and in particular to methods, apparatus, devices and storage media for firmware upgrades of optical modules. Background Technology

[0002] With the rapid development of data centers, 5G base stations, and high-capacity transmission networks, optical modules, as key components for photoelectric conversion and high-speed signal transmission, are receiving increasing attention for their performance stability and remote maintainability. To adapt to the remote maintenance and rapid iteration of network equipment, more and more optical modules are equipped with remote upgrade capabilities, enabling firmware optimization, feature expansion, or security patch updates without interrupting system operation. Based on this trend, firmware upgrade technology for optical modules has gradually become one of the key research directions in the optical communication industry.

[0003] In existing technologies, the main control device communicates via a standard communication interface (such as I...). 2 (C, MDIO, etc.) sends an upgrade request to the target optical module. After parsing the request, the optical module writes the received firmware data into its internal non-volatile memory. During the upgrade process, basic data integrity is typically verified using CRC checksums or simple hash algorithms. Once the upgrade is successful, the optical module is restarted to load the new firmware version. This type of technical solution enables remote batch upgrades, improves optical module maintenance efficiency, and is widely used in data center optical interconnects and carrier metropolitan area network construction scenarios.

[0004] Although remote upgrade mechanisms can effectively enable remote deployment and version iteration of optical module firmware, in low-speed I... 2 In abnormal scenarios such as C-link jitter or upgrade interruption, it is easy to cause risks such as firmware writing failure and optical module failure to start. There are also upgrade failure issues due to weak verification mechanisms and insufficient stability analysis. Summary of the Invention

[0005] To overcome the problem of upgrade failures caused by weak verification mechanisms and insufficient stability analysis in existing optical module firmware upgrade processes, this application provides a firmware upgrade method, apparatus, device, and storage medium for optical modules. By combining integrity hash value verification, communication link stability analysis, and multi-round self-testing mechanisms, the firmware upgrade method for optical modules improves the security and robustness of the upgrade process.

[0006] This invention provides a firmware upgrade method for an optical module, comprising: receiving a firmware upgrade request corresponding to the optical module, and extracting the firmware version identifier and verification code from the firmware upgrade request; obtaining the version information and runtime digest of the firmware running in the optical module, comparing and verifying the version information and runtime digest with the firmware version identifier and the verification code to obtain a verification result; if the verification result is inconsistent, terminating the upgrade process; if the verification result is consistent, loading the upgrade data from the firmware upgrade request into the optical module, and collecting data transmission integrity data in real time during the loading process. The integrity hash value and communication stability index are cross-compared with the original hash value of the firmware running in the optical module to obtain the comparison result. The communication stability index is then analyzed to obtain the analysis result. If any one of the comparison result or the analysis result is abnormal, the system rolls back to the initial state and reports an error. If neither the comparison result nor the analysis result is abnormal, the optical module undergoes multiple rounds of self-testing. If the self-test result meets a preset threshold, the original version data in the optical module is cleared. If the self-test result does not meet the preset threshold, the system is restored to the state before the upgrade.

[0007] Optionally, the step of receiving the firmware upgrade request corresponding to the optical module and extracting the firmware version identifier and verification code from the firmware upgrade request includes: listening to the firmware upgrade request sent by the external management device through a preset communication interface on the optical module, and triggering the firmware upgrade process of the optical module based on the firmware upgrade request; parsing the format of the data frame in the firmware upgrade request to obtain the firmware version field and the integrity verification field; performing field matching analysis on the firmware version field to obtain the firmware version identifier; and performing hash decoding operation on the integrity verification field to obtain the verification code.

[0008] Optionally, the step of obtaining the version information and running summary of the firmware running in the optical module includes: reading the status of the firmware running in the optical module to obtain a version code segment, a build time field, and summary information; performing binary parsing on the version code segment to obtain a major version number and a minor version number; performing time-series mapping analysis on the major version number and the build time field to obtain version information; and performing redundancy comparison processing on the minor version number and the summary information to obtain the running summary.

[0009] Optionally, the step of comparing and verifying the version information with the runtime digest, the firmware version identifier, and the checksum to obtain a verification result includes: performing field-level extraction on the version information and the runtime digest to obtain the current version hash value and the current configuration fingerprint; parsing the firmware version identifier and the checksum to obtain the target version hash value and the integrity identifier; performing consistency matching between the current version hash value and the target version hash value to obtain a version matching result; performing cross-validation between the current configuration fingerprint and the integrity identifier to obtain a digest matching result; and performing logical fusion analysis on the version matching result and the digest matching result to obtain a verification result.

[0010] Optionally, the step of collecting the integrity hash value and communication stability index of data transmission in real time during the loading process includes: collecting the data stream in segments during the loading process using a boundary detection mechanism to obtain segmented datasets; performing segmented hash operations on the segmented datasets to obtain a hash digest sequence for each segment; performing integrity detection on each data segment based on the hash digest sequence to obtain a set of valid segment identifiers; inputting the set of valid segment identifiers and the segmented datasets into a preset data stability analysis model to obtain a segment-level integrity identifier sequence; performing aggregation analysis on the hash digest sequence based on the segment-level integrity identifier sequence to obtain an integrity hash value; calculating the initial delay and jitter frequency during the loading process to obtain a signal delay distribution and frequency fluctuation curve; performing transmission stability calculations based on a transmission retry counter and a handshake failure counter to obtain a retry rate index and a failure rate index; and fusing and evaluating the signal delay distribution, frequency fluctuation curve, retry rate index, and failure rate index to obtain a communication stability index.

[0011] Optionally, the step of cross-comparing the integrity hash value with the original hash value of the firmware running in the optical module to obtain the comparison result includes: segmenting and parsing the integrity hash value to obtain an intra-segment verification field and a cross-segment digest fingerprint; performing positional verification between the intra-segment verification field and the basic hash segment stored in the optical module using comparison logic to obtain a positional consistency score; performing sequence matching between the cross-segment digest fingerprint and the hash trajectory recorded during firmware runtime to obtain a digest matching score; performing weighted fusion of the digest matching score based on the positional consistency score to obtain a structural consistency score; and comparing the structural consistency score with a stable matching threshold in historical upgrade data to obtain the comparison result.

[0012] Optionally, the step of performing stability analysis on the communication stability indicators to obtain analysis results includes: extracting the communication stability indicators from multiple dimensions to obtain the average latency value, the retry count statistics, and the handshake failure rate; performing time-domain fitting on the average latency value to obtain a stable trend curve and a maximum offset; comparing the retry count statistics with the stable trend curve to obtain abnormal retry segments; jointly analyzing the handshake failure rate and the maximum offset to obtain a protocol-level error indicator; making a credibility judgment on the abnormal retry segments and the protocol-level error indicator to obtain a stability level label; and inputting the stability level label into a preset upgrade decision-maker for matching analysis to obtain the analysis results.

[0013] This application also provides a firmware upgrade device for an optical module, comprising: a receiving module, configured to receive a firmware upgrade request corresponding to the optical module and extract the firmware version identifier and verification code from the firmware upgrade request; and an acquiring module, configured to acquire the version information and running digest of the firmware running in the optical module, compare the version information and the running digest with the firmware version identifier and the verification code to obtain a verification result, and if the verification result is inconsistent, terminate the upgrade process; if the verification result is consistent, load the upgrade data in the firmware upgrade request into the optical module, and collect data transmission data in real time during the loading process. The system includes an integrity hash value and a communication stability index; an analysis module is used to cross-compare the integrity hash value with the original hash value of the firmware running in the optical module to obtain a comparison result, and to perform stability analysis on the communication stability index to obtain an analysis result. If any one of the comparison result or the analysis result is abnormal, the system rolls back to the initial state and reports an error. If neither the comparison result nor the analysis result is abnormal, the system performs multiple rounds of self-testing on the optical module. If the self-test result meets a preset threshold, the system clears the original version data in the optical module. If the self-test result does not meet the preset threshold, the system restores to the state before the upgrade.

[0014] This application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the firmware upgrade method for the optical module described in any one of the above-described methods.

[0015] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when run by a processor, causes the processor to perform a firmware upgrade method for an optical module as described in any of the above-described applications.

[0016] Compared with existing technologies, this application has the following advantages: high reliability and strong stability. By introducing a two-way verification mechanism of firmware version identifier and runtime summary, a real-time feedback mechanism that synchronously collects integrity hash value and communication stability indicators during the upgrade data loading process, and a closed loop for anomaly rollback and self-test judgment constructed by combining structural comparison and stability analysis, it not only ensures the data consistency and communication link reliability of optical modules during firmware upgrades, but also significantly enhances fault recovery capability and system stability through multi-round self-testing and conditional clearing mechanisms, overcoming the upgrade failure problem caused by weak verification mechanism and insufficient stability analysis in existing optical module firmware upgrade processes. Attached Figure Description

[0017] The accompanying drawings are used to provide a further understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0018] Figure 1 This is a flowchart illustrating the firmware upgrade method for an optical module provided in an embodiment of the present invention. Figure 2 This is a schematic block diagram of the structure of the firmware upgrade device for an optical module provided in an embodiment of the present invention; Figure 3 This is a schematic block diagram of the structure of the electronic device provided in the embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. It should be noted that in various specific embodiments of this application, when processing data related to the characteristics of the target object, such as target object attribute information or attribute information sets, is required, the permission or consent of the target object will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. The target object can be a user. In addition, when embodiments of this application need to obtain target object attribute information, separate permission or consent from the target object will be obtained through pop-ups or redirection to a confirmation page. Only after obtaining the target object's separate permission or consent will the necessary target object-related data for the normal operation of the embodiments of this application be obtained.

[0020] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0021] The technical solution of the present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0022] Example 1: like Figure 1 As shown, this application provides a firmware upgrade method for optical modules. This firmware upgrade method effectively solves the upgrade failure problems caused by single verification dimensions, uncontrollable communication anomalies, and lack of error recovery mechanisms in the prior art by introducing a multi-dimensional comparison mechanism of version information and runtime digest, a dual acquisition mechanism of integrity hash value and communication stability index during data loading, and a result-oriented anomaly handling and self-checking mechanism. It achieves high robustness, high fault tolerance, and controllability in the firmware upgrade process, significantly improving the efficiency and stability of remote operation and maintenance of optical modules. Specifically, it is implemented through the following steps: S1. Receive the firmware upgrade request corresponding to the optical module, and extract the firmware version identifier and verification code from the firmware upgrade request.

[0023] Through the communication interface (e.g., I) configured on the optical module 2 The system continuously listens for command trigger events from external management devices via either the C interface or the MDIO interface. When a firmware upgrade request conforming to a preset data frame structure is detected, the system triggers the firmware upgrade process. Specifically, the data structure in the firmware upgrade request is first parsed to extract the firmware version field and integrity verification field. The firmware version field identifies the version number of the upgrade target, while the integrity verification field contains a cryptographic hash digest. Subsequently, field matching analysis is performed on the firmware version field to obtain the firmware version identifier. Finally, a hash decoding operation is performed on the integrity verification field to obtain the checksum.

[0024] For example, in a real-world upgrade process, the firmware version field might be "v3.2.7". Its verification field is a 64-bit SHA-256 hash value. The system parses this version field to convert it into a firmware version identifier "V327" and extracts the corresponding checksum "6a5f...9b3d" from the verification field, providing accurate data for subsequent comparison and verification. This ensures that the consistency verification between the upgrade request source and the target firmware has basic data support, effectively preventing erroneous version jump upgrades and malicious command injection.

[0025] S2. Obtain the version information and running summary of the firmware running in the optical module. Compare and verify the version information and running summary with the firmware version identifier and check code to obtain the verification result. If the verification result is inconsistent, stop the upgrade process. If the verification result is consistent, load the upgrade data in the firmware upgrade request into the optical module. During the loading process, collect the data transmission integrity hash value and communication stability index in real time.

[0026] The system internally calls and reads the currently running firmware status in the optical module to obtain the version code segment, build time field, and digest information. The version code segment is parsed from binary data to obtain the major version number and minor version number. Then, the major version number is mapped to the build time field to obtain the current version information. Finally, a redundancy comparison is performed between the minor version number and the digest information to generate a runtime digest.

[0027] Subsequently, based on the version information and runtime digest obtained above, a field-level comparison is performed with the firmware version identifier and checksum extracted in step S1. Specifically, the version information is converted into a current version hash value, the runtime digest is converted into a current configuration fingerprint, and the firmware version identifier and checksum are converted into a target version hash value and an integrity identifier code. The current version hash value and the target version hash value are matched for consistency, and the current configuration fingerprint and integrity identifier code are cross-validated. Finally, the two comparison results are logically fused and analyzed to obtain the verification result.

[0028] If the verification results are inconsistent, for example, the current version is V327 and the target version is V326, or the hash digest comparison fails, the system will abort the upgrade process to avoid erroneous writes. If the verification results are consistent, the system will proceed to the data loading stage.

[0029] During the loading phase, the upgrade data stream is collected in real time in segments using a boundary detection mechanism to obtain segmented datasets. Each segment is then subjected to a segmented hash operation to generate a hash digest sequence. Simultaneously, parameters such as signal delay, retry count, and handshake failure information are extracted during the loading process, forming the raw data foundation for communication stability indicators.

[0030] S3. Cross-compare the integrity hash value with the original hash value of the firmware running in the optical module to obtain the comparison result. Perform stability analysis on the communication stability indicators to obtain the analysis result. If any one of the comparison result or analysis result is abnormal, roll back to the initial state and report the error. If the comparison result and analysis result are not abnormal, perform multiple rounds of self-test on the optical module. If the self-test result meets the preset threshold, clear the original version data in the optical module. If the self-test result does not meet the preset threshold, restore to the state before the upgrade.

[0031] By parsing the integrity hash value generated during the loading process at the segment level, the intra-segment verification fields and cross-segment digest fingerprints are extracted. A field-by-field position verification is performed against the original hash value inherently stored in the optical module to calculate the position consistency score. Furthermore, the cross-segment digest is sequence-matched with the runtime hash trajectory to generate a digest matching score. These two indicators are then weighted and fused to generate a structural consistency score, which is compared with a historical stable matching threshold to output the comparison result.

[0032] Simultaneously, communication stability indicators are extracted and calculated from multiple dimensions to form average latency, retry count statistics, and handshake failure rate. These are then combined with a loading trend curve for time-domain fitting to determine the presence of abnormal retry segments or protocol-level error indicators, ultimately deriving a stability level label. This label is then input into a pre-defined upgrade decision-maker to complete the upgrade stability analysis.

[0033] If any anomaly is found in the above comparison or analysis results, such as a hash matching degree below 90% or a handshake failure rate exceeding 10%, a rollback mechanism will be immediately triggered to restore the system to the pre-upgrade state and output an error log. If no anomalies are found, a multi-round self-check process will be initiated to verify the consistency and conduct behavioral tests on the key functional units of the optical module. If the self-check results reach a preset threshold (e.g., stable running time exceeding 30 seconds, zero restarts, and interface fluctuation less than 1%), the old version data will be cleared. Otherwise, the system will be restored to the pre-upgrade state to ensure data security and functional stability.

[0034] In this embodiment, a firmware upgrade request corresponding to the optical module is received, and the firmware version identifier and checksum are extracted from the firmware upgrade request. The version information and runtime digest of the firmware running in the optical module are obtained, and the version information and runtime digest are compared and verified with the firmware version identifier and checksum to obtain a verification result. If the verification result is inconsistent, the upgrade process is terminated. If the verification result is consistent, the upgrade data in the firmware upgrade request is loaded into the optical module, and the data transmission integrity hash value and communication stability index are collected in real time during the loading process. The integrity hash value is cross-compared with the original hash value of the firmware running in the optical module to obtain a comparison result, and the communication stability index is analyzed to obtain an analysis result. If any of the comparison result or the analysis result is abnormal, the system rolls back to the initial state and reports an error. If neither the comparison result nor the analysis result is abnormal, the optical module undergoes multiple rounds of self-checks. If the self-check result meets a preset threshold, the original version data in the optical module is cleared. If the self-check result does not meet the preset threshold, the system reverts to the state before the upgrade.

[0035] The firmware upgrade method for optical modules described in this application introduces multiple verification mechanisms during the firmware upgrade process. These include pre-verification based on firmware version information and runtime digest, cross-verification based on integrity hash value and original hash value, link reliability analysis based on communication stability indicators, and a multi-round self-test mechanism, effectively improving the security and reliability of the upgrade process. Furthermore, a protection mechanism is set up to roll back to the initial state and report errors in case of abnormal situations during the upgrade process, further ensuring the recoverability of the optical module under abnormal conditions. The original version data is retained until the upgrade is successful, and the original firmware is cleared only after the self-test passes, enhancing the fault tolerance and controllability of the upgrade process. This is significantly superior to existing firmware upgrade schemes that rely on a single verification mechanism, overcoming the upgrade failure problem caused by weak verification mechanisms and insufficient stability analysis in existing optical module firmware upgrade processes.

[0036] Example 2: Furthermore, in the step of receiving the firmware upgrade request corresponding to the optical module and extracting the firmware version identifier and verification code from the firmware upgrade request, the firmware upgrade request sent by the external management device is listened to through the preset communication interface on the optical module, and the firmware upgrade process of the optical module is triggered based on the firmware upgrade request.

[0037] By deploying an I / O based on a hardware timed polling mechanism in the optical module 2 The C communication interface monitoring module periodically monitors whether data frame signals conforming to a preset format appear on the bus. Specifically, it utilizes I... 2In the master-slave architecture, the slave device detection mechanism automatically switches to firmware upgrade mode after receiving a start signal and matching the device address.

[0038] For example, during a network maintenance cycle, an external management device sends batch upgrade requests to multiple optical modules, which include specific preamble bytes and control flags. In this embodiment, by setting a fixed listening address range and a start frame identifier, when an upgrade request frame with the "0xF8" control byte and a matching address is detected, the optical module automatically activates its internal buffer and switches to receiving mode, thereby improving the response efficiency to firmware upgrade requests and avoiding false triggering issues.

[0039] The data frame in the firmware upgrade request is parsed to obtain the firmware version field and the integrity verification field. Field matching analysis is performed on the firmware version field to obtain the firmware version identifier. Hash decoding is performed on the integrity verification field to obtain the verification code.

[0040] The optical module deconstructs the received upgrade request data frames according to a preset format, dividing the data frames into a header area, a control area, a payload area, and a check area. Specifically, the optical module first verifies the protocol type in the header area. After confirming that it is an upgrade type, it extracts the firmware version field from the control area and performs field matching analysis. By comparing the version major number and version sub-number in the field structure with the list of currently supported versions, a firmware version identifier is generated.

[0041] Furthermore, the integrity verification field in the verification area is subjected to hash decoding, and the original hash value is extracted as the verification code using a preset MD5 or SHA-256 parsing function.

[0042] For example, if the firmware version field in the upgrade request is "V1.8.3" and the verification field is "C5B1F4…", the optical module will compare "V1.8.3" bit by bit to generate the corresponding firmware version identifier "183", and restore the complete hash verification code from the verification field through hash decoding for subsequent data consistency verification.

[0043] Furthermore, the steps of obtaining the firmware version information and runtime summary running in the optical module include: The status of the running firmware in the optical module is read to obtain the version code segment, build time field and summary information.

[0044] The optical module has a pre-installed firmware information block. By scheduling the status read command in the firmware management module, the core parameters in the firmware information block can be accessed. Specifically, the optical module first reads the fixed address segment of the firmware information block and extracts the 8-byte version encoding segment, the 4-byte build time field, and the 16-byte digest information.

[0045] For example, if the version code segment record value is "0x12030801", the build time field is a UNIX timestamp "0x63A5E3F0", and the digest information is "6AFD-E34C-...", then the firmware version is "V18.3.8.1", the build time is December 25, 2022, at 14:30, and the digest information is used for subsequent structural redundancy verification. In this way, key information about the currently running firmware of the optical module can be obtained completely, laying the foundation for version matching and consistency analysis during the upgrade process.

[0046] The version encoding segment is parsed in binary to obtain the major version number and minor version number. The major version number is then mapped to the build time field for time-series analysis to obtain version information.

[0047] The optical module internally calls a preset binary parsing engine to decompose the version code segment bit by bit into a high 4-bit major version number and a low 4-bit minor version number. Specifically, the major version number is used to identify the functional architecture level, and the minor version number is used to identify differential configuration parameters. Then, a time-series mapping analysis is performed between the major version number and the build time field to construct version information that includes the architecture generation and release timestamp.

[0048] For example, for the code segment "0x12030801", the major version number is "18" and the minor version number is "3.8.1". Combined with the build time field "0x63A5E3F0", the complete version information "V18_20221225_381" can be mapped. This format not only facilitates version tracing, but also provides key fields for subsequent version conflict checks.

[0049] Redundancy comparison is performed between the sub-version number and the summary information to obtain the running summary.

[0050] To ensure consistency between version information and digest information, the optical module performs hash expansion on the sub-version number to generate a standard fingerprint vector, which is then compared with the digest information using bit-level redundancy checking to determine if the digest information has shifted due to memory corruption or abnormal restarts. A comparison digest is generated for the sub-version number using a CRC64 and SHA1 combined hash algorithm. This digest is matched against the digest information using a double hash comparison mechanism. If the matching rate is higher than 90%, the digest is considered valid. Otherwise, a compensation read is initiated or an anomaly is marked.

[0051] For example, if the sub-version number "3.8.1" is expanded to generate a digest vector "E1A23F...", and it is completely consistent with the current digest information "E1A23F...", then the running digest can be confirmed to be valid, which helps to ensure the reliability and stability of the current firmware running status of the optical module.

[0052] Furthermore, the version information and runtime summary are compared and verified with the firmware version identifier and checksum. The verification results specifically include: The version information and runtime summary are extracted at the field level to obtain the current version hash value and the current configuration fingerprint. The firmware version identifier and check code are parsed to obtain the target version hash value and integrity identifier code.

[0053] The optical module parses the aforementioned version information and runtime digest field by field, and calls the hash encoding module to generate unique identifier values. Specifically, the current version hash value is generated by performing SHA-256 digest on the version information, and the current configuration fingerprint is a configuration-level fingerprint identifier obtained by performing MD5 compression on the digest information.

[0054] At the same time, the optical module performs the same SHA-256 digest calculation on the firmware version identifier extracted from the firmware upgrade request to obtain the target version hash value, and performs BASE64 reverse encoding and CRC decoding on the check code to obtain the integrity identifier code.

[0055] For example, if the current version information is "V18_20221225_381", its SHA-256 digest is "CF9A-12A3-...", and the digest information "6AFD-E34C-..." corresponds to the MD5 hash "F231-8C9B-...". Simultaneously, the firmware version identifier "V18_20231215_400" in the upgrade request generates the target version hash value "9BA2-C18F-...", and after decoding the checksum, the integrity identifier code "F231-8C9B-..." is obtained for comparison.

[0056] The current version hash value is matched with the target version hash value to obtain the version matching result. The current configuration fingerprint and integrity identifier are cross-validated to obtain the digest matching result.

[0057] The optical module first executes a hash matching function, comparing the hash value of the current version with the hash value of the target version character by character. It uses the longest common substring (LCS) matching algorithm combined with a Hamming distance threshold to determine whether they match. If the match is successful, it is marked as "version consistent"; otherwise, it is marked as "version inconsistent".

[0058] Secondly, the fingerprint and integrity identifier are configured using the MD5 sequence cross-bit XOR algorithm to perform bit-level verification on the two fingerprint values, and the error tolerance is set to no more than 5 bits.

[0059] For example, if the current version hash value matches the target version hash value in a 97.8% match rate, the version matching result is considered "passed". If the XOR result of the current configuration fingerprint "F231-8C9B" and the integrity identifier "F231-8C9B" is an all-zero sequence, the digest matching result is "completely identical".

[0060] Logical fusion analysis was performed on the version matching results and the summary matching results to obtain the verification results.

[0061] The optical module has a version consistency decision unit deployed inside. It performs logical fusion analysis on the version matching result and the digest matching result, and adopts the following judgment rule: the overall verification result is considered "successful" only when the version matching result is "passed" and the digest matching result is "completely consistent"; otherwise, it is marked as "failure".

[0062] For example, if the version matching result shows "passed" but the summary matching result shows "partial match", it is determined that there is a risk of data falsification, the upgrade conditions are not met, and the verification fails. If both are "passed", the next data loading logic is triggered, effectively improving the security and accuracy of version verification before the upgrade.

[0063] Furthermore, the real-time collection of data transmission integrity hash values ​​and communication stability indicators during the loading process specifically includes: The data stream during the loading process is collected in segments using a boundary detection mechanism to obtain segmented datasets. Segmented hash operations are then performed on the segmented datasets to obtain a hash digest sequence for each segment.

[0064] A data stream detector deployed on the optical module loading interface monitors the byte stream information in real time during the loading process and automatically segments the data according to preset segmentation boundary rules (such as fixed length, synchronization markers, etc.). Each segment is stored as an independent data block to form a segmented dataset.

[0065] For each data block, the optical module calls the hash operation engine to perform SHA-1 digest operation to form a hash digest sequence, which can reflect the original structure and integrity of the segmented dataset.

[0066] If a single loading task collects a 32KB data stream and sets a boundary threshold of 4KB, the data stream will be divided into 8 segments, each generating a hash digest "H1~H8". The corresponding hash digest sequence is {H1, H2, ..., H8}, ensuring that each data segment is not truncated, duplicated, or rearranged during transmission.

[0067] Integrity checks are performed on each data segment based on the hash digest sequence to obtain a set of valid segment identifiers. The set of valid segment identifiers and the segmented dataset are then input into a preset data stability analysis model to obtain a segment-level integrity identifier sequence.

[0068] The hash digest of each segment is compared with the standard hash template preset by the optical module to determine whether it matches the expected content. Segments that match are marked as valid segments, and a set of valid segment identifiers is generated.

[0069] Subsequently, the optical module inputs the set of valid segment identifiers and the corresponding segment dataset into the internal loading stability model. Based on rules such as inter-segment hash continuity and boundary stability, the model outputs the integrity level of each segment, forming a segment-level integrity identifier sequence.

[0070] For example, if the hash digests of segments 2 and 6 in the segmented dataset are inconsistent with the standard values, then the set of valid segment identifiers is {1,3,4,5,7,8}, and the sequence of segment-level integrity identifiers is {✓, ✗, ✓, ✓, ✓, ✗, ✓, ✓}, which is used to further determine the overall integrity risk.

[0071] The integrity hash value is obtained by aggregating and analyzing the hash digest sequence based on the segment-level integrity identifier sequence.

[0072] The optical module aggregates the hash digest values ​​corresponding to the valid segments in the segment-level integrity identifier sequence in an ordered manner, and then generates the overall integrity hash value through the SHA-256 algorithm, which serves as the integrity criterion for loading tasks.

[0073] This integrity hash value not only reflects the reliability of data transmission, but also serves as a key input parameter for subsequent comparisons.

[0074] For example, the hash digest values ​​"H1,H3,H4,H5,H7,H8" of 6 valid segments are concatenated in order to generate a complete data vector "D_full". After performing SHA-256 digest on D_full, the integrity hash value "H_complete" is obtained. This value will be used to cross-compare with the original hash value of the optical module's firmware to determine whether there is any illegal tampering or data loss.

[0075] The initial delay and jitter frequency during the loading process are calculated to obtain the signal delay distribution and frequency fluctuation curve. Based on the transmission retry counter and handshake failure counter, the transmission stability is calculated to obtain the retry rate index and failure rate index.

[0076] The optical module records the loading start time and the timestamp sequence of successful reception of each data segment. By statistically analyzing the time difference between the first data segment and subsequent segments, a signal delay distribution curve is plotted. Simultaneously, the data packet reception frequency per unit time is calculated, and a frequency fluctuation curve is plotted. Furthermore, by combining the underlying retry counter and handshake failure counter of the optical module, the retry ratio and failure rate in each loading are calculated as quantitative indicators of transmission link quality.

[0077] If 6 retries occur during a single load and 120 packets are used to complete the transmission, the retry rate is 5%. If 3 handshake failures occur and each transmission is expected to fail no more than once, the failure rate is 2.5%. These results will be marked and passed into the stability judgment logic.

[0078] The communication stability index is obtained by integrating and evaluating signal delay distribution, frequency fluctuation curve, retry rate index and failure rate index.

[0079] The optical module performs a comprehensive analysis of the above indicators using a preset stability evaluation function, and evaluates the overall communication stability of this loading process based on the time stability factor, retry tolerance, and protocol stability threshold.

[0080] Specifically, link stability is determined by calculating the standard deviation of signal delay and the maximum jitter amplitude. The final stability score is formed by normalizing and comparing the retry rate and failure rate with the historical tolerance range. Communication stability is considered to be up to standard when the stability score is higher than the set value.

[0081] For example, in a single loading operation, the standard deviation of signal delay is 1.8ms, the retry rate is 5%, the failure rate is 2.5%, and the final fusion yields a communication stability index of "87 points", which is greater than the set passing score of "80 points" and is marked as "communication stable". If it is lower than the set value, error handling or rollback operation is triggered.

[0082] Furthermore, the integrity hash value is cross-compared with the original hash value of the firmware running in the optical module, and the comparison results specifically include: The integrity hash value is segmented and parsed to obtain the intra-segment verification field and cross-segment digest fingerprint. The intra-segment verification field is matched with the basic hash segment stored in the optical module by comparison logic to obtain the position consistency score.

[0083] The optical module first performs segmented parsing on the generated integrity hash value, dividing it into multiple intra-segment verification fields and one or more cross-segment digest fingerprints. The intra-segment verification fields are used to identify the content hash status of each data segment, and the cross-segment digest fingerprints are used to describe the continuity of the overall hash structure.

[0084] Subsequently, the optical module calls the hash matching module to compare the verification field in each segment with the basic hash segment stored in the corresponding position of the original firmware in the optical module. The position consistency score is generated by the ratio of the number of successful comparisons to the total number of segments.

[0085] For example, if the integrity hash value is divided into 8 segments, the verification fields within each segment are {D1, D2, ..., D8}, and the original firmware hash segment of the optical module is {R1, R2, ..., R8}, when the comparison finds that D1D6 and R1R6 are completely consistent, while D7 and R7, and D8 and R8 are offset, the position consistency score is 75%, which is used as a reference for subsequent structural verification.

[0086] The digest fingerprint across segments is matched sequentially with the hash trace recorded during firmware runtime to obtain a digest matching score.

[0087] The optical module uses the cross-segment digest fingerprint as a dynamic matching template, calls the trajectory comparison algorithm (such as dynamic time warping DTW) to perform sequence-level fitting analysis with the firmware hash trajectory collected during operation, and obtains the digest matching score through matching distance and trend similarity.

[0088] This matching process not only considers the consistency of static values, but also introduces the tolerance capability of time dimension and location transfer, thereby improving the sensitivity and robustness of anomaly detection.

[0089] For example, if the cross-segment digest fingerprint is {F1, F2, F3, F4}, and the runtime hash trajectory is {F0, F1, F2, F3, F5}, where most of the content is similar but there is a perturbation in the order, then the matching score is 92%. If the trajectory reconstruction error is large, the matching score will drop below 65%, which is used to warn of potential integrity anomalies.

[0090] The summary matching score is weighted and fused based on the position consistency score to obtain the structure consistency score. The structure consistency score is then compared with the stable matching threshold in the historical upgrade data to obtain the comparison result.

[0091] The optical module constructs a weighted fusion function, using the location consistency score and the summary matching score as input variables. Based on empirical weights (such as 70% for location consistency and 30% for summary matching), a weighted sum is calculated to obtain the structure consistency score.

[0092] The structural consistency score is then compared with a preset stable matching threshold from historical upgrade tasks. If it is higher than the threshold (e.g., 85%), the data integrity verification for this round is considered successful, and the comparison result is returned as "successful". If it is lower than the threshold, it is marked as "failed", triggering the rollback mechanism.

[0093] For example, if the positional consistency score is 80% and the abstract matching score is 90%, then the structural consistency score is 80% × 0.7 + 90% × 0.3 = 83%. If the historically set stable matching threshold is 85%, then the result of this comparison is "failed" and the error handling process needs to be initiated.

[0094] Furthermore, a stability analysis was conducted on the communication stability indicators, and the specific results included: Multi-dimensional extraction of communication stability indicators yields average latency, retry count statistics, and handshake failure rate. Time-domain fitting of the average latency yields a stable trend curve and maximum offset.

[0095] Key performance parameters, including average latency, retry count, and handshake failure rate, are extracted from communication stability metrics to serve as the foundation for evaluating transmission quality. Subsequently, a time-domain fitting algorithm (such as sliding window linear regression) is used to perform trend analysis on the average latency data sequence, generating a stable trend curve that reflects the latency variation over time. Simultaneously, the maximum offset, i.e., the maximum deviation of the average latency from its mean, is calculated to reflect the range of transmission latency fluctuations and extreme cases.

[0096] If the average latency fluctuates around 100ms and the maximum offset is 30ms, it indicates that the communication latency fluctuates between 70ms and 130ms, providing a precise performance fluctuation range.

[0097] By comparing the retry count statistics with the stable trend curve, abnormal retry segments are obtained. By jointly analyzing the handshake failure rate and the maximum offset, protocol-level error indicators are obtained.

[0098] Time alignment and correlation analysis were performed on the retry count statistics and stable trend curves to identify time segments with significantly increased retry counts and abnormal delay trends, which were then marked as abnormal retry segments. Furthermore, a multi-index fusion model was used to assess the error probability in communication protocol execution, combining the handshake failure rate and the maximum offset index, to form a protocol-level error index.

[0099] For example, if the number of retries increases sharply and the delay trend increases within a certain period of time, and the handshake failure rate reaches 2%, then the protocol-level error index is assessed as high risk, indicating that the upgrade communication is hindered.

[0100] The reliability of abnormal retry segments and protocol-level error indicators is assessed to obtain stability level labels. These stability level labels are then input into a preset upgrade decision-maker. The upgrade decision-maker uses a preset rule engine to perform matching analysis between the stability level labels and the target upgrade state to obtain the analysis results.

[0101] Based on the frequency and duration of abnormal retry segments and the severity of protocol-level error indicators, a comprehensive stability level label, such as "high," "medium," or "low," is calculated using a reliability model. This stability level label is input into the upgrade decision-maker, which embeds a rule engine that intelligently matches the label with the target upgrade status according to a pre-defined rule base (e.g., "high stability allows upgrade," "medium stability requires manual confirmation," and "low stability requires upgrade abort"). The result is then output as an upgrade feasibility analysis.

[0102] If the stability level label is "low", the rule engine determines that the upgrade status is "not allowed", and the system will trigger the upgrade abort and error reporting process to ensure upgrade safety.

[0103] This embodiment uses the communication interface on the preset optical module to monitor firmware upgrade requests sent by external management devices in real time, and parses the data frames in the firmware upgrade requests to accurately extract the firmware version identifier and checksum, ensuring the legality and integrity of the upgrade requests. Furthermore, by reading the firmware status of the optical module in detail, the version encoding segment, build time field, and digest information are obtained. Combined with binary parsing and time-series mapping technology, version information and runtime digest are accurately constructed, achieving refined identification and verification of the firmware version. Simultaneously, the version information and runtime digest are compared with the firmware version identifier and checksum at the field level through logical fusion and comparison, ensuring accurate matching and consistency of the upgrade data.

[0104] During the loading process, a boundary detection mechanism is employed to segment and hash the data stream. Combined with a data stability analysis model, the integrity and transmission stability of each data segment are dynamically evaluated, generating integrity hash values ​​and communication stability indicators in real time to comprehensively monitor data transmission quality. The integrity hash value is segmented and multi-dimensionally matched with the original hash value of the optical module. Combining positional verification and sequence matching algorithms, a structural consistency score is calculated and compared against a benchmark threshold based on historical upgrade data to ensure data consistency and integrity.

[0105] Simultaneously, multi-dimensional extraction and time-domain fitting of communication stability indicators are performed, combined with joint analysis of abnormal retry segments and protocol-level error indicators to generate stability level labels. An upgrade decision-maker driven by a rule engine then intelligently assesses upgrade security. The overall solution achieves rigorous verification of optical module firmware upgrade requests, dynamic monitoring of data transmission, and intelligent decision-making during the upgrade process, effectively improving the security and reliability of firmware upgrades, reducing the risk of upgrade failure, and ensuring the stable operation of the optical module.

[0106] Example 3: like Figure 2As shown, this application also provides a firmware upgrade device 10 for an optical module, including a receiving module 11 for receiving a firmware upgrade request corresponding to the optical module and extracting the firmware version identifier and verification code from the firmware upgrade request. An acquiring module 12 is used to acquire the version information and running digest of the firmware running in the optical module, compare the version information and running digest with the firmware version identifier and verification code to obtain a verification result. If the verification result is inconsistent, the upgrade process is terminated; if the verification result is consistent, the upgrade data in the firmware upgrade request is loaded into the optical module. During the loading process, the integrity hash value of data transmission and communication stability indicators are collected in real time. Analysis module 13 is used to cross-compare the integrity hash value with the original hash value of the firmware running in the optical module to obtain the comparison result, perform stability analysis on the communication stability index, and obtain the analysis result. If any one of the comparison result or analysis result is abnormal, it rolls back to the initial state and reports an error. If the comparison result and analysis result are not abnormal, it performs multiple rounds of self-testing on the optical module. If the self-test result meets the preset threshold, it clears the original version data in the optical module. If the self-test result does not meet the preset threshold, it restores to the state before the upgrade.

[0107] In this embodiment, a structured optical module firmware upgrade device is formed by setting up a receiving module 11, an acquisition module 12, and an analysis module 13. The receiving module 11 is responsible for receiving firmware upgrade requests sent externally and accurately extracting the firmware version identifier and checksum to ensure the validity and security of the upgrade request. The acquisition module 12 reads the version information and runtime summary of the currently running firmware from the optical module and compares them with the version identifier and checksum in the upgrade request to achieve strict identity and version confirmation before the upgrade. The analysis module 13 collects the integrity hash value and communication stability index of data transmission in real time during the upgrade data loading process. By cross-comparing the hash value with the original hash value of the running firmware and performing multi-dimensional stability analysis on the communication stability index, it ensures the integrity of the upgrade data and the reliability of communication. If an anomaly is found, the device can roll back and report the error in a timely manner to ensure system security. If no anomaly is found, the upgrade result is verified through multiple rounds of self-checks. If successful, the old version data is cleared; if unsuccessful, the system is restored to the state before the upgrade. This device integrates upgrade request reception, data verification, real-time monitoring, and secure rollback functions, effectively improving the security and reliability of optical module firmware upgrades.

[0108] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the device and each module described above can be referred to the corresponding process in the aforementioned Embodiment 1, and will not be repeated here.

[0109] Example 4: like Figure 3As shown, this application provides an electronic device 20, including a memory 24, a processor 22, and a computer program stored on the memory 24. The processor 22 executes the computer program to implement the steps of the aforementioned method embodiments. In this embodiment, an electronic device 20 integrates a memory 24 and a processor 22, and, combined with the computer program stored in the memory 24, automates the execution of the optical module firmware upgrade method. The electronic device 20 utilizes the processor 22 to execute the computer program, completing key steps from receiving the firmware upgrade request and comparing and verifying version information with the runtime summary, to loading upgrade data and real-time acquisition and analysis of integrity and communication stability, and finally performing multiple rounds of self-checks and anomaly rollback. This solution, through the combination of hardware and software, provides a stable, efficient, and easily integrated firmware upgrade solution, suitable for the firmware upgrade needs of various optical module devices, improving the automation level of the upgrade process and the security of system operation.

[0110] In one alternative embodiment, an electronic device is provided, such as Figure 3 As shown, Figure 3 The illustrated electronic device 20 includes a processor 22 and a memory 24. The processor 22 and the memory 24 are connected, for example, via a bus 21. Optionally, the electronic device 20 may further include a transceiver 23, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 23 is not limited to one unit, and the structure of the electronic device 20 does not constitute a limitation on the embodiments of this application.

[0111] Example 5: This application also provides a computer-readable storage medium having a computer program stored thereon, which, when run by a processor, causes the processor to execute a firmware upgrade method for an optical module as described in Embodiment 1.

[0112] In this embodiment, a computer program for the optical module firmware upgrade method is stored on a computer-readable storage medium, enabling the programmatic implementation and convenient distribution of the method. The computer program stored on this medium, when run by the processor, can fully execute operations including receiving and extracting firmware upgrade requests, verifying version information and digest comparisons, loading upgrade data and collecting integrity and stability indicators, anomaly detection and security rollback, multi-round self-checks, and version data management. This implementation supports flexible deployment at the software level, facilitating rapid promotion and maintenance of system upgrades, and improving the portability and applicability of the optical module firmware upgrade solution.

[0113] The structures, proportions, sizes, etc., shown in the accompanying drawings of this specification are only for the purpose of assisting those skilled in the art in understanding and reading the content disclosed in the specification, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0114] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A firmware upgrade method for an optical module, characterized in that, include: Receive the firmware upgrade request corresponding to the optical module, and extract the firmware version identifier and verification code from the firmware upgrade request; The version information and running summary of the firmware running in the optical module are obtained. The version information and running summary are compared and verified with the firmware version identifier and the check code to obtain the verification result. If the verification result is inconsistent, the upgrade process is terminated. If the verification result is consistent, the upgrade data in the firmware upgrade request is loaded into the optical module. During the loading process, the integrity hash value of data transmission and communication stability indicators are collected in real time. The integrity hash value is cross-compared with the original hash value of the firmware running in the optical module to obtain the comparison result. The communication stability index is then analyzed to obtain the analysis result. If any of the comparison result or the analysis result is abnormal, the system is rolled back to the initial state and an error is reported. If neither the comparison result nor the analysis result is abnormal, the optical module undergoes multiple rounds of self-testing. If the self-test result meets a preset threshold, the original version data in the optical module is cleared. If the self-test result does not meet the preset threshold, the system is restored to the state before the upgrade.

2. The firmware upgrade method for an optical module according to claim 1, characterized in that, The step of receiving the firmware upgrade request corresponding to the optical module and extracting the firmware version identifier and verification code from the firmware upgrade request includes: The system listens for firmware upgrade requests sent by external management devices through a pre-defined communication interface on the optical module, and triggers the firmware upgrade process of the optical module based on the firmware upgrade request. The data frame in the firmware upgrade request is parsed to obtain the firmware version field and the integrity verification field. Field matching analysis is performed on the firmware version field to obtain the firmware version identifier. Hash decoding is performed on the integrity verification field to obtain the verification code.

3. The firmware upgrade method for an optical module according to claim 1, characterized in that, The step of obtaining the version information and running summary of the firmware running in the optical module includes: The status of the running firmware in the optical module is read to obtain the version code segment, the build time field, and the summary information. The version encoding segment is parsed in binary to obtain the major version number and the minor version number. The major version number is then used to perform time-series mapping analysis on the build time field to obtain version information. The sub-version number and the summary information are compared for redundancy to obtain the running summary.

4. The firmware upgrade method for an optical module according to claim 1, characterized in that, The step of comparing and verifying the version information with the runtime digest, the firmware version identifier, and the checksum to obtain the verification result includes: The version information and the running summary are extracted at the field level to obtain the current version hash value and the current configuration fingerprint. The firmware version identifier and the verification code are parsed to obtain the target version hash value and the integrity identifier code. The current version hash value is matched with the target version hash value to obtain a version matching result. The current configuration fingerprint is cross-validated with the integrity identifier code to obtain a digest matching result. Logical fusion analysis is performed on the version matching results and the summary matching results to obtain the verification results.

5. The firmware upgrade method for an optical module according to claim 1, characterized in that, The step of collecting the integrity hash value and communication stability indicators of data transmission in real time during the loading process includes: The data stream during the loading process is collected in segments using a boundary detection mechanism to obtain segmented datasets. Segmented hash operations are then performed on the segmented datasets to obtain a hash digest sequence for each segment. Based on the hash digest sequence, integrity checks are performed on each data segment to obtain a set of valid segment identifiers. The set of valid segment identifiers and the segmented dataset are then input into a preset data stability analysis model to obtain a segment-level integrity identifier sequence. The hash digest sequence is aggregated and analyzed based on the segment-level integrity identifier sequence to obtain the integrity hash value; The initial delay and jitter frequency during the loading process are calculated to obtain the signal delay distribution and frequency fluctuation curve. Based on the transmission retry counter and handshake failure counter, the transmission stability is calculated to obtain the retry rate index and failure rate index. The signal delay distribution, frequency fluctuation curve, retry rate index, and failure rate index are integrated and evaluated to obtain the communication stability index.

6. The firmware upgrade method for an optical module according to claim 1, characterized in that, The step of cross-comparing the integrity hash value with the original hash value of the firmware running in the optical module to obtain the comparison result includes: The integrity hash value is segmented and parsed to obtain the intra-segment verification field and cross-segment digest fingerprint. The intra-segment verification field is matched with the basic hash segment stored in the optical module by comparison logic to obtain the position consistency score. The cross-segment digest fingerprint is sequence matched with the hash trajectory recorded during firmware runtime to obtain a digest matching score; The summary matching score is weighted and fused based on the location consistency score to obtain the structure consistency score. The structure consistency score is then compared with the stable matching threshold in the historical upgrade data to obtain the comparison result.

7. The firmware upgrade method for an optical module according to claim 1, characterized in that, The step of performing stability analysis on the communication stability index and obtaining the analysis results includes: The communication stability indicators are extracted from multiple dimensions to obtain the average latency value, the retry count statistics, and the handshake failure rate. The average latency value is then fitted in the time domain to obtain the stability trend curve and the maximum offset. By comparing the retry count statistics with the stable trend curve, abnormal retry segments are obtained. By jointly analyzing the handshake failure rate and the maximum offset, a protocol-level error index is obtained. The abnormal retry segment is reliably judged against the protocol-level error index to obtain a stability level label. The stability level label is then input into a preset upgrade decision-maker for matching analysis to obtain the analysis results.

8. A firmware upgrade device for an optical module, characterized in that, include: The receiving module is used to receive the firmware upgrade request corresponding to the optical module and extract the firmware version identifier and verification code from the firmware upgrade request. The acquisition module is used to acquire the version information and running summary of the firmware running in the optical module, compare and verify the version information and running summary with the firmware version identifier and the check code, and obtain the verification result. If the verification result is inconsistent, the upgrade process is terminated. If the verification result is consistent, the upgrade data in the firmware upgrade request is loaded into the optical module. During the loading process, the integrity hash value of data transmission and communication stability indicators are collected in real time. The analysis module is used to cross-compare the integrity hash value with the original hash value of the firmware running in the optical module to obtain the comparison result, perform stability analysis on the communication stability index, and obtain the analysis result. If any one of the comparison result or the analysis result is abnormal, the system rolls back to the initial state and reports an error. If neither the comparison result nor the analysis result is abnormal, the system performs multiple rounds of self-testing on the optical module. If the self-test result meets a preset threshold, the system clears the original version data in the optical module. If the self-test result does not meet the preset threshold, the system restores the system to the state before the upgrade.

9. An electronic device, characterized in that, The device includes a memory and a processor, the memory storing a computer program that can run on the processor, and the processor executing the computer program to implement the firmware upgrade method for the optical module according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when run by a processor, causes the processor to perform the firmware upgrade method for the optical module as described in any one of claims 1 to 7.

Images