A remote upgrading method suitable for a PLBUS controller
By employing intelligent fragmentation and transmission algorithms, the Blake2s algorithm, and dynamic adaptive strategies to remotely upgrade PLBUS controllers, the problems of unreliable data transmission and high failure rates in remote upgrades of PLBUS controllers have been solved, achieving an efficient and secure upgrade process and improving the functionality of the equipment and the user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- 长沙力合微智能科技有限公司
- Filing Date
- 2024-12-30
- Publication Date
- 2026-07-14
AI Technical Summary
Traditional PLBUS controller remote upgrade methods suffer from problems such as unreliable data transmission and high failure rates, which affect user experience.
The system employs a master station to remotely select multiple PLBUS controllers for upgrade information structure adjustments. Through policy adjustments and batch upgrades in groups, combined with intelligent fragmentation and transmission algorithms, Blake2s algorithm verification and encrypted connection transmission, dynamic adaptive policies and retry mechanisms, secure upgrades are achieved.
It improved the stability, efficiency, success rate, and manageability of the upgrade process, and enhanced device functionality and user experience.
Smart Images

Figure CN119892637B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of PLBUS controller technology, and more specifically to a remote upgrade method for PLBUS controllers. Background Technology
[0002] Remote upgrades of smart devices are crucial for improving performance and fixing defects. However, traditional upgrade methods often suffer from unreliable data transmission and high failure rates, which severely impact user experience. Therefore, there is an urgent need to design a remote upgrade method suitable for PLBUS controllers to enhance the stability and scalability of the smart device upgrade process. Summary of the Invention
[0003] To address the aforementioned technical problems, this invention provides a remote upgrade method for PLBUS controllers, characterized by comprising the following steps:
[0004] S1. Remotely select a batch of multiple PLBUS controllers through the main station to start the upgrade and adjust the upgrade information structure;
[0005] S2. Based on S1, adjust the strategy of the PLBUS controllers in this batch according to the status of the previous upgrade information structure. PLBUS controllers that have passed the strategy adjustment and are not marked as having poor communication are grouped together for sequential batch upgrade.
[0006] S3. Based on S2, monitor the status of the grouped PLBUS controller and establish a feedback mechanism. Use intelligent slicing and transmission algorithms to feed back the status data of the PLBUS controller to the master station.
[0007] S4. Based on S3, after the master station receives the status data of the PLBUS controller after the packet is received, it starts the security upgrade mechanism, uses the Blake2s algorithm to calculate the checksum, and uses two independent encrypted connections to transmit data and verification information to transmit cloud files and terminal upgrade content to the PLBUS controller.
[0008] S5. Based on S4, after receiving cloud files and terminal upgrade content, the PLBUS controller performs interactive processing. If the interaction data between the terminal and the PLBUS controller is not frequent, the PLBUS controller will choose to make dynamic adaptive strategy adjustments. If the interaction data between the terminal and the PLBUS controller is stable, an automatic switching mechanism will be implemented based on the previous upgrade status of the PLBUS controller, and a retry mechanism will be implemented.
[0009] S6.1 Based on S5, the PLBUS controllers are grouped according to the adjusted strategy. If the dynamic adaptive strategy is enabled, the PLBUS controllers that failed to be upgraded in this round of strategy adjustment will be upgraded first. If the dynamic adaptive strategy is disabled, the exception will be recorded and the next item that needs to be upgraded will continue.
[0010] S6.2 Based on S5, if the retry mechanism upgrade is successful, it means that the remote upgrade of the PLBUS controller is successful and the upgrade of the PLBUS controller ends; if the retry mechanism upgrade fails, intelligent rollback and version management will be performed until the end.
[0011] Preferably, the method for adjusting the strategy in steps S2 and S5 includes the following steps:
[0012] S7.1 Based on the previous adjustment of measurement points, select PLBUS controllers that are not marked as having poor communication, and use a group batch upgrade method. A specific controller can be upgraded with a single upgrade command without waiting for each controller to respond individually.
[0013] S7.2, Based on S7.1, calculate the interaction time threshold for a single PLBUS controller:
[0014] S7.3 Based on S7.2, record the time taken for a successful interaction. If the time taken exceeds the set calculation threshold, mark the PLBUS controller as having unstable communication. If the time taken does not exceed the set calculation threshold, mark the PLBUS controller as having stable communication and continue to the next upgrade step.
[0015] S7.4 Based on S7.3, PLBUS controllers marked as having stable communication will undergo broadcast upgrades. If a PLBUS controller fails during the broadcast upgrade process, it will be marked as having poor communication and will switch to unicast upgrade mode. If a PLBUS controller succeeds during the broadcast upgrade process, it will be marked as having stable communication.
[0016] Based on S7.5, S7.3, and S7.4, the overall success rate and failure rate of this upgrade are calculated respectively.
[0017] Preferably, in step S7.5, the overall success rate of this group upgrade is: PS1;
[0018] The total number of PLBUS controllers successfully upgraded in the overall group = Nub + Ng;
[0019] Number of controllers that successfully broadcast: Nub = x × PU1;
[0020] Number of PLBUS controllers successfully grouped: Ng = Nuf × PS1 = (x × PU2) × PS1;
[0021] The overall failure rate for this group upgrade is: PS2 = 1 - PS1;
[0022] The number of PLBUS controllers that failed to group the data as a whole = (x × PU2) × (1 - PS1);
[0023] Where x represents the total number of PLBUS controllers;
[0024] PU1 represents the broadcast success rate;
[0025] PU2 represents the broadcast failure rate;
[0026] Number of PLBUS controllers that failed to group: Nuf × PS2;
[0027] Number of controllers that failed to broadcast: Nuf = x × PU2.
[0028] Preferably, in step S5, the retry mechanism includes retries triggered when the current interaction times out and retries triggered when the PLBUS controller fails to respond;
[0029] If the current interaction times out, the system will record the PLBUS controller and mark it as having poor communication. At the same time, the upgrade status, the longest time elapsed, the number of retries, and other information will be reported, and the upgrade of the PLBUS controller with good communication will be performed first.
[0030] If the PLBUS controller fails to respond, a retry is triggered immediately. If the retry still fails within the specified retry threshold, it is recorded as an upgrade anomaly and this measurement point is excluded in subsequent upgrades.
[0031] Preferably, the retries triggered when the PLBUS controller fails to respond include the following two cases:
[0032] If the current number of retries Rcurrent is less than the maximum number of retries Rmax, then a retry will be performed;
[0033] If the retry interval is initially set to the default value, the minimum threshold for interaction will be determined by the strategy adjustment thereafter.
[0034] This upgrade retry process will proceed via broadcast, multicast, and unicast in sequence.
[0035] Preferably, in step S1, the method for the master station to remotely select a batch of multiple PLBUS controllers to start the upgrade includes the following steps:
[0036] S1.1 Back-end staff select a specific PLBUS controller type on the main station and send the upgrade file to the terminal;
[0037] S1.2 Based on S1.1, the terminal's upgrade tool actively reads the version information of the PLBUS controller, calculates the subsequent upgrade strategy according to the communication status of the PLBUS controller, and reads and verifies the MD5 value of the upgrade file to ensure the integrity of the upgrade file.
[0038] S1.3, based on S1.2, the upgrade tool periodically reads the upgrade status to achieve real-time monitoring;
[0039] After a successful upgrade to S1.4 (based on S1.3), the main site will confirm the final result after a 2-minute delay.
[0040] Compared with the prior art, the present invention has the following beneficial effects:
[0041] (1) This invention improves applicability and stability through enhanced algorithm design, significantly improving the efficiency, success rate, security and manageability of the upgrade process. It has wide application value in the field of smart devices and can effectively improve the functionality and user experience of devices. Attached Figure Description
[0042] Figure 1 This is the overall flowchart of the present invention.
[0043] Figure 2 This is a flowchart of the security upgrade mechanism of the present invention.
[0044] Figure 3 This is a flowchart of the version management method of the present invention. Detailed Implementation
[0045] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.
[0046] In the description of this invention, unless otherwise stated, "a plurality of" means two or more; the terms "upper," "lower," "left," "right," "inner," "outer," "front end," "rear end," "head," "tail," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance.
[0047] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "connected" and "linked" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.
[0048] A remote upgrade method for PLBUS controllers includes the following steps:
[0049] S1. Remotely select a batch of multiple PLBUS controllers through the main station to start the upgrade and adjust the upgrade information structure;
[0050] Specifically, in step S1, the method for the master station to remotely select a batch of multiple PLBUS controllers to start the upgrade includes the following steps:
[0051] S1.1 Back-end staff select a specific PLBUS controller type on the main station and send the upgrade file to the terminal;
[0052] S1.2 Based on S1.1, the terminal's upgrade tool actively reads the version information of the PLBUS controller, calculates the subsequent upgrade strategy according to the communication status of the PLBUS controller, and reads and verifies the MD5 value of the upgrade file to ensure the integrity of the upgrade file.
[0053] S1.3, based on S1.2, the upgrade tool periodically reads the upgrade status to achieve real-time monitoring;
[0054] After a successful upgrade to S1.4 (based on S1.3), the main site will confirm the final result after a 2-minute delay.
[0055] The information structure in this embodiment includes at least the following:
[0056] Upgrade file path: Location where the upgrade file is stored; Data to be transmitted: Contains the specific data that needs to be upgraded; Number of transmissions: Counts the number of data packets that have been sent; Last transmission status: Records the status of the last transmission for subsequent monitoring; Whether to send the next frame: Indicates whether to continue sending data frames; Last transmission time: Used to control the transmission frequency.
[0057] Upgrading the information structure makes data organization and parsing more efficient, and the optimized upgrade process reduces operation steps and time, improving the user experience.
[0058] S2. Based on S1, adjust the strategy of the PLBUS controllers in this batch according to the status of the previous upgrade information structure. PLBUS controllers that have passed the strategy adjustment and are not marked as having poor communication are grouped together for sequential batch upgrade.
[0059] S3. Based on S2, monitor the status of the grouped PLBUS controller and establish a feedback mechanism. Use intelligent slicing and transmission algorithms to feed back the status data of the PLBUS controller to the master station.
[0060] Specifically, in this embodiment, the status of the grouped PLBUS controllers is monitored and a feedback mechanism is established. By monitoring the current upgrade status and providing feedback to the user, operators can promptly understand the upgrade progress. For example, status codes are used to indicate the current upgrade status, such as success, failure, or unknown status. A feedback log recording function is designed for subsequent analysis and troubleshooting. The real-time status monitoring and feedback mechanism provides transparent information for remote upgrades. After each data transmission, the upgrade system periodically reports the current status, ensuring that operators can understand the upgrade process immediately and respond quickly to problems.
[0061] In this embodiment, the intelligent fragmentation and transmission algorithm includes the following three points:
[0062] a) Adaptive setting of upgrade data block size: Adjust the data block size flexibly according to the carrier upgrade response to optimize write efficiency.
[0063] Write unit: Flash memory typically writes data in units of pages or sectors. If the length of data written in a single operation is less than the size of a page or sector, a complete write operation is still required, and the actual write time may not be significantly reduced.
[0064] Total write volume: If the length of each write is close to the size of a page or sector, write efficiency will improve when processing large data blocks. Conversely, frequent small data writes will increase write operations, thus increasing overall time consumption.
[0065] Erasing and writing efficiency: In Flash memory, writing usually requires erasing first, and erasing is also done in units of pages or sectors. Frequent small data writes increase the number of erase operations, affecting overall efficiency.
[0066] Write cycles: Each cell in a Flash memory unit supports a limited number of write cycles (e.g., thousands to tens of thousands). Larger data writes help distribute the write cycles more evenly, reducing wear in certain areas and thus improving the success rate; while frequent small writes may cause some areas to reach their write limit prematurely.
[0067] Adaptive Adjustment: The controller's maximum receive length is 255 bytes. Using the maximum transmission length will result in longer Flash write times, and delays or anomalies may occur when the controller processes data concatenation. Therefore, the initial upgrade will trigger dynamic adjustment of the data block size until the success rate reaches its optimal level.
[0068] b) Use CRC to calculate the checksum of each upgrade data block to ensure data integrity.
[0069] c) Employ encrypted connections to transmit upgrade data blocks and verification integrity information separately, enhancing security. This ensures that the upgrade data received by the terminal can be accurately sent to the controller.
[0070] The intelligent fragmentation and transmission algorithm used in this invention effectively reduces network burden and improves data transmission speed and success rate.
[0071] S4. Based on S3, after the master station receives the status data of the PLBUS controller after the packet is received, it starts the security upgrade mechanism, uses the Blake2s algorithm to calculate the checksum, and uses two independent encrypted connections to transmit data and verification information to transmit cloud files and terminal upgrade content to the PLBUS controller.
[0072] Specifically, the security upgrade mechanism in this embodiment includes the following three points:
[0073] d) Use the Blake2s algorithm to calculate checksums to improve security: cloud file transfers and terminal upgrade content transmission to the controller.
[0074] e) Use two independent encrypted connections to transmit data and verification information: CRC checks the integrity of the transmitted file content, and ESAM encrypts the transmitted data.
[0075] f) Multiple verifications ensure data integrity.
[0076] The security upgrade mechanism of this invention ensures the integrity and confidentiality of data and effectively prevents potential security threats.
[0077] S5. Based on S4, after receiving cloud files and terminal upgrade content, the PLBUS controller performs interactive processing. If the interaction data between the terminal and the PLBUS controller is not frequent, the PLBUS controller will choose to perform dynamic adaptive strategy adjustment. The dynamic adaptive strategy is adjusted according to historical records to ensure maximum optimization of retry operations.
[0078] If the data exchange between the terminal and the PLBUS controller is stable, an automatic switching mechanism and a retry mechanism will be implemented based on the previous upgrade of the PLBUS controller.
[0079] Specifically, in step S5, the retry mechanism includes retries triggered in the case of current interaction timeout and retries triggered in the case of PLBUS controller response failure;
[0080] If the current interaction times out, the system will record the PLBUS controller and mark it as having poor communication. At the same time, the upgrade status, the longest time elapsed, the number of retries, and other information will be reported, and the upgrade of the PLBUS controller with good communication will be performed first.
[0081] If the PLBUS controller fails to respond, a retry is triggered immediately. If the retry still fails within the specified retry threshold, it is recorded as an upgrade anomaly and this measurement point is excluded in subsequent upgrades.
[0082] The retries triggered when the PLBUS controller fails to respond include the following two cases:
[0083] If the current number of retries Rcurrent is less than the maximum number of retries Rmax, then a retry will be performed;
[0084] If the retry interval is initially set to the default value, the minimum threshold for interaction will be determined by the strategy adjustment thereafter.
[0085] This upgrade retry process will proceed via broadcast, multicast, and unicast in sequence.
[0086] The automatic switching mechanism effectively ensures that the system maintains a stable upgrade experience under different network conditions.
[0087] S6.1 Based on S5, the PLBUS controllers are grouped according to the adjusted strategy. If the dynamic adaptive strategy is enabled, the PLBUS controllers that failed to be upgraded in this round of strategy adjustment will be upgraded first. If the dynamic adaptive strategy is disabled, the exception will be recorded and the next item that needs to be upgraded will continue.
[0088] S6.2 Based on S5, if the retry mechanism upgrade is successful, it means that the remote upgrade of the PLBUS controller is successful and the upgrade of the PLBUS controller ends; if the retry mechanism upgrade fails, intelligent rollback and version management will be performed until the end.
[0089] This invention's robust retry mechanism automatically retryes upgrades when they fail, minimizing upgrade failures due to occasional errors and increasing the success rate. Furthermore, its intelligent rollback and version management functions allow for rapid reverting to a stable version in case of upgrade failure, while also flexibly managing version switching and reducing system downtime.
[0090] like Figure 3 As shown, the version management method in this embodiment includes the following steps:
[0091] 6.2.1. Retain old version files during the upgrade process for easy rollback;
[0092] S6.2.2 Use a dual-partition mechanism (APP2 partition and application code partition) to ensure that you can revert to the old version if the upgrade fails;
[0093] 6.2.3 Only after a successful upgrade will the new version files be moved to the application code area to ensure system stability.
[0094] The BACKUPS storage area stores the identifiers of the old version files; the APP2 area temporarily stores the new version files; after the upgrade is completed, the new version files are moved to the application code area.
[0095] In steps S2 and S5, the method for adjusting the strategy includes the following steps:
[0096] S7.1 Based on the previous adjustment of measurement points, select PLBUS controllers that are not marked as having poor communication, and use a group batch upgrade method. A specific controller can be upgraded with a single upgrade command without waiting for each controller to respond individually.
[0097] S7.2, Based on S7.1, calculate the interaction time threshold for a single PLBUS controller:
[0098] S7.3 Based on S7.2, record the time taken for a successful interaction. If the time taken exceeds the set calculation threshold, mark the PLBUS controller as having unstable communication. If the time taken does not exceed the set calculation threshold, mark the PLBUS controller as having stable communication and continue to the next upgrade step.
[0099] S7.4 Based on S7.3, PLBUS controllers marked as having stable communication will undergo broadcast upgrades. If a PLBUS controller fails during the broadcast upgrade process, it will be marked as having poor communication and will switch to unicast upgrade mode. If a PLBUS controller succeeds during the broadcast upgrade process, it will be marked as having stable communication.
[0100] Based on S7.5, S7.3, and S7.4, the overall success rate and failure rate of this upgrade are calculated respectively.
[0101] Specifically, the overall success rate of this group upgrade is: PS1;
[0102] The total number of PLBUS controllers successfully upgraded in the overall group = Nub + Ng;
[0103] Number of controllers that successfully broadcast: Nub = x × PU1;
[0104] Number of PLBUS controllers successfully grouped: Ng = Nuf × PS1 = (x × PU2) × PS1;
[0105] The overall failure rate for this group upgrade is: PS2 = 1 - PS1;
[0106] The number of PLBUS controllers that failed to group the data as a whole = (x × PU2) × (1 - PS1);
[0107] Where x represents the total number of PLBUS controllers;
[0108] PU1 represents the broadcast success rate;
[0109] PU2 represents the broadcast failure rate;
[0110] Number of PLBUS controllers that failed to group: Nuf × PS2;
[0111] Number of controllers that failed to broadcast: Nuf = x × PU2.
[0112] The main station can automatically adjust its upgrade strategy based on real-time data to adapt to changes in network load and device status, thereby optimizing the upgrade effect.
[0113] The PLBUS controller remote upgrade method provided by this invention improves applicability and stability through enhanced algorithm design, significantly improving the efficiency, success rate, security and manageability of the upgrade process. It has broad application value in the field of smart devices and can effectively improve the functionality and user experience of the devices.
[0114] The above embodiments are merely preferred embodiments of the present invention and should not be construed as limiting the scope of the present invention. Therefore, any modifications, equivalent changes, improvements, etc., made in accordance with the claims of the present invention shall still fall within the scope of the present invention.
Claims
1. A remote upgrade method for a PLBUS controller, characterized in that, Includes the following steps: S1. Remotely select a batch of multiple PLBUS controllers through the main station to start the upgrade and adjust the upgrade information structure; S2. Based on S1, adjust the strategy of the PLBUS controllers in this batch according to the status of the previous upgrade information structure. PLBUS controllers that have passed the strategy adjustment and are not marked as having poor communication are grouped together for sequential batch upgrade. S3. Based on S2, monitor the status of the grouped PLBUS controller and establish a feedback mechanism. Use intelligent slicing and transmission algorithms to feed back the status data of the PLBUS controller to the master station. S4. Based on S3, after the master station receives the status data of the PLBUS controller after the packet is received, it starts the security upgrade mechanism, uses the Blake2s algorithm to calculate the checksum, and uses two independent encrypted connections to transmit data and verification information to transmit cloud files and terminal upgrade content to the PLBUS controller. S5. Based on S4, after receiving cloud files and terminal upgrade content, the PLBUS controller performs interactive processing. If the interaction data between the terminal and the PLBUS controller is not frequent, the PLBUS controller will choose to make dynamic adaptive strategy adjustments. If the interaction data between the terminal and the PLBUS controller is stable, an automatic switching mechanism will be implemented based on the previous upgrade status of the PLBUS controller, and a retry mechanism will be implemented. S6.1 Based on S5, the PLBUS controllers are grouped according to the adjusted strategy. If the dynamic adaptive strategy is enabled, the PLBUS controllers that failed to be upgraded in this round of strategy adjustment will be upgraded first. If the dynamic adaptive strategy is disabled, the exception will be recorded and the next item that needs to be upgraded will continue. S6.2 Based on S5, if the retry mechanism upgrade is successful, it means that the remote upgrade of the PLBUS controller is successful and the upgrade of the PLBUS controller ends; if the retry mechanism upgrade fails, intelligent rollback and version management will be performed until the end. The method for adjusting the strategy in steps S2 and S5 includes the following steps: S7.1 Based on the previous adjustment of measurement points, select PLBUS controllers that are not marked as having poor communication, and use a group batch upgrade method. A specific controller can be upgraded with a single upgrade command without waiting for each controller to respond individually. S7.2, Based on S7.1, calculate the interaction time threshold for a single PLBUS controller: S7.3 Based on S7.2, record the time taken for a successful interaction. If the time taken exceeds the set calculation threshold, mark the PLBUS controller as having unstable communication. If the time taken does not exceed the set calculation threshold, mark the PLBUS controller as having stable communication and continue to the next upgrade step. S7.4 Based on S7.3, PLBUS controllers marked as having stable communication will undergo broadcast upgrades. If a PLBUS controller fails during the broadcast upgrade process, it will be marked as having poor communication and will switch to unicast upgrade mode. If a PLBUS controller succeeds during the broadcast upgrade process, it will be marked as having stable communication. Based on S7.5, S7.3, and S7.4, the overall success rate and failure rate of this upgrade are calculated respectively.
2. The remote upgrade method for a PLBUS controller according to claim 1, characterized in that, In step S7.5, the overall success rate of this group upgrade is: PS1; The total number of PLBUS controllers successfully upgraded in the overall group = Nub + Ng; Number of controllers that successfully broadcast: Nub = x × PU1; Number of PLBUS controllers successfully grouped: Ng = Nuf × PS1 = (x × PU2) × PS1; The overall failure rate for this group upgrade is: PS2 = 1 - PS1; The number of PLBUS controllers that failed to group the data as a whole = (x × PU2) × (1 - PS1); Where x represents the total number of PLBUS controllers; PU1 represents the broadcast success rate; PU2 represents the broadcast failure rate; Number of PLBUS controllers that failed to group: Nuf × PS2; Number of controllers that failed to broadcast: Nuf = x × PU2.
3. The remote upgrade method for a PLBUS controller according to claim 2, characterized in that, In step S5, the retry mechanism includes retries triggered when the current interaction times out and retries triggered when the PLBUS controller fails to respond. If the current interaction times out, the system will record the PLBUS controller and mark it as having poor communication. At the same time, the upgrade status, the longest time elapsed, the number of retries, and other information will be reported, and the upgrade of the PLBUS controller with good communication will be performed first. If the PLBUS controller fails to respond, a retry is triggered immediately. If the retry still fails within the specified retry threshold, it is recorded as an upgrade anomaly and this measurement point is excluded in subsequent upgrades.
4. The remote upgrade method for a PLBUS controller according to claim 3, characterized in that, The retries triggered when the PLBUS controller fails to respond include the following two cases: If the current number of retries Rcurrent is less than the maximum number of retries Rmax, then a retry will be performed; If the retry interval is initially set to the default value, the minimum threshold for interaction will be determined by the strategy adjustment thereafter. This upgrade retry process will proceed via broadcast, multicast, and unicast in sequence.
5. A remote upgrade method for a PLBUS controller according to claim 1, characterized in that, In step S1, the method for the master station to remotely select a batch of multiple PLBUS controllers to start the upgrade includes the following steps: S1.1 Back-end staff select a specific PLBUS controller type on the main station and send the upgrade file to the terminal; S1.2 Based on S1.1, the terminal's upgrade tool actively reads the version information of the PLBUS controller, calculates the subsequent upgrade strategy according to the communication status of the PLBUS controller, and reads and verifies the MD5 value of the upgrade file to ensure the integrity of the upgrade file. S1.3, based on S1.2, the upgrade tool periodically reads the upgrade status to achieve real-time monitoring; After a successful upgrade to S1.4 (based on S1.3), the main site will confirm the final result after a 2-minute delay.