Method and device for non-inductive upgrade of substation node firmware of bus system
By dividing the storage area in the bus system and adopting program boot code and data verification mechanisms, the storage management, data transmission and security issues of bus system firmware upgrades are solved, realizing seamless and reliable firmware upgrades.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-05
- Publication Date
- 2026-03-13
AI Technical Summary
Existing firmware upgrade methods for bus systems have shortcomings in storage management, data transmission, and security protection, which affect the reliability and efficiency of upgrades.
By dividing the memory of the substation node into a bootloader area, an application area, an image data area, and a parameter storage area, and using the program boot code to detect the upgrade flag, combined with the master station broadcasting firmware upgrade instructions, data packet sequence numbers, and checksums, data storage, verification, and system reset operations are realized, thus constructing a reliable firmware update mechanism.
It enables secure management of bus system firmware upgrades, ensuring the accuracy and reliability of the upgrade process and reducing the risk of manual intervention and system interruption.
Smart Images

Figure CN121658045A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data processing, specifically to a method and apparatus for seamlessly upgrading the firmware of a substation node in a bus system. Background Technology
[0002] Existing firmware upgrade methods for bus systems have significant shortcomings. Traditional systems perform poorly in firmware updates, failing to effectively integrate storage partitions and boot mechanisms, thus affecting upgrade reliability.
[0003] Furthermore, existing technologies suffer from bottlenecks in data transmission and verification. Most systems lack robust packet sequence management mechanisms and error retransmission strategies, making upgrade processes prone to failure.
[0004] The existing system has technical shortcomings in security protection. It lacks integrity verification of firmware data, making reliable program switching difficult through partition management, thus affecting system stability. Solving these problems is crucial for improving firmware upgrade efficiency. Summary of the Invention
[0005] To address the problems in the prior art, this application provides a method and apparatus for seamlessly upgrading the firmware of substation nodes in a bus system. This method effectively solves the shortcomings of traditional technologies in terms of storage management, data transmission, and upgrade security, and provides technical support for bus system firmware upgrades.
[0006] To solve at least one of the above problems, this application provides the following technical solution: Firstly, this application provides a method for seamlessly upgrading the firmware of a substation node in a bus system, comprising: The memory of the substation node is divided into a boot program area, an application program area, an image data area, and a parameter storage area. The boot program code is written in the boot program area. The boot program code is used to detect the upgrade flag bit and determine whether to copy the firmware data in the image data area to the application program area based on the upgrade flag bit. The boot program parameters are stored in the parameter storage area. The master station broadcasts firmware upgrade instructions to the substation nodes at preset time intervals. After receiving the firmware upgrade instructions, the substation nodes clear the data receiving pointer and the receiving sequence number counter. The master station sends firmware data packets to the substation nodes. The firmware data packets include packet header identifier, data packet sequence number, firmware data and check code. The substation nodes store the firmware data in the mirror data area according to the data packet sequence number and return data storage status information to the master station. The master station receives data storage status information returned by the sub-station node. When the data storage status information indicates a data storage error, it retransmits the firmware data packet with the corresponding sequence number. After sending all firmware data packets, it sends a verification data packet to the sub-station node. The sub-station node verifies the firmware data in the mirror data area. After the verification is successful, it sets the upgrade flag and performs a system reset operation. The program boot code copies the firmware data in the mirror data area to the application area.
[0007] Furthermore, it also includes: reading the capacity parameters and address space distribution of the substation node memory, calculating the starting address and length of each region based on the capacity parameters, marking the physical partition boundaries in the memory address space, generating a storage region allocation table, writing the storage region allocation table into the memory boot sector, and constructing a partition structure of boot program area, application program area, image data area and parameter storage area; Load the binary file of the program boot code into the boot program area, set the program jump direction table in the program boot code, allocate the storage address of the upgrade flag bit, initialize the upgrade flag bit to a preset value, establish the mapping relationship between the upgrade flag bit and the program jump direction table, and write the mapping relationship into the parameter storage area.
[0008] Furthermore, it also includes: reading the current value of the upgrade flag bit from the parameter storage area, comparing the upgrade flag bit with a preset threshold, selecting the jump address in the program jump direction table according to the comparison result, reading the length information and check value of the firmware data in the mirror data area, reading the firmware data in segments according to a fixed block size, and calculating the integrity check code of each data segment. Write the verified firmware data segment to the corresponding address in the application area, update the entry address in the program jump index table, point the entry address to the program start position in the application area, record the firmware data version number and timestamp in the parameter storage area, clear the upgrade flag, and set the program counter to the start address of the application area.
[0009] Furthermore, it also includes: the master station reads the system clock, generates a broadcast time window sequence, calculates the broadcast time slot position within the time window sequence, constructs a data frame for the firmware upgrade instruction, sets the target address of the data frame as the broadcast address, fills the data frame with the firmware version number and the total number of data packets, and sends the data frame to the substation node via the bus at a preset baud rate; After receiving the firmware upgrade command, the substation node resets the data receiving pointer to the starting address of the mirror data area, clears the receiving sequence number counter, erases the historical data in the mirror data area, and initializes the data receiving buffer. The master station calculates the number of data packets based on the firmware data size, generates a firmware data packet sequence, and adds a packet header identifier, data packet sequence number, firmware data, and checksum to each data packet.
[0010] Furthermore, it also includes: the substation node parses the received firmware data packet, extracts the packet header identifier for data frame boundary identification, reads the data packet sequence number and compares it with the value of the receiving sequence number counter, verifies the checksum of the firmware data, writes the verified firmware data into the data receiving buffer, calculates the target storage address of the firmware data in the mirror data area, and writes the firmware data in the data receiving buffer into the target storage address. The firmware data written to the mirror data area is read back for verification, a data storage status word is generated, the data storage status word is combined with the address identifier of the substation node to construct a status return data frame, the status return data frame is sent to the master station within a preset time slice, the value of the receiving sequence number counter is updated, and the system continues to wait to receive the next firmware data packet.
[0011] Furthermore, it also includes: the master station parses the status data frame returned by the substation node, extracts the data storage status word and address identifier, matches the data storage status word with the preset status code, records the address of the substation node with the data storage error and the data packet sequence number, repackages the firmware data packet corresponding to the data packet sequence number, adds a retransmission flag, and sends the repackaged firmware data packet to the bus in the next broadcast time window; The master station maintains a firmware data packet sending counter. When the sending counter reaches the preset total number of data packets, it generates a firmware data integrity verification packet. The verification packet is filled with the accumulated check value of the firmware data and the cyclic redundancy check code. The verification packet is sent to the sub-station node through the bus, and the master station waits for the sub-station node to return the verification result.
[0012] Furthermore, it also includes: after receiving the verification data packet, the substation node reads the firmware data in the mirror data area, calculates the cumulative check value and cyclic redundancy check code of the firmware data, compares the calculation result with the check value in the verification data packet, generates a verification comparison result, writes the verification comparison result into the parameter storage area, reads the program boot parameters in the boot program area, sets the upgrade flag bit, and writes the status of the upgrade flag bit into the parameter storage area. The substation node triggers a hardware reset signal, restarts the system, the program counter points to the starting address of the boot program area, the program boot code reads the upgrade flag status, selects the program execution path according to the upgrade flag status, and copies the firmware data in the image data area to the application area according to the preset block size, thus completing the firmware upgrade operation.
[0013] Secondly, this application provides an apparatus for seamlessly upgrading the firmware of a substation node in a bus system, comprising: The program boot module is used to divide the memory of the substation node into a boot program area, an application program area, an image data area, and a parameter storage area. The program boot code is written in the boot program area. The program boot code is used to detect the upgrade flag bit and determine whether to copy the firmware data in the image data area to the application program area based on the upgrade flag bit. The program boot parameters are stored in the parameter storage area. The firmware accuracy module is used by the master station to broadcast firmware upgrade instructions to the sub-station nodes at preset time intervals. After receiving the firmware upgrade instructions, the sub-station nodes clear the data receiving pointer and the receiving sequence number counter. The master station sends firmware data packets to the sub-station nodes. The firmware data packets include packet header identifier, data packet sequence number, firmware data and check code. The sub-station nodes store the firmware data in the mirror data area according to the data packet sequence number and return data storage status information to the master station. The firmware upgrade module is used by the master station to receive data storage status information returned by the sub-station node. When the data storage status information indicates a data storage error, it retransmits the firmware data packet with the corresponding sequence number. After sending all firmware data packets, it sends a verification data packet to the sub-station node. The sub-station node verifies the firmware data in the mirror data area. After the verification is successful, it sets the upgrade flag and performs a system reset operation. The program boot code copies the firmware data in the mirror data area to the application area.
[0014] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method for seamlessly upgrading the firmware of a substation node in a bus system.
[0015] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method for seamlessly upgrading the firmware of a substation node in a bus system.
[0016] Fifthly, this application provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the method for seamlessly upgrading the firmware of a substation node in a bus system.
[0017] As can be seen from the above technical solution, this application provides a method and apparatus for seamless firmware upgrade of substation nodes in a bus system. Through an innovative partitioned storage architecture and control via bootloader and flag bits, it achieves secure management of the upgrade process. A data transmission system is constructed, combining sequence number management and status feedback to establish a reliable firmware update mechanism. A verification strategy is introduced, ensuring the accuracy of the upgrade through data integrity verification and reset operations. This method effectively solves the shortcomings of traditional technologies in storage management, data transmission, and upgrade security, providing technical assurance for firmware upgrades in bus systems. Attached Figure Description
[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0019] Figure 1 This is a flowchart illustrating the method for seamlessly upgrading the firmware of a substation node in a bus system according to an embodiment of this application. Figure 2 This is a structural diagram of the device for seamlessly upgrading the firmware of a substation node in a bus system according to an embodiment of this application. Figure 3 This is a schematic diagram of the structure of the electronic device in the embodiments of this application.
[0020] Figure label: Electronic device 9600, central processing unit 9100, memory 9140, communication module 9110, input unit 9120, audio processor 9130, display 9160, power supply 9170, buffer memory 9141, application / function storage unit 9142, data storage unit 9143, driver storage unit 9144, antenna 9111, speaker 9131, microphone 9132. Detailed Implementation
[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0022] The acquisition, storage, use, and processing of data in this application all comply with relevant laws and regulations.
[0023] In view of the problems existing in the prior art, this application provides a method and apparatus for seamless firmware upgrade of substation nodes in a bus system. Through an innovative partitioned storage architecture and control via bootloader and flag bits, it achieves secure management of the upgrade process. A data transmission system is constructed, combining sequence number management and status feedback to establish a reliable firmware update mechanism. A verification strategy is introduced, ensuring the accuracy of the upgrade through data integrity verification and reset operations. This method effectively solves the shortcomings of traditional technologies in storage management, data transmission, and upgrade security, providing technical assurance for firmware upgrades in bus systems.
[0024] To effectively address the shortcomings of traditional technologies in storage management, data transmission, and upgrade security, and to provide technical support for bus system firmware upgrades, this application provides an embodiment of a method for seamlessly upgrading the firmware of substation nodes in a bus system. See [link to embodiment]. Figure 1 The method for seamlessly upgrading the firmware of substation nodes in the bus system specifically includes the following: Step S101: Divide the memory of the substation node into a boot program area, an application program area, an image data area, and a parameter storage area. Write the program boot code into the boot program area. The program boot code is used to detect the upgrade flag bit and determine whether to copy the firmware data in the image data area to the application program area based on the upgrade flag bit. Store the program boot parameters in the parameter storage area. This embodiment addresses a monitoring and alarm system where a master station connects multiple substations via a bus over a wide area. The substations are typically installed inside the equipment or in remote locations, making frequent disassembly impossible. The goal of step S101 is to create a bootable, rollback-capable firmware partition structure within the non-volatile memory of each substation node. During the boot phase, a tiny boot code, based on an upgrade flag, determines whether to perform a copy of the image to the application, ensuring a seamless transition during subsequent online broadcast upgrades.
[0025] This embodiment first reads the manufacturing information and capacity boundaries of the substation memory, and parses parameters such as Flash page size, alignment granularity, and erase / write cycle limits to generate a partition plan. Considering that the IAP bootloader area must have power-loss protection and a minimum trusted chain, this embodiment places the bootloader area in the lower segment of the physical address, with a length covering the boot code, jump direction table, and minimum verification routine; the application area is centrally located, with a length that meets the maximum firmware size in the current network and reserves redundancy; the image data area is the same length as the application area to facilitate full image copying; the parameter storage area uses a separate sector, supports wear leveling, and retains multi-version parameter records. After completing the boundary calculation, a "storage area allocation table" is constructed, which contains the starting address, length, verification method, and access permission flags of each area. A copy of this table is written to both the boot sector and the parameter storage area; the former is used for quick location during the boot period, and the latter is used for verification and maintenance during the runtime period.
[0026] The boot code written in the bootloader area consists of four parts: early power-on self-test (POST), upgrade flag reading and determination, image consistency check and conditional copying, and final jump. The POST focuses on minimum peripheral initialization and stack establishment to avoid peripheral malfunctions affecting the decision path. The upgrade flag is stored using a structured record in the parameter area, including flag status, target version number, image length, image CRC, record timestamp, and write count. This, combined with a double-record strategy and a newer sequence number, reduces the risk of write corruption during power outages. To ensure the decision does not depend on the master station's online status, the boot code can determine "whether to copy" locally: if the flag is not set or the image verification fails, it directly jumps to the existing program in the application area; if the flag is set and the image CRC matches, it enters the copying process, reading from the image area in fixed block sizes, calculating intra-segment verification, writing to the corresponding address in the application area, and then reading back the verification. After copying, it updates the jump to the index entry point in the application area, clears the flag, and records the new version information.
[0027] This embodiment establishes a one-to-one mapping between upgrade flags and the program jump direction table. The jump direction table is stored in a write-only area within the boot sector, containing three items: application entry address, abnormal rollback entry, and mirror copy entry. When the flags in the parameter area change, the boot program synchronously refreshes the "preferred entry" in the vector table to become the application entry after copying. If an unrecoverable error occurs during copying, the boot program writes the "preferred entry" back to the last stable application entry and increments the failure count in the parameter area so that the master station can identify the substation's status at the broadcast level, avoiding repeated upgrade triggers. This dual-channel recording ensures the traceability of boot decisions and lays the foundation for the verification and reset connection of subsequent steps S7xx.
[0028] Considering the wide distribution of substations and the occasional occurrence of power outages and interference, this embodiment incorporates multiple layers of protection in its partitioning and boot logic. Firstly, a mutual exclusion write lock is used between the mirror data area and the application area. During copying, only blocks in the application area that are in the "updating state" are allowed to be erased or written. After copying, the application area state is switched to "valid" in one go, reducing the probability of intermediate state operation. Secondly, the parameter area uses a circular log format, with each record containing a timestamp and page sequence number. Reading is based on the record with the largest sequence number, and cross-checking the two latest records is performed if necessary. Thirdly, the boot code size is controlled to a fixed upper limit and does not rely on external interrupts, preventing uncertain paths introduced by differences in peripheral hardware. Combined with the four-zone structure of IAP / APP / IMAGE / PARM described in this embodiment, this embodiment implements the structure at both the physical and logical levels, avoiding a disconnect between "zone name and zone meaning."
[0029] To help readers grasp the quantitative relationships within the decision chain, the decision conditions during the bootstrapping phase are summarized by the following expression: D = w1·F_flag + w2·F_crc + w3·F_len, where D is the replication trigger score (physically meaning the value used to determine whether to enter the mirror replication process), F_flag represents the upgrade flag status (physically meaning whether the upgrade request recorded in the parameter area is set, either 0 or 1), F_crc represents the CRC consistency check result in the mirror area (physically meaning whether the locally calculated CRC matches the CRC recorded in the parameter area / issued by the master station, either 0 or 1), F_len represents the image length validity check result (physically meaning whether the image length falls within the application area's carrying capacity and corresponds to the total number of packets, either 0 or 1), and w1, w2, and w3 are the strategy weights (physically meaning the importance of each criterion in the triggering process, summing to 1). When D exceeds the trigger threshold, the replication path is entered; otherwise, the existing application is maintained. This formula aligns with common engineering sense: only when the request is valid and the image is self-consistent is it worthwhile to bear the write / erase costs and restart risks associated with replication.
[0030] In a specific application scenario, the master station plans to initiate an upgrade for all substations during the nighttime window. During the day, the substations have cleared their receive pointers and received the image to the IMAGE area according to the broadcast instructions, but have not touched the APP area. Upon power-off and restart at night, the bootloader first reads the latest record in PARM, finds the flag set and the CRC comparison passes, and proceeds to block copying. During copying, if a block readback is inconsistent, the bootloader records the failed block number, rewrites the block three times, and if it still fails, a rollback is triggered: clearing the flag, restoring the vector table to point to the old APP, writing the failure count to the parameter area, and retaining the image for the next attempt. The next day, after maintenance personnel replace the memory, the master station sends out a verification packet again, the substation flag is reset to the set position, and after restarting, copying and switching the entry address successfully. This demonstrates that the bootloader decision follows the principle of "safety first, rollback possible," echoing the main process in the embodiment of "setting the upgrade flag after verification, resetting, and copying."
[0031] This embodiment also considers the need for a unified approach for substations with different hardware specifications. For small-capacity Flash models, the mirror area can be configured in half-size, and a complete mirror image can be formed by two rounds of transmission. The copying process uses "round number + block number" to locate segments. For Flash with dual banks, the application area and mirror area can be mapped to two banks. During the boot process, a bank switching pointer is used to achieve near-constant time version switching. The copying process degenerates into bank marker flipping, but the flags and CRC checks in the parameter area are still used to ensure the commonality of the claims. For example, for substations in environments with strong electrical interference, the boot code adds a clock stabilization wait and power supply voltage threshold confirmation after power-on to avoid writing to the parameter area at critical voltages and causing a "half-byte" state.
[0032] From a technical and effectiveness perspective, this embodiment solves the high costs and uncontrollable risks associated with traditional upgrades that require disassembling the device and manually plugging and unplugging the programmer. By establishing the four-zone structure and boot decision chain in the S101 phase, the subsequent broadcasting by the main station and the packet reception and verification by the substations have clear "landing points." The upgrade process is separated from the runtime and executed during the boot phase, ensuring that application threads are not interrupted and that on-site users are virtually unaware of the changes. In the event of an image anomaly or write failure, the substation can be restored to the previous usable version by using the logs and vector tables in the parameter area, ensuring the continuity of system operation. These effects do not come from exaggerated algorithmic promises but are naturally derived from the causal chain of storage partitions, flag state machines, and boot code.
[0033] Step S102: The master station broadcasts a firmware upgrade command to the sub-station node at a preset time interval. After receiving the firmware upgrade command, the sub-station node clears the data receiving pointer and the receiving sequence number counter. The master station sends a firmware data packet to the sub-station node. The firmware data packet includes a packet header identifier, a data packet sequence number, firmware data, and a checksum. The sub-station node stores the firmware data in the mirror data area according to the data packet sequence number and returns data storage status information to the master station. This embodiment focuses on step S102. The system topology consists of a single master station connected to multiple substations via a bus. The substations are distributed within the equipment and at remote locations. During operation, broadcast / time-slice reporting is the normal communication method. To complete firmware distribution without disassembling the substations, this embodiment constructs a periodic broadcast mechanism and a packet scheduler on the master station side, and implements command recognition, receive context initialization, image storage, and status reporting on the substation side. The two establish a weak synchronization relationship through sequence numbers and checksums, which tolerates out-of-order delivery and packet loss without interrupting on-site monitoring, control, and alarm functions.
[0034] In this embodiment, the master station first configures broadcast time parameters, including broadcast period Tb, command duty cycle Db, data broadcast window table W={wk}, and baud rate BR. Combined with the bus physical layer's duty cycle characteristics, the master station listens for bus signals before each wk period. Upon confirming idle time, it frames and sends an upgrade command. This command frame carries the firmware version number, total number of packets N, total image length L, and window plan number, with the target address set to the broadcast address. The logic behind this is to ensure that all substations simultaneously perceive that a unified upgrade session is about to begin, without immediately forcing a switch in operating mode, thus avoiding accidental triggering of ongoing alarm reporting. Substations whose upgrade commands are correctly parsed trigger a "receive context reset" locally, pointing the receive pointer to the beginning address of the image data area, clearing the receive sequence counter, erasing valid markers and residual data segments from the image area, allocating a receive buffer, and writing the current running state identifier into the parameter area for subsequent backtracking.
[0035] When officially distributing firmware data, the master station divides the firmware file into fixed fragment sizes S, generating data packets with sequence numbers 1 to N. Each data packet consists of a header identifier H, a data packet sequence number SEQ, firmware data PAYLOAD, and a checksum CHK. H is used for frame boundary and protocol version identification, SEQ provides target location in out-of-order situations, and CHK in this embodiment uses both fast CRC and low-overhead cumulative checksums, pre-calculated and filled by the master station during packetization. Considering the possibility of short-term collisions and echoes in the field, the master station does not require each substation to respond before broadcasting the next packet. Instead, it continuously broadcasts packets with increasing sequence numbers according to the broadcast window, allowing substations that are not idle at the same time to fill in subsequent rounds. The substation determines the mirror offset address to be written according to SEQ: offset = (SEQ-1) × S. If a duplicate packet is received, it is discarded directly. If an out-of-bounds SEQ or CHK error occurs, a status word is constructed to mark the error type and the relevant sequence number.
[0036] Regarding the storage and reporting process of the substation, this embodiment first writes the PAYLOAD to the RAM buffer before writing it to the mirror area. After CRC verification, it performs Flash page-level erasure and programming. After writing, it reads back the same address range for in-mirror verification and generates a status word STAT, which includes bit definitions such as "write successful / verification failed / duplicate packet / out-of-order / mirror out of bounds". Since the master station uses broadcasting, the substation cannot interrupt at any time. Therefore, this embodiment continues the time-slice mechanism of the previous embodiment: each substation has its own reporting time slice Ti. The substation encapsulates a status return frame in Ti, which includes the address identifier, the most recently processed SEQ, STAT, and a brief error statistics. After receiving the status return, the master station updates the "completion bitmap" of the substation. If the bitmap shows that some sequence numbers have not been acknowledged or the STAT indicates an error, the corresponding sequence number is marked as a retransmission candidate.
[0037] The master station's retransmission strategy is not to send packets point-to-point to each substation. Instead, it merges and deduplicates the "missing packet sequence lists" compiled from all substations, forming a minimal retransmission set R. Data packets with these sequence numbers are then inserted into the next broadcast window, with a retransmission flag placed in the packet header. The rationale for this is that on the broadcast channel, the same retransmission packet can simultaneously fill the gaps of multiple substations, compressing the overall latency and minimizing the impact on regular alarm services. If a substation still reports failure with the same sequence number after multiple rounds of retransmission, the master station records the substation's address and the failed sequence number, marking it as "suspected storage failure or environmental interference," and adds it to the manual watchlist at the end of the session. However, this upgrade session can still proceed for other substations without being slowed down by a single point of failure.
[0038] In a typical batch upgrade scenario, at 23:00, the master station issues an upgrade command, and substations A, B, and C all reset their receiving contexts. Data broadcasting begins at 23:05. A acknowledges all data within sequence numbers 1 to 50, B reports a CRC error at sequence number 20, and C reports out-of-order data at sequence number 33. The master station does not pause broadcasting; it first completes the first round of transmission from 1 to N, then constructs R={20,33,...} based on the responses, and inserts R into the second round window. Substation B successfully writes 20 and reads back OK, and C also successfully writes 33 in the next time slice, returning a normal status. For occasional duplicate packets, the substations discard them based on the SEQ and the local completion bitmap to avoid write amplification and Flash wear. Throughout the process, the application thread continues to report alarm status according to the original time slice. The upgrade transmission is performed within the broadcast window, without conflicting with alarm reporting, achieving "online and seamless" transmission.
[0039] To establish a manageable quantitative relationship for the project, this embodiment maintains a simple constraint between the transmission rhythm and the substation processing capacity on the master station side, avoiding "flooding" broadcasts that could cause substation buffer overflows. The target number of packets to be sent per window can be defined as M = floor((Wlen-ΣTi_busy) × BR / (Lhdr + Lseq + S + Lchk)), where Wlen represents the duration of the current broadcast window (physically meaning the total time the master station is allowed to use for upgrade transmission within this window), ΣTi_busy is the total time reserved by each substation for regular reporting within the window (physically meaning the time budget for ensuring monitoring / alarms), BR is the baud rate (physically meaning the bus transmission rate), and Lhdr, Lseq, S, and Lchk are the byte lengths of the packet header, sequence number field, payload, and checksum field, respectively. The master station schedules broadcasts with M as the upper limit, ensuring continuous transmission without crowding out regular services. All parameters have clear physical meanings, and the results exhibit an intuitive monotonic relationship with the field link capacity and load structure.
[0040] In terms of security and robustness, this embodiment employs three checks: in-packet CHK, mirror readback check, and status word report confirmation; additionally, two types of anti-jitter measures are implemented: rapid identification and discarding of duplicate packets by substations, and time smoothing of status jitter by the master station (only including in R after two consecutive errors). For lines with significant electromagnetic interference, the master station can issue parameters to "reduce S and increase redundancy" in the upgrade command, reducing the load per packet and increasing the number of transmission rounds, at the cost of a longer total time but an increased success rate; for tributaries with higher bandwidth, S can be increased in reverse to reduce protocol overhead. If the time slice configuration of some substations is sparse and status returns are delayed, the master station still waits for their feedback according to the bitmap mechanism, ensuring that the progress of the group is not affected by the delay of a few individuals.
[0041] From a technical and effectiveness perspective, this embodiment addresses the challenge of online firmware broadcasting in a multi-substation, widely distributed environment. On one hand, broadcasting replaces point-to-point upgrades, significantly reducing link occupancy and manual intervention. On the other hand, through deterministic mapping of sequence numbers and mirror offsets, and three-layer verification, it ensures that each substation can safely write firmware within its own rhythm, allowing for retransmission of incorrect writes and recovery from power failures, without disrupting the operating alarm link. Connecting with the IAP / APP / IMAGE / PARM four-zone structure constructed in step S101, the integrity verification and upgrade flag setting in subsequent steps only occur after all firmware data packets have been written. The upgrade process is effectively isolated within a controllable time window, reducing the user's perception of the upgrade process and reliably ensuring system continuity.
[0042] Step S103: The master station receives the data storage status information returned by the sub-station node. When the data storage status information indicates a data storage error, it retransmits the firmware data packet with the corresponding sequence number. After sending all firmware data packets, it sends a verification data packet to the sub-station node. The sub-station node verifies the firmware data in the mirror data area. After the verification is successful, it sets the upgrade flag and performs a system reset operation. The program boot code copies the firmware data in the mirror data area to the application area.
[0043] This embodiment focuses on step S103, with the scenario limited to the master station using a broadcast method to batch upgrade widely distributed substations. To reduce manual intervention, the system establishes a round-trip confirmation mechanism between the data plane and the control plane: after each substation writes a firmware packet to the image data area, it reads back for verification and reports "data storage status information." The master station uses this information to determine whether to resend data packets with specific sequence numbers. After all packets in this round have been sent, the master station initiates a full image verification data packet, triggering the substation to perform a full verification of the image data area. After setting the upgrade flag and resetting, the boot code completes the atomic switch from image to application. The logical chain of the entire process is "packet splitting—writing—reading back—status feedback—error location—retransmission—full image verification—setting and restarting—boot copying".
[0044] In this embodiment, the "data storage status information" is returned by the substation within a preset time slice, including packet sequence number, write address, readback verification result, error category, and substation address identifier. Upon receiving the data, the master station first checks the frame validity, then matches the status word with a preset status code. If the write is correct, the completion flag for that sequence number is updated; if an error occurs, the sequence number is added to the retransmission queue. Due to the use of broadcasting, some substations may miss a time slot, causing a delay in status feedback. The master station maintains a "packet transmission counter" and "acknowledgment coverage rate" at the framing layer. After the time window is reached, it broadcasts a second reminder to the substation address that has not met the standards and allows the substation to report its status in the next time slice, avoiding misjudging network congestion as a write failure. During retransmission, the master station repackages the data packet with the target sequence number and sets the "retransmission flag" so that the substation can distinguish between the first and retransmitted data at the receiving end and adopts an "out-of-order safe write" strategy: if the sequence number lags behind the receive counter but the position in the mirror area has not yet been marked as complete, writing by sequence number is allowed; if it is already complete, it is discarded to prevent overwriting correct data.
[0045] After the firmware data packet transmission count for all sequence numbers reaches the preset total, this embodiment enters the full image verification stage. The master station generates a verification data packet with a payload of a combination of cumulative checksum and CRC. After receiving the packet, the substation performs a two-step verification on the image data area: first, it calculates the cumulative sum based on a fixed block size to quickly screen for large-scale write errors; second, it calculates the full image CRC and compares it with the value sent by the master station, and writes the comparison result to the parameter storage area. If both steps pass, the substation sets the upgrade flag in PARM, recording the target version number, image length, CRC value, and timestamp; if any step fails, the substation clears the completion flag of the current reception counter but retains the image area data for subsequent packet replenishment. After receiving a "verification failure," the master station triggers error analysis: it statistically analyzes the failure distribution of failed substations and prioritizes retransmitting to these substations according to the missing or damaged block sequence numbers. This two-level verification arrangement, which prioritizes speed and then strictness, essentially follows the engineering common sense of "coarse positioning followed by precise confirmation," which both reduces latency and lowers misjudgments.
[0046] The action chain after successful verification is deliberately split into two segments to reduce risk. The first is the control of the triggering timing of the flag and reset. The substation records the successful verification in the parameter area and sets the upgrade flag, then triggers a hardware reset, and the program counter returns to the beginning of the bootstrap area. The second is that the isolation of copying and switching is handled by the bootstrap code, which does not intervene in the APP area during runtime. After power-on, the bootstrap code reads the upgrade flag and its associated image length and CRC value, independently completing block copying, intra-segment verification, and readback verification. After completion, it updates the jump to the index entry address and clears the upgrade flag. If an unrecoverable error occurs during the copying process, the bootstrap program rolls back to the previous application version and increases the failure count in the parameter area for the master station to identify and manually intervene in the next round of broadcasting. This layered processing ensures that runtime business threads are not interrupted by the upgrade process, meeting the goal of "seamless" operation.
[0047] Considering the handling of abnormal branches is particularly crucial. This embodiment establishes a criterion-handling correspondence for common anomalies: If the status information received by the master station is "write address out of bounds," it generally stems from a discrepancy between the mirror length and the total number of packets in the substation parameters. The master station will suspend subsequent transmissions and send a corrected "mirror length parameter packet." If the status is "readback CRC error," the data packet with that sequence number will be retransmitted first, and after three failed retransmissions, the substation will be marked as "on-site processing" to avoid infinite retries. If a substation does not respond for a long time but other substations are normal, the master station will independently slow down its broadcast and extend the time slice to accommodate weak links. For failures during the verification phase, but with the failed blocks concentrated in a few sequence numbers, the master station will choose incremental packet replenishment mode, broadcasting only the failed sequence numbers to shorten the repair time.
[0048] Within a specific upgrade window, the following operational trajectory can be observed: In the evening, the master station broadcasts 1000 data packets with sequence numbers at a uniform baud rate. Approximately 90% of the substations complete this in the first round. Some substations located in areas with electromagnetic interference report multiple "readback inconsistencies." The master station adds these sequence numbers to the retransmission list and attaches a retransmission flag in the next broadcast. After retransmission, a few substations still fail the full mirror CRC comparison. The master station, based on the failed block number, only sends the approximately 20 sequence numbers required by that substation. Finally, when the substation sends back "verification passed," it internally sets an upgrade flag, resets to the bootloader to execute mirror copying, and after the second power-on, the application entry points to the new version. Throughout this process, normal substations do not need to be shut down, and abnormal substations do not affect the entire network due to a single failure.
[0049] This embodiment can be described using a simplified expression to illustrate the retransmission decision and verification triggering of the main station: J = α·E_err + β·M_miss - γ·A_cov, where J is the retransmission queue trigger strength (physically meaning the value used to determine whether to immediately retransmit a sequence number), E_err represents the error count from the substation (physically meaning the number of times the sequence number is reported as written incorrectly or CRC incorrectly), M_miss represents the missing acknowledgment count (physically meaning the number of substations that did not receive a status report for the sequence number by the end of the window), A_cov is the coverage ratio (physically meaning the percentage of substations that have confirmed successful writes), and α, β, and γ are tradeoff coefficients. When J is positive and exceeds the threshold, the master station puts the sequence number into the retransmission queue; when the A_cov of all sequence numbers reaches the set threshold, the master station generates a full mirror verification data packet to enter the next stage. Each parameter in this formula corresponds one-to-one with the observable measurements on site, and the directionality is consistent with common sense.
[0050] Starting from technical issues and effectiveness, this embodiment solves the difficulties of "unlocatable anomalies, disordered retransmissions, and difficulty in ensuring overall image consistency" in broadcast upgrade scenarios. Through readback verification and status word feedback on the substation side, the master station can achieve accurate retransmission without introducing point-to-point sessions. Through two-level verification and a layered reset-replication mechanism, the upgrade action is limited to completion during the bootstrapping phase, minimizing the impact on services during operation. Through parameter area logs and failure counts, abnormal substations can be continuously identified and isolated, preventing them from dragging down the entire network. The resulting seamless upgrade path can be reused on a large-scale distributed substation network, maintaining controllability and security even under conditions of fluctuating communication quality and unstable on-site electrical environments.
[0051] As described above, the method for seamless firmware upgrade of substation nodes in a bus system provided in this application can achieve secure management of the upgrade process through an innovative partitioned storage architecture and bootloader and flag control. It constructs a data transmission system, combining sequence number management and status feedback to establish a reliable firmware update mechanism. A verification strategy is introduced, ensuring the accuracy of the upgrade through data integrity verification and reset operations. This method effectively solves the shortcomings of traditional technologies in storage management, data transmission, and upgrade security, providing technical assurance for bus system firmware upgrades.
[0052] In one embodiment of the method for seamlessly upgrading the firmware of a substation node in a bus system according to this application, it may further include the following: Step S201: Read the capacity parameters and address space distribution of the substation node memory, calculate the starting address and length of each region based on the capacity parameters, mark the physical partition boundaries in the memory address space, generate a storage region allocation table, write the storage region allocation table into the memory boot sector, and construct the partition structure of the boot program area, application program area, image data area and parameter storage area. Step S202: Load the binary file of the program boot code into the boot program area, set the program jump direction table in the program boot code, allocate the storage address of the upgrade flag bit, initialize the upgrade flag bit to a preset value, establish the mapping relationship between the upgrade flag bit and the program jump direction table, and write the mapping relationship into the parameter storage area.
[0053] This embodiment focuses on steps S201-S202, addressing the monitoring and alarm bus scenario described in this embodiment. Substation nodes use on-chip or external NOR Flash memory with significant differences in capacity and sector size. Furthermore, the substations are installed internally within the device, and upgrades must be completed in stages while the device is online. To ensure smooth transitions in subsequent stages such as broadcast packet splitting, image storage, and power-down reset replication, this embodiment first constructs a verifiable partition layout locally on the substation and then solidifies the minimum reliable boot chain and upgrade flag state machine into the boot area and parameter area.
[0054] This embodiment enters the storage survey process after the minimum peripheral initialization upon power-on. The driver obtains raw parameters such as capacity Cap, minimum erase / write granularity Pg, sector size Sec, alignment constraint Align, and lifetime index WeLimit by reading FlashID and feature registers, and determines the available address range by combining them with MCU address mapping. In the planning logic, all candidate boundaries are first rounded using Align, and then a fixed-length LIAP is reserved for IAP according to the "minimum trusted chain for bootstrapping" principle. The length covers the boot code, basic verification routines, and jump direction table, and reserves room for growth; the length of APP LAPP is increased by a certain amount of redundancy based on the largest firmware size in the current network; IMAGE is set to the same length as APP to facilitate full image copying; PARM uses at least one independent sector and supports circular logs. To avoid unrecognizable intermediate states, this embodiment embeds read-only metadata in the header of each region using "status bits + valid flags", including region type, starting address, length, CRC, and version field. After calculating the starting address and length of each zone, a "storage zone allocation table" is generated in memory. Its fields include ZoneType, Start, Length, EraseUnit, AccessAttr, and ZoneCRC. This table is then written to a fixed offset of the boot sector, and a redundant copy of the image is written to PARM for runtime self-checking and maintenance.
[0055] In the process of marking physical partition boundaries on disk, this embodiment considers the atomicity of Flash writing and the risk of power loss. Specifically, two region allocation table slots are reserved in the boot sector. During writing, a dual-write strategy is adopted: "write the new table first, then set a valid flag, and finally invalidate the old table." The valid flag is located in a separate byte, and the setting process is a one-way process from 1 to 0 to avoid power-loss bounce. The redundant table in the parameter area uses a circular log. Each write includes an incrementing counter and a timestamp. The reading end uses the record with the largest counter as the reference. If both ends are consistent and the CRC is correct, the loading is confirmed. Due to heavy electromagnetic interference in the field, this embodiment performs a full sector erase on the target sector before writing to ensure that there are no "dirty bits" interfering with the CRC calculation. After writing, a readback verification is performed immediately. If the verification fails, the sector is automatically switched to ensure the availability of the partition table.
[0056] In step S202, this embodiment loads the compiled boot code binary into the IAP. The loading process is different from application flashing, requiring strict alignment and small-step writing. The boot code contains four core modules: Reset entry and minimum stack / clock initialization, upgrade flag reading and judgment, image consistency and conditional copying, and final jump. To facilitate seamless switching later, this embodiment establishes a program jump propagation table (VEC) within the IAP, defined as a write-only region, containing the fields: EntryAPP (application entry address), EntryCopy (copy process entry), EntrySafe (abnormal rollback entry), and VEC_CRC. The writing of VEC also adopts a "write new + check + mark" strategy, and the starting offset of VEC is recorded in the IAP header. This way, even if the application area has not yet been generated, the IAP can independently complete the decision path.
[0057] Regarding the allocation of upgrade flag bits, this embodiment designs an "Upgrade Control Record" (UPGREC) in the PARM area. The fields include Flag (flag status bit), TargetVer (target version number), ImgLen (image length), ImgCRC (image CRC), RecSeq (log sequence number), Tstamp (timestamp), FailCnt (failure count), and LastErr (last error code). Flag uses bit fields to represent different stages, such as "0x0 Not requested, 0x5 Image downloaded and awaiting copying, 0xA Copying in progress, 0xF Copy completed and awaiting cleanup." The bootloader drives transitions through a finite state machine, avoiding the semantic inadequacy of a single boolean flag in complex scenarios. During initialization, Flag is written as "Not requested," EntryAPP points to the existing application entry point, EntryCopy and EntrySafe are filled with fixed addresses at compile time, VEC_CRC is calculated and archived, and UPGREC is written with two redundant copies, distinguished by RecSeq.
[0058] To establish the mapping relationship between the upgrade flag and the jump direction table, this embodiment defines the mapping rules in IAP: When the Flag is in "image completed and waiting to be copied" and the image CRC / length verification passes, the preferred entry of VEC is switched to EntryCopy. After copying is completed and the application entry self-check is successful, the preferred entry is atomically written back to EntryAPP, and the Flag is updated to "copy completed and waiting to be cleaned up". If an unrecoverable error occurs during the copying process, IAP rolls back the preferred entry to EntrySafe, increments FailCnt, records the fault code LastErr, and waits for the master station to broadcast a re-session or for on-site intervention. The mapping relationship is written by IAP once for solidification upon first power-on or at the end of the session, and the "VEC-UPGREC" association information is mirrored to PARM so that the runtime diagnostic module can read and report remotely.
[0059] To facilitate review and understanding, this embodiment abstracts partitioning and boot configuration into a calculable boundary constraint: LFlash ≥ LIAP + LAPP + LIMG + LPARM + ΣGuard, where LFlash is the total length of available Flash (physically meaning the writable capacity within the address space), LIAP / LAPP / LIMG / LPARM are the target lengths of the four zones (physically meaning the storage space required for the corresponding functional area), and ΣGuard is the sum of the protection gaps between each zone (physically meaning the reserved space brought about by alignment and isolation). When this inequality holds, the partitioning scheme can be implemented; if it does not hold, the IAP logic automatically degenerates into a "semi-mirror mode," that is, LIMG is configured as half of LAPP, the upgrade is spliced in the mirror area in two rounds, and the replication process is addressed using "round + block number," which is consistent with the practice in the embodiment that "partitions can be trimmed but the semantics remain unchanged."
[0060] In a specific equipment model example, the older substation has a capacity of only 2MB, with 64KB sectors, a boot sector of 128KB, a maximum application sector of 1MB, a mirror sector of 1MB, and a parameter sector of 64KB (dual-sector loop), with the remaining space used as a protection gap. The newer substation has a capacity of 4MB, with the IAP sector remaining at 128KB, the application sector and mirror sector each expanded to 1.5MB, and the parameter sector increased to 128KB to accommodate more logs. Both types of hardware load the same IAP binary, adapting only to differences in the allocation table generated by S201. The master station broadcast process and the substation mirror writing and status reporting protocols do not need to be forked, reducing maintenance complexity.
[0061] From a technical and effectiveness perspective, this embodiment addresses pain points such as inconsistent partitioning under different capacities and page granularities, and the unavailability of partition tables due to partial writes caused by power outages, through the closed loop of surveying, planning, writing, and verification in S201. Through bootstrapping in S202 and the mapping of vector tables and polymorphic flags, it establishes a causal chain of "image completed—when to copy—how to roll back," allowing subsequent broadcast packetization in S102 and verification reset in S7xx to run on a controllable platform. In practice, even in environments with strong interference, the redundancy and atomic update strategies of the partition table and VEC / UPGREC limit the risks to the recoverable range of the parameter area and boot area. Existing network service threads are not affected, and the upgrade process naturally transitions to boot-up execution. On-site personnel are unlikely to notice the process changes, meeting the application expectation of "seamless upgrades."
[0062] In one embodiment of the method for seamlessly upgrading the firmware of a substation node in a bus system according to this application, it may further include the following: Step S301: Read the current value of the upgrade flag bit from the parameter storage area, compare the upgrade flag bit with the preset threshold, select the jump address in the program jump direction table according to the comparison result, read the length information and check value of the firmware data in the mirror data area, read the firmware data in segments according to the fixed block size, and calculate the integrity check code of each data segment. Step S302: Write the verified firmware data segment to the corresponding address in the application area, update the entry address in the program jump table, point the entry address to the program start position in the application area, record the firmware data version number and timestamp in the parameter storage area, clear the upgrade flag, and set the program counter to the start address of the application area.
[0063] This embodiment focuses on steps S301 to S302, with the execution entity located in the boot program stage after the substation is powered on. Combining the IAP / APP / IMAGE / PARM four-zone structure described in the embodiment, it completes the "upgrade or not" determination, segmented verification and writing of image data, and entry address update and rollback protection without relying on the online status of the master station. The application scenario is where the master station has already broadcast the image data to each substation. The substations may have experienced unexpected power outages or link jitter; therefore, the boot code logic must be idempotent and recoverable.
[0064] In this embodiment, the structured upgrade control record is first read from the parameter storage area in step S301. Key fields include the upgrade flag (Flag), target version (Ver), image length (Len_img), image CRC (C_img), record timestamp (Ts), and failure count (FailCnt). A binary strategy is used to compare the flag with a preset threshold. However, considering the possibility of a "half-write" state during power outages, the bootloader introduces a decision rule that prioritizes the larger of the two records / sequence numbers to avoid misidentification. If the Flag does not reach the trigger threshold, the "stable application entry" is directly retrieved from the vector table and the bootloader jumps to it. If the Flag reaches the threshold, the image reading and verification process begins. Before this, the bootloader reads the boundary markers at the beginning and end of the image area, checks whether Len_img falls within the APP area's carrying range, and quickly compares the image header signature to rule out extreme cases of image structure corruption.
[0065] Regarding the reading of image data, this embodiment uses a fixed block size B for segmentation, with the physical offset of block number i being off = i × B. The bootloader reads the image data block by block into the RAM buffer, calculates the intra-segment integrity check code, and compares it with the segment check value within the image or the check derived from the full image C_img. To balance speed and robustness, intra-segment checks primarily use CRC-16, while cross-segment consistency uses rolling CRC or cumulative check as redundancy. When a segment check fails, the bootloader does not immediately abandon the upgrade but records the failed block number. If the number of failed blocks exceeds a threshold or the failed blocks are concentrated in a certain Flash page, the image as a whole is deemed unreliable, the Flag is cleared, the failure reason is written, and the application is redirected to the old application. If only a few blocks fail, other qualified segments are allowed to be written first, and the list of failed blocks is retained for subsequent incremental packet replacement triggered by the main station. This makes the time cost of the boot phase controllable and forms a closed loop with the "incremental retransmission" in the previous step S103.
[0066] Upon entering S302, for segments that pass verification, the bootloader performs writing according to the corresponding address in the application area. The writing process adopts a three-stage approach: "page erase—block programming—readback verification." First, the target page status is checked. If a valid old program flag exists within the page, other unupdated blocks within the page are moved or the entire page is erased to avoid cross-contamination. After programming is completed, the same range is immediately read back and the CRC is recalculated to confirm consistency. To reduce the risk of interruption, the bootloader sets the "updated state" flag in the application area, indicating that the area is in an inoperable intermediate state. Only when all target blocks are written and pass the readback will the state be atomically switched to "valid." At this time, the updater jumps to the entry address of the vector table, pointing the "preferred entry" to the starting position of the new program in the application area, while the "rollback entry" retains the address of the previous stable version. The vector table updates entries with serial numbers in an increment-only manner, ensuring that the last valid entry can be reconstructed based on the serial number after power failure.
[0067] Parameter logging is another critical control line. In this embodiment, after each batch block write is completed, the firmware version number Ver and timestamp Ts are written to the circular log in the parameter storage area. The log entries include the upgrade source (broadcast / manual), a summary of the failed block list, and the count of the pages written this time. Voltage and clock stability are confirmed before writing parameters to avoid writing half-bytes under boundary conditions. The log exists in a "small record, multiple versions" format, and the largest sequence number is used for reading, which does not rely on a single sector and reduces the risk of concentrated wear. After confirming that all blocks have passed the readback verification and the entry address has been successfully updated, the bootloader clears the upgrade flag Flag and sets the program counter PC to the application area starting address, performing the first jump, thereby completing a seamless switch from image to application in a cold start process.
[0068] This embodiment provides a logical explanation for the sequential arrangement of reading the Flag first, then verifying the Len / CRC, then performing segmented verification, and finally writing the App and updating the entry point: If the Flag is not checked first, a large overhead scan will be performed every time the power is turned on, prolonging the startup latency; if the App is written directly without verifying the Len / CRC, and the image is inconsistent, it will damage the existing stable version, and the bootstrap layer will lose its rollback anchor; if segmented verification is not used but the entire image is verified at once, the repairable parts cannot be identified when encountering partial damage, resulting in the entire upgrade being invalid. Therefore, the layered and segmented decision chain is a concrete engineering manifestation of the principles of "security first, rollback capability, and incremental repair capability".
[0069] In practical scenarios, two types of substations can be used as a comparison. Type A substation has a smaller Flash capacity, and the APP and IMAGE use a semi-mirroring strategy. Type B is set to 8 KB, and the mirror requires two rounds of downloading and splicing. The bootloader locates the segment using a binary index of "round number + block number," and the entry update waits for both rounds to pass before switching. Type B substation uses dual-bank Flash. The bootloader maps the APP to Bank0 and the IMAGE to Bank1. Segmented writing degenerates into bank pointer switching, but segmented readback verification and parameter logging are still performed to maintain the consistency of the scheme. Regardless of the hardware, the chain of Flag—Len—CRC—Block—Write—Readback—Vector remains unchanged, reflecting the universality of the claims.
[0070] To more intuitively express the triggering and convergence conditions of the bootstrapping phase, a simplified criterion can be given: T = a·F + b·C + c·L, where T is the upgrade trigger quantity (physically meaning the comprehensive score of whether to enter image copying and write the APP), F represents the validity of the upgrade flag bit (physically meaning the reliable setting state of the Flag in PARM, taking 0 / 1 or with confidence), C represents the consistency of the image CRC (physically meaning whether the CRC calculated in the image area is consistent with the record C_img, taking 0 / 1), L represents the length validity (physically meaning that Len_img is located in [Len_min, Len_max] and matches the total number of packets, taking 0 / 1), and a, b, and c are the policy weights (physically meaning the relative importance of the three conditions in the triggering, with a sum of 1). When T exceeds the threshold, the segmented read and write process is entered; if it is below the threshold, the old application entry is maintained. The parameters of this criterion are all derived from locally measurable quantities, and the causal direction conforms to common sense in engineering.
[0071] From a technical and effectiveness perspective, this embodiment addresses the "verifiability and secure switching of the upgrade image locally on the substation" at the bootstrap layer. Through multi-version logs and dual-entry vector tables in the parameter area, power outages and abnormal writes will not cause irreversible damage; through segmented verification and readback, local errors can be precisely located and left for incremental patching and repair at the upper layer; through the final step of clearing the Flag and setting the PC jump, the upgrade is completed within a single reset cycle, and the running state is not subject to write / erase interruptions. Connecting with the broadcast distribution in S102 and the full image verification in S103, S301-S302 decompose "whether the image can be used safely" and "how to switch to the new application" into two things that can be closed within the substation, making the entire seamless upgrade process reusable under large-scale field conditions with clear risk boundaries.
[0072] In one embodiment of the method for seamlessly upgrading the firmware of a substation node in a bus system according to this application, it may further include the following: Step S401: The master station reads the system clock, generates a broadcast time window sequence, calculates the broadcast time slot position within the time window sequence, constructs a data frame for the firmware upgrade instruction, sets the target address of the data frame to the broadcast address, fills the data frame with the firmware version number and the total number of data packets, and sends the data frame to the substation node via the bus at a preset baud rate. Step S402: After receiving the firmware upgrade instruction, the substation node resets the data receiving pointer to the starting address of the mirror data area, clears the receiving sequence number counter, erases the historical data in the mirror data area, initializes the data receiving buffer, and the master station calculates the number of data packets based on the firmware data size, generates a firmware data packet sequence, and adds a packet header identifier, data packet sequence number, firmware data, and checksum to each data packet.
[0073] This embodiment focuses on steps S401-S402, where the master station initiates a unified upgrade session to a wide-area distributed substation via broadcast without interrupting the monitoring and alarm services. To avoid conflicts with regular time-slice reporting, the master station first reads the current UTC and local synchronization offset from the system clock, and generates a broadcast time window sequence based on the preset session period and service time period prohibition table. The window elements include the start and end times, the allowed occupancy ratio, and the fault tolerance delay. Within each window, the master station calculates the broadcast time slot position based on the bus idle monitoring results. The time slot length matches the predetermined baud rate, ensuring that an upgrade command frame can completely enter the bus and be transmitted before the adjacent time slice switches, forming an alternating rhythm of "service-upgrade-service".
[0074] To ensure session consistency across all substations, the master station constructs a firmware upgrade command frame in the first time slot of each window. This data frame's destination address is the broadcast address, and its payload fields include the firmware version number, total number of data packets N, total image length L, session ID (SID), and window plan ID (WID). The version number is used by the substation to compare with the currently running version and determine whether to participate in the current session; N and L indicate the scale of subsequent packet sub-segments, providing a preset receiving context for the substation; the SID / WID provides session identity, facilitating recovery and follow-up after a restart or frame loss. After frame encapsulation, it is sent at a preset baud rate. Before transmission, the master station performs microsecond-level backoff of bus occupancy to prevent collisions with the substation's uplink frames in its time slice; after transmission, the master station maintains a brief silence period to give the substation processing space.
[0075] When the substation receives the upgrade command, it parses the packet header, confirms the broadcast target and protocol version, and then enters the receive context initialization. First, the data receive pointer is reset to the starting address of the mirror data area, and the receive sequence number counter is cleared to complete the deterministic mapping of the mirror offset in a dictionary manner. Next, historical data in the mirror area is erased, or at least valid markers and sectors to be covered are cleared to avoid old data residue causing false positives for subsequent full mirror verification. Then, the data receive buffer is initialized, with the buffer size aligned with the main station fragment size S, reserving a redundancy of one mirror page to accommodate readback verification. Finally, the metadata "Entry Session SID / WID, Receive Pointer = 0, Counter = 0" is recorded in the parameter area to ensure that the process can continue from the breakpoint when power is restored after a power outage.
[0076] The master station calculates the number of data packets based on the firmware data size, using N=ceil(L / S) to obtain the number of fragments. S is preset based on link quality and substation processing capacity or specified in the command. To reduce the risk of first packet loss, the master station uses a "guide + data" two-frame start in the first round of broadcasting: first broadcasting an upgrade command, followed immediately by the data packet with sequence number 1, ensuring that the substation can immediately receive the first packet after resetting the context. Subsequently, the master station generates a firmware data packet sequence, adding a header identifier H (for frame boundary and protocol version identification), a data packet sequence number SEQ (monotonically increasing from 1 to N), firmware data PAYLOAD (length S or L-(N-1)S for the last packet), and a checksum CHK (a combination of CRC and cumulative checksum) to each data packet. To ensure compatibility with out-of-order delivery and retransmission, the PAYLOAD does not contain offset information; the offset is calculated by the substation using offset=(SEQ-1)×S, avoiding conflicts caused by dual truth sources.
[0077] After completing the S402 initialization, the substation enters the data receiving state machine. Whenever a data packet is received, the substation first verifies the H and protocol version, then reads the SEQ and compares it with the local receive sequence number counter. If the SEQ is less than or equal to the counter and the corresponding mirror position has been marked as complete, it is determined to be a duplicate packet and discarded directly. If the checksum CHK fails, error statistics are constructed and the status is returned in its own reporting time slice. If valid, the PAYLOAD is written to the receive buffer, the intra-segment CRC is calculated, and if it matches CHK, page-level erasure and programming are performed. After writing, the same address range is read back. If the readback data matches the buffer data, the segment is marked as complete in the mirror bitmap, and the "maximum consecutive completed sequence number" of the receive sequence number counter is updated, forming a sliding front. This state machine, in conjunction with the aforementioned mirror-application partition structure, ensures that even if out-of-order, duplicate, or lost packets occur on the broadcast channel, consistency can be maintained locally through the bitmap and counter.
[0078] At the master station, the broadcast rhythm of the data packet sequence is constrained by both the service backup time and the data packet sequence. To avoid overwhelming the substation buffer, the master station calculates the target number M of packets that can be broadcast within each window based on the window duration, the total service time slice occupancy, and the frame length budget, and advances the sequence using the "at most M packets" principle. If the received status report shows concentrated packet loss in a certain segment, the master station can insert these sequence numbers in the next window, adding a "retransmission flag" to the packet header, allowing the substation to identify and complete the packet according to the bitmap rules. For the differences among distributed substations, this embodiment allows different branches to use different S and baud rates. The upgrade command carries parameters, and the substation receives and stores data according to its own branch strategy, ensuring that the session can continue even in complex electromagnetic environments and under heterogeneous bandwidth conditions.
[0079] Logically, S401 precedes S402, and the instruction frame field of S401 directly determines the content initialized in S402. If the master station does not provide accurate N and L, the sub-station cannot correctly establish the bitmap and erase / write range, and the subsequent full image CRC comparison becomes meaningless. If the sub-station writes directly without erasing the valid image markers, the mixture of old and new data will cause occasional pass-through checks, ultimately resulting in the failure of the full image. The upgrade session will roll back in stage S103, bringing additional latency. Therefore, this embodiment emphasizes the two-way cooperation of "master station clarification and sub-station clearing" to form a self-consistent chain.
[0080] In a reproducible scene segment, the master station generates three broadcast windows at 22:30, each 120 seconds long, with baud rates set to BR1 for the backbone and BR2 for the tributaries. In the first window, an upgrade command and the first few data packets are sent. Substations A and B reset their pointers and clear their counters. A completes the writing of the first 50 packets in this window, while B, being in a low-voltage area, only completes 30 packets, but both return status within their respective time slices. In the second window, the master station continues broadcasting according to the sequence and inserts packets with missing sequence numbers from B. Duplicate packets from A are discarded after being identified. B's bitmap is gradually completed, but the mirror validity flag is still not set, awaiting full mirror verification. In the third window, the master station only performs the final broadcast and prepares to trigger the verification phase. At this time, the substation's receive buffer is stable, waiting for the verification packet from S103 to enter the next process.
[0081] Considering anomalies and robustness, this embodiment adds two thresholds in S402: First, the determination of mirror area erasure failure. If erasure of a sector returns a non-empty byte, the system attempts a second erasure and changes the sector record. If it still fails, "Storage Anomaly" is written to the parameter area and reception is restricted, pending identification by the master station. Second, receive buffer overflow control. When the number of continuously arriving data packets exceeds the buffer capacity, the substation temporarily suspends the writing of subsequent data packets and only updates the most recent SEQ so that the master station can identify "insufficient processing time" in the statistics. In the next window, the master station reduces S or reduces the broadcast rate. These control logics make broadcast upgrades more controllable under realistic constraints.
[0082] From a technical and effectiveness perspective, this embodiment clarifies the "session boundary" for multiple substations participating simultaneously through the window-slot plan and broadcast command frame in S401. Through the receive context reset, mirror area cleanup, and standardized packet structure in S402, substations can stably receive, locate, and write data within their respective time slices. This process seamlessly integrates with subsequent status reporting, retransmission, and full mirror verification stages. The upgrade action's interference with operating alarm and telemetry services is reduced to an acceptable range. Furthermore, even in scenarios involving power outages, interference, or heterogeneous hardware, progress can still be restored using bitmaps and sequence number rules, meeting the engineering requirement of "seamless upgrades."
[0083] In one embodiment of the method for seamlessly upgrading the firmware of a substation node in a bus system according to this application, it may further include the following: Step S501: The substation node parses the received firmware data packet, extracts the packet header identifier for data frame boundary identification, reads the data packet sequence number and compares it with the value of the receiving sequence number counter, verifies the checksum of the firmware data, writes the verified firmware data into the data receiving buffer, calculates the target storage address of the firmware data in the mirror data area, and writes the firmware data in the data receiving buffer into the target storage address. Step S502: Read back the written firmware data from the mirror data area for readback verification, generate a data storage status word, combine the data storage status word with the address identifier of the substation node to construct a status return data frame, send the status return data frame to the master station within a preset time slice, update the value of the receiving sequence number counter, and continue to wait to receive the next firmware data packet.
[0084] This embodiment focuses on steps S501 to S502, with the execution entity being the substation node in an online running state. Combining the broadcast session and time-slice reporting mechanism in this embodiment, the substation needs to complete the orderly writing of firmware packets, in-image readback verification, and status reporting without interrupting the monitoring / alarm functions. The logical chain, from bottom to top, is "frame identification—sequence number verification—data verification—buffering—mapping addressing—page erasure programming—readback verification—status framing—time-slice transmission—counter advancement," with each step having clear inputs and outputs to ensure convergence to a consistent image even under out-of-order and frame-dropping conditions in the broadcast channel.
[0085] In this embodiment, in S501, the substation receiver first sends the bus byte stream to the protocol parser via interrupt-driven or DMA mode. The parser locates the frame boundary based on the packet header identifier H and verifies the protocol version and session number to exclude cross-session mixing. After boundary confirmation, the packet sequence number SEQ is read and compared with the local receive sequence number counter Ctr and the mirror completion bitmap Bitmap: if the Bitmap shows that the sequence number is complete, it is marked as a duplicate packet and discarded; if SEQ is out of bounds or less than 1, an error code is recorded and the status statistics are entered; if it is valid, the verification stage is entered. For the sub-payload PAYLOAD, the packet checksum CHK is verified first, and then the intra-segment CRC is recalculated in RAM. If the two match, it is determined that "verification passed". The verified data segment is written to the data receive buffer Buf, and then the target address offset in the mirror data area is calculated as offset = (SEQ-1) × S (S is the fragment size, which physically means the fixed number of bytes of firmware data per packet), and the content of Buf is written to the target address in page alignment. The writing process includes page-level erasure and segmented programming. If the target page still contains valid tags or spans multiple pages, the process follows a sub-flow of "protect - move - erase - write back - program" to avoid damaging adjacent blocks. After successful programming, the corresponding index is marked as completed in the Bitmap.
[0086] Considering the realities of line interference and out-of-order broadcasts, the "received sequence number counter" in this embodiment is not simply equal to the last received SEQ, but is defined as a sliding leading edge of the "maximum consecutive completed sequence number". Specifically, starting with Ctr, the continuous completion status of the Bitmap at Ctr+1, Ctr+2, ... is checked until the first incomplete sequence number is encountered, at which point a new Ctr is updated to the end of that continuous interval. This strategy ensures that even if a packet with a higher sequence number is received, the leading edge will not be incorrectly advanced; it can naturally move forward after the missing packet is filled, logically consistent with the main station's retransmission merging strategy.
[0087] In S502, the substation performs readback verification on the newly written packets. The readback reads data of the same length from the target address in the mirror area into the buffer, recalculates the intra-segment CRC, and compares it with the CRC of the previous buffer. To avoid false positives caused by read / write interleaving, the readback uses cache isolation and bus quiescent period triggering. The generated data storage status word STAT is expressed using bit fields, including flags such as W_OK (successful write), R_ERR (readback failure), C_ERR (verification failure), DUP (duplicate packet), and OOR (out of bounds), along with SEQ and a brief error count. Then, STAT is combined with the substation address identifier NodeID to construct a status return data frame, which is buffered in the reporting queue, awaiting its preset time slice for transmission. To avoid contention with alarm reporting, the priority of the status return frame is lower than that of security alarms but equal to that of status reporting, and its length is controlled within a single frame. If it hasn't been called within the time slice, the status frame in the queue maintains the latest overwriting the older one with the same sequence number, preventing reporting overload.
[0088] After the status return is sent, this embodiment updates the CTr and maintains synchronization between the Bitmap and the anomaly statistics. The update rule is as follows: if STAT.W_OK=1 and the segment readback is successful, then the CTr is advanced; if STAT is incorrect and the repeated reception limit has been reached, a record is appended to the "anomaly digest" in the parameter area so that the master station can identify "difficult-to-write sectors" during the summary. Subsequently, the receiving state machine returns to the initial state of waiting for the next packet and continues to execute the "frame identification - verification - writing" loop. For high-frequency repeated packets, the parser only performs a lightweight header check and discards them immediately without entering the Flash write path to reduce wear.
[0089] From an engineering perspective, the "buffering-mapping-writing" process of S501 and the "readback-reporting-progression" process of S502 form a strict closed loop. Preventing the Ctrl key (Ctr) from being pushed forward until a successful readback is achieved, and not accepting further writing to the sequence number until the Bitmap is set, prevents wear amplification caused by "repeatedly overwriting the same block" under electromagnetic interference. The refined error bits in the status word allow the master station to distinguish between "out-of-order / duplicate" and "physical write error / readback failure" problems, thus enabling the use of "merging and retransmission" or "sector-specific remedial strategies" in stage S103.
[0090] In a real-world segment, the substation receives three packets consecutively: SEQ=1, 3, and 2. The first packet passes verification and is written, with Bitmap[1]=1. The third packet (SEQ=3) is valid, but Bitmap[2]=0 is found. Therefore, after writing, only Bitmap[3]=1, and Ctr remains 1. Subsequently, the second packet arrives, and the write readback passes, with Bitmap[2]=1. At this point, the continuous interval 1→3 is checked to be complete, Ctr advances to 3, and the status queue generates three W_OK status words, which are reported in batches or merged within the substation's time slice. If a duplicate packet of SEQ=2 appears later, the parser discards it directly because Bitmap[2]=1, and uploads "DUP count" as a summary in the next time slice. The main station can then appropriately reduce the broadcast rate of this window.
[0091] To ensure robustness, this embodiment incorporates two types of protection. First, it includes pre-write voltage threshold detection and page temperature drift estimation. If the power supply is unstable or the temperature exceeds limits, the Buf is temporarily stored and programming is delayed until the environment recovers. Second, it provides mirror area error page isolation. When a sector experiences consecutive read failures exceeding a threshold, the sector is marked as a "suspected bad block," and writing is switched to a reserved redundant sector. A "migration prompt" is included in the status word, allowing the master station to record the need for maintenance of the sub-station in subsequent sessions. For smaller capacity models with limited reserved redundancy, a "semi-mirrored two-round write" degradation scheme is adopted. The bitmap is expanded in two dimensions according to "round × sequence number," and the S501 / S502 process remains unchanged.
[0092] To provide a calculable boundary for timing and load, this embodiment maintains a simple buffer saturation criterion on the substation side: B_occ = (R_in - W_out) × T_buf, where B_occ is the buffer occupancy estimate (physically meaning the number of bytes currently occupied by unwritten or pending readback check data in the buffer), R_in is the reception rate that successfully passes check per unit time (physically meaning the net bytes entering the buffer per second), W_out is the rate of page write and readback completed per unit time (physically meaning the bytes digested from the buffer per second), and T_buf is the evaluation window (physically meaning the internal tick period). When B_occ approaches the upper limit of the buffer capacity, the substation temporarily discards non-critical duplicate packets and raises the "insufficient processing tick" flag in the status frame. The master station can then reduce the processing speed or decrease the fragmentation S in the next window accordingly. All parameters are derived from real-time measurements, and their directionality conforms to physical intuition.
[0093] From a technical and effectiveness perspective, this embodiment solves the core challenges of "orderly packet storage, error localization, status feedback, and progress advancement" at the substation level in broadcast scenarios. Through frame boundary recognition and sequence number-bitmap dual constraints, it ensures that out-of-order / repetitive data does not compromise image consistency. Through page-level programming-based readback verification and fine-grained status words, the master station can perform accurate retransmissions without establishing point-to-point connections. Through time-slice status returns and buffer saturation criteria, on-site services and upgrades can proceed in parallel, and resource conflicts are controlled. Connecting with the preceding S401-S402 window / initialization and the subsequent S103 full image verification-reset-copy, S501-S502 ensure data correctness and traceability at the substation's internal gate, supporting the implementation of the entire "seamless upgrade" process.
[0094] In one embodiment of the method for seamlessly upgrading the firmware of a substation node in a bus system according to this application, it may further include the following: Step S601: The master station parses the status data frame returned by the substation node, extracts the data storage status word and address identifier, matches the data storage status word with the preset status code, records the address of the substation node with data storage error and the data packet sequence number, repackages the firmware data packet corresponding to the data packet sequence number, adds a retransmission flag, and sends the repackaged firmware data packet to the bus in the next broadcast time window. Step S602: The master station maintains a firmware data packet sending counter. When the sending counter reaches the preset total number of data packets, a firmware data integrity verification packet is generated. The verification packet is filled with the accumulated verification value of the firmware data and the cyclic redundancy check code. The verification packet is sent to the sub-station node through the bus, and the master station waits for the sub-station node to return the verification result.
[0095] This embodiment focuses on steps S601 to S602, with the main station as the execution entity. The goal is to complete error location, minimum set retransmission, and trigger full image integrity verification and enter the upgrade closed loop after all packet broadcasts are completed, relying on the status data frames returned by the substations in the time slice, without establishing a point-to-point connection during the broadcast upgrade session. The scenario is consistent with the embodiment: the main station broadcasts periodically, substations report by time slice, the link suffers from out-of-order issues, frame drops, and electromagnetic interference, and the substations are widely distributed and cannot be frequently shut down.
[0096] In this embodiment, a status data frame parsing pipeline is first established in S601. Upon arrival of each frame, the master station completes boundary identification using the protocol version and frame header identifier, and then extracts the address identifier NodeID and the data storage status word STAT. STAT is bit-field encoded, containing at least flags for successful write, failed readback, failed verification, duplicate packet, and out-of-bounds transmission, and carries the associated sequence number SEQ. The master station matches the STAT against the preset status code table, resulting in three categories: acknowledgment (both write and readback were successful), retransmission (CRC error, readback error, missing acknowledgment), and unrepairable (out-of-bounds or memory error). Acknowledgment is used to update the completion bitmap Bitmap[node] and continuous leading edge Ctr[node] of the substation; retransmission records (NodeID, SEQ) in the error log and counts it; unrepairable directly marks the substation as "requiring offline processing," but does not block the progress of other substations. The logic behind this is to implement the "send or not send" criterion in a computable state space, avoiding the mistaken identification of temporarily unreported data as failure.
[0097] To reduce redundancy in broadcast retransmissions, this embodiment merges and deduplicates errors and missing data from all substations. The master station periodically traverses each Bitmap[node] to obtain the set M_miss of sequence numbers not confirmed by "enough" substations across the entire network; and merges the set M_err of sequence numbers explicitly reported as errors from STAT, resulting in a retransmission candidate R = M_miss ∪ M_err. Rather than retransmitting individually for each substation, it is better to retransmit each sequence number in R only once, because the same retransmission packet can simultaneously complete multiple substations on the broadcast channel. The master station then enters the repackaging stage: it calls the sequence number index from the original firmware repository to read the corresponding fragment, regenerates the packet header and checksum, sets the retransmission flag ReX, and adds it to the sending queue of the next broadcast window. To prevent endless retries, the master station maintains a failure count for each (NodeID, SEQ). Nodes exceeding the threshold are removed from the "forced retransmission" list of R and moved to the "slowdown and alarm" path to avoid slowing down the overall process.
[0098] In a segment of a nighttime batch upgrade, the convergence process of this mechanism can be clearly observed. After the first round of broadcasting, the Bitmap of 90% of the substations was nearly full. A small number of substations reported readback errors on specific SEQs, and a few substations did not report due to sparse time slice allocation. The master station merged these sequence numbers and inserted them into the next window. After broadcasting once, the error count decreased in the reports, and the substations that did not report successfully reported in the next time slice, and the R set naturally shrank. If a substation fails multiple sequence numbers within the same sector range consecutively, the master station marks that range as "suspected bad block" in the log and adds the substation to the low-speed broadcast list. Subsequent windows reduce the fragment size and sending rate of the substation separately, while other substations maintain their original pace and are not affected.
[0099] Entering step S602, this embodiment initiates the whole image integrity verification process based on the sending counter. The sending counter Count accumulates according to the "total number of broadcast firmware data packets," and after reaching a preset N, the master station generates a firmware data integrity verification packet. The verification packet payload contains two items: cumulative verification Sum and CRC verification CRC_all. The reason for parallel execution of these two items is that Sum can quickly expose large-scale missing or misaligned data, while CRC_all can identify fine-grained errors and sequence errors. During generation, the master station performs an offline calculation on the original firmware image and caches the result to avoid redundant overhead on-site. After the verification packet is broadcast, the master station starts a "verification waiting window," in which it only accepts verification result reports from substations and no longer sends data packets to reduce the interference of link noise on the substation's local whole image calculation.
[0100] Regarding the response format of the substation, this embodiment assumes that the substation calculates the cumulative checksum and CRC of the mirror area locally according to the claims, writes the comparison result into the parameter area, and then sends back "verification pass / fail and failure type" within the time slice. After receiving the data, the master station divides the nodes and statistically analyzes the pass rate and failure distribution. If most nodes pass, and the failure blocks of the failed nodes are concentrated in a few sequence numbers, the master station does not immediately declare the session failed, but enters the "incremental repair" mode: it summarizes the failure sequence number set of the failed nodes, retransmits these fragments, and then sends a "mini-verification packet" containing only the verification information of the failure range, and completes the review in the next short window. If the failures are randomly dispersed and coincide with known interference periods, the master station will arrange a new full verification window, first slowing down and then performing a full verification to obtain more stable feedback. This layered verification strategy reduces repeated interference to the entire network.
[0101] To provide a quantitative boundary for retransmission triggering and verification triggering, this embodiment can adopt a simplified criterion: K = α·E + β·U-γ·C, where K is the retransmission triggering strength (physical meaning: whether a certain sequence number is included in the score of R), E is the error report count (physical meaning: the total number of times STAT explicitly reports an error for that sequence number), U is the unconfirmed coverage (physical meaning: the number of substations that have not successfully confirmed the sequence number at the end of the current window), C is the confirmed coverage rate (physical meaning: the proportion of substations that have successfully confirmed the sequence number), and α, β, and γ are trade-off coefficients (physical meaning: the sensitivity to errors and missing data and the strength of suppression of existing coverage). When K exceeds the threshold T_re, the sequence number enters R; when the C of all sequences reaches the threshold T_cov, the master station generates a full mirror verification packet and enters S602 waiting. This expression corresponds one-to-one with the observable measurements on site and is intuitive in its direction: more errors and more missing data lead to retransmission, and higher coverage leads to convergence.
[0102] In terms of engineering implementation details, the master station's sending queue is divided into two paths: the main sequence queue Qmain and the retransmission queue Qre. At the beginning of the window, Qmain prioritizes sending elements sequentially to Count=N, inserting several elements from Qre during the intervals. When entering the verification window, Qre is cleared and suspended until a verification report is received before deciding whether to resume Qre. The logging system maintains three types of metrics for each NodeID: retransmission benefit (the proportion of successful acknowledgments after retransmission), failure concentration (the window cohesion of error sequence numbers), and time slice delay (the offset of the status frame relative to the window reference time). High benefit indicates that the node's error is an intermittent frame loss, which can be resolved by continuing broadcasting; high concentration suggests a storage media problem, and offline implementation is recommended; high delay is mostly due to configuration and link scheduling issues, requiring appropriate adjustment of the time slice quota later. The master station updates the branch strategy parameters (shard size, window occupancy ratio, baud rate) based on these metrics, forming an iteratively self-consistent process.
[0103] In a case study of a multi-branch heterogeneous network, branch A has high bandwidth, numerous substations, and timely feedback; the master station passes almost all verification packets after the initial check packet. Branch B has low bandwidth and heavy interference; verification failures are concentrated in a few sequence numbers. The master station switches to retransmitting packets with a smaller S value and extends the verification waiting window; the packets pass after the second micro-verification packet. Branch C has two substations that exceed their boundaries and report errors, marked as unrepairable. The master station automatically removes them from the session, retaining their mirror images for later maintenance and retrying. Other substations continue to complete their sessions. Throughout the process, the service time slice is not encroached to a dangerous level, and the alarm channel remains stable.
[0104] From the perspective of technical issues and effectiveness, this embodiment solves three major challenges in broadcast upgrade scenarios: first, how to locate and repair packet errors without establishing point-to-point connections; second, how to use a single verification packet to ensure each substation's mirror integrity after the entire network broadcast is completed; and third, how to distinguish between abnormal nodes and occasional packet loss nodes and adopt different strategies. Through the chain of STAT—bitmap—merging R—repackaging—verification packet—incremental repair, the master station's error handling changes from coarse to precise, and the session termination conditions change from experience to quantification. The upgrade process remains coherent, traceable, and rollbackable in a large-scale distributed substation network, meeting the engineering goals of "low-cost, in-system, and seamless upgrade" proposed in this embodiment.
[0105] In one embodiment of the method for seamlessly upgrading the firmware of a substation node in a bus system according to this application, it may further include the following: Step S701: After receiving the verification data packet, the slave station node reads the firmware data in the mirror data area, calculates the cumulative check value and cyclic redundancy check code of the firmware data, compares the calculation results with the check values in the verification data packet to generate a check comparison result, writes the check comparison result into the parameter storage area, reads the program boot parameters in the bootloader area, sets the upgrade flag bit, and writes the status of the upgrade flag bit into the parameter storage area; Step S702: The slave station node triggers a hardware reset signal to restart the system. The program counter points to the starting address of the bootloader area. The program boot code reads the status of the upgrade flag bit, selects the program execution path according to the status of the upgrade flag bit, and copies the firmware data in the mirror data area to the application program area according to a preset block size to complete the firmware upgrade operation.
[0106] This embodiment focuses on steps S701 - S702, and the execution entity is the slave station node at the end of the upgrade session. The scenario assumes that the master station has completed the broadcast, retransmission, and writing into the mirror area of the firmware data packet according to the previous steps. Now, the slave station is triggered by the verification data packet to perform a consistency confirmation of the entire mirror locally, and enter the atomic switch of the boot period after the confirmation passes. The key link is "verifying the entire mirror - recording the result - setting the upgrade flag - hard reset - boot determination - block copying - entry switch - final cleaning", and its causal relationship is strictly consistent with the IAP / APP / IMAGE / PARM structure described in the embodiment.
[0107] In S701 of this embodiment, the slave station receives the verification data packet from the master station during its own time slice, and resolves the session number, the mirror length reference value Lr, the cumulative check Sum_ref, and CRC_ref. To avoid misjudgment caused by residues or out - of - bounds in the mirror area, the running - state firmware before boot first confirms the complete boundary of the mirror according to the mirror head and tail identifiers, and compares the actual length La with Lr. If La < Rr or exceeds the APP bearing range, a "length inconsistent" conclusion is directly generated and written into the parameter area. Entering the calculation stage, the slave station traverses the mirror area in a sequential flow: first accumulates each page to get Sum_calc, and then calculates the CRC_calc of the entire mirror with the same polynomial. The selection of the two reflects the level of "coarse check - strict check". The cumulative value is sensitive to large - scale writing errors, and CRC is sensitive to fine - grain differences. After completion, Sum_calc / CRC_calc is compared with Sum_ref / CRC_ref one by one to obtain a boolean comparison result, which is attached with a timestamp, mirror version, and session number, and written into the circular log of the parameter storage area; if the comparison fails, a summary of the failed page distribution is also attached to facilitate the master station to perform incremental packet supplementation.
[0108] Regarding the processing of flag bits and boot parameters, this embodiment follows the order of "record first, then set." Only when both the Sum and CRC comparisons are true, does the substation read the predefined boot parameter block in the boot program area, verify its version and vector table CRC, and confirm that the boot chain is usable. Subsequently, in the upgrade control record of the parameter area, the Flag is switched from "not requested / pending replication" to "image written and awaiting replication," and the target version number, image length, and CRC are recorded simultaneously, while the failure count is cleared to zero. This setting action uses dual-write redundancy to write to disk, employing an atomic sequence of "write new copy—verify—set valid flag—invalidate old copy" to prevent half-byte states from being left behind during power loss just before reboot. If any step of verification fails, the Flag remains unchanged, waiting for subsequent verification packets from the master station or manual intervention.
[0109] Upon entering S702, the substation triggers a hardware reset after completing parameter writing. The reset line restarts the MCU, and the program counter returns to the IAP start address. The early boot code of IAP first reads the parameter area, parses the Flag, image length, and CRC, and confirms the status as "image written and ready to be copied" before deciding to enter the copy path; otherwise, it starts according to the stable application entry point of the vector table. The copy path uses a fixed block size B. The image source address of block i is off_img=i×B, and the corresponding application target address is off_app=i×B. The bootloader performs erasure and programming page-aligned. After each block is written, it reads back for verification and records temporary progress. If any block fails verification, the copy process enters the "retry three times - mark failure - rollback" branch: if it still fails after three attempts, IAP rolls back the vector table's preferred entry point to the old application and records FailCnt+1 and the failed block number in the parameter area, waiting for subsequent session incremental repair to ensure safe startup.
[0110] To avoid uncertainty during entry point switching, this embodiment performs two atomic operations at the end of the copying process: First, it updates the program jump vector table, setting EntryAPP as the starting address of the new program in the application area, while retaining EntrySafe as the previous stable entry point; second, it clears the upgrade flag or sets it to "copying complete, pending cleanup," and records the new version number and timestamp. A quick self-check of the startup vector and stack pointer at the new application's starting address is inserted between these two steps to confirm basic runnability before committing the vector table update. If the self-check fails, a fallback entry is directly executed to avoid a "crash immediately after writing" black screen state. Finally, IAP redirects the program counter to EntryAPP to complete the first switch. The upgrade operation is closed during the boot phase, and the runtime thread is not disturbed.
[0111] In one scenario, a substation receives a check packet after completing a pre-broadcast. Sum / CRC calculations both pass, and the parameter area records "Ver=V2, SID=37, Ts=23:45," with the Flag set to "Pending Copying." After a reset, IAP copies blocks at B=8KB intervals. Readback fails on the 15th block, but IAP retryes twice successfully and continues until all blocks are copied, the vector table is updated, the Flag is cleared, and the new application takes off. In contrast, another substation, due to actual write corruption on a mirrored page, has CRC_calc not equal to CRC_ref in the S701 stage. The parameter area records the failure digest, and the Flag remains unset. The master station retransmits incremental packets in the next window according to the digest sequence number. This substation does not require a reset, reducing interference.
[0112] In principle, S701 closes the loop on the substation's local side to determine the reliability of the image. The relationship between indicators and results aligns with physical intuition: only when all three conditions are met—length consistency, cumulative verification, and CRC verification—is the image worthwhile to bear the replication cost. S702 breaks down the "switching process" into verifiable steps of "block programming + readback verification + vector update + flag cleanup." Failure at any step allows a rollback to the old application without affecting running threads. These two steps correspond one-to-one with the fields in the claims: reading the image, calculating and comparing verification, writing the comparison result and flag, hard reset, guiding the path selection based on the flag, and copying to the APP block by block. Combined with the packet writing and status return of the preceding S501 / S502, and the retransmission and full image triggering of S103, this embodiment completes a closed upgrade cycle from the data plane to the control plane, ensuring stable deployment even in scenarios with electromagnetic interference, power outages, and storage differences.
[0113] To effectively address the shortcomings of traditional technologies in storage management, data transmission, and upgrade security, and to provide technical support for bus system firmware upgrades, this application provides an embodiment of an apparatus for implementing all or part of the method for seamless upgrade of substation node firmware in a bus system. See [link to embodiment]. Figure 2 The device for seamlessly upgrading the firmware of substation nodes in the bus system specifically includes the following components: The program boot module 10 is used to divide the memory of the substation node into a boot program area, an application program area, an image data area, and a parameter storage area. The program boot code is written in the boot program area. The program boot code is used to detect the upgrade flag bit and determine whether to copy the firmware data in the image data area to the application program area based on the upgrade flag bit. The program boot parameters are stored in the parameter storage area. Firmware accuracy module 20 is used for the master station to broadcast firmware upgrade instructions to the sub-station nodes at preset time intervals. After receiving the firmware upgrade instructions, the sub-station nodes clear the data receiving pointer and the receiving sequence number counter. The master station sends firmware data packets to the sub-station nodes. The firmware data packets include packet header identifier, data packet sequence number, firmware data and check code. The sub-station nodes store the firmware data in the mirror data area according to the data packet sequence number and return data storage status information to the master station. The firmware upgrade module 30 is used for the master station to receive data storage status information returned by the sub-station node, and when the data storage status information indicates a data storage error, to resend the firmware data packet with the corresponding sequence number. After sending all firmware data packets, the master station sends a verification data packet to the sub-station node. The sub-station node verifies the firmware data in the mirror data area. After the verification is successful, the upgrade flag is set, and a system reset operation is performed. The program boot code copies the firmware data in the mirror data area to the application area.
[0114] As described above, the device for seamless firmware upgrade of substation nodes in a bus system provided in this application can achieve secure management of the upgrade process through an innovative partitioned storage architecture and bootloader and flag control. It constructs a data transmission system, combining sequence number management and status feedback to establish a reliable firmware update mechanism. A verification strategy is introduced, ensuring the accuracy of the upgrade through data integrity verification and reset operations. This method effectively solves the shortcomings of traditional technologies in storage management, data transmission, and upgrade security, providing technical assurance for bus system firmware upgrades.
[0115] From a hardware perspective, in order to effectively address the shortcomings of traditional technologies in storage management, data transmission, and upgrade security, and to provide technical support for bus system firmware upgrades, this application provides an embodiment of an electronic device for implementing all or part of the method for seamless upgrade of substation node firmware in the bus system. The electronic device specifically includes the following components: The system comprises a processor, memory, a communications interface, and a bus; wherein the processor, memory, and communications interface communicate with each other via the bus; the communications interface is used to transmit information between the device for seamlessly upgrading the firmware of substation nodes in the bus system and related devices such as the core business system, user terminals, and related databases; the logic controller can be a desktop computer, tablet computer, or mobile terminal, etc., and this embodiment is not limited to these. In this embodiment, the logic controller can be implemented with reference to the embodiments of the method for seamlessly upgrading the firmware of substation nodes in the bus system and the embodiments of the device for seamlessly upgrading the firmware of substation nodes in the bus system, the contents of which are incorporated herein, and repeated details will not be described again.
[0116] It is understood that the user terminal may include smartphones, tablet computers, network set-top boxes, portable computers, desktop computers, personal digital assistants (PDAs), in-vehicle devices, smart wearable devices, etc. Among these, the smart wearable devices may include smart glasses, smartwatches, smart bracelets, etc.
[0117] In practical applications, the method for seamlessly upgrading the firmware of substation nodes in a bus system can be partially executed on the electronic device side as described above, or all operations can be completed within the client device. The choice can be made based on the processing power of the client device and the limitations of the user's usage scenario. This application does not impose any limitations on this. If all operations are completed within the client device, the client device may further include a processor.
[0118] The aforementioned client device may have a communication module (i.e., a communication unit) that can communicate with a remote server to achieve data transmission with the server. The server may include a server on the task scheduling center side; in other implementation scenarios, it may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, a server cluster consisting of multiple servers, or a distributed server structure.
[0119] Figure 3 This is a schematic block diagram illustrating the system configuration of the electronic device 9600 according to an embodiment of this application. Figure 3 As shown, the electronic device 9600 may include a central processing unit 9100 and a memory 9140; the memory 9140 is coupled to the central processing unit 9100. It is worth noting that... Figure 3 This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions.
[0120] In one embodiment, the method for seamlessly upgrading the firmware of a substation node in a bus system can be integrated into a central processing unit 9100. The central processing unit 9100 can be configured to perform the following control: Step S101: Divide the memory of the substation node into a boot program area, an application program area, an image data area, and a parameter storage area. Write the program boot code into the boot program area. The program boot code is used to detect the upgrade flag bit and determine whether to copy the firmware data in the image data area to the application program area based on the upgrade flag bit. Store the program boot parameters in the parameter storage area. Step S102: The master station broadcasts a firmware upgrade command to the sub-station node at a preset time interval. After receiving the firmware upgrade command, the sub-station node clears the data receiving pointer and the receiving sequence number counter. The master station sends a firmware data packet to the sub-station node. The firmware data packet includes a packet header identifier, a data packet sequence number, firmware data, and a checksum. The sub-station node stores the firmware data in the mirror data area according to the data packet sequence number and returns data storage status information to the master station. Step S103: The master station receives the data storage status information returned by the sub-station node. When the data storage status information indicates a data storage error, it retransmits the firmware data packet with the corresponding sequence number. After sending all firmware data packets, it sends a verification data packet to the sub-station node. The sub-station node verifies the firmware data in the mirror data area. After the verification is successful, it sets the upgrade flag and performs a system reset operation. The program boot code copies the firmware data in the mirror data area to the application area.
[0121] As described above, the electronic device provided in this application, through an innovative partitioned storage architecture and bootloader and flag control, achieves secure management of the upgrade process. A data transmission system is constructed, combining sequence number management and status feedback to establish a reliable firmware update mechanism. A verification strategy is introduced, ensuring the accuracy of the upgrade through data integrity verification and reset operations. This method effectively solves the shortcomings of traditional technologies in storage management, data transmission, and upgrade security, providing technical assurance for bus system firmware upgrades.
[0122] In another embodiment, the device for seamlessly upgrading the firmware of substation nodes in the bus system can be configured separately from the central processing unit 9100. For example, the device for seamlessly upgrading the firmware of substation nodes in the bus system can be configured as a chip connected to the central processing unit 9100, and the method function of seamlessly upgrading the firmware of substation nodes in the bus system can be implemented through the control of the central processing unit.
[0123] like Figure 3As shown, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is worth noting that the electronic device 9600 does not necessarily need to include these components. Figure 3 All components shown; in addition, the electronic device 9600 may also include Figure 3 For components not shown, please refer to existing technologies.
[0124] like Figure 3 As shown, the central processing unit 9100, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device, which receives inputs and controls the operation of various components of the electronic device 9600.
[0125] The memory 9140 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned failure-related information, and also store a program for executing that information. The central processing unit 9100 may execute the program stored in the memory 9140 to perform information storage or processing, etc.
[0126] Input unit 9120 provides input to central processing unit 9100. Input unit 9120 may be, for example, a keypad or touch input device. Power supply 9170 provides power to electronic device 9600. Display 9160 displays images and text. Display may be, for example, an LCD display, but is not limited thereto.
[0127] The memory 9140 can be a solid-state memory, such as a read-only memory (ROM), random access memory (RAM), a SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROMs. The memory 9140 can also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application / function storage unit 9142 for storing application programs and function programs or processes for executing the operation of the electronic device 9600 via the central processing unit 9100.
[0128] The memory 9140 may also include a data storage unit 9143 for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 9144 of the memory 9140 may include various drivers for the electronic device for communication functions and / or for performing other functions of the electronic device (such as messaging applications, address book applications, etc.).
[0129] The communication module 9110 is a transmitter / receiver that sends and receives signals via the antenna 9111. The communication module 9110 (transmitter / receiver) is coupled to the central processing unit 9100 to provide input signals and receive output signals, which is the same as in a conventional mobile communication terminal.
[0130] Based on different communication technologies, multiple communication modules 9110 can be configured in the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module 9110 (transmitter / receiver) is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby realizing typical telecommunications functions. The audio processor 9130 may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor 9130 is coupled to a central processing unit 9100, enabling on-device recording via the microphone 9132 and on-device playback of stored audio via the speaker 9131.
[0131] Embodiments of this application also provide a computer-readable storage medium capable of implementing all steps of the method for seamlessly upgrading the firmware of a substation node in a bus system where the execution subject is a server or client, as described in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the method for seamlessly upgrading the firmware of a substation node in a bus system where the execution subject is a server or client, as described in the above embodiments. For example, when the processor executes the computer program, it implements the following steps: Step S101: Divide the memory of the substation node into a boot program area, an application program area, an image data area, and a parameter storage area. Write the program boot code into the boot program area. The program boot code is used to detect the upgrade flag bit and determine whether to copy the firmware data in the image data area to the application program area based on the upgrade flag bit. Store the program boot parameters in the parameter storage area. Step S102: The master station broadcasts a firmware upgrade command to the sub-station node at a preset time interval. After receiving the firmware upgrade command, the sub-station node clears the data receiving pointer and the receiving sequence number counter. The master station sends a firmware data packet to the sub-station node. The firmware data packet includes a packet header identifier, a data packet sequence number, firmware data, and a checksum. The sub-station node stores the firmware data in the mirror data area according to the data packet sequence number and returns data storage status information to the master station. Step S103: The master station receives the data storage status information returned by the sub-station node. When the data storage status information indicates a data storage error, it retransmits the firmware data packet with the corresponding sequence number. After sending all firmware data packets, it sends a verification data packet to the sub-station node. The sub-station node verifies the firmware data in the mirror data area. After the verification is successful, it sets the upgrade flag and performs a system reset operation. The program boot code copies the firmware data in the mirror data area to the application area.
[0132] As described above, the computer-readable storage medium provided in this application embodiment achieves secure management of the upgrade process through an innovative partitioned storage architecture and bootloader and flag control. A data transmission system is constructed, combining sequence number management and status feedback to establish a reliable firmware update mechanism. A verification strategy is introduced, ensuring the accuracy of the upgrade through data integrity verification and reset operations. This method effectively solves the shortcomings of traditional technologies in storage management, data transmission, and upgrade security, providing technical assurance for bus system firmware upgrades.
[0133] Embodiments of this application also provide a computer program product capable of implementing all steps in the method for seamlessly upgrading the firmware of a substation node in a bus system, where the execution subject is a server or client, as described in the above embodiments. When executed by a processor, this computer program / instruction implements the steps of the method for seamlessly upgrading the firmware of a substation node in a bus system. For example, the computer program / instruction implements the following steps: Step S101: Divide the memory of the substation node into a boot program area, an application program area, an image data area, and a parameter storage area. Write the program boot code into the boot program area. The program boot code is used to detect the upgrade flag bit and determine whether to copy the firmware data in the image data area to the application program area based on the upgrade flag bit. Store the program boot parameters in the parameter storage area. Step S102: The master station broadcasts a firmware upgrade command to the sub-station node at a preset time interval. After receiving the firmware upgrade command, the sub-station node clears the data receiving pointer and the receiving sequence number counter. The master station sends a firmware data packet to the sub-station node. The firmware data packet includes a packet header identifier, a data packet sequence number, firmware data, and a checksum. The sub-station node stores the firmware data in the mirror data area according to the data packet sequence number and returns data storage status information to the master station. Step S103: The master station receives the data storage status information returned by the sub-station node. When the data storage status information indicates a data storage error, it retransmits the firmware data packet with the corresponding sequence number. After sending all firmware data packets, it sends a verification data packet to the sub-station node. The sub-station node verifies the firmware data in the mirror data area. After the verification is successful, it sets the upgrade flag and performs a system reset operation. The program boot code copies the firmware data in the mirror data area to the application area.
[0134] As described above, the computer program product provided in this application, through an innovative partitioned storage architecture and bootloader and flag control, achieves secure management of the upgrade process. It constructs a data transmission system, combining sequence number management and status feedback to establish a reliable firmware update mechanism. A verification strategy is introduced, ensuring the accuracy of the upgrade through data integrity verification and reset operations. This method effectively solves the shortcomings of traditional technologies in storage management, data transmission, and upgrade security, providing technical assurance for bus system firmware upgrades.
[0135] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0136] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0137] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0138] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0139] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.
Claims
1. A method for seamlessly upgrading the firmware of a substation node in a bus system, characterized in that, The method includes: The memory of the substation node is divided into a boot program area, an application program area, an image data area, and a parameter storage area. The boot program code is written in the boot program area. The boot program code is used to detect the upgrade flag bit and determine whether to copy the firmware data in the image data area to the application program area based on the upgrade flag bit. The boot program parameters are stored in the parameter storage area. The master station broadcasts firmware upgrade instructions to the substation nodes at preset time intervals. After receiving the firmware upgrade instructions, the substation nodes clear the data receiving pointer and the receiving sequence number counter. The master station sends firmware data packets to the substation nodes. The firmware data packets include packet header identifier, data packet sequence number, firmware data and check code. The substation nodes store the firmware data in the mirror data area according to the data packet sequence number and return data storage status information to the master station. The master station receives data storage status information returned by the sub-station node. When the data storage status information indicates a data storage error, it retransmits the firmware data packet with the corresponding sequence number. After sending all firmware data packets, it sends a verification data packet to the sub-station node. The sub-station node verifies the firmware data in the mirror data area. After the verification is successful, it sets the upgrade flag and performs a system reset operation. The program boot code copies the firmware data in the mirror data area to the application area.
2. The method for seamlessly upgrading the firmware of a substation node in a bus system according to claim 1, characterized in that, The memory of the substation node is divided into a bootloader area, an application area, an image data area, and a parameter storage area. Bootloader code is written into the bootloader area. This bootloader code is used to detect the upgrade flag bit and includes: Read the capacity parameters and address space distribution of the substation node memory, calculate the starting address and length of each region based on the capacity parameters, mark the physical partition boundaries in the memory address space, generate a storage region allocation table, write the storage region allocation table into the memory boot sector, and construct the partition structure of the boot program area, application program area, image data area and parameter storage area. Load the binary file of the program boot code into the boot program area, set the program jump direction table in the program boot code, allocate the storage address of the upgrade flag bit, initialize the upgrade flag bit to a preset value, establish the mapping relationship between the upgrade flag bit and the program jump direction table, and write the mapping relationship into the parameter storage area.
3. The method for seamlessly upgrading the firmware of a substation node in a bus system according to claim 1, characterized in that, The step of determining whether to copy the firmware data in the image data area to the application area based on the upgrade flag, and storing program boot parameters in the parameter storage area, includes: Read the current value of the upgrade flag bit from the parameter storage area, compare the upgrade flag bit with the preset threshold, select the jump address in the program jump direction table according to the comparison result, read the length information and check value of the firmware data in the image data area, read the firmware data in segments according to the fixed block size, and calculate the integrity check code of each data segment. Write the verified firmware data segment to the corresponding address in the application area, update the entry address in the program jump index table, point the entry address to the program start position in the application area, record the firmware data version number and timestamp in the parameter storage area, clear the upgrade flag, and set the program counter to the start address of the application area.
4. The method for seamlessly upgrading the firmware of a substation node in a bus system according to claim 1, characterized in that, The master station broadcasts firmware upgrade instructions to the sub-station nodes at preset time intervals. After receiving the firmware upgrade instructions, the sub-station nodes clear their data reception pointer and reception sequence counter. The master station then sends firmware data packets to the sub-station nodes, including: The master station reads the system clock, generates a broadcast time window sequence, calculates the broadcast time slot position within the time window sequence, constructs a data frame for the firmware upgrade instruction, sets the target address of the data frame as the broadcast address, fills the data frame with the firmware version number and the total number of data packets, and sends the data frame to the substation node via the bus at a preset baud rate. After receiving the firmware upgrade command, the substation node resets the data receiving pointer to the starting address of the mirror data area, clears the receiving sequence number counter, erases the historical data in the mirror data area, and initializes the data receiving buffer. The master station calculates the number of data packets based on the firmware data size, generates a firmware data packet sequence, and adds a packet header identifier, data packet sequence number, firmware data, and checksum to each data packet.
5. The method for seamlessly upgrading the firmware of a substation node in a bus system according to claim 1, characterized in that, The firmware data packet includes a packet header identifier, a data packet sequence number, firmware data, and a checksum. The substation node stores the firmware data in the mirror data area according to the data packet sequence number and returns data storage status information to the master station, including: The substation node parses the received firmware data packet, extracts the packet header identifier for data frame boundary identification, reads the data packet sequence number and compares it with the value of the receiving sequence number counter, verifies the checksum of the firmware data, writes the verified firmware data into the data receiving buffer, calculates the target storage address of the firmware data in the mirror data area, and writes the firmware data in the data receiving buffer into the target storage address. The firmware data written to the mirror data area is read back for verification, a data storage status word is generated, the data storage status word is combined with the address identifier of the substation node to construct a status return data frame, the status return data frame is sent to the master station within a preset time slice, the value of the receiving sequence number counter is updated, and the system continues to wait to receive the next firmware data packet.
6. The method for seamlessly upgrading the firmware of a substation node in a bus system according to claim 1, characterized in that, The master station receives data storage status information returned by the sub-station node. When the data storage status information indicates a data storage error, it retransmits the firmware data packet with the corresponding sequence number. After sending all firmware data packets, it sends a verification data packet to the sub-station node, including: The master station parses the status data frame returned by the substation node, extracts the data storage status word and address identifier, matches the data storage status word with the preset status code, records the address of the substation node with data storage error and the data packet sequence number, repackages the firmware data packet corresponding to the data packet sequence number, adds a retransmission flag, and sends the repackaged firmware data packet to the bus in the next broadcast time window. The master station maintains a firmware data packet sending counter. When the sending counter reaches the preset total number of data packets, it generates a firmware data integrity verification packet. The verification packet is filled with the accumulated check value of the firmware data and the cyclic redundancy check code. The verification packet is sent to the sub-station node through the bus, and the master station waits for the sub-station node to return the verification result.
7. The method for seamlessly upgrading the firmware of a substation node in a bus system according to claim 1, characterized in that, The substation node verifies the firmware data in the mirror data area. Upon successful verification, it sets the upgrade flag and performs a system reset. The program boot code copies the firmware data from the mirror data area to the application area, including: After receiving the verification data packet, the substation node reads the firmware data in the mirror data area, calculates the cumulative check value and cyclic redundancy check code of the firmware data, compares the calculation result with the check value in the verification data packet, generates a verification comparison result, writes the verification comparison result into the parameter storage area, reads the program boot parameters in the boot program area, sets the upgrade flag bit, and writes the status of the upgrade flag bit into the parameter storage area. The substation node triggers a hardware reset signal, restarts the system, the program counter points to the starting address of the boot program area, the program boot code reads the upgrade flag status, selects the program execution path according to the upgrade flag status, and copies the firmware data in the image data area to the application area according to the preset block size, thus completing the firmware upgrade operation.
8. A device for seamlessly upgrading the firmware of a substation node in a bus system, characterized in that, The device includes: The program boot module is used to divide the memory of the substation node into a boot program area, an application program area, an image data area, and a parameter storage area. The program boot code is written in the boot program area. The program boot code is used to detect the upgrade flag bit and determine whether to copy the firmware data in the image data area to the application program area based on the upgrade flag bit. The program boot parameters are stored in the parameter storage area. The firmware accuracy module is used by the master station to broadcast firmware upgrade instructions to the sub-station nodes at preset time intervals. After receiving the firmware upgrade instructions, the sub-station nodes clear the data receiving pointer and the receiving sequence number counter. The master station sends firmware data packets to the sub-station nodes. The firmware data packets include packet header identifier, data packet sequence number, firmware data and check code. The sub-station nodes store the firmware data in the mirror data area according to the data packet sequence number and return data storage status information to the master station. The firmware upgrade module is used by the master station to receive data storage status information returned by the sub-station node. When the data storage status information indicates a data storage error, it retransmits the firmware data packet with the corresponding sequence number. After sending all firmware data packets, it sends a verification data packet to the sub-station node. The sub-station node verifies the firmware data in the mirror data area. After the verification is successful, it sets the upgrade flag and performs a system reset operation. The program boot code copies the firmware data in the mirror data area to the application area.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method for seamlessly upgrading the firmware of a substation node in a bus system as described in any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the method for seamlessly upgrading the firmware of a substation node in a bus system as described in any one of claims 1 to 7.
Citation Information
Patent Citations
Reliable firmware upgrading realizing method for distributed control system
CN104007996A
Remote upgrade method and remote upgrade device for wireless sensor network node
CN105573810A
Online upgrading method of microcontroller, microcontroller and storage medium
CN112181455A
Firmware program updating method and device of slave station equipment, equipment and storage medium
CN115048129A
Firmware upgrading method and device
CN115993978A