An atomic remote upgrading method of a power feeder terminal in a weak network environment

Abstract

The application discloses an atomic remote upgrading method of a power feeder terminal in a weak network environment and relates to the technical field of power system distribution network automation. The method comprises the following steps: after an upgrading instruction is triggered, FTU state self-checking is performed; after conditions are met, a special network FTP server is logged in to download an upgrading data frame; after recombination and verification, the upgrading data frame is copied to a backup-transit area; a bootloader copies the upgrading data frame to a cache area, then backs up a current version program file to the backup-transit area, and copies the upgrading data frame to a running area; if the copying fails, the current version program file in the backup-transit area is rolled back to the running area; after each area copying, integrity verification is required, and only when the verification is passed can the next step be entered; the method ensures that the content in the running area is always the complete current version program file or the upgrading data file before the content is finally verified and restarted, so that the device cannot be in an unusable state, and the running continuity of the FTU is ensured.

Description

Technical Field

[0001] This invention relates to the field of power system distribution network automation technology, specifically to an atomic remote upgrade method for power feeder terminals in a weak network environment. Background Technology

[0002] Feeder terminals (FTUs) are core field devices in distribution network automation systems, widely deployed at outdoor pole-mounted and box-type substations. They undertake critical functions such as power grid data acquisition, fault detection, and distribution network control. Remote firmware upgrades are essential for ensuring the stable operation of the distribution network system. Currently, most mainstream FTU remote upgrade technologies in the industry are based on the upgrade logic of general embedded devices, directly writing the upgrade file to the program storage area after transmitting it over the network. Although some solutions have added simple file verification and failure rollback strategies, due to limitations in FTU deployment scenarios and device characteristics, existing technologies still have many shortcomings in practical applications and cannot meet the stringent requirements of distribution network systems for FTU operational continuity and upgrade reliability.

[0003] In practical applications, the existing FTU remote upgrade technology faces several shortcomings: Firstly, FTUs deployed in weak network environments such as rural and mountainous areas are prone to data packet loss and transmission distortion when using traditional wireless TCP communication protocols and whole-packet file transmission or simple fragmented transmission modes. This can lead to corrupted upgrade files, resulting in upgrade failure, FTU interruption, or even complete system crashes, severely impacting the continuity of FTU operation. Secondly, general embedded upgrade solutions typically determine the success of the upgrade by checking the device's functionality after a restart. If the upgrade fails, a rollback command is issued. This strategy fails to consider the special characteristics of the FTU as a critical node in the power grid. In weak network environments, the time window for the server to determine upgrade failure and issue a rollback command is relatively long, making it difficult to meet the high reliability and continuity requirements of the distribution network for FTU operation. Thirdly, some solutions employ simple and crude failure rollback strategies that cannot cope with the complex operating conditions of FTUs in the field. If a power outage or hardware failure occurs during the copying of upgrade or rollback files, the upgrade or original files can easily become corrupted, causing the FTU to crash and become unusable. This significantly increases the difficulty of remote maintenance and the workload of on-site maintenance. Summary of the Invention

[0004] The purpose of this invention is to provide an atomic remote upgrade method for power feeder terminals in weak network environments, so as to solve the problem that the existing FTU remote upgrade technology mentioned in the background art is prone to interruption of equipment operation due to accidents.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] An atomic remote upgrade method for power feeder terminals in a weak network environment includes the following steps:

[0007] S1: Divide the storage space of the power feeder terminal unit (FTU) into an operating area, a backup-transfer area, and a buffer area;

[0008] S2: After the FTU upgrade command is triggered, the operating status parameters of the FTU are detected. If at least one of the operating status parameters exceeds the corresponding preset security threshold, the FTU upgrade will not be performed, and the parameter category and parameter value that exceed the corresponding preset security threshold among the operating status parameters will be reported; otherwise, the private network FTP server will be logged in, and the upgrade data frame will be downloaded in segments to the cache area through the wireless communication module.

[0009] S3: After all upgrade data frames are successfully downloaded, all the upgrade data frames are reassembled into an upgrade data file in sequence to generate a reassembly success flag. Based on the reassembly success flag, the upgrade data file is copied to the backup-transfer area to generate a first copy success flag. Based on the first copy success flag, an upgrade start flag is written into the FTU's solidified flag detection address.

[0010] S4: After the Bootloader detects the upgrade start flag, it copies the upgrade data file in the backup-transfer area to the cache area and generates a second copy success flag;

[0011] S5: Based on the second copy success flag, back up the currently running program file in the running area to the backup-transfer area and generate a backup success flag;

[0012] S6: Based on the backup success flag, copy the upgrade data file in the cache area sector by sector to the running area with a preset sector size, and generate a third copy success flag or copy failure flag;

[0013] S7: If the third copy success flag is detected, the upgrade start flag is cleared, an FTU soft reboot is triggered, and the remote upgrade of the FTU is completed; if the copy failure flag is detected, the current version program file in the backup-transfer area is copied sector by sector to the running area with a preset sector size, a rollback success flag is generated, the upgrade start flag is cleared according to the rollback success flag, an FTU soft reboot is triggered, an upgrade failure signal is generated, and the upgrade failure signal is reported.

[0014] The working principle of the atomic remote upgrade method for a power feeder terminal in a weak network environment is as follows: Three independent storage logical areas are partitioned from the FTU's storage space to ensure that the data in the three logical areas does not interfere with each other during the data copying process during the upgrade. When the FTU receives the upgrade command, it first performs a status self-check. Only when all upgrade conditions are met can the upgrade process begin, ensuring the stability of the FTU's environment and hardware conditions during the upgrade process. After the upgrade conditions are met, the FTU downloads upgrade data frames in fragments to the buffer area via a dedicated network FTP server, and reassembles all successfully downloaded upgrade data frames into an upgrade data file. After successful reassembly, a reassembly success flag is generated. Based on the reassembly success flag, the complete upgrade data file is copied to the backup-transfer area. After the upgrade data file in the backup-transfer area passes integrity verification, an upgrade start flag is written. The bootloader can only start the FTU's upgrade program after detecting the upgrade start flag: first, the upgrade data file in the backup-transfer area is copied to the buffer area, and after integrity verification, the upgrade data file in the running area is copied to the buffer area. The current version of the program file is backed up to the backup-transfer area. Only after the current version of the program file is successfully backed up can the upgrade data file be copied sector by sector to the running area. The upgrade data file in the running area generates a third copy success flag after passing the integrity check; otherwise, a copy failure flag is generated. When a copy failure flag is detected, it indicates that the upgrade has failed, and the current version of the program file backed up in the backup-transfer area needs to be rolled back to the running area. After passing the integrity check, a rollback success flag is generated. When either the third copy success flag or the rollback success flag is detected, it indicates that there is a complete and executable program file in the running area. After triggering an FTU soft restart, the FTU can load the executable file normally from the boot address. This method ensures the atomicity of the FTU upgrade process through transactional process management and multi-checking mechanisms. This ensures that if the FTU upgrade process is interrupted unexpectedly, its running area will still contain a normal and executable current version of the program file or upgrade data file, thereby ensuring the continuity of FTU operation in the power grid and greatly reducing the risk of FTU bricking due to upgrade failure.

[0015] Preferably, to ensure the independence of the three logical storage areas and reduce interference between different partitions during data read / write processes, the running area is the Flash1 storage area of ​​the FTU, which is used to run the current version program file or the upgrade data file. The backup-transfer area is the Flash2 storage area of ​​the FTU, and the cache area is the SDRAM cache of the FTU. The Flash1 storage area contains the boot address of the FTU. When the device starts up, it loads files from the boot address. To ensure file consistency and the continuity of FTU operation, the current version program file or upgrade data file must be completely stored in the Flash1 storage area before the device can be restarted.

[0016] Preferably, to ensure the stability of the FTU upgrade process and reduce the risk of upgrade interruption due to environmental fluctuations or hardware failures, an FTU status self-check must be performed before the upgrade. The operating status parameters to be checked include: power supply voltage stability, chip temperature, and remaining Flash lifespan.

[0017] Preferably, in step S2, during the step of downloading upgrade data frames in segments to the buffer via the wireless communication module, the integrity of the corresponding data frame needs to be verified after each data frame is downloaded. If the verification fails, the failed data frame is downloaded again and verified again. If the verification succeeds, the download and verification task of the next data frame is executed. In weak network environments, data is prone to packet loss or distortion. Through the closed-loop design of single-frame download, real-time verification, and failure retransmission, the complete reception rate of data frames can be improved, the amount of invalid data transmission can be reduced, and the occupation of network bandwidth can be reduced.

[0018] Preferably, to ensure the integrity and accuracy of the upgraded data file after reassembly, in step S3, after reassembling all the upgraded data frames into an upgraded data file in sequence, the method further includes: calculating the first target file checksum of the reassembled upgraded data file; if the first target file checksum is consistent with the preset checksum provided by the private network FTP server, a reassembly success flag is generated; otherwise, the process returns to step S2.

[0019] Preferably, in step S3, after copying the upgrade data file to the backup-transfer area, the method further includes: calculating the second target file checksum of the upgrade data file in the backup-transfer area after copying; if the second target file checksum matches the first target file checksum, a first copy success flag is generated; otherwise, the copying of the upgrade data file to the backup-transfer area is performed again. To properly store the downloaded upgrade data file, copying it completely to the non-volatile backup-transfer area can reduce the possibility of upgrade data file loss during the upgrade process.

[0020] Preferably, in step S4, after copying the upgrade data file from the backup-transfer area to the cache area, the method further includes: calculating the third target file checksum of the copied upgrade data file in the cache area; if the third target file checksum matches the second target file checksum, a second copy success flag is generated; otherwise, the second copy is determined to have failed, and the process of copying the upgrade data file from the backup-transfer area to the cache area is repeated; if the number of times the second copy is determined to have failed exceeds a first preset number, the FTU upgrade is abandoned, and a program file copy failure signal is reported; before executing the core steps of the FTU upgrade process, the upgrade data file in the backup-transfer area must be completely backed up to ensure that the integrity of the upgrade data file is not affected when backing up the current version program file to the backup-transfer area; if the upgrade data file fails to be backed up multiple times, it indicates that there may be a hardware failure in the storage area, and the upgrade process must be terminated to prevent the device from becoming bricked due to upgrade failure in the subsequent process.

[0021] Preferably, to ensure that the FTU has complete and accurate current version program files for rollback in the event of an upgrade failure, step S5, after backing up the currently running program files in the running area to the backup-transfer area, further includes: calculating the first original file checksum and the second original file checksum of the current version program files in the running area and the backup-transfer area respectively; if the second original file checksum matches the first original file checksum, a backup success flag is generated; otherwise, the backup is determined to have failed, and the process of backing up the currently running program files in the running area to the backup-transfer area is repeated; if the number of backup failures exceeds a second preset number, the FTU upgrade is abandoned, and an original file backup failure signal is reported; if the current version program files fail to back up multiple times, it indicates that there may be a hardware failure in the storage area, and the upgrade process needs to be terminated to prevent the device from becoming unusable due to a lack of rollback files after a subsequent upgrade failure.

[0022] Preferably, to ensure the atomicity and accuracy of writing the upgrade data file to the runtime area, in step S6, copying the upgrade data file from the cache area to the runtime area sector by sector with a preset sector size specifically includes: verifying the integrity of the corresponding upgrade data file segment after copying each sector of the upgrade data file segment to the runtime area; if the verification passes, the copying and verification task of the upgrade data file segment in the next sector is executed; if the verification fails, the copying and verification task of the corresponding upgrade data file segment is re-executed; if the number of integrity verification failures for a certain upgrade data file segment exceeds a third preset number, a copy failure flag is generated; after all upgrade data file segments pass the integrity verification, the fourth target file checksum of the upgrade data file in the runtime area is calculated; if the fourth target file checksum matches the third target file checksum, a third copy success flag is generated; otherwise, the copying of the upgrade data file from the cache area to the runtime area sector by sector with a preset sector size is re-executed; if the number of times the fourth target file checksum does not match the third target file checksum exceeds a fourth preset number, a copy failure flag is generated.

[0023] Preferably, to ensure the atomicity and reliability of the rollback process after an FTU upgrade failure, in step S7, copying the current version program file from the backup-transfer area to the running area sector by sector with a preset sector size specifically includes: after copying a current version program file fragment from each sector to the running area, verifying the integrity of the corresponding current version program file fragment; if the verification passes, executing the copying and verification task of the current version program file fragment in the next sector; if the verification fails, re-executing the copying and verification task of the corresponding current version program file fragment; if the current version program file fragment in a certain sector of the running area... If the number of integrity verification failures exceeds the fifth preset number, the corresponding sector is marked as a bad block. The reserved spare sector in the Flash hardware is then used to perform the copying and verification task of the current version program file fragment in the corresponding sector. After the copying, if the current version program file fragment in all sectors passes the integrity verification, the third original file checksum of the current version program file in the runtime area is calculated. If the third original file checksum is consistent with the second original file checksum, a rollback success flag is generated. Otherwise, the process of copying the current version program file from the backup-transfer area to the runtime area sector by sector with a preset sector size is re-executed.

[0024] One or more technical solutions provided by this invention have at least the following technical effects or advantages:

[0025] 1. By constructing a three-zone storage backup and a closed-loop design of backup-verification-write-re-verification, the atomicity of the entire FTU remote upgrade process is achieved, ensuring that any abnormality in any link during the upgrade process will not lead to the corruption of the FTU's original program files or the bricking of the equipment, thus ensuring the continuity of power equipment operation;

[0026] 2. During the FTU upgrade process, the contents of the running area remain as complete current version program files or upgrade data files until the final verification and restart, ensuring that the device does not become unusable and greatly reducing on-site maintenance work caused by upgrade failure.

[0027] 3. By performing a self-check of the device status before the upgrade, the hardware and environmental stability of the FTU during the upgrade is ensured, reducing the possibility of the upgrade process being interrupted due to hardware failure. Attached Figure Description

[0028] The accompanying drawings, which are provided to further illustrate embodiments of the invention and constitute a part of this invention, are not intended to limit the scope of the invention.

[0029] Figure 1 This is a flowchart illustrating an atomic remote upgrade method for a power feeder terminal in a weak network environment, as described in this invention. Detailed Implementation

[0030] To better understand the above-mentioned objectives, features, and advantages of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, where there is no conflict, the embodiments of the present invention and the features thereof can be combined with each other.

[0031] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and therefore the scope of protection of the invention is not limited to the specific embodiments disclosed below.

[0032] Example 1

[0033] Please refer to Figure 1 The present invention provides an atomic remote upgrade method for power feeder terminals in a weak network environment, comprising the following steps:

[0034] S1: The storage space of the power feeder terminal unit (FTU) is divided into an operating area, a backup-transfer area, and a cache area; among them, the operating area is the FTU's Flash1 storage area, which is used to run the current version of the program file or upgrade data file; the backup-transfer area is the FTU's Flash2 storage area; and the cache area is the FTU's SDRAM cache.

[0035] S2: After the FTU upgrade command is triggered, the operating status parameters of the FTU are detected. These operating status parameters include: power supply voltage stability, chip temperature, and remaining Flash lifespan. If at least one of the operating status parameters exceeds the corresponding preset safety threshold, the FTU upgrade is not performed, and the parameter category and value exceeding the corresponding preset safety threshold are reported. Otherwise, the dedicated network FTP server is logged in, and upgrade data frames are downloaded in segments to the cache via the wireless communication module. After each data frame is downloaded, the integrity of the corresponding data frame needs to be verified. If the verification fails, the failed data frame is downloaded again and verified again. If the verification succeeds, the download and verification task of the next data frame is executed. The preset safety threshold for power supply voltage stability is ±5% of the FTU's rated operating voltage, the preset safety threshold for chip temperature is the safe operating temperature range of the FTU's built-in CPU, and the preset safety threshold for remaining Flash lifespan is 5% of the total Flash lifespan. The size of each upgrade data frame is dynamically adjusted according to the real-time network quality.

[0036] S3: After all upgrade data frames are successfully downloaded, they are reassembled into an upgrade data file in sequence. The first target file checksum of the reassembled upgrade data file is calculated. If the first target file checksum matches the preset checksum provided by the private network FTP server, a reassembly success flag is generated; otherwise, the process returns to step S2. Based on the reassembly success flag, the upgrade data file is copied to the backup-transfer area. The second target file checksum of the copied upgrade data file in the backup-transfer area is calculated. If the second target file checksum matches the first target file checksum, a first copy success flag is generated; otherwise, the process of copying the upgrade data file to the backup-transfer area is repeated. Based on the first copy success flag, an upgrade start flag is written to the FTU's fixed flag detection address. The upgrade start flag is a custom hexadecimal identifier.

[0037] S4: After the Bootloader detects the upgrade start flag, it copies the upgrade data file from the backup-transfer area to the cache area. It calculates the third target file checksum of the upgraded data file in the cache area after copying. If the third target file checksum matches the second target file checksum, a second copy success flag is generated. Otherwise, the second copy is determined to have failed, and the process of copying the upgrade data file from the backup-transfer area to the cache area is repeated. If the number of times the second copy is determined to have failed exceeds a first preset number, the FTU upgrade is abandoned, and a program file copy failure signal is reported.

[0038] S5: Based on the second copy success flag, back up the currently running program file in the running area to the backup-transfer area. Calculate the first original file checksum and the second original file checksum of the current version program file in the running area and the backup-transfer area respectively. If the second original file checksum matches the first original file checksum, a backup success flag is generated; otherwise, the backup is determined to have failed, and the process of backing up the currently running program file in the running area to the backup-transfer area is repeated. If the number of backup failures exceeds a second preset number, the FTU upgrade is abandoned, and an original file backup failure signal is reported.

[0039] S6: Based on the backup success flag, copy the upgrade data file from the cache to the running area sector by sector with a preset sector size. After copying each sector of the upgrade data file fragment in the running area, verify the integrity of the corresponding upgrade data file fragment. If the verification passes, execute the copying and verification task for the upgrade data file fragment in the next sector; if the verification fails, re-execute the copying and verification task for the corresponding upgrade data file fragment. If the integrity verification of a certain upgrade data file fragment fails more than a third preset number of times, generate a copy failure flag. After all upgrade data file fragments pass the integrity verification, calculate the fourth target file checksum of the upgrade data file in the running area. If the fourth target file checksum matches the third target file checksum, generate a third copy success flag; otherwise, re-execute the process of copying the upgrade data file from the cache to the running area sector by sector with a preset sector size. If the fourth target file checksum does not match the third target file checksum more than a fourth preset number of times, generate a copy failure flag.

[0040] S7: If the third copy success flag is detected, clear the upgrade start flag, trigger an FTU soft reboot, and complete the remote upgrade of the FTU; if the copy failure flag is detected, copy the current version program file from the backup-transfer area to the running area sector by sector with a preset sector size. After copying each sector of the current version program file fragment in the running area, verify the integrity of the corresponding current version program file fragment. If the verification passes, execute the copy and verification task for the current version program file fragment in the next sector; if the verification fails, re-execute the copy and verification task for the corresponding current version program file fragment. If the integrity verification of the current version program file fragment in a certain sector of the running area fails more than the specified number of times... If the number of attempts exceeds five preset limits, the corresponding sector is marked as a bad block. The reserved spare sectors in the Flash hardware are then used to copy and verify the current version program file fragments in the corresponding sectors. After copying, all current version program file fragments in all sectors pass the integrity check. The third original file checksum of the current version program file in the runtime area is calculated. If the third original file checksum matches the second original file checksum, a rollback success flag is generated. Otherwise, the process of copying the current version program file from the backup-transfer area to the runtime area sector by sector, with a preset sector size, is repeated. Based on the rollback success flag, the upgrade start flag is cleared, an FTU soft reboot is triggered, an upgrade failure signal is generated, and the upgrade failure signal is reported.

[0041] Among them, CRC check can be used for frame-level and sector-level data verification, and MD5 check can be used for file-level integrity verification.

[0042] The first, second, third, fourth, and fifth preset times can be customized according to actual needs; in this embodiment, they are all set to 3 times.

[0043] Example 2

[0044] Based on Example 1, Example 2 will be described and illustrated with specific implementation cases.

[0045] This embodiment divides the FTU's storage space into a running area C1, a backup-transfer area C2, and a cache area SDRAM. A SIM7600 module is used as the wireless communication module, and the upgrade start flag is customized as 0x5A5A5A5A. A remote upgrade test was performed on an FTU. The results show that after the FTU completes its self-test and logs into the FTP server, it successfully downloads and reassembles the upgrade data file, generating a reassembly success flag. After writing the upgrade data file to the backup-transfer area, a first copy success flag is generated. Next, the device writes the upgrade start flag and initiates the upgrade process, entering the Bootloader upgrade control mode: the device first successfully copies the upgrade data file from the backup-transfer area C2 to the cache area SDRAM, generating a second copy success flag. Based on the second copy success flag, the device backs up the currently running program file in the running area C1 to the backup-transfer area C2. The system generates a backup success flag. Based on this flag, the upgrade data file in the SDRAM cache is successfully copied to the running area C1. After verification, a third copy success flag is generated. Detecting this flag indicates that the upgrade data file has been completely and accurately written to the running area C1. At this point, the bootloader executes a jump statement, jumping to the FTU's boot address to load the upgrade data file, successfully completing the remote FTU upgrade. During this FTU upgrade, the files in the running area C1 remain either complete original program files or complete upgrade program files until the device restarts. Even if an unexpected event occurs during the upgrade process, the bootloader can use the original program files backed up in the backup-transfer area C2 to quickly and completely roll back the files in the running area C1 to the original version, greatly reducing the possibility of the device becoming unusable and ensuring the continuity of FTU operation.

[0046] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0047] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for atomic remote upgrade of a power feeder terminal in a weak network environment, characterized in that, Includes the following steps: S1: Divide the storage space of the power feeder terminal unit (FTU) into an operating area, a backup-transfer area, and a buffer area; S2: After the FTU upgrade command is triggered, the operating status parameters of the FTU are detected. If at least one of the operating status parameters exceeds the corresponding preset security threshold, the FTU upgrade will not be performed, and the parameter category and parameter value that exceed the corresponding preset security threshold among the operating status parameters will be reported; otherwise, the private network FTP server will be logged in, and the upgrade data frame will be downloaded in segments to the cache area through the wireless communication module. S3: After all upgrade data frames are successfully downloaded, all the upgrade data frames are reassembled into an upgrade data file in sequence to generate a reassembly success flag. Based on the reassembly success flag, the upgrade data file is copied to the backup-transfer area to generate a first copy success flag. Based on the first copy success flag, an upgrade start flag is written into the FTU's solidified flag detection address. S4: After the Bootloader detects the upgrade start flag, it copies the upgrade data file in the backup-transfer area to the cache area and generates a second copy success flag; S5: Based on the second copy success flag, back up the currently running program file in the running area to the backup-transfer area and generate a backup success flag; S6: Based on the backup success flag, copy the upgrade data file in the cache area sector by sector to the running area with a preset sector size, and generate a third copy success flag or copy failure flag; S7: If the third copy success flag is detected, the upgrade start flag is cleared, an FTU soft reboot is triggered, and the remote upgrade of the FTU is completed; if the copy failure flag is detected, the current version program file in the backup-transfer area is copied sector by sector to the running area with a preset sector size, a rollback success flag is generated, the upgrade start flag is cleared according to the rollback success flag, an FTU soft reboot is triggered, an upgrade failure signal is generated, and the upgrade failure signal is reported.

2. The atomic remote upgrade method of power feeder terminal in weak network environment according to claim 1, characterized in that, The running area is the Flash1 storage area of ​​the FTU, and the running area is used to run the current version program file or the upgrade data file. The backup-transfer area is the Flash2 storage area of ​​the FTU, and the cache area is the SDRAM cache of the FTU.

3. The atomic remote upgrade method of power feeder terminal in weak network environment according to claim 1, characterized in that, The operating status parameters include: power supply voltage stability, chip temperature, and remaining Flash lifespan.

4. The atomic remote upgrade method of power feeder terminal in weak network environment according to claim 1, characterized in that, In step S2, during the step of downloading upgrade data frames in segments to the buffer via the wireless communication module, the integrity of the corresponding data frame needs to be verified after each data frame is downloaded. If the verification fails, the failed data frame is downloaded again and verified again. If the verification succeeds, the download and verification task of the next data frame is executed.

5. The atomic remote upgrade method of power feeder terminal in weak network environment according to claim 1, characterized in that, In step S3, after reassembling all the upgrade data frames into an upgrade data file in sequence, the method further includes: calculating the first target file checksum of the reassembled upgrade data file; if the first target file checksum matches the preset checksum provided by the private network FTP server, a reassembly success flag is generated; otherwise, the process returns to step S2.

6. The atomic remote upgrade method of a power feeder terminal in a weak network environment according to claim 5, wherein, In step S3, after copying the upgrade data file to the backup-transfer area, the method further includes: calculating the second target file checksum of the upgrade data file in the backup-transfer area after copying; if the second target file checksum is consistent with the first target file checksum, a first copy success flag is generated; otherwise, the copying of the upgrade data file to the backup-transfer area is performed again.

7. The atomic remote upgrade method of a power feeder terminal in a weak network environment according to claim 6, wherein, In step S4, after copying the upgrade data file from the backup-transfer area to the cache area, the method further includes: calculating the third target file checksum of the upgraded data file in the cache area after copying; if the third target file checksum matches the second target file checksum, a second copy success flag is generated; otherwise, the second copy is determined to have failed, and the process of copying the upgrade data file from the backup-transfer area to the cache area is repeated; if the number of times the second copy is determined to have failed exceeds a first preset number, the FTU upgrade is abandoned, and a program file copy failure signal is reported.

8. The atomic remote upgrade method of a power feeder terminal in a weak network environment according to claim 7, wherein, In step S5, after backing up the currently running program file in the running area to the backup-transfer area, the process further includes: calculating the first original file checksum and the second original file checksum of the currently running program file in the running area and the backup-transfer area respectively; if the second original file checksum matches the first original file checksum, a backup success flag is generated; otherwise, the backup is determined to have failed, and the process of backing up the currently running program file in the running area to the backup-transfer area is repeated; if the number of backup failures exceeds a second preset number, the FTU upgrade is abandoned, and an original file backup failure signal is reported.

9. The atomic remote upgrade method of power feeder terminal in weak network environment according to claim 8, characterized in that, In step S6, copying the upgrade data file from the cache to the running area sector by sector with a preset sector size specifically includes: verifying the integrity of the corresponding upgrade data file segment after copying each sector's upgrade data file segment in the running area; if the verification passes, executing the copying and verification task for the upgrade data file segment in the next sector; if the verification fails, re-executing the copying and verification task for the corresponding upgrade data file segment; if the number of integrity verification failures for a certain upgrade data file segment exceeds a third preset number, generating a copy failure flag; after all upgrade data file segments pass the integrity verification, calculating the fourth target file checksum of the upgrade data file in the running area; if the fourth target file checksum matches the third target file checksum, generating a third copy success flag; otherwise, re-executing the copying of the upgrade data file from the cache to the running area sector by sector with a preset sector size; if the number of times the fourth target file checksum does not match the third target file checksum exceeds a fourth preset number, generating a copy failure flag.

10. The atomic remote upgrade method of power feeder terminal in weak network environment according to claim 9, characterized in that, In step S7, copying the current version program file from the backup-transfer area to the running area sector by sector with a preset sector size specifically includes: after copying a current version program file segment from each sector in the running area, verifying the integrity of the corresponding current version program file segment; if the verification passes, executing the copying and verification task for the current version program file segment in the next sector; if the verification fails, re-executing the copying and verification task for the corresponding current version program file segment; if the integrity verification of the current version program file segment in a certain sector of the running area fails more than five times... If a preset number of attempts are made, the corresponding sector is marked as a bad block. The reserved spare sector in the Flash hardware is then used to perform the copying and verification of the current version program file fragment in the corresponding sector. After the copying, if the current version program file fragment in all sectors passes the integrity verification, the third original file checksum of the current version program file in the runtime area is calculated. If the third original file checksum is consistent with the second original file checksum, a rollback success flag is generated. Otherwise, the process of copying the current version program file from the backup-transfer area to the runtime area sector by sector with a preset sector size is repeated.

Images