Charging pile firmware online upgrading method and system

Abstract

The invention belongs to the field of online upgrading, and particularly relates to a charging pile firmware online upgrading method and system so as to solve the technical problems that errors cannot be positioned in real time through one-time verification, and verification and firmware module characteristics are disjointed due to the fact that a traditional Merkel tree adopts field reservation partitioning. The upgrading method comprises the following steps: S1, obtaining a plurality of secondary data blocks as leaf node data, and calculating a leaf node hash value for each piece of leaf node data by a server; s2, obtaining a final root hash; obtaining root Hash of the sub-trees, wherein the root Hash of all the sub-trees forms a sub-tree root Hash set; s3, comparing the local sub-tree root hash with the corresponding sub-tree root hash in the sub-tree root hash set, and verifying the integrity of the first-level data block; and S4, the server continues to transmit the remaining leaf node data from the first primary data block which is not verified completely according to the list, so that breakpoint resume is realized. The firmware upgrading efficiency and success rate are improved, the data retransmission amount is reduced, and communication resources are saved.

Description

Technical Field

[0001] This invention belongs to the field of online upgrades, and particularly relates to a method and system for online firmware upgrades of charging piles. Background Technology

[0002] With the rapid development of the new energy vehicle industry, the number of charging piles deployed and their application scope are expanding daily. In order to continuously optimize charging algorithms, fix potential security vulnerabilities, or add new interactive functions, the firmware of charging piles needs to be upgraded remotely online (OTA) regularly.

[0003] In practical applications, firmware upgrades for charging stations face numerous challenges: Firstly, the deployment environment of charging stations is complex, especially in underground parking lots or remote areas where network connections may be unstable, easily leading to firmware download interruptions. Once the full-packet download method is interrupted, it often needs to start from scratch, severely impacting upgrade efficiency and wasting significant network bandwidth resources. Secondly, firmware upgrade security is paramount. Data packets may be maliciously tampered with or unintentionally damaged during transmission. Execution without effective verification can result in charging station malfunctions and inability to bill properly.

[0004] To ensure data integrity, existing technologies typically perform a one-time verification by comparing the overall hash value or digital signature after the entire firmware upgrade package has been downloaded. This method cannot detect and locate erroneous data in real time during the download process; if verification fails, all the previous download time and resources are wasted. By dividing the firmware into blocks and constructing hash trees or Merkle trees, independent verification of data blocks is achieved, supporting breakpoint resumption to some extent. However, Merkle tree construction methods usually use fixed-length blocks, causing the verification and recovery mechanism to become disconnected from the modular nature of the firmware. When handling differential updates or interruption recovery involving only a portion of the modules, the communication overhead and management complexity remain high, failing to achieve the most efficient verification and resumption strategy. Summary of the Invention

[0005] This invention provides a method and system for online firmware upgrade of charging piles, which solves the technical problem that one-time verification cannot locate errors in real time, and that the traditional Merkle tree uses field segmentation, which leads to a disconnect between verification and firmware module characteristics.

[0006] In a first aspect, the present invention provides a method for online firmware upgrade of a charging pile, comprising the following steps: S1, the server partitions the firmware upgrade package based on preset logical function modules to obtain multiple first-level data blocks; first-level data blocks with a size smaller than a preset threshold are directly used as leaf node data; first-level data blocks with a size larger than the preset threshold are divided into fixed-length segments to obtain multiple second-level data blocks as leaf node data, and all leaf node data constitute the complete firmware content; the server calculates the leaf node hash value for each leaf node data. S2, the server constructs a complete Merkle tree based on the hash values ​​of all leaf nodes to obtain the final root hash; the server constructs a subtree from the hash values ​​of all leaf node data corresponding to each first-level data block to obtain the root hash of the subtree, and the root hashes of all subtrees constitute the subtree root hash set. S3, the charging pile terminal obtains the last root hash and subtree root hash set from the server; after the charging pile terminal receives all the leaf node data that constitutes any first-level data block, it constructs a subtree locally based on the hash value of the leaf node data and calculates the local subtree root hash. By comparing the local subtree root hash with the corresponding subtree root hash in the subtree root hash set, the integrity of the first-level data block is verified. S4. When the firmware upgrade is interrupted and resumed, the charging pile terminal reports a list of all first-level data blocks that have been verified and are complete to the server. The server then continues to transmit the remaining leaf node data starting from the first unverified first-level data block according to the list, thus achieving breakpoint resume transmission.

[0007] Furthermore, the server partitions the firmware upgrade package based on preset logical function modules to obtain multiple first-level data blocks, including the following steps: The firmware upgrade package is divided into a bootloader module, an operating system kernel module, a core application module, and a user interface resource module, with each module forming a primary data block.

[0008] Furthermore, first-level data blocks with a size smaller than a preset threshold are directly used as leaf node data; first-level data blocks with a size larger than the preset threshold are divided into fixed-length segments to obtain multiple second-level data blocks as leaf node data, including the following steps: The preset threshold is set to 1MB, and the length of the fixed-length segment is 256KB; When the size of the primary data block is greater than 1MB, the primary data block is divided into multiple secondary data blocks of 256KB. If the size of the last secondary data block is less than 256KB, the actual size of the secondary data block shall prevail.

[0009] Furthermore, the server calculates the leaf node hash value for each leaf node data. The method is defined by the following formula: ; in, For the preset hash operation, The content of the leaf node data, This is the global index number of the leaf node data. For firmware version identifier, This indicates a binary concatenation operation.

[0010] Furthermore, upon recovery after a firmware upgrade interruption, the charging station terminal reports to the server a list of all verified and complete Level 1 data blocks, including the following steps: The charging pile terminal sends a JSON object to the specified API endpoint of the server via an HTTPS POST request. The JSON object contains an array named "verified_blocks", which contains the index numbers of all verified and complete first-level data blocks in ascending order. The server parses the JSON object, determines the index number of the first missing first-level data block, and resumes transmission starting from the first leaf node data of the first-level data block corresponding to the index number.

[0011] Secondly, the present invention provides a charging pile firmware online upgrade system, comprising: Data block acquisition and processing unit: The server partitions the firmware upgrade package based on preset logical function modules to obtain multiple first-level data blocks; first-level data blocks with a size smaller than a preset threshold are directly used as leaf node data; first-level data blocks with a size larger than the preset threshold are split into fixed-length segments to obtain multiple second-level data blocks as leaf node data, and all leaf node data constitute the complete firmware content; the server calculates the leaf node hash value for each leaf node data. Merkle tree construction unit: The server constructs a complete Merkle tree based on the hash values ​​of all leaf nodes to obtain the final root hash; the server constructs a subtree from the hash values ​​calculated from all leaf node data corresponding to each first-level data block to obtain the root hash of the subtree, and the root hashes of all subtrees constitute the subtree root hash set; Integrity verification unit: The charging pile terminal obtains the last root hash and subtree root hash set from the server; after the charging pile terminal receives all the leaf node data that constitutes any first-level data block, it constructs a subtree locally based on the hash value of the leaf node data and calculates the local subtree root hash. By comparing the local subtree root hash with the corresponding subtree root hash in the subtree root hash set, the integrity of the first-level data block is verified. Resumable Transmission Unit: When the firmware upgrade is interrupted and resumed, the charging pile terminal reports a list of all first-level data blocks that have been verified and are complete to the server. The server then continues to transmit the remaining leaf node data starting from the first incomplete first-level data block according to the list, thus achieving resumeable transmission.

[0012] Furthermore, the server partitions the firmware upgrade package based on preset logical function modules to obtain multiple first-level data blocks, including the following steps: The firmware upgrade package is divided into a bootloader module, an operating system kernel module, a core application module, and a user interface resource module, with each module forming a primary data block.

[0013] Furthermore, first-level data blocks with a size smaller than a preset threshold are directly used as leaf node data; first-level data blocks with a size larger than the preset threshold are divided into fixed-length segments to obtain multiple second-level data blocks as leaf node data, including the following steps: The preset threshold is set to 1MB, and the length of the fixed-length segment is 256KB; When the size of the primary data block is greater than 1MB, the primary data block is divided into multiple secondary data blocks of 256KB. If the size of the last secondary data block is less than 256KB, the actual size of the secondary data block shall prevail.

[0014] Furthermore, the server calculates the leaf node hash value for each leaf node data. The method is defined by the following formula: ; in, For the preset hash operation, The content of the leaf node data, This is the global index number of the leaf node data. For firmware version identifier, This indicates a binary concatenation operation.

[0015] Furthermore, upon recovery after a firmware upgrade interruption, the charging station terminal reports to the server a list of all verified and complete Level 1 data blocks, including the following steps: The charging pile terminal sends a JSON object to the specified API endpoint of the server via an HTTPS POST request. The JSON object contains an array named "verified_blocks", which contains the index numbers of all verified and complete first-level data blocks in ascending order. The server parses the JSON object, determines the index number of the first missing first-level data block, and resumes transmission starting from the first leaf node data of the first-level data block corresponding to the index number.

[0016] The beneficial effects are as follows: This invention constructs a subtree verification system closely related to the firmware logical structure by first-level partitioning the firmware upgrade package according to logical functional modules and combining this with secondary fixed-length segmentation of large-size modules. This allows the charging pile terminal to immediately perform independent and complete verification by comparing the subtree root hash after receiving all data from any logical module, without waiting for the entire firmware download to complete. Therefore, when the upgrade process is interrupted due to network instability, it can achieve precise breakpoint resumption by using logical modules that have passed integrity verification as the smallest unit, resuming only the data of modules that are incomplete or have failed verification. This not only improves the efficiency and success rate of firmware upgrades and copes with complex network environments, but also reduces data retransmission and saves communication resources. Furthermore, by incorporating the global index sequence number and firmware version identifier into the hash calculation, the rigor of data verification is enhanced, ensuring the security and reliability of the upgrade process. Attached Figure Description

[0017] Figure 1 This is a diagram illustrating the first-level partition of a firmware upgrade package. Figure 2 This is a schematic diagram of the secondary partitioning of a primary data block; Figure 3 A schematic diagram of leaf node hash calculation; Figure 4 A schematic diagram of a two-level Merkle tree structure; Figure 5 This is a flowchart of the resume download process. Detailed Implementation

[0018] An embodiment of the online firmware upgrade method for charging piles provided by this invention: A method for online firmware upgrade of a charging pile includes the following steps: S1, the server partitions the firmware upgrade package based on preset logical function modules to obtain multiple first-level data blocks; first-level data blocks with a size smaller than a preset threshold are directly used as leaf node data; first-level data blocks with a size larger than the preset threshold are divided into fixed-length segments to obtain multiple second-level data blocks as leaf node data, and all leaf node data constitute the complete firmware content; the server calculates the leaf node hash value for each leaf node data.

[0019] The server identifies the individual functional parts within the firmware upgrade package based on the firmware's compilation configuration file or description file. These components include the bootloader, operating system kernel, file system, and specific applications. Subsequently, the server physically divides the firmware binary file according to these logical boundaries. For example, a 10MB firmware upgrade package is divided into a 512KB bootloader data block, a 4MB kernel data block, and a 5.488MB application data block; these three constitute the first-level data blocks. Figure 1 As shown.

[0020] Assuming a preset threshold of 256KB, for a 512KB Bootloader data block, because its size exceeds 256KB, the server will perform a secondary fixed-length split on the data block, for example, dividing it into eight 64KB secondary data blocks. For a 4MB Kernel data block, it will also be split into 64 secondary data blocks in 64KB units. If there is a 100KB configuration file module, because its size is less than 256KB, the configuration file module itself is treated as a whole and not split. These eight secondary data blocks from the Bootloader, the 64 secondary data blocks from the Kernel, and the 100KB configuration file module together constitute the leaf node data of the Merkle tree, as shown below. Figure 2 As shown.

[0021] The default hash operation is preferably the SHA-256 algorithm. Taking firmware version V1.0.1 as an example, the first leaf node data is the first 64KB data block of the Bootloader, with a global index number of 0. The server concatenates this 64KB binary content, the string "0", and the string "V1.0.1" into a byte stream, performs a SHA-256 operation on this byte stream, and obtains the hash value of the leaf node. The second leaf node data is the second 64KB data block of the Bootloader, with a global index number of 1. The server concatenates and hashes the content, the string "1", and the string "V1.0.1", and so on, generating a unique hash value for all leaf node data. Figure 3 As shown.

[0022] S2, the server constructs a complete Merkle tree based on the hash values ​​of all leaf nodes to obtain the final root hash; the server constructs a subtree from the hash values ​​calculated by all leaf node data corresponding to each first-level data block to obtain the root hash of the subtree, and the root hashes of all subtrees constitute the subtree root hash set.

[0023] Taking the aforementioned Bootloader module as an example, the server pairs the eight leaf node hashes generated for the module, calculates the hash value for each pair, and generates four parent node hashes. These four hashes are then paired again to generate two hashes. Finally, the two hashes are paired again to generate a unique subtree root hash, which is the subtree root hash of the Bootloader module. The server performs the same operation on all other first-level data blocks, such as the Kernel, to obtain their respective subtree root hashes.

[0024] Subsequently, all these subtree root hashes (e.g., Bootloader subtree root hash, Kernel subtree root hash, Application subtree root hash) are used as new leaf nodes. Following the same pairwise hashing method, a higher-level Merkle tree is constructed. The unique hash value at the top is the final root hash of the entire firmware, such as... Figure 4 As shown.

[0025] S3, the charging pile terminal obtains the last root hash and subtree root hash set from the server; after the charging pile terminal receives all the leaf node data that constitutes any first-level data block, it constructs a subtree locally based on the hash value of the leaf node data and calculates the local subtree root hash. By comparing the local subtree root hash with the corresponding subtree root hash in the subtree root hash set, the integrity of the first-level data block is verified.

[0026] Before the upgrade begins, the charging station terminal downloads a metadata file from the server, which contains the final root hash and a list of subtree root hashes for all modules. The charging station terminal then begins downloading eight 64KB secondary data blocks from the Bootloader module. After all eight secondary data blocks are received, the charging station terminal locally calculates eight local leaf node hash values ​​by concatenating the global index numbers 0 to 7 and the firmware version identifier V1.0.1. Using these eight local hash values, the terminal constructs a subtree locally using the same pairwise hashing method as the server, calculating a local Bootloader subtree root hash. The locally calculated local subtree root hash is compared with the server's Bootloader subtree root hash obtained from the metadata file. If they match completely, it proves that the Bootloader module data has been received completely and without errors.

[0027] S4. When the firmware upgrade is interrupted and resumed, the charging pile terminal reports a list of all first-level data blocks that have been verified and are complete to the server. The server then continues to transmit the remaining leaf node data starting from the first unverified first-level data block according to the list, thus achieving breakpoint resume transmission.

[0028] Assume the charging station terminal has successfully downloaded and verified the Bootloader and Kernel first-level data blocks, but the network connection is interrupted during the download of the Application data block. When the network is restored, the charging station terminal sends a resume request to the server, containing a list of completed modules, including the Bootloader and Kernel. Upon receiving the request and parsing the list, the server checks the complete firmware module sequence table and confirms that the first two modules are complete. Therefore, the server skips all leaf node data for the Bootloader and Kernel, directly locates the first leaf node data of the Application module, and continues transmitting to the charging station terminal from this data block until all remaining modules have been transmitted. Figure 5 As shown.

[0029] In an optional embodiment, the server partitions the firmware upgrade package based on preset logical functional modules to obtain multiple first-level data blocks, including the following steps: The firmware upgrade package is divided into a bootloader module, an operating system kernel module, a core application module, and a user interface resource module, with each module forming a primary data block.

[0030] Assuming a firmware upgrade package to be upgraded is 80MB in total size, the server does not treat the firmware upgrade package as a single unit, but instead divides it according to its internal logical functional structure. For example, the bootloader module is 512KB in size and is divided into the first primary data block with an index of 0. The operating system kernel module (such as the Linux kernel) is 10MB in size and is divided into the second primary data block with an index of 1. The core application module contains the main business logic programs of the charging pile, and its size is 55MB, divided into the third primary data block with an index of 2. The user interface resource module contains icons, fonts, and multilingual text, etc., and its total size is 14.488MB, which is the fourth primary data block with an index of 3.

[0031] In this way, the entire firmware upgrade process is logically broken down into updates to four independent functional modules. The advantage of this approach is that if an error occurs during the transmission or verification of a module (such as the core application module), the charging station terminal only needs to re-request that first-level data block, without having to re-download the entire 80MB firmware upgrade package. This functional module division makes the upgrade process more flexible and efficient, especially in situations with unstable networks, improving the recovery efficiency of interrupted transmissions and the success rate of the upgrade.

[0032] In an optional embodiment, first-level data blocks with a size smaller than a preset threshold are directly used as leaf node data; first-level data blocks with a size larger than the preset threshold are divided into fixed-length segments to obtain multiple second-level data blocks as leaf node data, including the following steps: The preset threshold is set to 1MB, and the length of the fixed-length segment is 256KB; When the size of the primary data block is greater than 1MB, the primary data block is divided into multiple secondary data blocks of 256KB. If the size of the last secondary data block is less than 256KB, the actual size of the secondary data block shall prevail.

[0033] Taking the aforementioned 80MB firmware upgrade package as an example, the preset threshold is 1MB, and the fixed-length segment is 256KB. For the first primary data block (i.e., the 512KB bootloader module), since its size is less than 1MB, it constitutes a complete leaf node data on its own. For the second primary data block (i.e., the 10MB operating system kernel module), its size is greater than 1MB, so it needs to be segmented a second time. The server will segment the second primary data block into 40 secondary data blocks, each 256KB in size. These 40 secondary data blocks together constitute the leaf node data set corresponding to the operating system kernel module.

[0034] Similarly, the 55MB core application module will be divided into 220 secondary data blocks of 256KB each. The 14.488MB user interface resource module, with a size of 14835.2KB, will be divided into 57 secondary data blocks of 256KB each, and a final secondary data block of 243.2KB.

[0035] Large functional modules are further subdivided into data slices of uniform size, which facilitates subsequent slice-by-slice hash verification and transmission control, enabling more granular verification of data integrity and ensuring data accuracy during transmission.

[0036] In an optional embodiment, the server calculates a leaf node hash value for each leaf node data. The method is defined by the following formula: ; in, For the preset hash operation, The content of the leaf node data, This is the global index number of the leaf node data. For firmware version identifier, This indicates a binary concatenation operation.

[0037] Taking the first 256KB secondary data block of the operating system kernel module as an example, we will illustrate the calculation process of the leaf node hash value. This involves retrieving the content of the leaf node data. That is, this 256KB of binary data. Furthermore, it determines the global index number of the leaf node data. Since the bootloader module is the first leaf node data, with an index of 0, the global index number of this second-level data block is 1. Retrieve firmware version identifier. For example, the string v1.2.0.

[0038] During computation, the server concatenates the three data parts into binary data. First, it retrieves 256KB of data, then concatenates it with the binary representation of the integer 1, followed by the binary representation of the string "v1.2.0". After forming a large binary data stream, the server uses the SHA-256 hash algorithm to calculate a 256-bit hash value. This hash value serves as the unique verification fingerprint for the leaf node data. It not only ensures that the data content itself has not been tampered with, but also, by binding to the global index and firmware version, prevents data blocks from being rearranged, replaced, or used to attack other firmware versions.

[0039] In an optional embodiment, when the firmware upgrade is interrupted and then resumed, the charging pile terminal reports a list of all first-level data blocks that have passed verification to the server, including the following steps: The charging pile terminal sends a JSON object to the specified API endpoint of the server via an HTTPS POST request. The JSON object contains an array named "verified_blocks", which contains the index numbers of all verified and complete first-level data blocks in ascending order. The server parses the JSON object, determines the index number of the first missing first-level data block, and resumes transmission starting from the first leaf node data of the first-level data block corresponding to the index number.

[0040] Assume the firmware upgrade package contains four primary data blocks, indexed 0, 1, 2, and 3. The charging station terminal has successfully downloaded and fully verified the bootloader module (index 0) and the operating system kernel module (index 1). While downloading the core application module (index 2), the network connection is suddenly interrupted. After the network is restored, the charging station terminal needs to continue the upgrade from the point of interruption, rather than starting from scratch.

[0041] To enable resumeable data transmission, the charging station terminal sends an HTTPS POST request to the server's upgrade interface, such as api.server.com / firmware / resume. The request body is a JSON object with the content {"verified_blocks":[0,1]}. The first-level data blocks with indices 0 and 1 are already securely stored on the terminal. Upon receiving this request, the charging station server parses the JSON content and determines that the client has completed the first two first-level data blocks. The charging station server then determines that the next first-level data block to be transmitted is the core application module with index 2, and continues transmitting data to the charging station terminal starting from the first leaf node data of the core application module (i.e., the first 256KB data block), thus resuming the upgrade process.

[0042] An embodiment of the online firmware upgrade system for charging piles provided by this invention: A charging pile firmware online upgrade system includes: Data block acquisition and processing unit: The server partitions the firmware upgrade package based on preset logical function modules to obtain multiple first-level data blocks; first-level data blocks with a size smaller than a preset threshold are directly used as leaf node data; first-level data blocks with a size larger than the preset threshold are split into fixed-length segments to obtain multiple second-level data blocks as leaf node data, and all leaf node data constitute the complete firmware content; the server calculates the leaf node hash value for each leaf node data. Merkle tree construction unit: The server constructs a complete Merkle tree based on the hash values ​​of all leaf nodes to obtain the final root hash; the server constructs a subtree from the hash values ​​calculated from all leaf node data corresponding to each first-level data block to obtain the root hash of the subtree, and the root hashes of all subtrees constitute the subtree root hash set; Integrity verification unit: The charging pile terminal obtains the last root hash and subtree root hash set from the server; after the charging pile terminal receives all the leaf node data that constitutes any first-level data block, it constructs a subtree locally based on the hash value of the leaf node data and calculates the local subtree root hash. By comparing the local subtree root hash with the corresponding subtree root hash in the subtree root hash set, the integrity of the first-level data block is verified. Resumable Transmission Unit: When the firmware upgrade is interrupted and resumed, the charging pile terminal reports a list of all first-level data blocks that have been verified and are complete to the server. The server then continues to transmit the remaining leaf node data starting from the first incomplete first-level data block according to the list, thus achieving resumeable transmission.

[0043] Furthermore, the server partitions the firmware upgrade package based on preset logical function modules to obtain multiple first-level data blocks, including the following steps: The firmware upgrade package is divided into a bootloader module, an operating system kernel module, a core application module, and a user interface resource module, with each module forming a primary data block.

[0044] Furthermore, first-level data blocks with a size smaller than a preset threshold are directly used as leaf node data; first-level data blocks with a size larger than the preset threshold are divided into fixed-length segments to obtain multiple second-level data blocks as leaf node data, including the following steps: The preset threshold is set to 1MB, and the length of the fixed-length segment is 256KB; When the size of the primary data block is greater than 1MB, the primary data block is divided into multiple secondary data blocks of 256KB. If the size of the last secondary data block is less than 256KB, the actual size of the secondary data block shall prevail.

[0045] Furthermore, the server calculates the leaf node hash value for each leaf node data. The method is defined by the following formula: ; in, For the preset hash operation, The content of the leaf node data, This is the global index number of the leaf node data. For firmware version identifier, This indicates a binary concatenation operation.

[0046] Furthermore, upon recovery after a firmware upgrade interruption, the charging station terminal reports to the server a list of all verified and complete Level 1 data blocks, including the following steps: The charging pile terminal sends a JSON object to the specified API endpoint of the server via an HTTPS POST request. The JSON object contains an array named "verified_blocks", which contains the index numbers of all verified and complete first-level data blocks in ascending order. The server parses the JSON object, determines the index number of the first missing first-level data block, and resumes transmission starting from the first leaf node data of the first-level data block corresponding to the index number.

Claims

1. A method for online firmware upgrade of a charging pile, characterized in that, Includes the following steps: S1, the server partitions the firmware upgrade package based on preset logical function modules to obtain multiple first-level data blocks; First-level data blocks with a size smaller than a preset threshold are directly used as leaf node data; First-level data blocks with a size greater than a preset threshold are split into fixed-length segments to obtain multiple second-level data blocks as leaf node data. All leaf node data constitute the complete firmware content. The server calculates the leaf node hash value for each leaf node data. S2, the server constructs a complete Merkle tree based on the hash values ​​of all leaf nodes to obtain the final root hash; the server constructs a subtree from the hash values ​​of all leaf node data corresponding to each first-level data block to obtain the root hash of the subtree, and the root hashes of all subtrees constitute the subtree root hash set. S3, the charging pile terminal obtains the last root hash and subtree root hash set from the server; When the charging pile terminal receives all the leaf node data that constitutes any first-level data block, it constructs a subtree locally based on the hash value of the leaf node data and calculates the local subtree root hash. The integrity of the first-level data block is verified by comparing the local subtree root hash with the corresponding subtree root hash in the subtree root hash set. S4. When the firmware upgrade is interrupted and resumed, the charging pile terminal reports a list of all first-level data blocks that have been verified and are complete to the server. The server then continues to transmit the remaining leaf node data starting from the first unverified first-level data block according to the list, thus achieving breakpoint resume transmission.

2. The online firmware upgrade method for charging piles according to claim 1, characterized in that, The server partitions the firmware upgrade package based on preset logical function modules to obtain multiple first-level data blocks, including the following steps: The firmware upgrade package is divided into a bootloader module, an operating system kernel module, a core application module, and a user interface resource module, with each module forming a primary data block.

3. The online firmware upgrade method for charging piles according to claim 2, characterized in that, First-level data blocks with a size smaller than a preset threshold are directly used as leaf node data; First-level data blocks larger than a preset threshold are split into fixed-length segments to obtain multiple second-level data blocks as leaf node data, including the following steps: The preset threshold is set to 1MB, and the length of the fixed-length segment is 256KB; When the size of the primary data block is greater than 1MB, the primary data block is divided into multiple secondary data blocks of 256KB. If the size of the last secondary data block is less than 256KB, the actual size of the secondary data block shall prevail.

4. The online firmware upgrade method for charging piles according to claim 3, characterized in that, The server calculates the leaf node hash value for each leaf node data. The method is defined by the following formula: ; in, For the preset hash operation, The content of the leaf node data, This is the global index number of the leaf node data. For firmware version identifier, This indicates a binary concatenation operation.

5. The online firmware upgrade method for charging piles according to any one of claims 1-4, characterized in that, When the firmware upgrade is interrupted and resumed, the charging pile terminal reports a list of all verified and complete first-level data blocks to the server, including the following steps: The charging pile terminal sends a JSON object to the specified API endpoint of the server via an HTTPS POST request. The JSON object contains an array named "verified_blocks", which contains the index numbers of all verified and complete first-level data blocks in ascending order. The server parses the JSON object, determines the index number of the first missing first-level data block, and resumes transmission starting from the first leaf node data of the first-level data block corresponding to the index number.

6. A charging pile firmware online upgrade system, characterized in that, include: Data block acquisition and processing unit: The server partitions the firmware upgrade package based on preset logical function modules to obtain multiple first-level data blocks; First-level data blocks with a size smaller than a preset threshold are directly used as leaf node data; First-level data blocks with a size greater than a preset threshold are split into fixed-length segments to obtain multiple second-level data blocks as leaf node data. All leaf node data constitute the complete firmware content. The server calculates the leaf node hash value for each leaf node data. Merkle tree construction unit: The server constructs a complete Merkle tree based on the hash values ​​of all leaf nodes to obtain the final root hash; the server constructs a subtree from the hash values ​​calculated from all leaf node data corresponding to each first-level data block to obtain the root hash of the subtree, and the root hashes of all subtrees constitute the subtree root hash set; Integrity verification unit: The charging pile terminal obtains the last root hash and subtree root hash set from the server; When the charging pile terminal receives all the leaf node data that constitutes any first-level data block, it constructs a subtree locally based on the hash value of the leaf node data and calculates the local subtree root hash. The integrity of the first-level data block is verified by comparing the local subtree root hash with the corresponding subtree root hash in the subtree root hash set. Resumable Transmission Unit: When the firmware upgrade is interrupted and resumed, the charging pile terminal reports a list of all first-level data blocks that have been verified and are complete to the server. The server then continues to transmit the remaining leaf node data starting from the first incomplete first-level data block according to the list, thus achieving resumeable transmission.

7. The online firmware upgrade system for charging piles according to claim 6, characterized in that, The server partitions the firmware upgrade package based on preset logical function modules to obtain multiple first-level data blocks, including the following steps: The firmware upgrade package is divided into a bootloader module, an operating system kernel module, a core application module, and a user interface resource module, with each module forming a primary data block.

8. The online firmware upgrade system for charging piles according to claim 7, characterized in that, First-level data blocks with a size smaller than a preset threshold are directly used as leaf node data; First-level data blocks larger than a preset threshold are split into fixed-length segments to obtain multiple second-level data blocks as leaf node data, including the following steps: The preset threshold is set to 1MB, and the length of the fixed-length segment is 256KB; When the size of the primary data block is greater than 1MB, the primary data block is divided into multiple secondary data blocks of 256KB. If the size of the last secondary data block is less than 256KB, the actual size of the secondary data block shall prevail.

9. The online firmware upgrade system for charging piles according to claim 8, characterized in that, The server calculates the leaf node hash value for each leaf node data. The method is defined by the following formula: ; in, For the preset hash operation, The content of the leaf node data, This is the global index number of the leaf node data. For firmware version identifier, This indicates a binary concatenation operation.

10. The online firmware upgrade system for charging piles according to any one of claims 6-9, characterized in that, When the firmware upgrade is interrupted and resumed, the charging pile terminal reports a list of all verified and complete first-level data blocks to the server, including the following steps: The charging pile terminal sends a JSON object to the specified API endpoint of the server via an HTTPS POST request. The JSON object contains an array named "verified_blocks", which contains the index numbers of all verified and complete first-level data blocks in ascending order. The server parses the JSON object, determines the index number of the first missing first-level data block, and resumes transmission starting from the first leaf node data of the first-level data block corresponding to the index number.

Images