Cloud batch firmware upgrading method and system for old charging pile

Abstract

The application relates to the technical field of electric digital data processing, and discloses a cloud-based batch firmware upgrading method and system for old charging piles. The method comprises the following steps: acquiring current running state data of the old charging pile, constructing a four-element constraint image, acquiring a current firmware and a target firmware, and generating a firmware version difference dependency graph; determining a difference slice sequence meeting a storage safety constraint according to the four-element constraint image and the difference dependency graph, arranging hierarchical breakpoint anchors and generating a breakpoint state table; performing safety verification on the segment before writing into the charging pile, and performing writing after the verification; when a transmission interruption or verification failure occurs, performing breakpoint recovery and difference reorganization verification according to the breakpoint state table and resuming transmission, and performing integrity verification after all segments are written; if the verification is passed, monitoring heartbeat and communication handshake state to determine whether the upgrading is completed, otherwise, returning to the version before the upgrading. The application improves the upgrading success rate, reliability and safety of the old charging pile.

Description

Technical Field

[0001] This application relates to the field of electronic digital data processing technology, and in particular to a cloud-based batch firmware upgrade method and system for old charging piles. Background Technology

[0002] With the continuous increase in the number of new energy vehicles, the operation and maintenance pressure on charging piles, as a critical infrastructure, is becoming increasingly prominent. Remote firmware upgrades have become a core means to ensure the functional iteration and security vulnerability repair of charging piles. However, a large number of older charging piles deployed in the early stages face multiple technical challenges during the firmware upgrade process.

[0003] First, the capabilities of older charging piles exhibit significant fragmentation. Different batches of devices vary considerably in storage partition size, communication module performance, and cache space configuration, with some devices possessing only minimal operating resources. Traditional upgrade solutions employ a uniform firmware package push strategy, failing to adapt to the actual capacity of individual devices, frequently resulting in upgrade interruptions due to insufficient storage space. Second, the dependencies between firmware modules further exacerbate upgrade complexity. The firmware of older charging piles typically consists of multiple functional partitions, such as a billing module, communication protocol stack, and power management unit, with inter-module dependencies and data interactions. If modules are not updated in the correct order during the upgrade process, interface incompatibility or functional failure can occur. More seriously, incorrect upgrades of some modules can affect the rollback operations of other modules, ultimately potentially causing the entire device to fail to boot. Furthermore, charging piles are often deployed in areas with weak signal coverage, such as underground parking garages and remote sites, frequently encountering network fluctuations during upgrades. Traditional solutions lack precise recovery mechanisms after transmission interruptions, requiring the entire firmware package to be retransmitted from scratch, wasting bandwidth and extending the upgrade cycle. Data corruption during transmission is also difficult to detect in a timely manner; the problem only becomes apparent when the device restarts after erroneous fragments have been written to the partition.

[0004] Therefore, how to build an upgrade mechanism that can adapt to individual constraints, satisfy module dependencies, resist network fluctuations, and ensure data integrity under the premise of limited and differentiated equipment capabilities has become an urgent technical problem to be solved in the field of firmware upgrades for old charging piles. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a cloud-based batch firmware upgrade method and system for older charging piles, which solves the problem of low reliability in firmware upgrades under environments with fragmented device capabilities and unstable communication networks.

[0006] Firstly, this application provides a cloud-based batch firmware upgrade method for older charging piles, the method comprising: Step S1: Obtain the current operating status data of the old charging pile, construct a four-element constraint profile of the old charging pile including version, partition, link and cache, obtain the current firmware and target firmware, and generate a firmware version difference dependency graph based on the current firmware and the target firmware. Step S2: Based on the quaternion constraint profile and the firmware version difference dependency graph, determine the differential sharding sequence that satisfies the storage security constraints, and set up hierarchical breakpoint anchors for the differential sharding sequence and generate a breakpoint status table; Step S3: The cloud server adaptively transmits differential segments based on the real-time link quality data, cache usage, and segment verification results of the old charging pile. Before writing each differential segment, the old charging pile performs a security verification on the current differential segment. After the verification is passed, the writing is performed. Step S4: When transmission is interrupted or verification fails, breakpoint recovery and differential reassembly verification are performed according to the breakpoint status table. After all differential segments are written from the breakpoint, integrity verification of the entire packet and service partition is performed on the written firmware. Step S5: If the integrity verification passes, restart the old charging pile, monitor the device heartbeat and communication handshake status after restarting to determine the upgrade completion status. If the integrity verification fails or the device heartbeat is abnormal, restore the old charging pile to the firmware version before the upgrade.

[0007] Secondly, this application provides a cloud-based batch firmware upgrade system for older charging piles, the system comprising: The data acquisition module is used to acquire the current operating status data of old charging piles, construct a four-element constraint profile of the old charging piles (version, partition, link, and cache), acquire the current firmware and the target firmware, and generate a firmware version difference dependency graph based on the current firmware and the target firmware. The hierarchical breakpoint module is used to determine the differential sharding sequence that satisfies the storage security constraints based on the quaternary constraint profile and the firmware version difference dependency graph, and to set hierarchical breakpoint anchors for the differential sharding sequence and generate a breakpoint status table. The security verification module is used by the cloud server to adaptively transmit differential segments based on the real-time link quality data, cache usage, and segment verification results of the old charging pile. Before writing each differential segment, the old charging pile performs a security verification on the current differential segment, and executes the writing after the verification is passed. The fragment writing module is used to perform breakpoint recovery and differential reassembly verification according to the breakpoint status table when the transmission is interrupted or the verification fails. After all differential fragments are written from the breakpoint, the module performs integrity verification on the written firmware for the whole packet and service partition. The continuous monitoring module is used to restart the old charging pile if the integrity verification passes, monitor the device heartbeat and communication handshake status after restarting to determine the upgrade completion status, and restore the old charging pile to the firmware version before the upgrade if the integrity verification fails or the device heartbeat is abnormal.

[0008] Compared with the prior art, the beneficial effects of the present invention are at least as follows: This application constructs a four-element constraint profile of version, partition, link, and cache, combined with a firmware version difference dependency graph, to accurately quantify the personalized capability boundaries of each old charging pile and clarify the upgrade dependencies between modules. This ensures that the segmentation and sorting of the differential sharding sequence and the dynamic removal of low-priority shards not only meet storage security constraints but also follow the upgrade order determined by internal firmware call dependencies and data dependencies, thereby avoiding upgrade failures and system anomalies caused by device capability fragmentation and module dependency disorder from the source.

[0009] Based on this, this application dynamically deploys first-level and second-level breakpoint anchors and generates a breakpoint status table according to the comprehensive link quality score. It adaptively adjusts the transmission rate by combining real-time link quality, cache usage and fragment verification results. Before writing, it performs local hash verification, power supply status detection and service session status detection on each differential fragment. Only after multiple verifications are passed will the writing be performed, which significantly improves the transmission reliability and data disk security in weak network environments.

[0010] When transmission is interrupted or verification fails, the last breakpoint anchor point is accurately located based on the breakpoint status table, and breakpoint recovery and differential reassembly verification are performed. Only the incomplete data is resumed, avoiding the bandwidth waste caused by full retransmission. After the resumed transmission is completed, dual verification is performed using the whole packet hash and the service partition hash. Combined with the monitoring of the device heartbeat and communication protocol handshake status after restart, a complete upgrade adjudication chain from data verification to operation verification is constructed. If any link fails, an atomic rollback is triggered to restore the device to the version before the upgrade, effectively ensuring a high success rate of the upgrade process and high availability of the device. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart of a cloud-based batch firmware upgrade method for old charging piles in an embodiment of this application. Figure 2 This is a flowchart of step S5 in an embodiment of this application; Figure 3 This is a structural architecture diagram of an embodiment of this application; Figure 4 This is a schematic diagram of the cloud-based batch firmware upgrade system for old charging piles, as described in an embodiment of this application. Detailed Implementation

[0013] This application provides a cloud-based batch firmware upgrade method and system for older charging piles. The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" or "having" and any variations thereof are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0014] For ease of understanding, the specific process of the embodiments of this application is described below. Please refer to [link / reference]. Figure 1 The cloud-based batch firmware upgrade method for older charging piles, as described in this application embodiment, includes: Step S1: Obtain the current operating status data of the old charging pile, construct a four-element constraint profile of the old charging pile including version, partition, link and cache, obtain the current firmware and target firmware, and generate a firmware version difference dependency graph based on the current firmware and target firmware.

[0015] In step S1, the process of constructing a four-element constraint profile of the old charging pile, including: obtaining hardware identifiers and current operating status data from the old charging pile; parsing the current operating status data; extracting the remaining storage space size and communication module type information; generating link constraints and cache constraints based on the remaining storage space size, communication module type information, and historical network fluctuation records; obtaining the current firmware version number and current partition table of the old charging pile; generating version constraints based on the current firmware version number; and generating partition constraints based on the current partition table.

[0016] Specifically, the first step is to acquire the current operational status data of older charging piles. These older charging piles are typically deployed in outdoor stations or underground parking lots, with relatively outdated hardware configurations, limited storage space, and communication modules that may use different standards. Their network conditions are also significantly affected by the on-site environment. To accurately characterize the actual capability boundaries of each device, the cloud-based upgrade server establishes a communication connection with the charging pile and sends a status query command to the charging pile. Upon receiving the query command, the charging pile reads the locally stored hardware identification information, which includes the device serial number, manufacturer identification, hardware model, and production batch. Simultaneously, it collects current operational status data, covering various aspects such as the usage of the storage system, the working status of the communication module, power supply parameters, and the operational logs of the business modules.

[0017] After obtaining the above data, the cloud server parses and processes the operational status data. The parsing process first identifies the format version of the data packets. Different batches of charging piles may use different data encapsulation protocols, and the parsing module matches the corresponding parsing rules based on the hardware identifier. After parsing, the remaining storage space and communication module type information of the older charging piles are extracted. The remaining storage space is calculated by subtracting the currently used space from the total storage capacity. The used space includes firmware usage, configuration file usage, log file usage, and temporary cache usage. The communication module type information includes the module model, supported frequency bands, maximum transmission rate, signal strength range, and protocol stack version. This information is read from the communication module's registers or obtained by querying the device configuration table.

[0018] Based on the extracted remaining storage space size, communication module standard information, and historical network fluctuation records, link constraints and cache constraints are generated in the four-element constraint profile. Among them, historical network fluctuation records refer to network quality data generated during the communication between the charging pile and the cloud server over a period of time, including statistical information such as packet loss rate, latency jitter, throughput fluctuation, and number of connection interruptions at different times. These data are usually stored in the cloud database in the form of time-series data.

[0019] The link constraint generation process first extracts the packet loss rate and latency jitter frequency of the charging pile over a past statistical period from historical network fluctuation records. Specifically, the packet loss rate is calculated as the ratio of the number of lost packets to the total number of packets sent within the statistical period, and the latency jitter frequency is calculated as the ratio of the number of events where the latency value deviates from the average latency by a preset threshold to the total number of communications. Based on this, the packet loss rate and latency jitter frequency are normalized to unify their dimensions to the same numerical range. Then, the normalized packet loss rate and latency jitter frequency are weighted and summed according to preset weights to generate a comprehensive link quality score. The weight of packet loss rate is set to 0.7, and the weight of latency jitter frequency is set to 0.3. The weight of packet loss rate is greater than that of latency jitter frequency because packet loss directly leads to data loss and requires retransmission, having a more significant impact on the upgrade task. This comprehensive link quality score is the final generated link constraint, used in subsequent steps to calculate the dynamic anchor insertion interval. A higher comprehensive link quality score indicates poorer link quality, requiring a denser deployment of breakpoint anchors. Simultaneously, by combining the theoretical maximum transmission rate and historical actual throughput records in the communication module standard information, the average and peak transmission rates of the device in different time periods are calculated, and rate constraint information is generated and incorporated into the link constraints, which serves as the basis for dynamic adjustment of the transmission rate in subsequent adaptive transmission strategies.

[0020] The generation of cache constraints is based on the remaining storage space and the device's cache management strategy. Older charging piles typically use a fixed-size buffer to temporarily store received differential fragments. The buffer capacity is determined by the device's hardware design. To avoid data loss due to buffer overflow, a safe single-transmission threshold needs to be calculated based on the remaining storage space and buffer configuration. This single-transmission threshold is the core parameter of the cache constraint. Specifically, the calculation method is as follows: using the buffer capacity as a baseline, a safety margin is reserved to cope with cache fragmentation and manage metadata space. This safety margin is either a fixed percentage of the total buffer capacity or dynamically set based on the statistical average of the cache fragmentation rate generated during the old charging pile's historical operation. The product of this percentage or dynamic setting value and the total buffer capacity is used as the reserved space. The available buffer size after deducting the safety margin is used as the maximum fragmentation threshold for a single transmission. This maximum fragmentation threshold is the specific manifestation of the cache constraint, used in subsequent steps to determine the upper limit of each differential fragment size, ensuring that the amount of data transmitted in a single transmission is always within the device's cache capacity, and providing a quantitative basis for the subsequent segmentation of differential fragment sequences.

[0021] Simultaneously, the current firmware version number and current partition table of the old charging pile are obtained. The current firmware version number is a unique identifier that identifies the firmware currently running on the charging pile. It usually adopts a multi-segment structure, including information such as major version number, minor version number, revision number, and compilation timestamp. By parsing the version number, the basic architecture, supported business functions, and known defect fixes of the firmware can be determined. This firmware version number directly serves as the specific content of the version constraint. The current partition table describes the logical partition structure of the charging pile storage system, containing multiple partition entries. Each entry records attributes such as the partition's starting address, size, type, permissions, and purpose. Common partition types include bootloader partitions, kernel partitions, business application partitions, configuration data partitions, and log storage partitions. The boundary address and size information of each partition are extracted from the current partition table to generate partition constraints. Version constraints and partition constraints, together with the aforementioned link constraints and cache constraints, constitute a complete four-element constraint profile. This profile is repeatedly referenced in subsequent differential fragmentation sequence generation, transmission strategy formulation, and write verification stages to ensure that the upgrade process is always carried out within the device's security constraints.

[0022] By constructing a four-element constraint profile covering version, partition, link, and cache, the personalized capability boundaries of each old charging pile can be accurately quantified, enabling upgrade strategies to adapt to complex operating conditions such as limited storage and network fluctuations, thus avoiding upgrade failures and system anomalies caused by fragmented device capabilities from the source.

[0023] The step S1 of generating the firmware version difference dependency graph includes: comparing the binary files of the current firmware and the target firmware to extract the changed business partitions and system partitions; analyzing the function call relationships and data dependencies within the business partitions and system partitions, determining the upgrade order of each partition based on the function call relationships and data dependencies, and generating partition priorities; constructing the firmware version difference dependency graph based on the partition priorities and the changed business partitions, and marking the call dependencies and rollback impact scope in the firmware version difference dependency graph.

[0024] Specifically, after constructing the quaternary constraint profile, in order to generate an upgrade strategy that adapts to the individual constraints of old charging piles, it is necessary to perform a structured analysis of the differences between the current firmware and the target firmware, clarify the calling dependencies and upgrade order between each change partition, so that the subsequent segmentation and sorting of differential fragment sequences have a reliable logical basis.

[0025] Specifically, the cloud server obtains the current firmware and the target firmware. The current firmware refers to the firmware version currently running and used by the old charging pile, i.e., the old version firmware already installed on the device before the upgrade, stored in the charging pile's storage medium, and is the starting point and baseline for this upgrade. The target firmware refers to the new firmware version that the old charging pile is expected to upgrade to, stored in the cloud server, containing feature iterations, bug fixes, or security vulnerability patches, and is the target endpoint for this upgrade. The cloud server obtains the current firmware by retrieving the firmware binary file corresponding to the current firmware version number from the firmware library stored in the cloud, based on the old charging pile's operating status data obtained in step S1. The cloud server obtains the target firmware by reading the pre-uploaded and configured new version firmware binary file from the cloud firmware library according to the preset upgrade task.

[0026] After obtaining the current firmware and the target firmware, the binary files of the two are compared. Both the current firmware and the target firmware are stored in binary file form. The comparison process adopts a byte-by-byte comparison method. First, the hash fingerprint of each firmware file is calculated. The difference between the two firmware versions is determined by the fast comparison of the hash fingerprint. If the hash fingerprint is inconsistent, it is determined that the firmware has been changed. Then, a detailed byte-level comparison is performed on the files with differences to locate the specific change location and change content. Based on this, the changed business partition and system partition are extracted.

[0027] For the extracted business partitions and system partitions, we analyze their internal function call relationships and data dependencies. The function call relationship describes the interface call path between different modules within the firmware. When one module calls the function interface provided by another module, the former depends on the latter. During the firmware upgrade process, the dependent module must complete the upgrade first. The data dependency relationship describes the data sharing and access mode between different modules within the firmware. When one module needs to read or modify the data structure generated by another module, the former has a data dependency on the latter.

[0028] Since function call graphs and data dependency graphs depict the relationships between modules from the dimensions of control flow and data flow, respectively, a single-dimensional analysis cannot fully reflect the true dependency constraints between modules. Therefore, it is necessary to merge the two to construct a unified directed dependency graph. The specific fusion method is as follows: using partitions or modules as nodes, and function call relationships and data dependencies as directed edges, when either a function call relationship or a data dependency relationship exists between two modules, a directed edge is established between the two nodes, with the direction of the edge pointing from the dependent to the dependent. For example, if the communication protocol processing module calls a low-level network interface function provided by the operating system kernel module, a directed edge is established in the dependency graph from the operating system kernel module to the communication protocol processing module, indicating that the communication protocol processing module depends on the operating system kernel module. Similarly, if the charging control logic module needs to read the rate parameter table in the configuration data partition, a directed edge is established in the dependency graph from the configuration data partition to the charging control logic module, indicating that the charging control logic module depends on the configuration data partition.

[0029] Based on this directed dependency graph, the upgrade order of each partition is determined by topological sorting. Topological sorting is a node sorting algorithm for directed acyclic graphs. Its basic logic is as follows: Find all nodes with an in-degree of zero in the graph. An in-degree of zero means that the node is not depended on by any other node, that is, the partition corresponding to the node does not depend on any other partition and can be upgraded first; remove the node from the graph and delete all its outgoing edges, and update the in-degree of the remaining nodes; repeat the above process until all nodes are removed. The order in which the nodes are removed is the upgrade order that satisfies all dependency constraints. If a cycle exists in the directed dependency graph, it indicates that there is a circular dependency between modules. At this time, an exception message is output and the upgrade task is terminated, because a circular dependency means that two modules depend on each other, and a valid upgrade order cannot be determined. In the node removal sequence obtained by topological sorting, the partition corresponding to the node removed first has a higher upgrade priority and should be upgraded first. The partition corresponding to the node removed later depends on the partition upgraded first and must wait for the partition to be upgraded before it can be upgraded. Once the upgrade order is determined, a priority value is assigned to each partition. The allocation method is as follows: the partition corresponding to the first node removed in the topological sorting sequence has the lowest priority value, indicating that it will be upgraded earliest. The priority values ​​of subsequent nodes increase sequentially, indicating that the upgrade order will be delayed sequentially.

[0030] A firmware version difference dependency graph is constructed based on partition priority and the changed business partitions. This graph marks call dependencies and the scope of rollback impact. The directed dependency graph generated in the previous steps encompasses all business partitions and system partitions and their inter-partition dependencies. The firmware version difference dependency graph is a simplification and annotation of this directed dependency graph. Its construction scope includes the changed business partitions and system partitions extracted in the previous steps, as well as other partitions associated with these changed partitions through call dependency paths. The construction method is as follows: using the changed partition as the core node, and connecting it with call dependency edges and data dependency edges in the directed dependency graph, all related partitions on the changed partition and its dependency paths are included in the firmware version difference dependency graph, and each node is marked with its partition priority value.

[0031] Based on this, call dependencies and rollback impact scope are marked in the firmware version difference dependency graph. Call dependencies are marked as follows: for each node in the graph, all upstream nodes that the node depends on are traced level by level along the directed edge, and the tracing results are marked on the corresponding node in the form of a call dependency list. This list records all partitions that must be upgraded before the current partition upgrade. Rollback impact scope is marked as follows: for each node in the graph, all downstream nodes that depend on the node are traced level by level along the opposite direction of the directed edge, and the tracing results are marked on the corresponding node in the form of a rollback impact list. This list records all partitions that must be rolled back when the partition upgrade fails and needs to be rolled back. Through these markings, each node in the firmware version difference dependency graph is accompanied by three types of attribute information: priority value, call dependency list, and rollback impact list. The directed edges between nodes retain the original dependency relationship type identifier to distinguish between call dependencies and data dependencies.

[0032] The firmware version difference dependency graph constructed in the above manner further clarifies the upstream and downstream dependency boundaries and fault impact radius of each changed partition based on the partition priority. This provides a quantitative basis for the decision to remove low-priority fragments during the subsequent differential fragmentation sequence generation process. It also defines a clear rollback range boundary for precise rollback operations in case of upgrade anomalies, enabling the upgrade task to have interpretable and quantifiable decision support when facing insufficient storage space or execution anomalies.

[0033] Step S2: Based on the quaternion constraint profile and firmware version difference dependency graph, determine the differential sharding sequence that satisfies the storage security constraints, and set up hierarchical breakpoint anchors for the differential sharding sequence and generate a breakpoint status table.

[0034] In step S2, determining the differential sharding sequence that satisfies storage security constraints includes: determining the boundary position of each partition based on the cache constraints in the quaternary constraint profile and the partitioning constraints, and combining the partitioning priority in the firmware version difference dependency graph to divide the complete differential packet into at least one initial shard; determining whether the cumulative size of the initial shards exceeds the remaining storage space of the old charging pile; if it does not exceed the remaining storage space, sorting the initial shards according to the partitioning priority to generate a preliminary differential sharding sequence.

[0035] Specifically, based on the quaternary constraint profile and firmware version difference dependency graph constructed in step S1, in order to generate an upgrade data package that adapts to the storage capacity of old charging piles, the complete differential package needs to be finely segmented and sorted according to the device caching capacity, partition boundaries and module dependencies.

[0036] First, the maximum fragmentation threshold for a single transmission is determined based on the cache constraints in the quaternion constraint profile. This threshold ensures that the size of each differential fragment is always within the capacity of the device cache. Based on this, the boundary positions of each partition are determined according to the partition constraints, ensuring that each initial fragment after subsequent splitting falls entirely within a single partition without crossing partition boundaries, thus avoiding data overwriting of adjacent partitions during writes due to fragments spanning two partitions. After obtaining the maximum fragmentation threshold and the boundary positions of each partition, the complete differential packet is split based on the partition priority in the firmware version difference dependency graph. During splitting, partitions to be processed are selected in ascending order of partition priority. The lower the priority value, the earlier the upgrade order, and the higher the priority for splitting and subsequent transmission. Then, the range of difference data corresponding to that partition in the complete differential packet is determined based on the boundary position of that partition. The complete differential packet is a binary file containing all the difference data between the two firmware versions, generated by comparing the current firmware and the target firmware byte-by-byte using a binary differential algorithm. This differential file records all the byte content required for upgrading from the current firmware to the target firmware, as well as the target write position of each changed byte in the target firmware's storage space. The difference data range refers to the boundary of the set of all difference data corresponding to a specific partition in the complete difference packet. Specifically, it is the byte range defined by the start and end addresses of that partition in the target firmware storage space. Since each difference byte in the complete difference packet carries its target write location information in the target firmware, during segmentation, based on the start address and size of each partition in the partition constraints, all difference bytes whose target write location falls within the address range of that partition can be selected from the complete difference packet. The set of these difference bytes constitutes the difference data range corresponding to that partition.

[0037] Then, using the maximum fragmentation threshold as the upper limit, the differential data within the partition is sequentially divided into multiple initial fragments according to their physical offsets in the firmware. Each initial fragment is no larger than the maximum fragmentation threshold and is completely located within the boundary of the partition. The physical offset refers to the absolute address position of the differential data in the target firmware storage space; that is, the byte offset value calculated based on the starting address of the firmware storage area. This value directly corresponds to the physical address where the data should be written in the charging pile's storage chip. The physical offset is calculated by the binary differential algorithm based on the partition layout of the target firmware when generating the complete differential packet and is recorded in the header information of the differential packet. During the fragmentation process, the differential data within the same partition are arranged in ascending order of physical offset. This ensures that write operations are executed continuously according to the storage address order, avoiding frequent jumps in the write pointer that could reduce the efficiency of writing to the storage medium.

[0038] If the amount of differential data corresponding to a partition is less than or equal to the maximum fragmentation threshold, it is directly used as an initial fragment. The amount of differential data refers to the total number of bytes contained in the differential data range corresponding to the partition, that is, the number of all differential bytes in the complete differential packet whose target write position falls within the address range of the partition. This number is directly read from the header information of the complete differential packet or obtained by counting bytes of the filtered differential data. If it is greater than the maximum fragmentation threshold, it is split into multiple consecutive initial fragments according to the maximum fragmentation threshold. The size of the last fragment can be less than the threshold. Each initial fragment obtained by the above method is accompanied by a partition ownership identifier, the starting write offset in the target firmware, the fragment length, and the hash check value of the fragment content. The starting write offset is calculated based on the starting address of the partition in the target firmware and the relative offset of the fragment within the partition.

[0039] After the segmentation is completed, it is determined whether the cumulative size of all initial segments exceeds the remaining storage space of the old charging pile. The remaining storage space comes from the cache constraint in the quaternary constraint profile, which represents the maximum capacity that the device can actually use to store differential data during the upgrade process. If the cumulative size does not exceed the remaining storage space, it means that the device has enough space to accommodate all differential data. Then, the initial segments are sorted according to the partition priority. The segments with smaller partition priority values ​​are placed at the beginning of the sequence. Multiple segments in the same partition are arranged according to their physical offset in the firmware. After sorting, a preliminary differential segment sequence is generated. The order of each segment in this sequence is the execution order of its subsequent transmission and writing.

[0040] By using the above method, the complete differential packet is initially segmented under the dual constraints of cache constraints and partition constraints. This ensures that the size of each differential segment is adapted to the device's buffer capacity, avoids the risk of data overwriting caused by segments crossing partition boundaries, and ensures that the upgrade order strictly follows the dependencies between modules by combining partition priority sorting.

[0041] The process of generating the initial differential fragment sequence includes: if the remaining storage space is exceeded, identifying low-priority fragments that can be delayed for upgrade based on the partition priority and call dependency relationship in the firmware version difference dependency graph; removing low-priority fragments from the initial fragments to ensure that the cumulative size of the remaining initial fragments does not exceed the remaining storage space size; and regenerating the differential fragment sequence based on the remaining initial fragments.

[0042] Specifically, considering the significant differences in remaining storage space among older charging piles, the cumulative size of the initially generated differential sharding sequence may exceed the remaining storage space of some devices. To ensure that the generated differential sharding sequence can be adapted to devices with different storage capacities, differentiated processing is required for cases exceeding storage capacity limits.

[0043] If the cumulative size of all the initial fragments exceeds the remaining storage space of the old charging pile, it indicates that the device cannot accommodate all the differential data at once. It is necessary to identify the low-priority fragments that can be delayed in upgrading based on the partition priority and call dependency relationship in the firmware version difference dependency graph.

[0044] The specific method for identifying low-priority fragments is as follows: First, the initial fragments are sorted in descending order of partition priority value. The fragment with the highest priority value corresponds to the last partition in the upgrade order, which is the fragment with the lowest upgrade urgency. When multiple fragments have the same priority value, the call dependency degree of each fragment's corresponding partition in the firmware version difference dependency graph is further compared. The call dependency degree is determined by counting the number of other partitions that depend on that partition. The statistical range of this dependency number includes all downstream partitions that can be reached by tracing back level by level along the directed edges in the firmware version difference dependency graph, that is, it includes both partitions that directly depend on that partition and partitions that indirectly depend on that partition through other partitions. The fewer the number of dependencies, the smaller the impact of the missing upgrade of that partition on the operation of other modules. This fragment is a low-priority fragment that can be delayed in upgrading. By comprehensively judging through the above two dimensions, that is, prioritizing the elimination of fragments with high priority values ​​and low call dependencies, the core modules that are critical to the operation of the system can be preserved to the greatest extent.

[0045] After identifying low-priority fragments, these fragments are removed from the initial fragment set. The cumulative size of the remaining initial fragments is then checked to see if it exceeds the remaining storage space. If it does, the identification and removal process is repeated until the cumulative size of the remaining initial fragments does not exceed the remaining storage space. Finally, the remaining initial fragments are reordered according to their partition priority values ​​in ascending order to generate a differential fragment sequence. The removed low-priority fragments are not transmitted immediately. They are transmitted and written only after the device completes the writing of the current batch of fragments and releases the storage space, through subsequent supplementary upgrade tasks. This allows for batch upgrades under limited storage space conditions.

[0046] In this way, when the remaining storage space of the device is insufficient to accommodate all differential data, the device intelligently identifies and removes shards that can be delayed in upgrading based on partition priority and call dependency, so that the upgrade task can be executed normally on the storage-constrained device. At the same time, the shards that are retained are all core modules with high priority and high call dependency, ensuring the integrity of the device's basic functions and the operability of the upgraded system.

[0047] In step S2, setting up hierarchical breakpoint anchors and generating a breakpoint status table for the differential fragment sequence includes: extracting link constraints from the quaternary constraint profile, obtaining a comprehensive link quality score from the link constraints, determining the dynamic anchor insertion interval based on the comprehensive link quality score; inserting first-level breakpoint anchors into the byte stream of the differential fragment sequence according to the dynamic anchor insertion interval, and inserting second-level breakpoint anchors at the partition switching positions of the differential fragment sequence; recording the offsets of the first-level and second-level breakpoint anchors, and generating a breakpoint status table based on the recorded offsets.

[0048] Specifically, to further improve the transmission reliability of differential fragmented sequences in weak network environments, it is necessary to deploy hierarchical recovery anchor points in the differential data stream based on the link quality characteristics of the charging pile, and establish a status table to record the transmission progress, so as to provide accurate positioning basis for subsequent breakpoint resumption.

[0049] First, the link constraints are extracted from the quaternary constraint profile. From these constraints, a comprehensive link quality score is obtained. This score, calculated in step S1 based on historical network fluctuation records, is generated by normalizing and weighting the packet loss rate and latency jitter frequency. It comprehensively characterizes the link quality of the charging pile; a higher score indicates poorer link quality. Based on this comprehensive link quality score, a dynamic anchor insertion interval is determined. This interval determines how many bytes in the differentially segmented byte stream are inserted as a breakpoint anchor. The determination method is as follows: a higher comprehensive link quality score indicates poorer link quality, requiring denser breakpoint anchors to cope with more frequent transmission interruption risks; that is, a smaller dynamic anchor insertion interval. Conversely, a lower comprehensive link quality score indicates better link quality, allowing for sparser breakpoint anchors to reduce metadata overhead; that is, a larger dynamic anchor insertion interval. By establishing a pre-defined mapping relationship between scores and insertion intervals, the overall link quality score is converted into a specific byte interval value. This mapping relationship adopts a segmented correspondence method, specifically: the complete range of values ​​for the overall link quality score is divided into multiple consecutive score intervals, and a corresponding fixed byte interval value is configured for each score interval. The score interval with a smaller score value corresponds to a larger byte interval value, and the score interval with a larger score value corresponds to a smaller byte interval value. When determining the current dynamic anchor insertion interval, the score interval into which the current overall link quality score falls is first determined, and then the fixed byte interval value corresponding to that score interval is used as the anchor insertion interval for this transmission.

[0050] According to the calculated dynamic anchor insertion interval, first-level breakpoint anchors are inserted into the byte stream of the differential fragment sequence. The dynamic anchor insertion interval directly determines the distribution density of the first-level breakpoint anchors. The smaller the interval, the denser the first-level breakpoint anchors, and the higher the breakpoint recovery accuracy, but the metadata overhead also increases accordingly. The larger the interval, the sparser the first-level breakpoint anchors, and the metadata overhead decreases, but the amount of data that needs to be retransmitted during breakpoint recovery also increases accordingly. The first-level breakpoint anchors are marker points that are evenly inserted into the byte stream of the differential fragment sequence at the dynamic interval. Each first-level breakpoint anchor records the offset of the current byte position and the cumulative check value of the data transmitted up to that position. The offset is used to quickly locate the interruption position during transmission recovery, and the cumulative check value is used to verify the integrity and correctness of the transmitted data.

[0051] Simultaneously, secondary breakpoint anchors are inserted at the partition switching positions of the differential fragment sequence. The insertion positions of these secondary breakpoint anchors are independent of the dynamic anchor insertion interval; instead, they are fixed at the start and end boundaries of each partition to achieve partition-level transmission control. When a transmission interruption occurs, the system first searches for the nearest secondary breakpoint anchor. If the partition corresponding to this secondary breakpoint anchor has been completely transmitted, transmission is resumed directly from the start position of the next partition. If the partition has not been completely transmitted, the system searches for the nearest primary breakpoint anchor within that partition and resumes transmission from that primary anchor position. Through this method, the dynamic anchor insertion interval controls the deployment density of primary breakpoint anchors to adapt to different link qualities, while the secondary breakpoint anchors provide coarser-grained recovery reference points at partition boundaries. Together, they form a hierarchical cooperation, constituting a breakpoint recovery positioning system.

[0052] The system records the offsets of first-level and second-level breakpoint anchors. Based on these offsets, a breakpoint status table is generated. This table is a data structure for centrally managing information about all breakpoint anchors in the differential fragment sequence. It contains multiple entries, each corresponding to a breakpoint anchor, recording attributes such as anchor type, offset, checksum, partition, and status flag. The breakpoint status table stores anchor entries in ascending order of offset. The status flag field records the transmission status of the data segment corresponding to that anchor, including values ​​such as not transmitted, transmitting, transmitted, checksum passed, and checksum failed. When the upgrade task starts, the status flags of all anchors are initialized to "not transmitted." As transmission progresses, the cloud server updates the anchor status flags based on feedback from the charging piles. When a transmission interruption occurs, the system queries the breakpoint status table to identify the last anchor with a checksum passed, thus determining the boundary of successfully transmitted data and resuming transmission from that anchor point.

[0053] The hierarchical breakpoint anchors and the generated breakpoint status table deployed in the above manner establish a precise recovery coordinate system in the differential fragment sequence. This enables the incomplete differential data to be accurately resumed from the nearest breakpoint position based on the precise positioning information recorded by the anchors after the transmission is interrupted. This avoids retransmitting the entire differential data packet from the beginning, significantly reducing network bandwidth waste and upgrade time. It is especially suitable for deployment scenarios of old charging piles with poor signal coverage and frequent network fluctuations.

[0054] Step S3: The cloud server adaptively transmits differential segments based on the real-time link quality data, cache usage, and segment verification results of the old charging piles. Before writing each differential segment, the old charging pile performs a security verification on the current differential segment. After the verification is passed, the writing is performed.

[0055] Step S3 includes: the cloud server dynamically adjusts the transmission rate based on the acquired real-time link quality data, cache usage, and fragment verification results, and sends the differential fragments and corresponding fragment digests to the old charging piles; the old charging piles receive the differential fragments, calculate the local hash value of the differential fragments, compare the local hash value with the fragment digest corresponding to the differential fragments, and verify data integrity; the old charging piles detect whether the current power supply status meets the preset power supply conditions, detect whether there is an ongoing business session, and verify the security of the device operating environment; if the local hash value is consistent with the fragment digest, the current power supply status meets the preset power supply conditions, and the current business session status is idle, the current differential fragment is written to the corresponding partition in the target storage area according to the write offset carried by the current differential fragment; when the local hash value is inconsistent with the fragment digest, the writing of the current differential fragment is rejected and a retransmission request is triggered to the cloud server.

[0056] Specifically, after generating the differential fragment sequence and setting up breakpoints and anchor points, in order to reliably transmit the differential data to the old charging piles and ensure the security of the writing process, it is necessary to dynamically adjust the transmission strategy according to the real-time network conditions and device status, and to perform multiple checks on the integrity and environmental security of the differential fragments before writing.

[0057] In practice, the cloud server continuously acquires real-time link quality data, buffer usage, and fragment verification results from older charging piles during transmission. Real-time link quality data includes the packet loss rate and latency of the current transmission link, used to assess instantaneous changes in network conditions. Buffer usage reflects the current used space ratio of the charging pile's buffer, used to determine if the device has the ability to receive new data. Fragment verification results are feedback on the integrity verification of previously transmitted differential fragments, including the cumulative number of verification failures and the timestamp of the most recent failure. When the cumulative number of verification failures exceeds a preset failure threshold within a preset time window, the cloud server determines that the current transmission link has a persistent problem. In addition to reducing the transmission rate, it triggers a link quality assessment process, sending link probe packets to the charging pile to measure the current round-trip latency and packet loss rate. If the measurement results are below a preset link quality lower limit, transmission is paused and resumed only after the link recovers. This mechanism avoids bandwidth and energy waste caused by repeated transmission failures due to continuously deteriorating link quality.

[0058] The cloud server dynamically adjusts the transmission rate based on the above three pieces of information: when the real-time link quality is good, the cache usage is low, and all fragment verification results pass, the transmission rate is appropriately increased to improve upgrade efficiency. The criteria for good real-time link quality are that the real-time measured packet loss rate is lower than a preset packet loss rate threshold and the real-time measured latency is lower than a preset latency threshold. The criteria for low cache usage are that the proportion of used cache space is lower than a preset first cache usage proportion threshold. The criteria for cache usage approaching the upper limit are that the proportion of used cache space is higher than a preset second cache usage proportion threshold, which is greater than the first cache usage proportion threshold. When the real-time measured packet loss rate is not lower than the preset packet loss rate threshold or the real-time measured latency is not lower than the preset latency threshold, the link quality is considered deteriorated. When the link quality deteriorates, the cache usage approaches the upper limit, or verification fails, the transmission rate is promptly reduced or transmission is paused to avoid data loss due to network congestion or cache overflow. Meanwhile, the cloud server sends each differential segment and its corresponding segment digest to the old charging piles. The segment digest is a fixed-length hash value calculated by the cloud server on the original data of the segment using a hash algorithm during the differential segment generation stage, which serves as a reference for the integrity of the segment after transmission.

[0059] After receiving the differential data segment, the older charging station first verifies its data integrity. Specifically, the charging station calculates the local hash value of the received differential data segment, that is, it uses the same hash algorithm as the cloud server to calculate a fixed-length hash value on the received binary data, and then compares this local hash value byte-by-byte with the segment digest sent by the cloud server along with the differential data segment. If the two match, it indicates that the differential data segment has not been corrupted or tampered with during transmission, and the data integrity verification passes; if they do not match, it indicates that the data has been corrupted, the charging station refuses to receive the segment, and triggers a retransmission request to the cloud server.

[0060] After data integrity verification is passed, the charging pile continues to verify the security of the device's operating environment, including detecting the current power supply status and whether there is an ongoing business session. The current power supply status is detected by reading the device's power management module to determine if the input voltage is within the normal range and if the backup battery has sufficient power, ensuring that the storage content will not be inconsistent due to power interruption during the write process. The current business session status is detected by querying the device's business management module to determine if there is an active charging session or other critical business operation, ensuring that the write operation will not compete for storage resources with business operations or cause business interruption. Only when the local hash value matches the fragment digest, the current power supply status meets the preset power supply conditions, and the current business session status is idle, will the charging pile write the differential fragment to the corresponding partition in the target storage area according to the write offset carried by the differential fragment. The write offset indicates the starting position of the fragment in the target firmware, ensuring that the data is written to the correct storage address. When the local hash value does not match the fragment digest, the charging pile refuses to write the differential fragment and triggers a retransmission request to the cloud server, requesting the cloud server to resend the fragment.

[0061] Through the above methods, the cloud server dynamically adjusts the transmission rate based on the real-time network and device status, achieving a balance between transmission efficiency and reliability. At the same time, the charging pile performs multiple checks on the data integrity and device operating environment of each differential segment before writing, ensuring that only complete and secure differential segments can be written to the storage area, effectively avoiding the risk of firmware corruption caused by damaged data being written to disk or interruption during the writing process.

[0062] Step S4: When transmission is interrupted or verification fails, breakpoint recovery and differential reassembly verification are performed according to the breakpoint status table. After all differential segments are written from the breakpoint, integrity verification of the entire packet and service partition is performed on the written firmware.

[0063] Step S4 includes: sending an interruption status report to the cloud server when transmission is interrupted or security verification fails; the cloud server parses the interruption status report, queries the breakpoint status table, and obtains the last breakpoint anchor point; based on the offset corresponding to the last breakpoint anchor point, it re-extracts the untransmitted differential data from the differential fragment sequence and sends it to the old charging pile; after receiving the untransmitted differential data, the old charging pile performs differential reassembly verification by combining the written fragment digest and the partition write confirmation code to confirm the continuity and consistency of the connection between the old and new data; after the transmission is resumed, the old charging pile performs whole packet integrity verification and business partition integrity verification on the target storage area that has been written.

[0064] Specifically, after completing the adaptive transmission and secure writing of differential segments, in order to further address abnormal situations such as network interruptions or verification failures that may occur during transmission, a breakpoint recovery mechanism needs to be established to ensure the continuity of data transmission, and the integrity of the firmware as a whole and key business partitions needs to be verified after all data is written.

[0065] In practice, when an old charging pile detects a network connection failure or a security verification failure, it sends an interruption status report to the cloud server. The interruption status report includes the timestamp of the interruption, the interruption reason code, the last successfully received segment number, the last successfully written segment number, and the summary information of the breakpoint status table. The interruption reason code is used to distinguish different types of interruption situations such as network disconnection, verification failure, power abnormality, and user termination, helping the cloud server to determine the nature of the interruption and subsequent processing strategies.

[0066] After receiving the interruption status report, the cloud server parses the report and queries the breakpoint status table to obtain the last breakpoint anchor. The last breakpoint anchor is the last anchor entry in the breakpoint status table marked as verified or written. The anchor entries in the breakpoint status table are arranged in ascending order of their corresponding offsets. Each anchor entry contains a status flag indicating whether the data segment corresponding to that anchor has been confirmed to have been written. When the cloud server queries the breakpoint status table, it traverses backward from the end of the table to the beginning, that is, it checks each entry one by one from the anchor with the largest offset. The first anchor entry marked as verified or written is determined as the last breakpoint anchor. The offset corresponding to this anchor marks the boundary of data that has been confirmed to have been transmitted. Data after this offset needs to be retransmitted, while data before this offset has been completely received and does not need to be retransmitted. Based on the offset corresponding to the last breakpoint anchor point, the cloud server re-extracts the differential data that has not yet been transmitted from the differential fragment sequence. That is, starting from the offset, it reads all the remaining differential data from the differential fragment sequence and re-segments the extracted data into differential fragments according to the same segmentation rules as the initial transmission. Then, it sends the re-segmented differential fragments to the old charging piles.

[0067] After receiving the untransmitted differential data, the old charging pile performs differential reassembly verification by combining the written fragment digest and the partition write acknowledgment code. The written fragment digest records the hash value of each successfully written fragment. The partition write acknowledgment code is a unique identifier generated for each partition, obtained by combining the digest values ​​of all written fragments within the partition. It is used to characterize the cumulative verification feature of the written data in that partition. The specific method of this combination calculation is as follows: according to the order of the physical offset of each written fragment within the partition from smallest to largest, the digest values ​​of each fragment are sequentially arranged and concatenated into a complete byte sequence. Then, a hash calculation is performed on the concatenated byte sequence, and the calculated hash value is used as the partition write acknowledgment code for that partition. The cloud server uses the same combination calculation method when generating the partition write acknowledgment code to ensure that the cumulative hash value calculated at the charging pile end is comparable and consistent with the partition write acknowledgment code provided by the cloud server.

[0068] The complete process of differential reassembly verification consists of three levels: The first level is address continuity verification, which calculates the end offset of the last written segment based on its start offset and data length. This end offset is compared with the start offset of the newly received data. If they match, the address is considered continuous; otherwise, it indicates address jumps or overlaps, triggering a retransmission request. The second level is partition ownership verification, which checks whether the partition identifier carried by the newly received data matches the partition identifier of the last written segment. If they match, the data continues within the same partition; if they do not match and the current secondary breakpoint anchor has been confirmed, cross-partition continuation is allowed; otherwise, it is considered data misalignment and a retransmission is triggered. The third level is cumulative hash verification, which, after address continuity and partition ownership verification both pass, concatenates the data of the written segments with the newly received data in address order. The local cumulative hash value is calculated byte-by-byte for the concatenated data stream. Simultaneously, the fragment digest values ​​provided by the cloud server are concatenated into a complete byte sequence in address order, and then a hash calculation is performed on this concatenated byte sequence. The result is used as the cloud confirmation check code. The local accumulated hash value is compared with the cloud-based verification code. If they match, the data reassembly is considered successful, and the old and new data are seamlessly connected in terms of content and order. If they do not match, it indicates a discrepancy in the data content, triggering a retransmission request. Through this three-level progressive verification, the correctness and reliability of the connection between old and new data are comprehensively ensured from the three dimensions of address, ownership, and content.

[0069] After the transmission is completed and all differential fragments are written to the target storage area, the old charging pile performs overall packet integrity verification and business partition integrity verification on the target storage area. The overall packet integrity verification covers all partitions of the firmware, performing hash calculations byte-by-byte from the start of the bootloader partition to the end of the last partition to obtain the current overall packet hash value. This hash value is then compared with the target firmware's overall packet hash value provided by the cloud server to verify the integrity and correctness of the entire firmware data. The business partition integrity verification calculates a hash value for each business partition separately and compares it with the corresponding target hash value, providing a more granular verification of the data integrity of each functional module.

[0070] The breakpoint recovery mechanism established in the above manner can accurately locate the boundary of transmitted data based on the breakpoint status table when the network is interrupted or the verification fails. It only resumes the transmission of the incomplete differential data, avoiding the bandwidth waste and time consumption caused by full retransmission. At the same time, the differential reassembly verification ensures the seamless connection between the old and new data, providing a reliable data foundation for determining the completion status of subsequent upgrades.

[0071] Step S5: If the integrity verification passes, restart the old charging pile and monitor the device heartbeat and communication handshake status after restarting to determine the upgrade completion status. If the integrity verification fails or the device heartbeat is abnormal, restore the old charging pile to the firmware version before the upgrade.

[0072] Step S5 includes: after all differential fragments are written, calculating the current whole packet hash value and the current business partition hash value of the target storage area; comparing the current whole packet hash value with the target whole packet hash value provided by the cloud server, and comparing the current business partition hash value with the target business partition hash value provided by the cloud server; if both comparisons are consistent, the old charging pile is restarted, and the device heartbeat and communication protocol handshake status are monitored after restarting; when the device heartbeat is normal and the communication protocol handshake is successful, the upgrade is determined to be complete; if any hash comparison is inconsistent, or the device heartbeat is abnormal, or the communication protocol handshake fails, an abnormal rollback is triggered, and the storage content of the old charging pile is restored to the firmware version before the upgrade.

[0073] Specifically, after completing the differential segment resume transmission and integrity verification, in order to ensure that the upgraded firmware can start normally and provide services, a comprehensive hash verification of the newly written firmware data is required. After the verification is passed, the device is restarted to check the running status of the new firmware. At the same time, it has the backup capability to restore the device to the version before the upgrade in case of an anomaly.

[0074] In specific implementation, such as Figure 2The diagram shows a flowchart of step S5. After all differential fragments are written, the old charging pile calculates the current total hash value and the current service partition hash value of the target storage area. The calculation range of the current total hash value covers all partitions of the firmware, from the start address of the bootloader partition to the end address of the last partition. A fixed-length hash value is obtained by hashing byte by byte. The specific algorithm used for this hash calculation is exactly the same as the algorithm used by the cloud server when calculating the target total hash value and the target service partition hash value during the differential packet generation stage. This ensures that the current hash value calculated by the charging pile has a comparable consistency with the target hash value provided by the cloud server. It should be noted that under normal upgrade procedures, if all differential fragments are written correctly and there is no data loss, the current hash value calculated locally should be consistent with the target hash value provided by the cloud. However, in practical applications, if the differential fragment reassembly logic allows the removal of some data ranges that do not need to be changed, resulting in a difference between the local calculation range and the cloud calculation range, the local hash value and the cloud hash value may be inconsistent. At this point, the system does not unconditionally roll back and retry. Instead, it determines the outcome based on a preset rollback strategy and fault tolerance mechanism: if the hash value inconsistency is due to the expected data removal range, and this removal range has been confirmed through partition ownership verification and address continuity verification, then the upgrade is allowed to continue; if the inconsistency exceeds the expected tolerance range, a retransmission request is triggered, and the cause of the anomaly is recorded for analysis by operations and maintenance personnel to avoid the situation where the upgrade cannot be completed due to an infinite loop of rollback caused by hash value inconsistency. The current business partition hash value is a hash value calculated separately for each business partition, used to characterize the data integrity of each business function module. The cloud server has pre-calculated the target full packet hash value and the target business partition hash value of the target firmware during the differential packet generation stage, and provides these hash values ​​as metadata for the upgrade task to the charging pile.

[0075] After the charging pile completes the calculation of the current hash value, it compares the current total hash value with the target total hash value provided by the cloud server, and then compares the current business partition hash value with the corresponding target business partition hash value provided by the cloud server. If both comparisons match, it indicates that all differential fragments have been written correctly, the target firmware is completely consistent with the target firmware stored in the cloud server, and the data integrity verification has passed. If any hash comparison does not match, it indicates that data errors, omissions, or corruption occurred during the writing process, the firmware is incomplete or incorrect, and an abnormal rollback is directly triggered, that is, the stored content of the old charging pile is restored to the firmware version before the upgrade.

[0076] The specific execution method for abnormal rollback is as follows: The charging pile reads the old firmware backup data saved before the upgrade from the preset backup storage area. This backup data is generated by completely copying the key partitions of the current firmware before step S1 is executed. The backup scope includes at least the bootloader partition, kernel partition, and business application partition. After reading the backup data, it is written back to the corresponding storage area according to the starting address of each partition, overwriting the new firmware data written during the upgrade process. After the rollback is completed, the charging pile performs a soft reset to load the restored old firmware. After the reset, a rollback completion report is sent to the cloud server. The report includes the rollback execution result and the current firmware version number. After receiving the rollback completion report, the cloud server confirms that the device has been restored to the state before the upgrade, updates the upgrade task record, and marks the upgrade status of the device as rollback complete. If an abnormality occurs again during the rollback writing process, the charging pile stops the writing operation and enters safe mode, waiting for manual intervention. At the same time, it continuously reports the abnormal status to the cloud server through heartbeat messages. Through the above rollback execution and confirmation mechanism, the executability of abnormal rollback operations and the traceability of results are ensured, avoiding the complete unrecoverable state of the device due to rollback failure.

[0077] After all hash comparisons pass, the aging charging pile is restarted. The restart operation is achieved through either a software reset or a hardware reset. A software reset clears the current running state and reloads the bootloader by calling the operating system's restart command. A hardware reset briefly cuts off the power to the main control chip and then restores power via the power management module. After restarting, the device boots and starts the system using the newly written target firmware. During the restart process, the cloud server continuously monitors the device heartbeat and communication protocol handshake status of the aging charging pile. The device heartbeat is a periodic status signal sent by the charging pile to the cloud server after system startup, used to confirm that the device has successfully started and maintains a communication connection with the cloud. The cloud server judges a normal heartbeat based on two dimensions: the first dimension is that the firmware version number carried by the heartbeat is consistent with the target firmware version; the second dimension is that the heartbeat reception time does not exceed a preset waiting timeout threshold. That is, the timer starts after the device restarts, and the first heartbeat signal is received within the preset timeout period. A heartbeat is considered normal when both dimensions are met, and abnormal when either dimension is not met. The communication protocol handshake is a process of protocol version negotiation and authentication between the charging pile and the cloud server when re-establishing a communication connection after a restart. This handshake is performed when a communication connection is established for the first time after the device restarts. Protocol version negotiation refers to the two communicating parties exchanging the protocol version numbers they support and reaching a consensus on the protocol version. Authentication refers to the charging pile submitting its identity credentials to the cloud server, which then verifies these credentials and returns a successful verification response. When the protocol version negotiation reaches a consensus and the authentication verification is successful, the communication protocol handshake is considered successful; if the protocol version negotiation fails to reach a consensus or the authentication verification fails, the communication protocol handshake is considered to have failed.

[0078] When the cloud server receives a heartbeat from the old charging pile and the firmware version number in the heartbeat matches the target firmware version, and the communication protocol handshake is successfully completed, it indicates that the device has successfully started and is running the new firmware, and network communication is normal. At this point, the upgrade is considered complete. If any hash comparison is inconsistent, or the heartbeat is not received after the device restarts, or the communication protocol handshake fails, an abnormal rollback is triggered. The abnormal rollback is executed as follows: the backup data of the old firmware is read from the storage area backed up before the upgrade, written back to the corresponding storage partition, and the new firmware data written during the upgrade is overwritten. This accurately restores the storage content of the old charging pile to the firmware version before the upgrade, ensuring that the device can start and run normally with the old version.

[0079] By employing the above methods, after the firmware is written, the integrity and correctness of the data are ensured through dual hash comparison of the entire package and the business partition. The bootability and normal function of the new firmware are verified through heartbeat monitoring and protocol handshake after reboot. A complete upgrade adjudication chain from data verification to operation verification is constructed. At the same time, if any link fails, an atomic rollback is triggered to restore the device to the state before the upgrade, effectively avoiding the device's inability to boot or its abnormal function due to upgrade failure.

[0080] like Figure 3 The diagram shows the structural architecture of this application, mainly comprising two parts: a cloud server and an upgrade agent module located at each older charging pile. The cloud server further includes an upgrade package management module and a device management module. The upgrade package management module is responsible for storing and maintaining firmware versions and their corresponding differential packages, and generating personalized differential upgrade packages based on device constraint information provided by the device management module when an upgrade task starts. The device management module is responsible for managing the device information, operating status, and upgrade task records of all older charging piles connected to the cloud. It constructs a four-element constraint profile by obtaining the operating status data reported by each charging pile, and formulates differentiated upgrade strategies for each device based on this profile. The older charging pile includes an upgrade control module, a local storage module, and a power management module. The upgrade control module is responsible for receiving differential segments from the cloud, performing segment verification and writing operations, handling breakpoint recovery processes, and reporting upgrade progress and status. The local storage module is used to temporarily store the received differential segments and record the breakpoint status table. The power management module is responsible for detecting the power supply status before writing to ensure power safety during the upgrade process. The cloud server and older charging piles exchange data via a communication network. This network handles the distribution of differential segments, the uploading of interruption status reports, and communication for heartbeat detection and handshake protocols. Through the coordinated operation of this system architecture, a closed-loop upgrade process is achieved, encompassing the entire chain from cloud policy generation to secure writing to the charging pile and status feedback.

[0081] The above describes a cloud-based batch firmware upgrade method for aging charging piles according to embodiments of this application. The following describes a cloud-based batch firmware upgrade system for aging charging piles according to embodiments of this application. Please refer to [link / reference]. Figure 4 A cloud-based batch firmware upgrade system for older charging piles, as described in this application embodiment, includes: The data acquisition module is used to acquire the current operating status data of old charging piles, construct a four-element constraint profile of old charging piles including version, partition, link and cache, acquire the current firmware and target firmware, and generate a firmware version difference dependency graph based on the current firmware and target firmware. The hierarchical breakpoint module is used to determine the differential sharding sequence that meets the storage security constraints based on the quaternary constraint profile and firmware version difference dependency graph, and to set hierarchical breakpoint anchors for the differential sharding sequence and generate a breakpoint status table. The security verification module is used by the cloud server to adaptively transmit differential segments based on the real-time link quality data, cache usage, and segment verification results of the old charging piles. Before writing each differential segment, the old charging pile performs a security verification on the current differential segment, and executes the writing after the verification is passed. The fragment writing module is used to perform breakpoint recovery and differential reassembly verification according to the breakpoint status table when the transmission is interrupted or the verification fails. After all differential fragments are written, the module resumes transmission from the breakpoint and performs integrity verification of the entire packet and service partition on the written firmware. The continuous monitoring module is used to restart the old charging pile if the integrity verification passes, monitor the device heartbeat and communication handshake status after restarting to determine the upgrade completion status, and restore the old charging pile to the firmware version before the upgrade if the integrity verification fails or the device heartbeat is abnormal.

[0082] In summary, this application addresses the core technical challenges of fragmented capabilities, complex firmware module dependencies, harsh network environments, and difficulty in ensuring upgrade reliability in legacy charging piles. It proposes a cloud-based batch firmware upgrade method and system for legacy charging piles. This method precisely quantifies the personalized capability boundaries of each device by constructing a four-element constraint profile of the legacy charging pile's version, partition, link, and cache. It clarifies the upgrade order and abnormal rollback boundaries by generating a firmware version difference dependency graph and marking partition priorities, call dependencies, and rollback impact ranges. Guided by the constraint profile and dependency graph, it generates a differential fragment sequence that satisfies storage security constraints and deploys hierarchical breakpoint anchors and breakpoint status tables. Combining real-time link quality adaptive transmission of differential fragments, it performs multiple checks on data integrity and environmental security before writing. When transmission is interrupted or checks fail, it accurately locates and executes breakpoint recovery and difference reassembly checks based on the breakpoint status table. Finally, through dual integrity checks of the entire packet and business partitions, as well as monitoring of device heartbeats and communication handshake states after restarting, it constructs a complete upgrade adjudication chain from data verification to operational verification, triggering atomic rollback in case of any abnormality at any stage. The proposed solution systematically solves the technical challenges of upgrading old charging piles, effectively improving the success rate, reliability, and safety of the upgrade, and possesses outstanding substantive features and significant progress.

[0083] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0084] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

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

Claims

1. A cloud-based batch firmware upgrade method for aging charging piles, characterized in that, The method includes: Step S1: Obtain the current operating status data of the old charging pile and construct a four-element constraint profile of the old charging pile's version, partition, link, and cache. Constructing the four-element constraint profile of the old charging pile includes: obtaining hardware identifiers and current operating status data from the old charging pile; parsing the current operating status data; extracting the remaining storage space size and communication module standard information; extracting the packet loss rate and latency jitter frequency of the old charging pile from historical network fluctuation records over a past statistical period, and normalizing them respectively; weighting and summing the normalized packet loss rate and latency jitter frequency according to preset weights to generate a comprehensive link quality score; and combining the theoretical maximum transmission rate in the communication module standard information with historical actual throughput records to calculate the average transmission rate and peak transmission rate of the old charging pile at different times, generating rate constraint information; and constructing link constraints based on the comprehensive link quality score and rate constraint information. A safety margin is reserved on the basis of the buffer capacity. The safety margin is based on a fixed percentage of the total buffer capacity or dynamically set according to the average value of the cache fragmentation rate generated by the old charging pile during its historical operation. The product of the fixed percentage or the dynamic setting value and the total buffer capacity is used as the reserved space. The available buffer size after deducting the safety margin is used as the maximum fragmentation threshold for a single transmission. This maximum fragmentation threshold is the cache constraint. Obtain the current firmware version number and current partition table of the old charging pile, generate version constraints based on the current firmware version number, and generate partition constraints based on the current partition table; Obtain the current firmware and the target firmware, and generate a firmware version difference dependency graph based on the current firmware and the target firmware. Generating the firmware version difference dependency graph includes: comparing the binary files of the current firmware and the target firmware to extract the changed service partitions and system partitions; analyzing the function call relationships and data dependencies within the service partitions and the system partitions, determining the upgrade order of each partition based on the function call relationships and the data dependencies, and generating partition priorities; constructing the firmware version difference dependency graph based on the partition priorities and the changed service partitions, and marking the call dependencies and rollback impact scope in the firmware version difference dependency graph. Step S2: Based on the quaternary constraint profile and the firmware version difference dependency graph, determine the differential shard sequence that satisfies the storage security constraints. Determining the differential shard sequence that satisfies the storage security constraints includes: determining the boundary position of each partition based on the cache constraints in the quaternary constraint profile and the partition constraints, and combining the partition priorities in the firmware version difference dependency graph to divide the complete differential packet into at least one initial shard; determining whether the cumulative size of the initial shard exceeds the remaining storage space of the old charging pile; if it does not exceed the remaining storage space, sorting the initial shards according to the partition priorities to generate a preliminary differential shard sequence. The process involves setting up hierarchical breakpoint anchors and generating a breakpoint status table for the differential fragment sequence. Specifically, this includes: extracting link constraints from the quaternary constraint profile, obtaining a comprehensive link quality score from the link constraints, determining the dynamic anchor insertion interval based on the comprehensive link quality score, inserting first-level breakpoint anchors into the byte stream of the differential fragment sequence according to the dynamic anchor insertion interval, and inserting second-level breakpoint anchors at the partition switching positions of the differential fragment sequence; recording the offsets of the first-level and second-level breakpoint anchors, and generating a breakpoint status table based on the recorded offsets. Step S3: The cloud server adaptively transmits differential segments based on the real-time link quality data, cache usage, and segment verification results of the old charging pile. Before writing each differential segment, the old charging pile performs a security verification on the current differential segment. After the verification is passed, the writing is performed. Step S4: When transmission is interrupted or verification fails, breakpoint recovery and differential reassembly verification are performed according to the breakpoint status table. Differential reassembly verification is performed by combining the written fragment digest and partition write confirmation code. The differential reassembly verification includes address continuity verification, partition ownership verification and cumulative hash verification to confirm the continuity and consistency at the junction of old and new data. The partition write confirmation code is obtained by combining the digest values ​​of all written fragments in the partition. After all differential fragments are written from the breakpoint, the integrity of the entire packet and service partition is verified on the written firmware. Step S5: If the integrity verification passes, restart the old charging pile, monitor the device heartbeat and communication handshake status after restarting to determine the upgrade completion status. If the integrity verification fails or the device heartbeat is abnormal, restore the old charging pile to the firmware version before the upgrade.

2. The cloud-based batch firmware upgrade method for aging charging piles according to claim 1, characterized in that, Generating the initial differential slice sequence also includes: If the remaining storage space is exceeded, then based on the partition priority and call dependency relationship in the firmware version difference dependency graph, low-priority fragments that can be delayed for upgrade are identified. Low-priority fragments are removed from the initial fragments, ensuring that the cumulative size of the remaining initial fragments does not exceed the size of the remaining storage space. A differential fragment sequence is then regenerated based on the remaining initial fragments.

3. The cloud-based batch firmware upgrade method for aging charging piles according to claim 1, characterized in that, Step S3 includes: The cloud server dynamically adjusts the transmission rate based on the real-time link quality data, cache usage, and fragment verification results, and sends the differential fragments and corresponding fragment summaries to the old charging piles. The old charging pile receives differential segments, calculates the local hash value of the differential segments, compares the local hash value with the segment digest corresponding to the differential segments, and verifies data integrity. The old charging pile detects whether the current power supply status meets the preset power supply conditions, detects whether there is an ongoing business session, and verifies the safety of the equipment operating environment. If the local hash value is consistent with the fragment digest, the current power supply status meets the preset power supply conditions, and the current service session status is idle, the current differential fragment is written to the corresponding partition in the target storage area according to the write offset carried by the current differential fragment. When the local hash value is inconsistent with the fragment digest, the current differential fragment is not written and a retransmission request is triggered to the cloud server.

4. The cloud-based batch firmware upgrade method for aging charging piles according to claim 1, characterized in that, Step S4 includes: In the event of transmission interruption or security verification failure, an interruption status report is sent to the cloud server. The cloud server parses the interruption status report, queries the breakpoint status table, and obtains the last breakpoint anchor point. Based on the offset corresponding to the last breakpoint anchor point, the untransmitted differential data is re-extracted from the differential fragment sequence and sent to the old charging pile. After receiving the untransmitted differential data, the old charging pile performs differential reassembly verification by combining the written fragment digest and the partition writing confirmation code to confirm the continuity and consistency at the junction of the old and new data. After the transmission is resumed, the old charging pile performs a full package integrity check and a business partition integrity check on the target storage area that has been written.

5. The cloud-based batch firmware upgrade method for aging charging piles according to claim 1, characterized in that, Step S5 includes: After all differential fragments have been written, calculate the current whole packet hash value and the current business partition hash value of the target storage area; Compare the current total packet hash value with the target total packet hash value provided by the cloud server, and compare the current service partition hash value with the target service partition hash value provided by the cloud server; If both comparisons match, the old charging pile is restarted, and the device heartbeat and communication handshake status are monitored after the restart. When the device heartbeat is normal and the communication handshake is successful, the upgrade is considered complete. If any hash comparison is inconsistent, or the device heartbeat is abnormal, or the communication handshake fails, an abnormal rollback is triggered, restoring the stored content of the old charging pile to the firmware version before the upgrade.

6. A cloud-based batch firmware upgrade system for aging charging piles, used to implement the cloud-based batch firmware upgrade method for aging charging piles as described in any one of claims 1-5, characterized in that, The system includes: The data acquisition module is used to acquire the current operating status data of the old charging piles and construct a four-element constraint profile of the old charging piles, including: acquiring hardware identifiers and current operating status data from the old charging piles; parsing the current operating status data; extracting the remaining storage space size and communication module type information; extracting the packet loss rate and latency jitter frequency of the old charging piles in the past statistical period from historical network fluctuation records, and normalizing them respectively; weighting and summing the normalized packet loss rate and latency jitter frequency according to preset weights to generate a comprehensive link quality score; and calculating the average transmission rate and peak transmission rate of the old charging piles in different time periods by combining the theoretical maximum transmission rate in the communication module type information with historical actual throughput records to generate rate constraint information; and constructing link constraints based on the comprehensive link quality score and rate constraint information; reserving a safety margin based on the buffer capacity, with the safety margin being a fixed percentage of the total buffer capacity as the benchmark value, or based on the old charging piles' historical operating data. The average cache fragmentation rate generated during the process is dynamically set, and the product of a fixed percentage or dynamically set value and the total buffer capacity is used as the reserved space. The available buffer size after deducting the safety margin is used as the maximum fragmentation threshold for a single transmission. This maximum fragmentation threshold is the cache constraint. The current firmware version number and current partition table of the old charging pile are obtained. Version constraints are generated based on the current firmware version number, and partition constraints are generated based on the current partition table. The current firmware and target firmware are obtained, and a firmware version difference dependency graph is generated based on the current firmware and the target firmware. Generating the firmware version difference dependency graph includes: comparing the binary files of the current firmware and the target firmware, extracting the changed business partitions and system partitions; analyzing the function call relationships and data dependencies within the business partitions and the system partitions, determining the upgrade order of each partition based on the function call relationships and the data dependencies, and generating partition priorities; constructing the firmware version difference dependency graph based on the partition priorities and the changed business partitions, and marking the call dependencies and rollback impact range in the firmware version difference dependency graph. The hierarchical breakpoint module is used to determine a differential fragment sequence that satisfies storage security constraints based on the quaternary constraint profile and the firmware version difference dependency graph. Determining the differential fragment sequence that satisfies storage security constraints includes: determining the boundary positions of each partition based on the cache constraints in the quaternary constraint profile and the partition constraints, and combining this with the partition priorities in the firmware version difference dependency graph to segment the complete differential packet to obtain at least one initial fragment; determining whether the cumulative size of the initial fragment exceeds the remaining storage space of the old charging pile; if it does not exceed the remaining storage space, then segmenting the initial fragment according to the partition priorities. The initial fragments are sorted to generate a preliminary differential fragment sequence; and hierarchical breakpoint anchors are set up for the differential fragment sequence and a breakpoint status table is generated. Specifically, this includes: extracting link constraints from the quaternary constraint profile, obtaining a comprehensive link quality score from the link constraints, determining the dynamic anchor insertion interval based on the comprehensive link quality score; inserting first-level breakpoint anchors into the byte stream of the differential fragment sequence according to the dynamic anchor insertion interval, and inserting second-level breakpoint anchors at the partition switching positions of the differential fragment sequence; recording the offsets of the first-level breakpoint anchors and the second-level breakpoint anchors, and generating a breakpoint status table based on the recorded offsets. The security verification module is used by the cloud server to adaptively transmit differential segments based on the real-time link quality data, cache usage, and segment verification results of the old charging pile. Before writing each differential segment, the old charging pile performs a security verification on the current differential segment, and executes the writing after the verification is passed. The fragment writing module is used to perform breakpoint recovery and differential reassembly verification according to the breakpoint status table when the transmission is interrupted or the verification fails. It combines the written fragment digest and the partition writing confirmation code to perform differential reassembly verification. The differential reassembly verification includes address continuity verification, partition ownership verification and cumulative hash verification to confirm the continuity and consistency of the connection between the old and new data. The partition writing confirmation code is obtained by combining the digest values ​​of all written fragments in the partition. After resuming the transmission from the breakpoint and completing the writing of all differential fragments, the module performs integrity verification of the entire packet and the service partition on the written firmware. The continuous monitoring module is used to restart the old charging pile if the integrity verification passes, monitor the device heartbeat and communication handshake status after restarting to determine the upgrade completion status, and restore the old charging pile to the firmware version before the upgrade if the integrity verification fails or the device heartbeat is abnormal.

Images