Serial port equipment firmware upgrading method and system

Abstract

The invention relates to the technical field of communication equipment operation and maintenance, in particular to a serial port equipment firmware upgrading method and system. The serial port equipment firmware upgrading method comprises the steps that an upgrading task instruction issued by a remote management platform is received, and after equipment identity verification and upgrading file integrity verification are executed, system protection measures are started; creating a security isolation sandbox environment, forbidding a high-risk function module in a script execution environment, and defining addressing parameters of target serial port equipment; standard scripts are loaded, and serial port read-write, file operation and state reporting type security interaction interfaces are injected; calling a mode switching function of the standardized script, so that the serial port equipment is switched to a firmware upgrading mode from an operation mode; cyclically calling a data transmission function of the standardized script to transmit firmware data in blocks, and synchronously implementing timeout monitoring; and after upgrading is completed or abnormal interruption occurs, the security isolation sandbox environment is destroyed, the original business is recovered, and an upgrading result is reported to the remote management platform.

Description

Technical Field

[0001] This disclosure relates to the field of communication equipment operation and maintenance technology, and in particular to a method and system for firmware upgrade of serial port devices. Background Technology

[0002] With the development of IoT and industrial monitoring technologies, a large number of heterogeneous serial port devices (such as switching power supplies and air conditioners in base station environmental monitoring) have been widely deployed, making remote firmware upgrades a key requirement for device lifecycle management. Currently, the mainstream upgrade methods rely on manual on-site operation or vendor-owned platforms. Manual upgrades require on-site wiring by technicians, resulting in low efficiency, high maintenance costs, and significant susceptibility to personnel skill levels. Vendor-owned platforms, due to their closed protocols, cannot achieve unified management, creating management blind spots and failing to meet the needs of large-scale maintenance.

[0003] Existing related patent solutions have limitations in application scenarios: Chinese patent document CN120835294A discloses a remote FOTA secure upgrade method for terminal devices, which uses sub-upgrade package combination and encryption mechanisms to improve efficiency and security, but it focuses on terminal devices that support FOTA and is not adapted to the "one master, multiple slaves" networking characteristics of serial ports, nor is it compatible with multiple vendors' proprietary upgrade protocols; Chinese patent document CN120880496B discloses an upgrade method based on HPLC power line carrier networks, which optimizes reliability through dynamic fragmentation and multi-path transmission, but it depends on the HPLC network environment and is not suitable for serial communication scenarios, and it does not involve unified scheduling of scripts from multiple vendors; Chinese patent document CN120994224A discloses a remote firmware upgrade method for FPGAs, which ensures stability through packet transmission and rollback mechanisms, but it is only for FPGA chips, has poor versatility, and cannot be adapted to ordinary heterogeneous serial port devices; Chinese patent document CN120880906A... The method for upgrading roadside equipment under the vehicle-road-cloud architecture was disclosed. The low-load upgrade window was selected through model prediction, but the core focus was on optimizing the upgrade timing. The issues of serial port device addressing interference and multi-vendor protocol compatibility were not resolved.

[0004] These current conditions make it difficult for existing solutions to meet the upgrade requirements of serial port devices in terms of scale, standardization, and security. There is an urgent need for a remote upgrade solution that can be compatible with multiple vendors' proprietary protocols, ensure the security of execution units, and adapt to the characteristics of serial port networking, in order to solve technical pain points such as poor protocol compatibility, high operation and maintenance costs, and uncontrollable upgrade process. Summary of the Invention

[0005] This disclosure provides a method and system for firmware upgrade of serial port devices.

[0006] According to one aspect of this disclosure, a method for firmware upgrade of a serial port device is provided, comprising: receiving an upgrade task instruction issued by a remote management platform, parsing and obtaining key parameters, performing device identity verification and upgrade file integrity verification, and activating system protection measures after successful verification; creating a secure isolation sandbox environment, disabling high-risk function modules in the script execution environment, and specifying the addressing parameters of the target serial port device; loading a standardized script developed by the device manufacturer according to a preset interface specification, and injecting secure interactive interfaces for serial port read / write, file operation, and status reporting; calling the mode switching function of the standardized script to switch the serial port device from the running mode to the firmware upgrade mode; repeatedly calling the data transmission function of the standardized script to transmit firmware data in blocks, and simultaneously implementing timeout monitoring based on the upgrade file size and communication transmission rate; after the upgrade is completed or abnormally interrupted, destroying the secure isolation sandbox environment, restoring the original system services, and reporting the upgrade result to the remote management platform.

[0007] Based on one aspect of the technical solution, by integrating the entire process design including verification protection, security sandbox isolation, standardized script adaptation, dynamic timeout monitoring and service recovery, it is possible to achieve remote unified upgrades of heterogeneous serial port devices from multiple vendors, taking into account upgrade security, compatibility and reliability, and significantly reducing operation and maintenance costs and equipment failure risks.

[0008] According to at least one embodiment of the upgrade method of this disclosure, the device identity verification is to compare the unit identifier and device identifier in the instruction with the stored operation and maintenance identifier and management device list to confirm that it is the target execution unit and that the specified serial port device exists; the upgrade file integrity verification is to calculate the checksum of the downloaded standardized script and firmware data and compare it with the verification information in the instruction.

[0009] According to the technical solution of this embodiment, the legitimacy of the upgrade execution entity and the target device can be accurately confirmed, avoiding accidental upgrades, while ensuring that the upgrade files have not been tampered with, thus guaranteeing the reliability of the upgrade foundation.

[0010] According to the upgrade method of at least one embodiment of this disclosure, the system protection measures include suspending the regular data acquisition service of the target serial port device, suspending its own multi-level restart mechanism, and preventing its own configuration parameter change operations.

[0011] According to the technical solution of this embodiment, the interference between regular business and upgrade operations during the upgrade process can be avoided, the upgrade can be prevented from being interrupted due to system restart or configuration change, and the upgrade environment can be ensured to be stable.

[0012] According to at least one embodiment of the upgrade method of this disclosure, the high-risk function module includes file operation class, system call class, debugging class and package management class module; the addressing parameter is the address information of the target serial port device, used to accurately locate the target device.

[0013] According to the technical solution of this embodiment, illegal access of scripts to system resources can be blocked from the source, ensuring the security of the execution unit itself, while achieving accurate addressing of the target device and avoiding addressing deviation.

[0014] According to at least one embodiment of the upgrade method of this disclosure, the secure interaction interface includes a serial port data read / write interface, a firmware file operation interface, a millisecond-level latency interface, and an upgrade status reporting interface, and is the only channel for standardized scripts to interact with external devices and their own resources.

[0015] According to the technical solution of this embodiment, a safe and controllable interaction path can be provided for the script, which can not only meet the functions required for upgrade, but also avoid the script from abusing resources, and realize full control of the interaction process.

[0016] According to at least one embodiment of the upgrade method disclosed herein, the preset interface specification is a unified function call specification, including initialization function, pre-verification function, mode switching function, data transmission function, upgrade execution function, abnormal termination function, and resource cleanup function, which can be adapted by the device manufacturer without modifying the underlying device protocol.

[0017] According to the technical solution of this embodiment, it is possible to unify the script development standards of multiple vendors, reduce the adaptation costs of vendors, achieve "one-time development, multi-device compatibility", and improve the universality of upgrade solutions.

[0018] According to at least one embodiment of the upgrade method of this disclosure, the standardized script is a Lua script; the secure isolation sandbox environment is built by starting a Lua virtual machine; the loading form of the standardized script includes source code or pre-compiled bytecode, with the pre-compiled bytecode form used to protect the vendor's source code and improve loading speed.

[0019] According to the technical solution of this embodiment, the lightweight and easily embedded characteristics of Lua scripts can be used to adapt to the resource constraints of execution units. The bytecode format protects the intellectual property rights of manufacturers, optimizes loading efficiency, and balances practicality and security.

[0020] According to at least one embodiment of the upgrade method of this disclosure, the timeout monitoring threshold includes a total timeout threshold and a progress timeout threshold; the total timeout threshold is calculated based on the total number of bytes in the upgrade package, the baseline time consumption per unit of data, and a preset timeout margin coefficient; the progress timeout threshold is calculated based on the unit progress update time consumption and the maximum retransmission failure time consumption; the baseline time consumption per unit of data is determined in combination with the communication transmission rate and the device processing performance.

[0021] According to the technical solution of this embodiment, it can dynamically adapt to upgrade packages of different sizes and communication scenarios, avoid timeout misjudgment or failure to interrupt in time caused by fixed thresholds, and improve the accuracy of timeout monitoring.

[0022] According to the upgrade method of at least one embodiment of the present disclosure, the formula for calculating the total timeout threshold is: Total timeout threshold = (Total number of bytes in the upgrade package / 1024) × Base time per unit of data × (1 + Total timeout margin coefficient); The total timeout margin coefficient is 0.5; The base time per unit of data includes the serial port write time and the device processing response time, and is calculated based on the baud rate of the serial communication interface.

[0023] According to the technical solution of this embodiment, the total timeout calculation logic can be quantified, ensuring the standardization and accuracy of threshold calculation, and providing a unified timeout judgment basis for different baud rates and different sizes of upgrade packages.

[0024] According to at least one embodiment of the upgrade method of this disclosure, the block transmission of firmware data includes: if a single transmission fails, a standardized script executes retransmission control, with a maximum retransmission count of not less than 3 times, and the process is terminated after the maximum retransmission count is reached; if the total upgrade time exceeds the total timeout threshold or the progress update time exceeds the progress timeout threshold, the transmission is immediately interrupted, and the abnormal termination function of the standardized script is called to perform an emergency termination operation.

[0025] According to the technical solution of this embodiment, the impact of a single transmission failure can be reduced through a retransmission mechanism, and the device can be prevented from being in an abnormal upgrade state for a long time through timeout interruption, thereby reducing the risk of the device becoming "bricked".

[0026] According to at least one embodiment of the upgrade method of this disclosure, the restoration of the original system services includes restoring the data acquisition function of the target serial port device, restoring its own multi-level restart mechanism, and allowing its own configuration parameter change operations. The restoration operation is triggered after the security isolation sandbox environment is destroyed.

[0027] According to the technical solution of this embodiment, the normal operation of the execution unit and serial port device can be quickly restored after the upgrade is completed, shortening the service interruption time and reducing the impact on the normal operation of the equipment.

[0028] According to at least one embodiment of the upgrade method of this disclosure, the method further includes downloading standardized scripts and firmware data to local storage after parsing and obtaining key parameters and before performing device identity verification.

[0029] According to the technical solution of this embodiment, the files required for the upgrade can be prepared in advance, avoiding file download failures due to network fluctuations during the upgrade process and ensuring the continuity of the upgrade process.

[0030] According to at least one embodiment of the upgrade method of this disclosure, the method further includes, during the process of executing the data transmission function of the standardized script in a loop to transmit firmware data in blocks and simultaneously implementing the timeout monitoring step based on the upgrade file size and communication transmission rate, obtaining upgrade status information in real time after each call to the data transmission function and before the next call to the output transmission function, the upgrade status information including device operating mode, upgrade progress and upgrade status.

[0031] According to the technical solution of this embodiment, the upgrade dynamics can be monitored in real time, and problems such as abnormal mode switching and progress stagnation can be detected in a timely manner, providing data support for subsequent anomaly handling.

[0032] According to at least one embodiment of the upgrade method of this disclosure, the method further includes, before the standardized script developed by the loading device manufacturer according to the preset interface specification is injected into the serial port read / write, file operation, and status reporting security interaction interface, after downloading the standardized script and before loading the standardized script, performing a format verification on the downloaded standardized script to confirm that it conforms to the preset interface specification.

[0033] According to the technical solution of this embodiment, script format errors can be detected in advance, avoiding interruption of the upgrade process due to non-compliance with script specifications, and improving the reliability of the upgrade preparation stage.

[0034] According to at least one embodiment of the upgrade method of this disclosure, the method further includes performing a functional self-test on the upgraded serial port device after the destruction of the security isolation sandbox environment and before reporting the upgrade result, verifying that key functional modules such as the communication link and firmware operation status are normal before reporting the result.

[0035] According to the technical solution of this embodiment, it is possible to confirm that the equipment is operating normally before reporting the upgrade results, avoid false reports of successful upgrades, and improve the accuracy of upgrade results and the reliability of equipment operation.

[0036] According to at least one embodiment of the upgrade method of this disclosure, the addressing parameters of the target serial port device include addressing and interference avoidance strategies in multi-device connection scenarios: if serial port resources are sufficient, a "one master, one slave" independent wiring method is adopted to achieve accurate addressing of the target device; if multiple devices need to be connected to the same serial port, a mixed access method of devices from different manufacturers or types is adopted to reduce bus communication interference, so that the upgrade command accurately points to the target device.

[0037] The technical solution of this implementation method can adapt to complex networking scenarios such as "one master and multiple slaves", reduce communication interference between devices, ensure accurate transmission of upgrade commands, and improve the success rate of upgrades in complex environments.

[0038] According to at least one embodiment of the upgrade method of this disclosure, the upgrade strategy supported by the standardized script includes full upgrade and differential upgrade; during the full upgrade, the complete firmware file is read and transmitted through the file operation interface; during the differential upgrade, the standardized script parses the differential packets and synthesizes them into data blocks before transmission; the upgrade strategy is confirmed by the standardized script after loading the standardized script and before calling the mode switching function.

[0039] According to the technical solution of this embodiment, it can flexibly adapt to different upgrade requirements. Differential upgrade can reduce the amount of data transmission and shorten the upgrade time, while full upgrade can ensure firmware integrity and improve the flexibility and adaptability of the solution.

[0040] According to another aspect of this disclosure, a serial port device firmware upgrade apparatus is provided, including a remote management platform, a field monitoring unit, and at least one serial port device; the remote management platform is used to issue upgrade task instructions, query upgrade status, and receive upgrade results; the field monitoring unit is connected to the serial port device through a serial communication interface and to the remote management platform through a communication network; the field monitoring unit is configured to execute the serial port device firmware upgrade method according to any embodiment of this disclosure; the serial port device is a heterogeneous terminal device connected to the field monitoring unit. Attached Figure Description

[0041] The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0042] Figure 1 This is a schematic diagram of the overall process of a serial port device firmware upgrade method according to one embodiment of the present disclosure.

[0043] Figure 2 This is a flowchart of a white-box FSU upgrade A interface device firmware program according to one embodiment of the present disclosure.

[0044] Figure 3 This is a diagram illustrating the overall firmware architecture of a white-box FSU upgrade A-interface device according to one embodiment of the present disclosure. Detailed Implementation

[0045] The present disclosure will now be described in further detail with reference to the accompanying drawings and examples. It should be understood that the specific examples described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.

[0046] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0047] In practical application scenarios such as base station environmental monitoring and industrial IoT, serial port devices (such as switching power supplies, air conditioners, and sensors) are often deployed in a "one master, multiple slaves" network using field monitoring units (FSUs). These devices are dispersed and involve heterogeneous models from multiple manufacturers, presenting a series of scenario-based technical challenges for firmware upgrades: Multi-vendor proprietary protocol compatibility challenges: Serial port devices from different vendors use proprietary upgrade protocols and instruction sequences, and there is no unified standard for upgrade logic. As a unified operation and maintenance entry point, FSU cannot directly adapt to the proprietary upgrade processes of various devices, which means that upgrade tasks need to rely on vendor-specific tools, making it difficult to achieve batch scheduling and centralized management, resulting in high operation and maintenance costs.

[0048] Addressing and interference risks in "one master and multiple slaves" networking: When multiple devices are connected to the same serial bus, upgrade commands and data transmission can easily interfere with other normal devices. In addition, some manufacturers' proprietary upgrade protocols do not support addressing, resulting in low accuracy in locating the target device and a high upgrade failure rate.

[0049] FSU system security is lacking: Upgrade logic (such as scripts and programs) provided by vendors may contain high-risk operations. Direct execution can easily lead to unauthorized access to FSU system resources, causing system crashes or data leaks, and threatening the stability of the entire network.

[0050] The timeout monitoring has insufficient adaptability to different scenarios: the size of the upgrade package (from a few KB to hundreds of KB) and the serial communication rate (such as 9600bps to 115200bps) vary greatly. Fixed timeout thresholds are prone to "small packet misjudgment interruption" or "large packet timeout without response", resulting in poor adaptability.

[0051] Conflicts between upgrades and regular business operations: If the FSU continues to collect data from the target device during the upgrade process, or if it restarts or changes its configuration, it will compete for resources with the upgrade operation, causing the upgrade to be interrupted. Furthermore, failure to restore business operations in a timely manner after the upgrade will create monitoring blind spots.

[0052] To address these issues, this disclosure proposes the following technical solution. This solution employs a comprehensive process design encompassing "verification protection → security isolation → standardized adaptation → precise addressing → chunked transmission and dynamic timeout monitoring → service recovery" to specifically resolve the aforementioned scenario-specific problems. Specifically, a unified preset interface specification allows devices from multiple vendors to adapt without modifying the underlying protocol; a security sandbox disables high-risk functions to ensure FSU system security; explicit addressing parameters avoid "one master, multiple slaves" interference; dynamic timeout monitoring based on upgrade file size and communication rate improves adaptability; and service start / stop mechanisms before and after upgrades prevent conflicts. Ultimately, this achieves remote, batch, secure, and efficient firmware upgrades for serial port devices, significantly reducing maintenance costs and failure risks.

[0053] Figure 1 A schematic diagram illustrating the overall flow of a serial port device firmware upgrade method according to one embodiment of this disclosure is shown. Figure 1 The method shown includes steps S110 to S160.

[0054] In step S110, the system receives the upgrade task instruction issued by the remote management platform, parses and obtains key parameters, performs device identity verification and upgrade file integrity verification, and activates system protection measures after the verification is successful.

[0055] like Figure 2 The flowchart shown is a detailed process for upgrading the firmware of a white-box FSU device with an A interface. The specific workflow in step S110 is as follows: Receiving and parsing upgrade task instructions: The FSU's communication module receives upgrade task instructions from the OMC platform (e.g., an MQTT message with the message name SET_DEVICE_FIRMWARE_UPGRADE). The FSU parses this structured message to obtain key parameters, including: task ID, device ID to be upgraded, current and target firmware versions, storage paths of Lua package files and firmware data packages, and checksums.

[0056] The scripting language is not limited to Lua; other scripting engines with similar characteristics, such as Python or JavaScript, can also be used. FSU provides the corresponding language virtual machine and secure isolation environment, and injects appropriate secure API functions for serial port and file operations.

[0057] Local pre-verification and system protection measures activated: The FSU's task processing thread parses the received upgrade task instructions and immediately performs multi-level local checks to ensure the legality and accuracy of the task, specifically including: Device identity verification: The FSU compares the FSUID and DeviceID in the command with its own stored operation and maintenance ID and the list of devices managed locally to confirm that this FSU is the target execution unit and that the specified device exists. If the verification fails, the process is terminated and an error is reported.

[0058] File Download and Integrity Verification: After successful verification, FSU downloads the specified Lua upgrade package and firmware data package files to local storage, calculates the checksum, and compares it to ensure file integrity. If verification fails, the process terminates and an error is reported.

[0059] Only after all the above checks pass will the FSU perform the following system protection operations before proceeding with the upgrade: Suspend data collection: Suspend routine data collection from the target device to avoid data collection and upgrade instructions interfering with each other during the upgrade process.

[0060] Pause-restart mechanism: Pause the system restart action caused by the "triple restart" of the system to prevent the upgrade from failing due to system restart during the upgrade process.

[0061] Prevent configuration changes: Prevent configuration changes to the FSU (such as protocol library upgrades or device parameter modifications) to ensure a stable upgrade environment.

[0062] If any verification fails, the FSU will immediately terminate the task and send an alert to the OMC platform. Only after the verification passes and the system protection measures take effect will the upgrade process continue with subsequent steps.

[0063] In step S120, a secure isolation sandbox environment is created, high-risk function modules in the script execution environment are disabled, and the addressing parameters of the target serial port device are specified.

[0064] like Figure 2 As shown, the specific workflow in step S120 is as follows: Initialize the Lua security sandbox environment and explicitly define addressing constraints: FSU starts its embedded Lua virtual machine and creates a secure sandbox execution environment. This is a critical security step; in this environment, FSU disables access permissions for high-risk function modules in the Lua standard library, such as io, os, debug, and package, to prevent scripts from executing unauthorized operations and to ensure the security of the FSU system itself.

[0065] Meanwhile, FSU uses the target device address (addr) parsed from the OMC instruction as a key parameter, accurately passing it in when calling the init function of the Lua script. This design aims to solve the device addressing problem in a "one master, multiple slaves" scenario. For operational communication (such as data acquisition based on standard protocols like CETC and Modbus), the FSU and equipment manufacturer scripts can use this address for precise communication, avoiding interference.

[0066] For upgrade-state communication (switch commands, firmware data transmission), the protocol is proprietary to the device manufacturer, and there is a possibility that addressing may not be used (e.g., broadcast mode or a specific trigger command sequence may be used). In such cases, the upgrade data stream may interfere with other devices on the same bus, or the communication of other devices may interrupt the upgrade process. Refer to the embodiments section for details on this scenario.

[0067] In step S130, a standardized script developed by the device manufacturer according to a preset interface specification is loaded, and security interaction interfaces such as serial port read / write, file operation, and status reporting are injected.

[0068] like Figure 2 As shown, the specific workflow in step S130 is as follows: Loading scripts and injecting APIs: The FSU loads the Lua upgrade package source code downloaded in step S202 into the secure sandbox environment created in step S203. As an optimized implementation, the Lua source code can also be pre-compiled into bytecode, which the FSU directly loads and executes. This approach can protect the vendor's source code to some extent and speed up the loading process. Subsequently, the FSU injects a series of its own implemented secure API functions into the Lua environment for Lua scripts to call. These APIs are the sole channel for Lua scripts to interact with FSU resources and external devices, and mainly include the following functions: 1. read_uart(timeout): Reads data from the serial port of the connected device.

[0069] 2. write_uart(buffer, len): Writes data to the serial port of the connected device.

[0070] 3. fopen(filename): Opens the firmware data file that has been downloaded to the local machine in read-only binary mode.

[0071] 4. file:read(len), file:seek(), file:ftell(), file:close(): Perform safe operations such as reading, locating, querying position, and closing an open file handle.

[0072] 5. milli_sleep(ms): Implements millisecond-level delay.

[0073] 6. report_signals(in_str): Sends the telemetry signals that the script wants to report to the FSU.

[0074] Execute the initialization function: The FSU calls the vendor-implemented `init(in_str)` function in the Lua script, assembling parameters parsed from the OMC instructions (such as device address, file list, and version number) into a JSON-formatted string and passing it to the function. This step is intended to initialize the vendor script's internal state.

[0075] Execute the pre-verification function: The FSU calls the check() function in the Lua script. Within this function, the manufacturer pre-interacts with the target device by calling APIs such as write_uart and read_uart injected by the FSU to verify whether the device is eligible for upgrades.

[0076] In step S140, the mode switching function of the standardized script is called to switch the serial port device from the running mode to the firmware upgrade mode.

[0077] like Figure 2 As shown, the specific workflow in step S140 is as follows: Execution mode switching function: The FSU calls the `set_mode(FLASH_MODE)` function in the Lua script. Within this function, the manufacturer sends a sequence of proprietary commands to the device by calling `write_uart`, switching it from normal operation mode to firmware upgrade mode.

[0078] In step S150, the data transmission function of the standardized script is called repeatedly to transmit firmware data in blocks, and timeout monitoring based on the upgrade file size and communication transmission rate is implemented simultaneously.

[0079] like Figure 2 As shown, the specific workflow in step S150 is as follows: Looping data transmission and scheduling: The FSU enters a transfer loop, continuously calling the `transfer(block_index)` function in the Lua script. This function, implemented by the device manufacturer, is used to complete single data block transfers, and the FSU is responsible for loop scheduling and process management based on the return value.

[0080] Each time the transfer(block_index) function is called, the following process is executed: a. Data Acquisition: Based on the block index, read data from independent files via the file operation API injected by FSU, or parse data directly from variables embedded in Lua scripts.

[0081] b. Data transmission and verification: Call write_uart to send data according to the device's private protocol, and read the response frame through read_uart to verify whether the transmission was successful.

[0082] c. Retransmission control: If the transmission fails, retransmission is performed within the script, and the process terminates after the maximum number of retries is reached.

[0083] d. Return value: The function returns three values: a boolean flag indicating whether to continue transmission, an error message string, and the index of the next block.

[0084] FSU scheduling logic: If continue_transfer returns true, then update block_index to the returned next_block and continue the loop.

[0085] If continue_transfer returns false, the loop exits immediately, and the transfer result (success / failure and error information) is recorded.

[0086] Upgrade the timeout monitoring mechanism: FSU initiates a separate timeout monitoring task throughout the upgrade process. The timeout threshold is dynamically calculated based on the total amount of firmware data in this upgrade using a validated theoretical model to ensure its reasonableness.

[0087] 1. The formula for calculating the total timeout threshold is as follows: Total timeout threshold (seconds) = (Total bytes of upgrade package / 1024) * Baseline time per KB * (1 + Total timeout margin coefficient); Total size of the upgrade package: Total bytes of the program package + firmware package.

[0088] Baseline time per KB: This value is a core parameter based on baud rate and typical device response performance. For a 9600 baud rate (8-N-1 format), the calculation is based on the following: Serial port write time: Transmitting 1 byte actually requires 10 bits. Therefore, the theoretical time to send 1KB (1024 bytes) of data is ≈ (1024 * 10) / 9600 ≈ 1.067 seconds.

[0089] Device processing and serial port read time: Considering the time required for the device to process each frame of data and generate a response, as well as the time for the FSU to read the serial port response, an empirical time of 1 second is allocated for each 1KB of data written.

[0090] Total: Therefore, the baseline time per KB = 1.067 seconds (write) + 1 second (processing and reading) = 2.067 seconds.

[0091] Margin coefficient: To account for uncertainties such as data verification time and data retransmission, a safety margin of 50% is set (i.e., margin coefficient = 0.5).

[0092] Calculation example: If the total firmware size is 100 KB (102,400 bytes): Total timeout threshold = (102,400 / 1024) * 2.067 * (1 + 0.5) = 100 * 2.067 * 1.5 = 310.05 seconds; 2. Progress timeout threshold (seconds) Progress timeout threshold (seconds) = (time required for a normal progress update of 1% + time required for failure after exceeding the maximum number of retransmissions) × (1 + margin coefficient); The time required for a normal 1% update progress is: (Total bytes of the upgrade package / 1024) × Baseline time per KB × 0.01; Time taken for a failure to complete after exceeding the maximum number of retransmissions: Maximum number of retransmissions × read / write timeout; Balance factor = 0.5 Calculation example: If the total firmware size is 100 KB (102,400 bytes): Normal progress update 1% time = (102,400 / 1024) × 2.067 * 0.01 = 2.067 seconds; Maximum retransmission failure time = 5 (times) × 5 (seconds / time) = 25 seconds; Progress timeout threshold = (2.067 + 25) * 1.5 ≈ 40.6 seconds.

[0093] The FSU dynamically calculates the total timeout threshold for this upgrade task based on this formula. If the actual total time taken for the upgrade process exceeds this threshold or the progress update time exceeds the progress timeout threshold, the FSU immediately interrupts the current upgrade process and calls the `abort_upgrade()` function in the Lua script. The vendor should perform necessary emergency termination operations in this function.

[0094] Regardless of whether the abort_upgrade() call succeeds or fails, FSU will continue to execute the standard cleanup process: calling the finalize() function to clean up resources and finally reporting the upgrade failure result.

[0095] Get upgrade status: After each successful call to key interface functions such as transfer and upgrade, the FSU calls the script's get_status() function to obtain and update the following device status information: device_mode: Device operating mode (running state / upgrade state); upgrade_status: Upgrade status (not started / in progress / completed / failed); progress: Upgrade progress (0-100%) By obtaining the upgrade status, the FSU monitors the upgrade health in real time, providing a basis for status reporting and timeout determination. This call will continue throughout the entire upgrade process.

[0096] The OMC platform can obtain the current upgrade status and progress during the upgrade process by sending a query (an MQTT message named GET_DEVICE_FIRMWARE_UPGRADE_STATUS).

[0097] Issue upgrade command and confirm: The FSU calls the `upgrade()` function in the Lua script. Within this function, the manufacturer sends the final upgrade execution command (such as a command to burn Flash memory) to the device via serial port and reads the device's response. This process may require waiting for the device to restart.

[0098] In step S160, after the upgrade is completed or abnormally interrupted, the security isolation sandbox environment is destroyed, the original system services are restored, and the upgrade results are reported to the remote management platform.

[0099] like Figure 2 As shown, the specific workflow in step S160 is as follows: Resource cleanup and system recovery: Regardless of the success or failure of the preceding steps, the FSU will call the `finalize()` function in the Lua script. Within this function, the manufacturer performs necessary final operations, such as ensuring the device mode switches back to NORMAL_MODE and is ready for the next upgrade. Afterward, the FSU is responsible for performing resource cleanup and serial port service recovery. 1. Destroy the Lua sandbox environment and all memory resources it occupies.

[0100] 2. Restore the normal data acquisition function of the serial port.

[0101] 3. Restore the "triple restart" mechanism to ensure the long-term stable operation of the FSU.

[0102] 4. Allow configuration changes and remove the block on device configuration changes during the upgrade process.

[0103] Report the final results: FSU generates an upgrade result reporting message (an MQTT message named SEND_DEVICE_FIRMWARE_UPGRADE_RESULT) and sends the final result of this execution (success / failure code, progress, error description, etc.) back to the OMC platform, thus completing the entire FSU-based execution process.

[0104] This disclosure aims to provide a method for upgrading the firmware of A-interface devices via FSU to solve the aforementioned problems in the prior art, enabling unified management of various device manufacturers, device types, and firmware versions on the existing network on a unified OMC management platform, reducing the upgrade time for a single device from 1 day / device to hours, significantly reducing operation and maintenance costs, and improving operation and maintenance efficiency and quality.

[0105] like Figure 3 The diagram shown illustrates the overall architecture of a white-box FSU for upgrading the firmware of an A-interface device according to one embodiment of this disclosure. This architecture clearly defines the interaction boundaries of each module: the unified OMC platform acts as the control layer, responsible for issuing upgrade tasks and receiving results; the white-box FSU acts as the execution layer, providing a secure operating environment and API support for vendor-standardized scripts through its built-in firmware upgrade execution module and white-box SDK; and various A-interface devices act as the terminal layer, receiving upgrade commands and firmware data via serial ports to complete the upgrade operation. This architecture intuitively illustrates the core design principle of "separation of control and execution, and decoupling of general capabilities from private logic," providing an architectural reference for understanding subsequent specific processes.

[0106] The core of this disclosure lies in proposing a firmware upgrade method and system based on sandbox isolation and standardized interfaces, aiming to solve the technical challenge of unified remote upgrades for devices from multiple vendors. Specifically, this disclosure provides a method for performing firmware upgrades on A-interface devices on a Field Monitoring Unit (FSU). The execution entity of the method is the FSU, and its core concept is to decouple the general platform scheduling capabilities from the device's proprietary upgrade logic. Specifically, the FSU loads and executes a Lua script upgrade package developed by the device manufacturer according to a predetermined interface specification, and provides it with a reliable and secure execution environment and a series of necessary injected function APIs, thereby driving the A-interface device connected to its serial port to complete the entire firmware upgrade process.

[0107] The specific applications of the technical solution disclosed herein may include the following: Example 1: Engineering Implementation Recommendations for a "One Master, Multiple Slaves" Scenario Optimal: When FSU serial port resources are sufficient, it is strongly recommended to use a "one master, one slave" wiring method to upgrade the equipment, fundamentally physically isolating interference.

[0108] Second best option: If serial port resources are scarce, priority should be given to ensuring that important equipment such as switching power supplies and precision metering equipment are connected using a "one master, one slave" configuration.

[0109] Compatibility: If multiple devices must be connected to the same serial port, it is recommended to mix devices from different manufacturers or of different types to reduce the probability of conflicts between their proprietary upgrade protocols. At the same time, device manufacturers should fully consider bus compatibility in their proprietary protocol design.

[0110] Example 2: This method supports full upgrade mode. The BinFiles array issued by the OMC platform contains a complete firmware data file (such as full_firmware.bin). The transfer function implemented by the device manufacturer reads this file by calling APIs such as fopen and file:read, and sends the data to the device in chunks via write_uart.

[0111] Example 3: This method also supports differential upgrade mode. The BinFiles array issued by the OMC platform contains a differential packet file (such as delta_patch.bin). The device manufacturer implements the differential algorithm in the transfer function, reads the differential packet data, synthesizes a new data block in the script, and then sends the synthesized data through write_uart, thereby significantly reducing the amount of data transmission.

[0112] Example 4: Upgrade Timeout and Abnormal Interruption Handling Process This example illustrates the handling process of this disclosure when encountering an anomaly. Suppose that during the data transmission in step S208, multiple retransmissions fail due to signal interference, triggering the progress timeout threshold (e.g., 40.6 seconds) mentioned in step S208-1.

[0113] The FSU immediately interrupts the transmission loop and calls the `abort_upgrade()` function in the Lua script. Within this function, the manufacturer implements a proprietary command to send a "terminate upgrade" message to the device.

[0114] Subsequently, the FSU continues to execute the standard cleanup process, calling the finalize() function in the vendor script to attempt to restore the device to the running state (NORMAL_MODE).

[0115] Finally, the FSU performs resource cleanup and system recovery (step S211) and reports the final result (step S212) to the OMC platform. The result error message is (device upgrade timeout interruption).

[0116] Through the verification of the above specific applications, this disclosure brings the following technical effects: 1. It has achieved unified and standardized management of firmware upgrades for A-interface devices from multiple manufacturers and models, solving the problems of "data silos" and compatibility.

[0117] Causal reasoning: Because this disclosure innovatively defines a set of device-independent standardized Lua script interface specifications and designs FSU as a unified execution engine, different equipment manufacturers only need to develop their own upgrade scripts according to this specification to access the unified tower platform. This fundamentally solves the problem of incompatibility between manufacturers' proprietary upgrade protocols and the inability to manage them uniformly on a single platform, achieving true platform-based and standardized upgrade management.

[0118] 2. It greatly improves upgrade efficiency and automation level, and significantly reduces operation and maintenance costs and human operation risks.

[0119] Causal reasoning: Because this disclosure achieves end-to-end remote automation from task issuance on the OMC platform to automatic execution by the FSU, and provides complete timeout monitoring, status reporting, and exception handling mechanisms, it completely avoids frequent on-site operations by technical personnel. This not only improves upgrade efficiency from the "man-day" level to the "hour" level, but also greatly saves travel and labor costs, and avoids the risk of errors introduced by the uneven skill levels of human operators.

[0120] 3. While achieving the required functions, the high level of security and reliability of the FSU main system was ensured.

[0121] Causal reasoning: Because this disclosure adopts Lua sandbox security isolation technology, which strictly limits the resources that the script can access (it can only read through the injected security API, serial port and firmware files), and implements system protection measures (pause collection, restart mechanism, etc.) before the upgrade, it can absolutely guarantee the security and stability of the FSU operating system while driving various vendor scripts to perform high-risk upgrade operations. It effectively prevents system paralysis caused by upgrade script defects or malicious exploitation, and resolves the contradiction between openness and security.

[0122] 4. A highly robust upgrade process is provided for complex live network environments, maximizing the success rate of upgrades.

[0123] Causal reasoning: Because this disclosure designs a dual timeout monitoring mechanism (total timeout + progress timeout) based on dynamic calculation and a complete anomaly handling closed loop (abort_upgrade -> finalize -> resource cleanup -> result reporting), it can sensitively detect abnormal states such as transmission lag and device unresponsiveness, and promptly and safely interrupt and clean up the site to prevent the device from becoming unusable. Thus, when facing complex network environments such as network fluctuations and signal interference, it can maximize the final success rate of the upgrade task or achieve safe failure.

[0124] The specific embodiments of this disclosure may also have the following alternative forms, for example: Alternatives to secure isolation and API injection methods: 1. This disclosure constructs a sandbox by disabling high-risk standard libraries and injecting secure APIs. An alternative is that the security isolation mechanism is not limited to the language virtual machine level; it can also employ operating system-level containerization technologies (such as Docker containers) or lightweight virtualization technologies to isolate the entire Lua script and its runtime environment within a separate container. FSU interacts with the container through predefined, secure inter-process communication (IPC) methods (such as Unix sockets and message queues), thereby achieving the same or even stronger resource isolation and security control effects.

[0125] 2. Another alternative is to implement the security isolation mechanism using the WebAssembly (Wasm) runtime. FSU has a built-in Wasm runtime (such as Wasmtime, WAMR), and device manufacturers compile upgrade logic into Wasm bytecode modules instead of Lua bytecode. Wasm's inherent memory safety, sandbox isolation, and capability-oriented security model naturally provide strong isolation without requiring the active disabling of high-risk functions. FSU injects the necessary host capabilities (such as read_uart, write_uart, etc.) into the Wasm module through its import mechanism, achieving the same security control effect as the Lua solution, with potential advantages in performance and security.

[0126] Alternatives to transfer protocols and file retrieval methods: 1. In this disclosure, the firmware data package is downloaded from the server via the FTP protocol. Alternatives include: the file download protocol is not limited to FTP; it can also be replaced with HTTP / HTTPS, SFTP, or an MQTT-based file transfer extension protocol. Furthermore, the firmware data can also be downloaded directly from the device manufacturer's own server by a Lua script through its internal logic (such as calling injected network APIs), without the OMC specifying the download. The FSU is only responsible for providing network communication capabilities and implementing security verification.

[0127] Alternatives to upgrade strategy triggering and control: 1. In this invention, the upgrade process is triggered by an active command issued by the OMC platform. An alternative approach is that the triggering of the upgrade task does not necessarily depend entirely on OMC platform commands; the FSU can possess a certain degree of edge autonomy. For example, the FSU can periodically and proactively query a firmware version server, or automatically download the corresponding Lua upgrade package and data package when it detects an outdated device version locally, and then autonomously initiate the upgrade process after reporting to the OMC platform, achieving more intelligent edge operations and maintenance.

[0128] Alternatives to status reporting methods: In this invention, the upgrade status and results are reported to the OMC via the MQTT protocol. Alternative solutions include: the communication method for status reporting is not limited to MQTT; other IoT communication protocols can also be used, such as HTTP / HTTPS RESTful API, CoAP, or a mechanism that stores data locally during network interruptions and retransmits it after network recovery.

[0129] It is understood that the above-mentioned alternative solutions are merely exemplary and only replace a certain link or specific operation form of the core technical solution of this disclosure. Therefore, without describing the specific content of the above-mentioned alternative solutions in detail, those skilled in the art can fully implement the technical solution of this disclosure.

[0130] For ease of explanation, certain steps of the above method are described in relation to modules. It should be understood that the corresponding module performing one or more steps of the above method may be one or more hardware modules specifically configured to perform the corresponding step, or implemented by a processor configured to perform the corresponding step, or stored in a computer-readable medium for implementation by a processor, or implemented by some combination thereof.

[0131] In the description of this specification, the references to terms such as "one embodiment / mode," "some embodiments / modes," "example," "specific example," or "some examples," etc., refer to specific features, structures, or characteristics described in connection with that embodiment / mode or example, which are included in at least one embodiment / mode or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment / mode or example. Moreover, the specific features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments / modes or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments / modes or examples described in this specification, as well as the features of different embodiments / modes or examples.

[0132] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.

Claims

1. A serial device firmware upgrade method, characterized by, The method comprises the following steps: Receiving an upgrade task instruction issued by a remote management platform, parsing and obtaining key parameters, performing device identity verification and upgrade file integrity verification, and starting system protection measures after verification; Creating a secure sandbox environment, disabling high-risk function modules in the script execution environment, and specifying the addressing parameters of the target serial device; Loading standardized scripts developed by device manufacturers according to the preset interface specification, injecting safe interaction interfaces such as serial port read-write, file operation, and state reporting; Calling the mode switching function of the standardized script to switch the serial device from the running mode to the firmware upgrade mode; Cyclically calling the data transmission function of the standardized script to block transfer firmware data, and synchronously implementing timeout monitoring based on the size of the upgrade file and the communication transmission rate; After the upgrade is completed or interrupted abnormally, destroying the secure sandbox environment, restoring the original system business, and reporting the upgrade result to the remote management platform.

2. The method of claim 1, wherein, The device identity verification is to compare the unit identifier and device identifier in the instruction with the stored operation and maintenance identifier and management device list to confirm that the unit is the target execution unit and the specified serial device exists; the upgrade file integrity verification is to calculate the checksum of the downloaded standardized script and firmware data, and compare it with the verification information in the instruction.

3. The method of claim 1, wherein, The system protection measures include suspending the regular data collection business of the target serial device, suspending the multi-level restart mechanism of the device itself, and preventing the configuration parameter change operation of the device itself.

4. The method of claim 1, wherein, The high-risk function modules include file operation, system call, debugging, and package management modules; the addressing parameters are address information of the target serial device, which is used to accurately locate the target device.

5. The method of claim 1, wherein, The safe interaction interface includes serial port data read-write interface, firmware file operation interface, millisecond-level delay interface, and upgrade state reporting interface, and is the only channel for the standardized script to interact with external devices and its own resources.

6. The method of claim 1, wherein, The preset interface specification is a unified function call specification, including initialization function, pre-verification function, mode switching function, data transmission function, upgrade execution function, abnormal termination function, and resource cleaning function, and device manufacturers do not need to modify the device bottom protocol to adapt.

7. The method of claim 1, wherein, The standardized script is a Lua script; the secure sandbox environment is built by starting a Lua virtual machine; the loading form of the standardized script includes source code or pre-compiled bytecode form, and the pre-compiled bytecode form is used to protect the manufacturer's source code and improve the loading speed.

8. The method of claim 1, wherein, The threshold of the timeout monitoring includes the total timeout threshold and the progress timeout threshold; the total timeout threshold is calculated based on the total byte size of the upgrade package, the reference time consumption per unit data, and the preset timeout margin coefficient; the progress timeout threshold is calculated based on the unit progress update time consumption and the maximum retransmission failure time consumption; the reference time consumption per unit data is determined in combination with the communication transmission rate and the device processing performance.

9. The method of claim 8, wherein, The calculation formula of the total timeout threshold is: total timeout threshold = (upgrade package total byte size / 1024) x reference time consumption per unit data x (1 + total timeout margin coefficient); the total timeout margin coefficient is 0.5; the reference time consumption per unit data includes serial port write time and device processing response time, which is calculated based on the baud rate of the serial communication interface.

10. The method of claim 1, wherein, The block transmission firmware data includes: if a single transmission fails, the standardized script performs retransmission control, the maximum number of retransmissions is not less than 3 times, and the process is terminated after reaching the maximum number of retransmissions; if the total upgrade time exceeds the total timeout threshold or the progress update time exceeds the progress timeout threshold, the transmission is immediately interrupted, and the emergency termination operation is performed by calling the abnormal termination function of the standardized script.

11. The method of claim 1, wherein, The original service of the recovery system includes data acquisition function of the target serial port device, multi-level restart mechanism of the recovery system, and configuration parameter change operation of the recovery system, and the recovery operation is triggered after destroying the secure isolation sandbox environment.

12. The method of claim 1, wherein, The method further comprises downloading the standardized script and the firmware data to the local storage after parsing the key parameters and before performing the device identity verification.

13. The method of claim 1, wherein, The method further comprises, in the process of performing the cyclic calling of the data transmission function of the standardized script to block transmit the firmware data and synchronously implementing the timeout monitoring step based on the upgrade file size and the communication transmission rate, after each calling of the data transmission function and before the next calling of the transmission function, real-time acquisition of upgrade state information, the upgrade state information including device running mode, upgrade progress and upgrade state.

14. The method of claim 1, wherein, The method further comprises, after destroying the secure isolation sandbox environment and before reporting the upgrade result, performing a function self-check on the upgraded serial port device, and reporting the result after verifying the normality of the key function modules, the key function modules including but not limited to communication link and firmware running state.

15. The method of claim 1, wherein, The explicit addressing parameters of the target serial port device include addressing and interference avoidance strategies in the multi-device hanging scene: if the serial port resources are sufficient, the "one master and one slave" independent wiring method is used to realize accurate addressing of the target device; if multiple devices need to be connected to the same serial port, different manufacturers or types of devices are mixed to access, so as to reduce bus communication interference and make the upgrade instruction accurately point to the target device.

16. A serial device firmware upgrade system, characterized by The system comprises a remote management platform, a field monitoring unit and at least one serial port device; the remote management platform is used to issue upgrade task instructions, query upgrade states and receive upgrade results; the field monitoring unit is connected with the serial port device through a serial communication interface and connected with the remote management platform through a communication network, and the field monitoring unit is configured to execute the serial port device firmware upgrade method of any one of claims 1-17; the serial port device is a heterogeneous terminal device connected to the field monitoring unit.

Images