Remote firmware updating optimization method for electric bicycle charging pile

Abstract

The invention relates to a remote firmware updating optimization method for an electric bicycle charging pile, relates to the technical field of remote firmware updating of Internet of Things equipment, and solves the problem of transmission reliability in a weak network environment by optimizing a data block size and a transmission protocol according to real-time network quality through a dynamic block transmission strategy and a protocol adaptive switching mechanism. Constructing an end-to-end security protection system by adopting a multi-level security verification mechanism and combining frame verification, file hash and digital signature hierarchical verification; a hardware compatibility precise matching algorithm is designed, and based on structured version number interval comparison and a double-partition firmware updating mechanism, the adaptability of a firmware version and hardware is ensured; and establishing an exception monitoring and closed-loop recovery system, and realizing full-process self-healing after updating failure through an error classification model, a recovery strategy routing table and intelligent state rollback. The method improves the transmission success rate of firmware updating, the safety protection level and the system fault-tolerant capability, and is suitable for a remote operation and maintenance scene of a large-scale charging pile group.

Description

Technical Field

[0001] The present application relates to the technical field of remote firmware update for IoT devices, and in particular to a remote firmware update optimization method for electric bicycle charging piles. Background Art

[0002] The current remote firmware update technology for electric bicycle charging piles generally has problems such as poor network adaptability, weak security, rough compatibility verification and insufficient abnormal recovery capabilities.

[0003] Traditional methods use a fixed block strategy to transmit firmware files, but are unable to dynamically adjust block size based on real-time network signal strength. This leads to a surge in packet loss and low retransmission efficiency in weak network environments. Security verification often relies on a single verification mechanism (such as CRC), lacking the ability to coordinate protection against complex attacks such as data tampering and identity forgery, making it difficult to meet the security compliance requirements of IoT devices. Hardware compatibility verification typically only compares major version numbers, ignoring minor version numbers and subtle differences in hardware components, which can easily cause runtime failures due to firmware and hardware driver mismatches.

[0004] In addition, existing technologies lack full-process exception monitoring and closed-loop recovery mechanisms. After an update fails, manual intervention is required to restart the device or roll back the version. The operation and maintenance costs are high and it is difficult to ensure high system availability. Summary of the Invention

[0005] The purpose of this application is to provide an optimization method for remote firmware updates of electric bicycle charging piles, which solves the technical difficulties of existing charging pile firmware update methods in network fluctuation environments, such as low transmission reliability, lack of multi-level security protection, inaccurate hardware compatibility verification, and reliance on manual intervention for abnormal recovery.

[0006] The remote firmware update optimization method for an electric bicycle charging station provided in this application includes the following steps: S1. Build a layered communication protocol architecture. Dynamically schedule and update tasks at the application layer to generate transmission strategies. The transport layer generates dynamic block strategies based on real-time network signal strength. The network layer selects communication protocols based on transmission unit size. S2. Encapsulate the structured firmware file and generate a file format including a compression algorithm identifier, a hardware version compatibility range, and a multi-level checksum field. In the file format, each frame of data carries a unique serial number and a checksum. S3. Execute network adaptive transmission, transmit the structured firmware file based on the dynamic block strategy and communication protocol, and trigger a priority retransmission mechanism when packet loss is detected; S4. Implement multi-level security verification, performing frame check verification, file integrity hash verification, and digital signature legitimacy verification on the transmission data stream in sequence; S5. Decompression and hardware compatibility verification: decompress the firmware data that has passed security verification and match the hardware version of the target device with the compatibility range declared in the file format; S6, abnormal monitoring and closed-loop recovery, when a preset number of errors are detected continuously during the transmission, verification or firmware update process, it switches to the backup partition to resume operation and generate an error report.

[0007] Preferably, in the dynamic block strategy, the block length L and the network signal strength RSRP satisfy the following piecewise function relationship: in: RSRP: Reference Signal Received Power.

[0008] Preferably, the frame check verification adopts CRC16-CCITT algorithm, and its generating polynomial is: G(x)=x 16 +x 12 +x 5 +x 0 ; The checksum calculation method satisfies: in: D k : The integer value of the kth byte of the data frame, n: The byte length of the data part of a single frame, Indicates byte-wise exclusive OR operation.

[0009] Preferably, the digital signature legitimacy verification adopts the elliptic curve digital signature algorithm, and its verification formula is: R≡(s -1 ·(H(m)+d Q ·R))mod p; in: R is the horizontal coordinate of the elliptic curve point in the signature, s is the signature random number, H(m): the hash value of the firmware data calculated by the SHA-256 algorithm, d Q is the private key parameter, and p is the elliptic curve prime field modulus.

[0010] Preferably, the file format includes the following fields: Start tag field: fixed 4-byte hexadecimal identifier; Compression algorithm type field: 1-byte identifier, defining uncompressed, ZIP, 7ZIP, or LZ4 algorithm; Hardware version compatibility field: 8-byte range value, defining the minimum and maximum compatible version numbers; Original firmware hash value field: 16 bytes storing the MD5 hash value.

[0011] Preferably, in the priority retransmission mechanism, the upper limit N of the number of retransmissions of ordinary data frames is max satisfy: in: P loss : Current network packet loss rate; Ceiling function.

[0012] Preferably, the hardware compatibility verification needs to satisfy the following inequality: V min ≤V dev ≤V max ; in: V dev : Hardware version number of the target device; V min 、V max : The compatible version range declared in the firmware file.

[0013] Preferably, the triggering conditions for abnormal monitoring and closed-loop recovery are: Three or more errors of the same type occur cumulatively during a single update process. Error types include: Transmission error: frame check failure or data loss Verification error: Hash check or signature verification failed Compatibility Error: Hardware version mismatch.

[0014] Preferably, the calculation formula of the decompression buffer size B is: B=2 CP[4:7] ×1024 bytes; in: CP[4:7]: The high 4-bit binary value of the compression parameter field.

[0015] In summary, this application includes at least one of the following beneficial technical effects: 1. This invention builds a layered communication protocol architecture, combines dynamic block segmentation with adaptive network protocol switching, and optimizes data transmission unit size and protocol stack configuration under varying network signal strengths. This design effectively addresses the high packet loss rate issue in weak network environments, ensuring reliable transmission of firmware updates in complex network conditions and avoiding update interruptions caused by network fluctuations. 2. This invention employs a layered security system that combines frame-level verification, file hash verification, and digital signature verification, performing step-by-step verification of the data transmission process, file integrity, and publisher identity. This mechanism protects against multiple security threats, including data tampering, man-in-the-middle attacks, and malicious firmware injection, forming a security protection chain that covers the entire firmware update lifecycle. 3. This invention utilizes a structured version number interval verification algorithm and a dual-partition firmware update mechanism to precisely match hardware compatibility before an update. If an update fails, the system quickly switches to the backup partition for recovery. This design effectively avoids device downtime caused by version incompatibility or update interruptions, significantly improving the success rate of charging pile firmware updates and system availability.

[0016] 4. Based on an error classification model and recovery strategy routing table, this invention constructs a closed-loop control system from error detection and status analysis to automatic recovery. By real-time monitoring of key node status and intelligent recovery strategy selection, it can complete fault isolation and system self-healing without human intervention, significantly reducing operation and maintenance costs and downtime risks. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a flow chart of the method of this application. DETAILED DESCRIPTION

[0018] The following is combined with Figure 1 , further details of this application are given.

[0019] Example: A remote firmware update optimization method for an electric bicycle charging pile comprises the following steps: S1. Build a layered communication protocol architecture. Dynamically schedule and update tasks at the application layer to generate transmission strategies. The transport layer generates dynamic block strategies based on real-time network signal strength. The network layer selects communication protocols based on transmission unit size. When constructing a layered communication protocol architecture, the present invention implements dynamic scheduling and network resource adaptation of firmware update tasks through multi-level collaborative control. First, an application layer update trigger model is established, and the time distribution characteristics of the equipment load rate are statistically analyzed based on the historical operation data of the charging pile. For example, the active status data of each charging pile is collected at a preset time granularity to construct a load rate time series set. Subsequently, the cumulative load rate index within a continuous period is calculated by a sliding window analysis method. When the index is lower than the preset load rate threshold, it is determined to be an available update window. This model can achieve active avoidance of high-load periods to prevent update operations from affecting users' normal charging services.

[0020] In the dynamic block strategy of the transport layer, a mapping relationship between network signal strength and transmission unit length is first established. For example, the reference signal received power measurement value is obtained in real time through the wireless communication module, and multiple signal strength intervals are set as the basis for determining the block length adjustment. Preferably, the signal strength is divided into three levels: high, medium, and low, and different block length parameters are configured for each level. The block length selection function can be expressed as: L = f(RSRP); Where L is the block length, and RSRP is the real-time signal strength measurement. This function dynamically optimizes the data transmission unit size based on the network environment, using larger blocks to improve transmission efficiency when signal strength is high, and smaller blocks to reduce packet loss in weak signal conditions.

[0021] The network-layer protocol selection mechanism achieves adaptive switching by detecting the maximum transmission unit size (MTU) of the current network. First, a protocol decision matrix is ​​established, mapping transmission unit sizes to communication protocol types. For example, if the maximum transmission unit size supported by the network link is less than or equal to a preset protocol switching threshold, a constrained application protocol designed for low-power devices is selected. Otherwise, a message queue transport protocol supporting persistent connections is used. This mechanism automatically adapts to the transmission characteristics of different network infrastructures, ensuring compatibility between the protocol stack and the physical layer's transmission capabilities.

[0022] During the transmission control process, the breakpoint resume function achieves rapid recovery after update interruption by recording the sequence of successfully transmitted data blocks. First, a dedicated storage area is allocated in the non-volatile memory to record the progress status information of the current file transfer. For example, the storage structure includes a file identifier, the sequence number of the last confirmed data block, and a partial transmission data buffer. When an abnormal network connection interruption is detected, the current transmission status is written to the persistent storage medium. When resuming the transmission, the breakpoint record is first read and its validity is verified, and then the unfinished data block is transmitted again from the breakpoint position. This design can avoid repeated transmissions caused by network fluctuations and reduce the consumption of invalid data traffic.

[0023] The collaborative working mechanism between the application layer and the transport layer is implemented through an event-driven model. When the application layer scheduler generates an update task, it first sends a resource request instruction to the transport layer. After the transport layer responds to the instruction, it dynamically adjusts the block strategy parameters based on the current network quality assessment results and encapsulates the configuration parameters in the protocol control frame header. For example, the control frame contains a block length identifier, a retransmission priority flag, and protocol version information. The network layer automatically selects the optimal transmission protocol based on the block strategy parameters, establishes an end-to-end communication link, and initiates the data encapsulation process. Parameter transfer between layers is implemented through shared memory areas, ensuring real-time synchronization of status information and low-latency interaction.

[0024] During signal strength detection, a sliding mean filter algorithm is used to eliminate the impact of instantaneous signal fluctuations on the block strategy. First, raw signal strength data is acquired at a fixed sampling period. The weighted average of the last N sampling points is then calculated as the effective measurement value. Preferably, weight coefficients are assigned according to an exponential decay law, with more recent data receiving a higher weight. This processing method can suppress short-term sudden changes in signal strength and avoid the loss of transmission efficiency caused by frequent switching of block lengths. The filtered signal strength value is input into the block decision module, driving the dynamic adjustment of transmission unit parameters.

[0025] During the protocol switching process, the network layer performs real-time detection of the transmission unit size and protocol stack reconfiguration. First, the maximum transmission unit parameter of the current network interface is obtained through the underlying driver interface, and then this parameter is compared with the preset protocol switching threshold. For example, when the maximum transmission unit size exceeds the threshold, a message queue protocol stack optimized for high-traffic transmission is initialized. Otherwise, a lightweight protocol stack suitable for narrowband IoT is loaded. After the protocol stack switch is completed, a readiness status notification is sent to the application layer, triggering the subsequent data transmission process. This mechanism can automatically select the optimal communication protocol based on the physical layer characteristics of the network link, improving the robustness of the transmission process.

[0026] Data exchange between layers is achieved through standardized interface protocols, ensuring the modularity and scalability of the architecture. Task instructions sent from the application layer to the transport layer include updating file metadata, priority identifiers, and time constraint parameters. Link status information reported back by the transport layer includes real-time throughput, packet loss rate, and signal quality metrics. Protocol configuration parameters reported by the network layer include frame structure definitions, error recovery mechanisms, and flow control strategies. By defining clearly defined interface data formats and interaction timings, each functional module can be independently upgraded and optimized without affecting the stability of the overall architecture.

[0027] The exception handling mechanism within the layered architecture enables rapid fault location through cross-layer status monitoring. The transport layer monitors the transmission status of data blocks in real time and, upon detecting continuous packet loss, sends a link quality alert to the application layer. The network layer protocol stack includes a built-in heartbeat detection function to regularly verify the availability of end-to-end connections. For example, when the number of heartbeat packet timeouts reaches a preset threshold, the protocol stack is triggered to restart the process and renegotiate transmission parameters. This monitoring system promptly detects abnormal conditions at each layer and, through inter-layer collaboration, enables rapid fault isolation and recovery.

[0028] S2. Encapsulate the structured firmware file and generate a file format including a compression algorithm identifier, a hardware version compatibility range, and a multi-level checksum field. In the file format, each frame of data carries a unique serial number and a checksum. When encapsulating structured firmware files, the present invention ensures the integrity and verifiability of data transmission by designing a file format with multi-level verification. First, a file header metadata model is established, defining a set of key fields used to identify firmware attributes. For example, the file header includes a start tag field to identify the file type, preferably using a fixed byte sequence as a format verification benchmark. A compression algorithm identification field is then set, declaring the data compression method and parameter configuration information through bit encoding. This design provides a clear basis for algorithm selection during subsequent decompression processing.

[0029] The construction of the hardware version compatibility field in the file format is achieved through the definition of the version number range. First, the hardware version encoding rules of the target device are parsed, and the storage structure and comparison logic of the version number value are extracted. For example, the compatible range is split into the lowest version number and the highest version number for storage, and the version number is preferably represented by a 32-bit unsigned integer. This field can verify the compatibility of the device before the firmware is updated to avoid system anomalies caused by version mismatch. The original firmware hash value field is set at the end of the file header to store the integrity check value of the uncompressed firmware data. The length of this field preferably matches the number of bits output by the hash algorithm.

[0030] The data frame encapsulation process first establishes a frame sequence number generation mechanism to ensure the order of data blocks during transmission is traceable. For example, each data frame is assigned an incremental sequence number, preferably implemented using a 16-bit cyclic count. The frame data portion is processed using a compression algorithm, with compression parameters dynamically configured via the file header field. For streaming compression algorithms, a dictionary identifier is further set in the frame header to indicate the dictionary version information used during the compression process. This design enables dynamic adaptation of the decompression buffer size, avoiding waste of memory resources.

[0031] The generation of the frame check code uses the polynomial division remainder algorithm to achieve data integrity protection. First, define the check polynomial expression, preferably using the internationally standardized cyclic redundancy check parameters. For a frame data D with a length of n bytes k , the check value calculation process can be expressed as: Among them, G(x) is the generating polynomial, D k Represents the value of the kth byte. This calculation process can verify the integrity of the frame in real time during data transmission and detect transmission errors in a timely manner.

[0032] The compression algorithm selection strategy is determined by combining the file header identification field with the device resource status. First, a compression algorithm identification mapping table is established to associate the encoding value with the specific algorithm implementation library. For example, the identification field uses a 4-bit binary encoding, supporting multiple modes such as uncompressed, dictionary compression, and streaming compression. For resource-constrained devices, a memory usage limit is further set in the compression parameters. The calculation of the compression dictionary size BB can be expressed as: Among them, C p is the configuration value in the compression parameter field, and K is the unit base value. This parameterized design can dynamically adjust compression resource usage based on device memory capacity, achieving a balance between processing efficiency and resource consumption.

[0033] The file end marker field is designed to identify the end of the firmware data. A specific byte combination is preferably used as the end marker, and the length of this field is symmetrical with the file header start marker. For example, a 4-byte fixed code is appended to the end of the file, forming a closed-loop verification structure with the file header start marker. When data is transmitted to the end of the file, the recipient verifies the file integrity by comparing the end marker, triggering the subsequent verification process.

[0034] During the compression process, the dictionary initialization strategy affects compression efficiency and compatibility. For dictionary-based compression algorithms, the dictionary version number and generation parameters are first declared in the file header. For example, the dictionary preferably uses a pre-set standard dictionary library, and differential encoding is used to reduce dictionary data transmission volume. When the target device detects that the target device already has the same version of the dictionary stored, the local dictionary is directly used for decompression, avoiding bandwidth waste caused by repeated dictionary data transmission.

[0035] The coordinated operation of multiple checksums is achieved through layered verification logic. The file header hash field provides a baseline for the integrity of the original firmware, the frame checksum ensures the reliability of individual frame data transmission, and the file tail marker verifies the integrity of the overall structure. These three layers of verification operate at different processing stages: the file header hash verifies data authenticity after decompression, the frame checksum provides real-time error correction during transmission, and the file tail marker verifies data integrity during reassembly. This design enables the construction of a comprehensive data verification system.

[0036] The storage format of the version compatibility field takes into account the differences in version numbers among devices from different manufacturers. First, a version number parsing rule is defined to convert the device hardware version into a numeric value for comparison. For example, the hardware version is 1 byte, and the version number is split into four fields: major version, sub-version, revision number, and build number, each 2 bytes long, for a total of 8 bytes. During compatibility verification, each sub-segment of the device version number is compared against the range value declared in the file header to ensure that the version matches accurately to the revision level.

[0037] The reserved fields in the file structure are designed to provide compatibility support for subsequent functional expansion. Preferably, an undefined area of ​​a specific length is set in the file header and data frame, and the activation status of the extended functions is controlled by the version identification field. For example, the reserved field is initially set to zero. When a new version identification is detected, the parser automatically calls the extension processing module to decode the reserved field. This design maintains compatibility with existing devices while supporting future protocol upgrades.

[0038] In the data frame encapsulation link, the block strategy of the compression algorithm affects the transmission efficiency and processing delay. For the streaming compression algorithm, the compression block length is first determined according to the decompression buffer size of the target device. For example, the compression block length L is c Associated with the decompression buffer size B, it satisfies the relationship: L c ≤α·B; Where α is the compression ratio estimation factor. This constraint ensures that the receiving device does not need to dynamically expand its buffer during decompression, thus avoiding the risk of memory overflow. The compressed block length parameter is passed to the receiving device via the file header field, driving the pre-allocation of decompression resources.

[0039] The persistent storage of file formats uses a platform-independent binary encoding method. First, define the byte order conversion rules to ensure data parsing consistency between devices with different architectures. For example, all numeric fields are preferably stored in network byte order (big endian mode), and string fields are encoded in ASCII format. This design can eliminate the impact of device processor architecture differences on file parsing and achieve cross-platform compatibility.

[0040] During integrity verification, the choice of hash algorithm balances computational efficiency and security. The hash value field in the file header preferably uses a multi-algorithm hybrid verification scheme. For example, both MD5 and SHA-256 hash values ​​are calculated and stored simultaneously. Dual verification is performed when device resources are sufficient, while single-algorithm verification is used when resources are limited. This design dynamically adjusts verification strength based on device performance, balancing security and computational overhead.

[0041] The data frame boundary detection mechanism works in conjunction with the sequence number and length fields. Each data frame header contains a data length field. Combined with the total number of frames declared in the file header, the receiver can accurately reconstruct the original file. For example, if a discontinuous sequence number or an abnormal length field is detected, an error recovery process is immediately triggered, requesting retransmission of the abnormal data frame. This mechanism effectively addresses issues such as out-of-order transmission and data corruption during network transmission.

[0042] The bit-encoded design of the compression parameter configuration field improves storage space utilization. Information such as the compression algorithm type, compression level, and dictionary identifier is encoded into a single byte field. For example, the lower 4 bits represent the algorithm type, while the upper 4 bits store the compression level parameter. This compact encoding method enables the transmission of multi-dimensional configuration information within a limited field space, reducing protocol header overhead.

[0043] The extensible file structure design achieves forward compatibility through version control fields. A version identification field is set in the file header to clearly indicate the revision level of the format specification. For example, when the parser detects a new version file, it automatically loads the corresponding extended parsing module to process the newly added fields. When older devices encounter the new format file, they are prompted to upgrade their firmware based on the version number. This mechanism ensures system compatibility during protocol evolution.

[0044] Regarding exception handling, the file encapsulation process includes a built-in format validation pre-check mechanism. Before a file is sent, a complete self-verification process is performed, including field boundary checking, hash value recalculation, and compression and decompression loop testing. For example, if a file header field out of bounds or a checksum mismatch is detected, the transmission is automatically terminated and an error log is generated. This pre-check mechanism eliminates data transmission anomalies caused by file encapsulation errors at the source.

[0045] S3. Execute network adaptive transmission, transmit the structured firmware file based on the dynamic block strategy and communication protocol, and trigger a priority retransmission mechanism when packet loss is detected; The present invention achieves efficient and reliable data transmission through dynamic block strategies and protocol adaptation mechanisms when implementing network-adaptive transmission. First, a transmission control state machine model is established, dividing the transmission process into four phases: block encapsulation, protocol selection, priority scheduling, and breakpoint management. For example, the state machine employs an event-driven architecture, triggering dynamic adjustment of transmission parameters in response to network quality changes. This model coordinates the coordinated operation of various submodules, ensuring that transmission strategies are compatible with real-time network conditions.

[0046] The implementation of the dynamic block strategy begins with establishing a block length calculation function that maps network signal strength measurements to discrete block length parameters. For example, the signal strength interval division uses a threshold comparison method, defining multiple signal strength levels as trigger conditions for block adjustment. The mapping relationship between block length L and signal strength RSRP can be expressed as a piecewise function: Where θ1 and θ2 are preset signal strength thresholds, and L1, L2, and L3 are the corresponding block lengths. This function dynamically optimizes packet size based on channel quality, reducing the risk of packet loss when the signal fades.

[0047] The protocol selection mechanism dynamically switches transport protocols by monitoring network layer parameters in real time. First, a protocol decision matrix is ​​established, associating the maximum transmission unit (MTU) size with the protocol type. For example, if the MTU value supported by the current network is less than or equal to the protocol switching threshold τ, the Constrained Application Protocol (CoAP) is selected; otherwise, the Message Queuing Telemetry Transport (MQTT) is selected. This mechanism automatically adapts to the transmission characteristics of different network infrastructures, ensuring that the protocol stack matches the physical layer capabilities.

[0048] The priority retransmission mechanism ensures the reliability of critical data by setting differentiated retransmission strategies. First, define the frame priority classification rules and mark the first frame, last frame and control frame of the file as high priority. For example, high priority frames use an unlimited retransmission strategy until a confirmation response is received. The upper limit N for the number of retransmissions of ordinary data frames is 1. max By packet loss rate Ploss Dynamic calculation: Among them, N base is the preset base number of retransmissions, and b is the logarithmic base. This formula dynamically adjusts the upper limit of retransmissions based on network stability, increasing the number of retransmission attempts when the packet loss rate is high.

[0049] The breakpoint resume feature implements interruption recovery by persistently storing the transfer progress status. First, a breakpoint record structure is defined in non-volatile memory, containing a file identifier, the last successful frame number, and a buffer for partial transfer data. For example, the breakpoint record is updated after each completed block transfer, using a write-ahead log (WAL) mechanism to ensure data consistency. When a transfer interruption is detected, the most recent valid breakpoint record is read and the unfinished block is resumed from the breakpoint. This design avoids repeated transmission of successful data and reduces network resource consumption.

[0050] The timing logic of the transmission control process is strictly constrained by a finite state machine. First, the transmission session is initialized, loading the file block queue and protocol configuration parameters. Then, the data transmission state is entered, sending packets in a block sequence and starting a timeout timer. Upon receiving an acknowledgment (ACK) from the receiver, the block is marked as complete and the next block is moved to. If no acknowledgment is received within the timeout, the block is retransmitted or discarded based on the priority policy. This process ensures the orderly and recoverable transmission process.

[0051] The network quality assessment module calculates the real-time packet loss rate through the sliding window statistical method. First, define the time window length T W , count the total number of packets sent within the window N send and the number of confirmation packets N ack Packet loss rate P loss The calculation formula is: This value is updated every time a time window is completed and is used to dynamically adjust the retransmission strategy parameters. The sliding window mechanism can smooth out instantaneous network fluctuations and provide a stable quality assessment indicator.

[0052] The data block encapsulation process follows the structured file format definition. Each packet header contains a block number, length, and priority flag fields, while the data portion carries the compressed firmware content. For example, the block number is implemented using a 16-bit cyclic counter that automatically wraps when the number space is exhausted. The length field indicates the number of valid bytes in the data portion, allowing the receiver to verify the integrity of the block. This encapsulation format clearly defines block boundaries and supports out-of-order reception and reassembly verification.

[0053] The protocol adaptation layer implements dynamic loading and unloading of the transport protocol stack. When the protocol decision module triggers a protocol switch, it first releases the current protocol stack resources and then initializes the new protocol control block. For example, CoAP protocol stack initialization includes UDP port binding and message ID generator setup; MQTT protocol stack initialization requires establishing a TCP connection and negotiating a Quality of Service (QoS) level. This layer abstracts and isolates protocol differences, providing a unified transport interface for upper layers.

[0054] The priority scheduler allocates network bandwidth resources through a weighted round-robin algorithm. First, the weight coefficient ω is set for different priority queues. h (high priority) with ω l (low priority). During scheduling, packets are extracted from each queue according to the weight ratio and sent, meeting the following requirements: Where ρ is the preset minimum priority-to-bandwidth ratio. This algorithm can ensure that high-priority frames have sufficient transmission opportunities while avoiding long-term starvation of low-priority data.

[0055] Transmission integrity verification is achieved through end-to-end checksum comparison. The sender calculates and appends a checksum when encapsulating the blocks, and the receiver performs checksum verification after reassembling the blocks. For example, the checksum algorithm used is a cyclic redundancy check (CRC), and the generator polynomial G(x) satisfies: Among them, k is the check code width, g i The polynomial coefficients are used. This checksum mechanism can detect bit errors in data transmission and trigger retransmission requests for erroneous blocks.

[0056] The abnormal interruption processing process is realized by the heartbeat mechanism and the watchdog timer. During the transmission process, heartbeat packets are sent regularly to maintain the connection activity. heartbeat If there is no heartbeat response, the connection is considered disconnected. The watchdog timer will be interrupted when the maximum no-response time T max This dual detection mechanism can quickly identify network failures and trigger the breakpoint saving and connection reestablishment process.

[0057] The transmission progress visualization module provides real-time status feedback via the protocol control channel. The sender periodically generates transmission progress reports, including the percentage of blocks transferred, the current transmission rate, and the estimated remaining time. For example, progress reports are encapsulated as independent control messages and sent before data blocks. This feedback mechanism provides transparent transmission process monitoring capabilities for upper-layer applications, supporting user interaction and logging.

[0058] The hysteresis control of dynamic block adjustment avoids frequent switching by designing the hysteresis interval. A hysteresis band Δθ is set near the signal strength thresholds θ1 and θ2. When the signal strength is within θ i Maintain the current block length unchanged when the signal fluctuates within the range of ±Δθ. This design can suppress the block size oscillation caused by short-term signal fluctuations and improve transmission stability. The formula is corrected to: This hysteresis mechanism avoids parameter jitter by memorizing the previous state, and requires additional maintenance of historical block length information in the state machine.

[0059] S4. Implement multi-level security verification, performing frame checksum verification, file integrity hash checksum verification, and digital signature legitimacy verification on the transmission data stream in sequence; The present invention implements multi-level security verification, building a security assurance system that covers the entire lifecycle of the transmitted data stream through a layered verification mechanism. First, a frame-level verification model is established to perform real-time integrity verification on each transmitted data unit. For example, a cyclic redundancy check algorithm is used to generate a frame check code, which is appended to the end of the data frame and transmitted along with the main data. By recalculating the check value and comparing it with the received value, the receiver can detect bit errors or data tampering during transmission. This layered verification operates during the data transmission phase, providing fundamental data reliability assurance for subsequent processing.

[0060] The polynomial selection for the frame check algorithm directly affects the error detection capability. Preferably, the internationally standardized generator polynomial definition is used, and its mathematical expression is: Among them, k is the check code width, g i For a data frame D with a length of n bytes, the check value calculation process first treats the data as a polynomial D(x) and performs a modulo 2 division operation: CRC=D(x)·x k mod G(x); The remainder obtained from the calculation is the check code. This algorithm can detect sudden errors and random bit flips, and trigger a retransmission request for the corresponding data frame when the check fails.

[0061] The file integrity verification phase generates a digital fingerprint of the firmware data using a hash algorithm. First, after reassembling all data frames at the receiving end, a hash calculation is performed on the original data stream before decompression. For example, a cryptographically secure hash function is used to generate a fixed-length digest value H(m), and its calculation process satisfies: H(m) = Hash(m); Where m is the reassembled firmware data byte stream. The calculated result is compared with the hash reference value stored in the file header. If there is a mismatch, the file integrity is considered compromised. This verification layer operates during the data reassembly phase, ensuring that the firmware content has not been tampered with or damaged during transmission.

[0062] The digital signature verification phase uses asymmetric encryption technology to verify the legitimacy of the firmware source. First, the digital signature attached to the end of the file is parsed to extract the signature elements r and s. For example, the Elliptic Curve Digital Signature Algorithm (ECDSA) is used for verification, and its mathematical verification conditions are: R≡(s -1 ·(H(m)+d Q ·r))mod p; Where R is the horizontal coordinate of the elliptic curve point, d Q Where is the issuer's private key parameter, and p is the elliptic curve domain modulus. During verification, the coordinates of the temporary point are calculated using the public key Q. If the equation is satisfied, the signature is valid. This level of verification confirms the authenticity of the firmware publisher and prevents malicious firmware injection attacks.

[0063] In the timing control of the verification process, the three levels of verification form a strict dependency relationship. Frame check is performed in real time upon data reception. Frames that fail check are immediately discarded and retransmission is requested. File hash verification is triggered after all blocks have been received and reassembled. If verification fails, the received data is discarded and processing is terminated. Digital signature verification, as the final security checkpoint, is performed only after hash verification passes, ensuring the correct implementation of additional security measures such as certificate chain validity verification and signature timestamp checking.

[0064] The exception handling mechanism manages verification errors at different levels through status code classification. A frame checksum failure generates an E1xx series error code, recording the error frame sequence number and the expected checksum value. A file hash mismatch triggers an E201 error, recording the byte position of the difference between the actual hash value and the reference value. A signature verification failure generates an E202 error, extracting the Certificate Revocation List (CRL) to verify the issuer's identity. This classification mechanism accurately identifies the type of security threat and provides structured log data for subsequent troubleshooting.

[0065] Hash calculation optimization improves the efficiency of large file verification by parallelizing block processing. First, the reorganized firmware data is divided into processing blocks of equal length, and the intermediate hash value is calculated independently for each block. The final hash value is generated by concatenating the intermediate results of each block, satisfying: H total =Hash(H1‖H2‖…‖H n ); Among them, H iis the hash value of the i-th data block, and || represents the byte concatenation operation. This parallel processing can fully utilize the resources of multi-core processors and reduce the time complexity of a single hash calculation.

[0066] Elliptic curve parameter configuration strictly follows standardized cryptographic specifications. Preferably, the NIST P-256 curve parameter definition is used, where the prime field modulus p satisfies: p=2 256 -2 224 +2 192 +2 96 -1; Parameters such as the coordinates of the base point G and the covariance factor h are preset according to standard documentation. This standardized configuration ensures interoperability among algorithm implementations and avoids verification failures due to inconsistent parameters.

[0067] The certificate chain verification process verifies the identity of the issuing party by traversing trust anchors. It first extracts the X.509 certificate chain from the firmware signature, verifying the validity of each certificate signature step by step until it reaches the root certificate. For example, the root certificate fingerprint is pre-stored in the device's secure storage area. During verification, the certificate hash value is calculated and compared with the pre-stored fingerprint. This mechanism establishes a trusted certificate verification path and detects abnormal conditions such as the revocation or expiration of intermediate certificates.

[0068] Timestamp verification, as an extension of signature verification, mitigates the risk of replay attacks. The signature information from the authoritative timestamp server is extracted from the signature attributes, and the logical relationship between the timestamp's validity period and the issuance time is verified. For example, the firmware signature timestamp must be within the device's current security window and no earlier than the certificate's validity start time. This verification ensures the timeliness and sequence correctness of firmware updates.

[0069] Memory security is achieved by enabling hardware isolation technology during the verification process. Separate memory protection zones are allocated for hash calculation and signature verification modules, preventing unauthorized processes from accessing intermediate data during cryptographic operations. For example, ARM TrustZone technology is used to separate the secure and non-secure worlds, allowing key storage and cryptographic operations to be performed in a secure environment. This design protects against side-channel attacks and memory tampering attacks.

[0070] A verification result caching mechanism optimizes efficiency in repeated verification scenarios. For verified firmware files, their hash values ​​and digital signatures are stored in a secure cache. When the same file identifier is detected again, the cached record is prioritized for comparison rather than recalculation. This mechanism reduces redundant computing resources while ensuring data freshness through cache entry expiration policies.

[0071] The fault tolerance mechanism enhances system robustness by setting a configurable verification retry threshold. When the number of consecutive frame check failures reaches a preset threshold, the system automatically switches to a redundant communication channel for retransmission. For example, if the primary cellular network channel fails, a backup LoRaWAN channel is used to transmit critical control frames. This mechanism can mitigate the impact of localized network failures on the verification process and maintain system availability.

[0072] The key update protocol dynamically manages certificates and public keys through a secure channel. When a root certificate expiration or key compromise is detected, the Online Certificate Update Protocol (OCSP) is initiated to retrieve the latest certificate chain. For example, the update request message is sent to the key management server via HTTPS. The response data is digitally signed and then written to a secure storage area. This protocol ensures the timeliness and security of cryptographic materials.

[0073] On resource-constrained devices, a layered verification degradation strategy is employed to balance security and performance. When memory resources are insufficient, digital signature verification is prioritized, and hash verification is switched to a lightweight algorithm. For example, when RAM falls below a threshold, the MD5 algorithm is automatically selected instead of SHA-256 for hash calculations. This dynamic adaptation mechanism maintains system stability while safeguarding core security functions.

[0074] Verification process audit tracking provides full traceability through secure logging. Each verification step generates a timestamped log entry, recording the operation type, input data fingerprint, and verification result. For example, log entries are encrypted and stored in tamper-resistant memory, allowing extraction and analysis through a secure debugging interface. This audit mechanism provides a complete chain of evidence for post-event security analysis.

[0075] The algorithm implementation is optimized by using pre-computation techniques to reduce real-time computational overhead. Static data, such as the CRC checksum table and elliptic curve doubling table, is pre-generated during the initialization phase and stored in fast-access memory. For example, the CRC32 table lookup method converts polynomial calculations into 256-item pre-stored remainder table lookups, reducing computational complexity from O(n) to O(1). This optimization significantly improves the real-time response performance of the verification process.

[0076] Multi-level verification state synchronization is achieved through an event flag mechanism. Upon frame check completion, the data available flag is set, triggering the hash verification thread to start. After hash verification passes, the integrity flag is set, activating the digital signature verification process. This flag-driven mechanism ensures strict sequential execution of each verification layer, preventing inconsistent system states caused by race conditions.

[0077] S5. Decompression and hardware compatibility verification: decompress the firmware data that has passed security verification and match the hardware version of the target device with the compatibility range declared in the file format; The present invention ensures that the firmware can be safely updated through a structured data processing process when performing decompression and hardware compatibility verification. First, a dynamic allocation model for the decompression buffer is established to determine the memory requirement based on the compression algorithm identifier. For example, the high 4-bit binary value of the compression parameter field in the file header is parsed and mapped to the exponential factor C. p The calculation formula of buffer size B is: Here, K is a preset base unit value. This formula dynamically allocates memory space based on the complexity of the compression algorithm, preventing buffer overflows and resource waste. During the initialization phase, the decompression module requests a contiguous memory area of ​​a specified size to provide storage space for subsequent data expansion.

[0078] Hardware version compatibility verification is achieved by comparing the version number interval. First, read the hardware version number V from the device non-volatile memory. dev , the value is preferably stored in a read-only area at the specified address. The version number matching condition is defined as: V min ≤V dev ≤V max ; Among them, V min and V max The compatibility range boundary value declared in the file header. The verification module compares the device version number with the file header field byte by byte. If any byte is out of range, the device is deemed incompatible. This mechanism precisely controls the firmware version compatibility range and prevents system failures caused by hardware mismatches.

[0079] The decompression process uses a streaming decoding algorithm to achieve efficient memory utilization. First, the compression dictionary is loaded into a buffer, and the dictionary version is confirmed by a file header identifier. For example, if the dictionary identifier matches a pre-stored local dictionary, the local dictionary is directly called to accelerate decompression. During data decompression, the compressed stream is read sequentially in blocks, and a reverse encoding operation is performed to restore the original data. This process can reduce peak memory usage and is suitable for resource-constrained embedded devices.

[0080] The dual-partition firmware update mechanism achieves secure updates through address remapping. The device memory is divided into a primary partition and a backup partition, with the partition switch flag stored in a separate configuration area. For example, before the firmware update, the target partition is verified to be idle and the decompressed firmware data is written to the inactive partition. After the firmware update is complete, the partition switch flag is updated, allowing the device to boot from the new partition upon reboot. This design ensures a rapid rollback to a working version in the event of a firmware update failure, maintaining basic system functionality.

[0081] Decompression integrity is verified through a dual-factor cyclic redundancy check (CRC) and hash comparison. After decompression, a CRC check is performed on the restored data, ensuring that the check polynomial is consistent with the pre-compression parameters. A hash value of the decompressed data is then calculated and compared with the original hash value stored in the file header. Typically, the hash algorithm uses the same configuration parameters as before compression to ensure consistency in verification conditions. This dual-factor check can identify data corruption or memory errors during the decompression process.

[0082] Version number encoding rules use a hierarchical structure to define hardware compatibility. The version number is broken down into major, minor, and revision fields, each occupying a separate byte segment. For example, a difference in the major version number indicates hardware architecture incompatibility, a difference in the minor version number indicates a peripheral interface change, and a difference in the revision number indicates a firmware tweak. During verification, different error codes are generated based on the level of difference, providing refined information support for fault diagnosis.

[0083] The memory release policy is executed immediately after the firmware update passes verification. The decompression buffer is released in two scenarios: immediately upon successful firmware update verification; and if verification fails, the buffer data is retained until error recovery is complete. For example, a memory write-protection check is performed before the release operation to prevent the accidental release of in-use data areas. This policy optimizes memory resource utilization and prevents invalid data from occupying storage space for extended periods of time.

[0084] The firmware update verification process includes two levels: block-by-block verification and global verification. First, a read verification is performed on each firmware update block, comparing the written data with the original data for binary consistency. Once all blocks have passed verification, a hash check is performed on the entire partition to ensure the integrity of the firmware update data. For example, the block size is aligned with the memory erase unit to reduce the number of accesses during the verification process. This layered verification enables early detection of physical storage media defects.

[0085] Abnormal interruption recovery uses firmware update progress markers to enable resuming the firmware update from a breakpoint. The current firmware update block number is recorded in non-volatile memory. The storage structure includes the block index, checksum, and timestamp. When a firmware update interruption is detected, the most recent valid progress marker is read, and the firmware update continues by skipping the confirmed correct block. This mechanism avoids duplication of firmware updates for verified data, significantly reducing recovery time.

[0086] The hardware version number is encrypted and stored using Physically Unclonable Function (PUF) technology to enhance tamper resistance. The PUF module generates a mixed hash value from the device's unique identifier and version number, which is then stored in a write-protected memory area. During verification, the mixed hash value is recalculated and compared with the stored value. A mismatch indicates that the version number has been tampered with. This technology protects against hardware-level version counterfeiting attacks, enhancing overall system security.

[0087] The decompression algorithm selector dynamically loads the decoding module based on the file header identifier. A library of multiple decompression algorithms is pre-installed, including streaming and dictionary decoding. For example, when the identifier points to streaming decoding, the sliding window buffer is initialized; when it points to dictionary decoding, the pre-trained dictionary tree is loaded. This dynamic loading mechanism adapts to firmware files generated by different compression strategies, improving system compatibility.

[0088] Post-firmware update functional testing verifies system stability using a pre-set set of test cases. It automatically performs peripheral interface testing, memory stress testing, and communication protocol handshake verification. For example, a GPIO port test sends a specific pulse sequence and detects the response waveform to confirm that the hardware driver is loading correctly. If a test fails, the current partition is automatically marked as abnormal, triggering a rollback to the backup partition. This testing process can identify potential compatibility issues and ensure reliable system operation after the update.

[0089] The grayscale release mechanism uses a mask field to control the scope of device updates. A bit mask parameter is set in the compatible range field of the file header and bitwise ANDed with the device serial number. For example, the least significant bit of the mask controls the production batch, and the next-lowest bit controls the region code. The firmware update is only allowed if the device signature matches the mask parameter. This mechanism enables phased and controlled firmware releases.

[0090] Firmware signature inheritance verification is enforced during hardware version changes. When a major version upgrade is detected, the new firmware is required to include compatibility declarations for all devices configured with the previous version. For example, this is done by traversing the previous version's compatibility range set to verify the new version's superset relationship. This mechanism ensures backward compatibility during hardware iterations and prevents orphaned versions from occurring between device batches.

[0091] An error code mapping table provides operators with precise fault location. Each verification failure generates a composite error code containing the module identifier, error type, and severity level. For example, error code 0xE301 indicates a hardware version major number mismatch, while 0xE302 indicates a minor number out of range. The code table is stored in a separate read-only memory and can be read and parsed through the debug interface. This design accelerates on-site fault diagnosis and reduces system downtime.

[0092] Firmware update integrity is ensured through post-write read (PVR) technology. After writing to each storage cell, an immediate read verification is performed to compare the written value with the expected value. For example, a bit flip detection algorithm is used in NORFlash memory to count the number of flipped bits and determine whether it exceeds the error correction code tolerance. This technology can identify write anomalies caused by storage media aging, improving the reliability of the firmware update process.

[0093] Multi-device batch firmware updates optimize processing efficiency through parallel verification queues. A firmware update task queue is created on the gateway device, and parallel verification is performed on devices of the same model. For example, DMA channels are used to simultaneously transmit verification data from multiple devices, and hardware accelerators are used to parallelize hash calculations. This optimization significantly reduces the overall time required to update a group of devices, making it suitable for centralized maintenance of charging stations.

[0094] S6, abnormal monitoring and closed-loop recovery, when a preset number of errors are detected continuously during the transmission, verification or firmware update process, it switches to the backup partition to resume operation and generate an error report.

[0095] The present invention ensures system robustness through a multi-level error detection and automatic recovery mechanism when implementing exception monitoring and closed-loop recovery. First, an error classification model is established to classify possible exceptions that may occur in the update process into three categories: transmission errors, verification errors, and compatibility errors. For example, transmission errors include data block loss or verification failure events, verification errors include hash value mismatches and signature verification anomalies, and compatibility errors refer to hardware versions exceeding the range declared in the file. This classification model can provide accurate type identification for error handling and drive the execution of differentiated recovery strategies.

[0096] The error counter uses a sliding time window algorithm to count the frequency of abnormal occurrences. Define the time window length T w , maintain error type code queue E in the window q When a new error event i When this happens, remove old records in the queue that exceed the time window and update the current error count: Among them, δ is the indicator function, when e j Type and E t If type is the same, it takes 1, otherwise it takes 0. t ype)≥N th The recovery mechanism is triggered when N th The algorithm can dynamically calculate the distribution of recent errors to avoid historical anomalies interfering with current state judgment.

[0097] The recovery triggering conditions are strictly constrained by the finite state machine model. The system state set {S0: normal, S1: warning, S2: recovering} is defined, and the state transition rules are: S0→S1: When C(E t ype)≥N th / 2; S1→S2: When C(E type )≥N th ; S2→S0: Recovery verification passed; This state machine forces the system to go through the early warning phase before entering recovery, reserving a time window for manual intervention.

[0098] The dual partition switching mechanism achieves seamless recovery through address remapping. The device storage area is divided into primary partition P m With the backup partition P b , the partition status is recorded in the independent configuration area P c When recovery is triggered, the following sequence of operations is performed: Suspend the current task and prohibit new write operations; P c The active partition identifier in the b ; Refresh the memory address mapping table; Restart the system and run from P b Load the firmware; This process can complete partition switching within 5ms, minimizing service interruption time.

[0099] The recovery verification process includes dual detection of partition integrity and functionality. First, calculate the hash value H of the backup partition. b , and the pre-stored reference value H base Compare and verify data integrity: Then perform core function self-test, including peripheral driver initialization test and communication protocol handshake verification. Update P after all tests pass c The partition health status flag in the , otherwise the secondary recovery process is triggered.

[0100] The error log generation module uses a structured data format to record the exception context. Each log record contains: Error Code (E1xx / E2xx / E3xx) Occurrence timestamp (ISO8601 format) Unique device identifier Logs of relevant data fingerprints (such as the hash value of the errored block) are encrypted with AES-GCM and stored in a secure storage area to prevent unauthorized tampering. This design provides a complete, auditable chain of evidence for post-event root cause analysis.

[0101] The automatic recovery strategy selects differentiated processing paths based on the error type. For transmission errors, the network channel is prioritized for retransmission and failed blocks are retransmitted; verification errors trigger a firmware redownload; and compatibility errors freeze the update process and report to the management platform. For example, a policy routing table maps error codes to a pre-set recovery action sequence, ensuring scalability and maintainability of the processing logic.

[0102] The heartbeat detection mechanism maintains system recoverability through keep-alive messages. The monitoring daemon process periodically (period T h ) sends heartbeat requests to each functional module, and is expected to r Receive a response within the time. When N consecutive losses h When the module is in an unrecoverable state, the following operations are performed: 1. Dump module runtime status to non-volatile memory 2. Reset the module process or hardware unit 3. Restore the execution context from the dumped state. This mechanism can detect deep anomalies such as deadlocks or resource leaks and restore basic system functions.

[0103] Storage media health monitoring prevents data corruption through bad block rate indicators. Real-time statistics of the number of write / erase times N of the storage block. we , when: N we ≥α·N max ; When the block is marked as a high-risk area, N max is the nominal durability of the media, and α is a preset coefficient. When the number of high-risk blocks detected exceeds the threshold, data is automatically migrated to reserved space and the address mapping table is updated. This mechanism can extend the lifespan of the storage and reduce the probability of recovery failure due to physical damage.

[0104] Closed-loop recovery verification achieves stability assurance through the negative feedback mechanism in control theory. Define the recovery action set A={a1,a2,...,a n}, after executing the recovery action, collect the system status index M and calculate the state deviation: ΔM=||MM target ||; When ΔM>β, the next priority recovery action is selected and iteratively executed until the system returns to a stable state. This closed-loop control can avoid system paralysis caused by the ineffectiveness of a single recovery action. Error propagation suppression prevents cascading failures by isolating boundaries. An independent memory protection domain is divided for each functional module. When a module crashes, the hardware memory management unit (MMU) automatically isolates its address space. For example, the MPU configuration is used to set the module working memory to non-privileged access mode, and illegal access triggers a hardware exception interrupt. This design can limit the impact of local failures and improve the overall system availability.

[0105] The real-time resource monitoring module tracks the CPU, memory and network resource usage. Define resource overload judgment conditions: R usage >γ·R total ; where R totalis the total amount of resources, and γ is the overload threshold coefficient. When overload is detected, the system dynamically degrades the quality of service for non-core functions (for example, by extending the update task cycle), prioritizing resource supply for basic monitoring and recovery functions. This strategy maintains minimum system availability when resources are scarce.

[0106] The version rollback protocol provides a final guarantee mechanism when recovery fails. When the number of consecutive recovery attempts exceeds N rollback When the system is downgraded, the last available version of the firmware is obtained from a remote server to perform a forced downgrade. The rollback process verifies the digital signature and compatibility of the old version, completely erases the current partition and writes the old version. This protocol can overcome the limitations of local recovery and achieve system recovery through external resources.

[0107] The secure recovery channel ensures the transmission of critical commands via an independent communication link. If the primary network becomes unavailable, a backup out-of-band management channel (such as a hardware serial port) is used to transmit recovery commands. For example, the HDLC protocol is used to encapsulate recovery control commands, which include a CRC32 checksum and sequence number to prevent replay attacks. This channel maintains minimal control capabilities in the event of a primary protocol stack failure.

[0108] Persistent state storage utilizes a dual layer of protection: a write-ahead log (WAL) and checksums. When saving and restoring context, the operation log entry is written first, followed by actual data storage, and finally the checksum is updated. Log integrity is prioritized during reads, and any checksum errors trigger a log replay to restore data consistency. This mechanism prevents incomplete state storage caused by sudden power outages.

[0109] The anomaly prediction model identifies risks in advance through time series analysis. Collect the timestamps of historical error events to construct the event interval sequence T = {t1, t2, ..., t n}, calculate the autocorrelation function: Where μ is the sequence mean. When significant periodic characteristics are detected, preventive recovery is proactively performed before the predicted peak period (e.g., memory fragmentation recovery). The recovery process is visualized through dual indication via status code LEDs and protocol messages. The device panel LED flashes according to a preset coding pattern to indicate the current recovery stage, and status change events are sent to the monitoring center via the management protocol. For example, a solid yellow light indicates an early warning state, a flashing red light indicates recovery in progress, and a solid green light indicates complete recovery. This dual indication mechanism provides consistent status awareness for on-site and remote operation and maintenance personnel.

[0110] The fault-tolerant clock synchronization protocol maintains event timing even when the system clock is out of sync. It uses the Berkeley algorithm for hybrid synchronization with multiple reference clock sources, defining clock skew. (This predictive maintenance reduces the likelihood of unexpected anomalies.)

[0111] When |Δt|>δ t The system gradually adjusts the local clock to avoid sudden, large jumps. This gradual synchronization maintains the reliability of the event log's timing even when the clock circuit fails. The self-learning recovery strategy optimizes processing efficiency through a reinforcement learning model.

[0112] Record the execution effect and time of each recovery action and build the state-action value function: Where r is the recovery effectiveness score, and λ is the discount factor. By continuously updating the Q-value table, the system can gradually select a more optimal recovery strategy. This learning mechanism must be verified in a sandbox environment before being deployed to production systems to ensure the security of the learning process.

[0113] The examples of this specific embodiment are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Identical components are represented by the same reference numerals. Therefore, any equivalent changes made based on the structure, shape, and principle of this application should be included in the scope of protection of this application.

Claims

1. A remote firmware update optimization method for an electric bicycle charging station, characterized in that: The following steps are involved: S1. Build a layered communication protocol architecture. Dynamically schedule and update tasks at the application layer to generate transmission strategies. The transport layer generates dynamic block strategies based on real-time network signal strength. The network layer selects communication protocols based on transmission unit size. S2. Encapsulate the structured firmware file and generate a file format including a compression algorithm identifier, a hardware version compatibility range, and a multi-level checksum field. In the file format, each frame of data carries a unique serial number and a checksum. S3. Execute network adaptive transmission, transmit the structured firmware file based on the dynamic block strategy and communication protocol, and trigger a priority retransmission mechanism when packet loss is detected; S4. Implement multi-level security verification, performing frame checksum verification, file integrity hash checksum verification, and digital signature legitimacy verification on the transmission data stream in sequence; S5. Decompression and hardware compatibility verification: decompress the firmware data that has passed security verification and match the hardware version of the target device with the compatibility range declared in the file format; S6, abnormal monitoring and closed-loop recovery, when a preset number of errors are detected continuously during the transmission, verification or firmware update process, it switches to the backup partition to resume operation and generate an error report.

2. The remote firmware update optimization method for an electric bicycle charging pile according to claim 1, characterized in that: In the dynamic block strategy, the block length L and the network signal strength RSRP satisfy the following piecewise function relationship: in: RSRP: Reference Signal Received Power.

3. The remote firmware update optimization method for an electric bicycle charging pile according to claim 1, characterized in that: The frame checksum verification adopts the CRC16-CCITT algorithm, and its generating polynomial is: G(x)=x 16 +x 12 +x 5 +x 0 ; The checksum calculation method satisfies: in: D k : The integer value of the kth byte of the data frame, n: The byte length of the data part of a single frame, Indicates byte-wise exclusive OR operation.

4. The remote firmware update optimization method for an electric bicycle charging pile according to claim 1, characterized in that: The digital signature legitimacy verification adopts the elliptic curve digital signature algorithm, and its verification formula is: R≡(s -1 ·(H(m)+d Q ·R))mod p; in: R is the horizontal coordinate of the elliptic curve point in the signature, s is the signature random number, H(m): the hash value of the firmware data calculated by the SHA-256 algorithm, d Q is the private key parameter, and p is the elliptic curve prime field modulus.

5. The remote firmware update optimization method for an electric bicycle charging pile according to claim 1, characterized in that: The file format includes the following fields: Start tag field: fixed 4-byte hexadecimal identifier; Compression algorithm type field: 1-byte identifier, defining uncompressed, ZIP, 7ZIP, or LZ4 algorithm; Hardware version compatibility field: 8-byte range value, defining the minimum and maximum compatible version numbers; Original firmware hash value field: 16 bytes storing the MD5 hash value.

6. The remote firmware update optimization method for an electric bicycle charging pile according to claim 1, characterized in that: In the priority retransmission mechanism, the upper limit N of the number of retransmissions of ordinary data frames is max satisfy: in: P loss : Current network packet loss rate; Ceiling function.

7. The remote firmware update optimization method for an electric bicycle charging pile according to claim 1, characterized in that: The hardware compatibility verification must satisfy the following inequalities: In min ≤V dev ≤V max ; in: V dev : Hardware version number of the target device; V min 、V max : The compatible version range declared in the firmware file.

8. The remote firmware update optimization method for an electric bicycle charging pile according to claim 1, characterized in that: The triggering conditions for abnormal monitoring and closed-loop recovery are: Three or more errors of the same type occur cumulatively during a single update process. Error types include: Transmission error: frame check failure or data loss Verification error: Hash check or signature verification failed Compatibility Error: Hardware version mismatch.

9. A remote firmware update optimization method for an electric bicycle charging station, characterized in that: The calculation formula of the decompression buffer size B is: B=2 CP[4:7] ×1024 bytes; in: CP[4:7]: The high 4-bit binary value of the compression parameter field.

Images