Health-aware modular upgrade method and system for feeder device embedded software

Abstract

This invention provides a modular upgrade method and system for health-aware embedded software of feeder devices, relating to the field of power distribution network feeder technology. The method includes: generating an upgrade package via the host computer of the feeder device and parsing it to obtain a sequence of modules to be upgraded; dividing the embedded software of the feeder device, extracting the target logic layer, performing an upgrade on the target loadable module set based on the sequence of modules to be upgraded, determining whether the trial operation health obtained from the preliminary upgrade results reaches a preset health threshold, and confirming the upgrade of the embedded software based on the determination result. This solves the technical problems of existing feeder device embedded software upgrades, which are mostly whole-system updates, resulting in time-consuming downtime, cumbersome operations, and a tendency to cause protection logic anomalies and equipment malfunctions. Through layered modular upgrades and multi-dimensional health-aware verification, it achieves the technical effect of refined module-level upgrades and zero-downtime upgrades for feeder devices.

Description

Technical Field

[0001] This invention relates to the field of power distribution network feeder technology, and more specifically to a modular upgrade method and system for health awareness of embedded software in feeder devices. Background Technology

[0002] As core terminal equipment in new power systems, distribution automation feeder devices are installed at key nodes such as pole-mounted switches, ring main units, branch boxes, and substations on 10kV / 20kV / 35kV distribution lines, undertaking critical tasks such as telemetry, remote signaling, remote control, protection, fault location and isolation, and metering. The embedded software of the feeder device runs on operating systems such as RTOS or embedded Linux, and includes numerous functional modules such as hardware drivers, communication protocol stacks, protection algorithms, human-machine interaction, self-diagnosis, and data management.

[0003] Current feeder device software upgrades typically use complete firmware updates as the smallest unit, resulting in overly coarse-grained upgrades. Even minor functional changes require a full firmware release, leading to lengthy data packet transmission times, heavy verification workload, and the potential for introducing hidden defects through unrelated code recompilation. Modules cannot iterate independently, resulting in low development and maintenance efficiency. Furthermore, the upgrade process requires equipment shutdown and restart, during which feeder protection functions are completely disabled, making it impossible to handle sudden faults promptly. Upgrades can only be carried out during off-peak hours in the early morning, resulting in high labor costs and limited operational windows. Additionally, existing technologies lack automatic control over module dependencies, and multi-module collaborative upgrades are prone to sequential errors, easily causing protection logic anomalies and equipment malfunctions, ultimately affecting power supply reliability and operational stability.

[0004] In summary, existing embedded software upgrades for feeder devices mostly involve complete updates, which are time-consuming and cumbersome to perform, and can easily lead to abnormal protection logic, equipment malfunctions, and technical problems that affect power supply reliability. Summary of the Invention

[0005] The purpose of this application is to provide a modular upgrade method and system for health-aware embedded software of feeder devices, which solves the technical problems that existing feeder device embedded software upgrades are mostly whole-system updates, which are time-consuming and cumbersome to operate, and are prone to protection logic abnormalities, equipment operation failures, and affect power supply reliability.

[0006] In view of the above problems, this application provides a method and system for modular upgrade of health-aware embedded software of feeder devices.

[0007] The first aspect of this application provides a health-aware modular upgrade method for embedded software of a feeder device. The method includes: generating an upgrade package via a host computer of the feeder device and parsing the upgrade package using an upgrade parsing mechanism to obtain a sequence of modules to be upgraded; dividing the embedded software of the feeder device to obtain a software partitioning result and extracting a target logical layer from the software partitioning result, wherein the target logical layer corresponds to a target loadable module set; performing an upgrade on the target loadable module set based on the sequence of modules to be upgraded to obtain preliminary upgrade results for a preset observation period; determining whether the trial operation health level obtained from the preliminary upgrade results reaches a preset health level threshold, obtaining a judgment result, and performing an upgrade confirmation of the embedded software based on the judgment result.

[0008] Optionally, the original upgrade package generated by the host computer is obtained; the original upgrade package is processed into multiple upgrade data fragments; the multiple upgrade data fragments are sent to the feeder device, and the feeder device receives each of the multiple upgrade data fragments and writes them into a temporary storage area and records the set of received fragments; when the communication interruption is restored, only the missing fragments are transmitted; wherein, each of the multiple upgrade data fragments carries a fragment number and a fragment check code.

[0009] Optionally, the upgrade package is subjected to multi-layer security verification, wherein the multi-layer security verification includes transport layer segment-by-segment verification, content layer overall hash verification, source layer digital signature verification, timeliness layer anti-replay verification, and module-by-module verification.

[0010] Optionally, multiple modules to be upgraded that have passed verification are obtained from the upgrade package; according to the upgrade parsing mechanism, the dependency description information of each module to be upgraded is parsed and dependency compatibility checks are performed; the upgrade execution order of the multiple modules to be upgraded is determined based on the verified inter-module dependencies, forming the sequence of modules to be upgraded.

[0011] Optionally, the currently installed module list is merged with the upgrade module list corresponding to the multiple modules to be upgraded to construct the expected module list after the upgrade; based on any dependency description table of any module in the expected module list, any dependent module is determined; it is determined whether the any dependent module meets the predetermined upgrade constraints, wherein the predetermined upgrade constraints refer to the fact that all dependent modules recorded in the arbitrary dependency description table exist in the expected module list and their versions meet the first predetermined version requirements and the application binary interface version match; if the any dependent module does not meet the predetermined upgrade constraints, the overall upgrade fails and diagnostic information is returned.

[0012] Optionally, for any given module, all other modules that depend on it are traversed in reverse to verify that the version constraints of each dependent module are still satisfied under the second predetermined version. After the dependency check passes, a directed acyclic graph is constructed with the module dependency relationship as directed edges and the modules as nodes, and the sequence of modules to be upgraded is determined according to the reverse topological order of advancing from the leaf node to the root node.

[0013] Optionally, the target module in the sequence of modules to be upgraded is extracted, the first target version currently running in the target module is backed up to the backup storage area, and the binary target file of the second target version is written to the shadow storage area; the function pointers of all external interfaces of the target module in the preset interface routing table are updated in one go using atomic operations, so that they switch from pointing to the first target version to pointing to the second target version; wherein, the preset interface routing table refers to a two-dimensional table structure stored in the memory of the feeder device for recording the current implementation function pointers and interface version numbers of the external interfaces of each module, and the atomic operation is to update the function pointers of all external interfaces of the target module in the preset interface routing table in one go by disabling interrupts or hardware atomic instructions.

[0014] Optionally, the module self-test indicators are obtained by returning self-test results through the module initialization entry function; key function heartbeat indicators are obtained by periodically reporting heartbeat messages and receiving statistics; resource usage indicators are obtained by monitoring the CPU utilization and memory usage; for modules associated with protection functions, consistency verification indicators are obtained by comparing the upgraded module processing results with the real-time nuclear protection logic output; and the trial operation health status is obtained by comprehensively scoring the module self-test indicators, the key function heartbeat indicators, the resource usage indicators, and the consistency verification indicators.

[0015] Optionally, if the trial operation health reaches the preset health threshold, the upgrade is submitted, and the first target version in the backup storage area is destroyed; if the trial operation health does not reach the preset health threshold, an automatic rollback is triggered, and the function pointers of all external interfaces of the target module in the preset interface routing table are switched from the second target version to point to the first target version using atomic operations, and the second target version in the shadow storage area is cleared; wherein, the automatic rollback supports a three-level strategy: a single module rollback is performed when the health of a single module fails to meet the standard; a batch rollback is performed in reverse topology order when multiple modules with dependencies are upgraded simultaneously and any module fails to meet the standard; and a full rollback is performed by the bootloader when the feeder device experiences a serious crash and fails to restart during the trial operation.

[0016] A second aspect of this application provides a health-aware modular upgrade system for embedded software of a feeder device. The system includes: a module sequence acquisition component, used to generate an upgrade package via the host computer of the feeder device and to parse the upgrade package using an upgrade parsing mechanism to obtain a sequence of modules to be upgraded; a logic level extraction component, used to partition the embedded software of the feeder device to obtain a software partitioning result and extract a target logic level from the software partitioning result, wherein the target logic level corresponds to a target loadable module set; an upgrade execution component, used to perform upgrade execution on the target loadable module set based on the sequence of modules to be upgraded, to obtain preliminary upgrade results for a preset observation period; and an upgrade result judgment component, used to judge whether the trial operation health level obtained from analyzing the preliminary upgrade results reaches a preset health level threshold, obtain a judgment result, and execute upgrade confirmation of the embedded software based on the judgment result.

[0017] One or more technical solutions provided in this application have at least the following technical effects or advantages: An upgrade package is generated by the host computer of the feeder device, and an upgrade parsing mechanism is introduced to parse the upgrade package to obtain a sequence of modules to be upgraded. The embedded software of the feeder device is divided to obtain a software partitioning result, and the target logic layer in the software partitioning result is extracted, wherein the target logic layer corresponds to a target loadable module set. Based on the sequence of modules to be upgraded, the target loadable module set is upgraded to obtain a preliminary upgrade result for a preset observation period. The trial operation health obtained from the preliminary upgrade result is judged and analyzed to determine whether it reaches a preset health threshold, and a judgment result is obtained. Based on the judgment result, the upgrade confirmation of the embedded software is executed. Through layered modular upgrades and multi-dimensional health perception verification, the feeder device achieves module-level fine-grained, zero-downtime, and self-healing remote upgrades, improving upgrade safety, power distribution terminal operation and maintenance efficiency, and power supply reliability.

[0018] The above description is merely an overview of the technical solution of this application. To better understand the technical means of this application and to facilitate its implementation according to the description, and to make the above and other objects, features, and advantages of this application more apparent, specific embodiments of this application are described below. It should be understood that the content described in this section is not intended to identify key or important features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent through the following description. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in 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 merely exemplary. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0020] Figure 1 A flowchart illustrating the modular upgrade method for health-aware embedded software of the feeder device provided in this application.

[0021] Figure 2 This is a flowchart illustrating the process of obtaining the sequence of modules to be upgraded in the health-aware modular upgrade method for the embedded software of the feeder device provided in this application.

[0022] Figure 3 A schematic diagram of the health-aware modular upgrade system for the embedded software of the feeder device provided in this application.

[0023] Figure labeling: Module sequence acquisition component 11, logical hierarchy extraction component 12, upgrade execution component 13, upgrade result judgment component 14. Detailed Implementation

[0024] This application provides a modular upgrade method and system for health-aware embedded software of feeder devices. It addresses the technical problems of existing feeder device embedded software upgrades, which are mostly complete updates, resulting in time-consuming downtime, cumbersome operations, and potential for protection logic anomalies, equipment malfunctions, and impacts on power supply reliability. The method achieves refined, zero-downtime upgrades of feeder devices through layered modular upgrades and multi-dimensional health-aware verification, thereby improving upgrade safety, distribution terminal maintenance efficiency, and power supply reliability.

[0025] The technical solutions of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. It should be understood that the present invention is not limited to the exemplary embodiments described herein. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention. It should also be noted that, for ease of description, only the parts related to the present invention are shown in the accompanying drawings, not all of them.

[0026] Example 1, as Figure 1 As shown, this application provides a modular upgrade method for health-aware embedded software of a feeder device, the method comprising: The host computer of the feeder device generates an upgrade package, and an upgrade parsing mechanism is introduced to parse the upgrade package to obtain the sequence of modules to be upgraded.

[0027] Furthermore, the upgrade package is generated by the host computer of the feeder device, including: obtaining the original upgrade package generated by the host computer; performing fragmented transmission processing on the original upgrade package to obtain multiple upgrade data fragments; sending the multiple upgrade data fragments to the feeder device, and writing each of the multiple upgrade data fragments into a temporary storage area and recording the received fragment set after receiving each fragment through the feeder device; when the communication interruption is restored, only the missing fragments are transmitted; wherein, each of the multiple upgrade data fragments carries a fragment number and a fragment check code.

[0028] Specifically, the host computer, i.e., the power distribution master station or the maintenance handheld terminal, retrieves the target module binary file for the specific feeder unit (FTU) from the version management library according to the instructions of the maintenance personnel, and encapsulates it into an original upgrade package. The original upgrade package adopts a custom fixed-structure binary format, and its file layout is as follows: package header (512 bytes, fixed format); module list (recording the ID, version, offset and length of all modules contained in this upgrade package); upgrade script (optional, recording special processing logic for this upgrade, such as preprocessing or postprocessing operations before and after the upgrade); module body (the loadable module format LMF files of each module are concatenated in sequence. The LMF format consists of a file header, module descriptor, code segment, read-only data segment, read-write data segment, uninitialized data segment, symbol export table, symbol reference table, and relocation table); and package tail signature block (512 bytes, storing the digital signature of the entire upgrade package content, excluding the signature block itself). The specific fields in the packet header include: Magic Number (4 bytes, fixed value 0x55504746, ASCII is UPGF); Packet Format Version Number (2 bytes); Target Device Model Compatibility List (4 bytes × N, listing the device model codes applicable to this upgrade package); Total Packet Length (8 bytes); Module List Offset (4 bytes); Module List Length (4 bytes); Upgrade Script Offset (4 bytes, 0x00000000 indicates no script); Upgrade Script Length (4 bytes); Module Body Start Offset (4 bytes); Number of Modules (2 bytes); Packet Generation Timestamp (8 bytes UTC time); Packet Unique Identifier (16 bytes UUID, used for replay protection); Host Computer Identifier (16 bytes, identifying the issuing entity of the upgrade package); Packet SHA-256 Hash (32 bytes, calculated on all content from the packet header to the signature block); Reserved Fields (padded to 512 bytes). The host computer then slices the original upgrade package into multiple upgrade data fragments according to fixed fragment sizes, such as 4KB, 8KB, or 16KB. Each upgrade data fragment is appended with a fragment number and a fragment checksum. The fragment number is a sequence number starting from 0 and is used by the receiving end for reassembly and sorting to prevent out-of-order delivery. The fragment checksum is used for real-time bit error detection before writing to the temporary storage area. The fragment checksum is a CRC32 checksum value and is encapsulated in the fragment header. For upgrades in encrypted scenarios or sensitive modules, the entire upgrade package is encrypted during transmission. The specific mechanism is as follows: the host computer generates a one-time AES-256 or SM4 session key for this upgrade session, encrypts the session key with a preset public key, appends the encrypted key block to the header of the original upgrade package, and uses the session key to perform symmetric encryption on the original upgrade package. After obtaining the original upgrade package, the session key is first decrypted with the private key, and then decrypted again with the session key. This ensures confidentiality while avoiding the performance overhead of asymmetric encryption of large amounts of data.

[0029] The host computer sequentially sends each upgrade data fragment to the feeder unit via a predetermined communication protocol, such as IEC60870-5-104 or MQTT. Upon receiving each upgrade data fragment, the feeder unit writes it to a temporary storage area. This temporary storage area is a dedicated buffer in the feeder unit's memory, such as external Flash or internal RAM, reserved for temporary storage during this upgrade. The feeder unit also records the received fragment set in non-volatile memory. When communication is interrupted and resumed, such as through a successful reconnection via the transmission control protocol or triggered by a link acknowledgment frame from the host computer, the feeder unit proactively informs the host computer of a summary of the received fragment set, including the maximum continuous range of received fragments or a list of missing fragments. Upon receiving this summary, the host computer compares the entire fragment set with the set of fragments received by the feeder unit using set difference operations to calculate the missing fragments in the current transmission session. The host computer then transmits only the missing fragments, avoiding duplicate transmissions of successfully transmitted parts and saving communication traffic and time overhead under poor-quality channels.

[0030] For example, this upgrade requires updating the communication protocol stack module of the feeder device. The compiled binary file is 512KB in size. The host computer sets the fragment size to 16KB, dividing the original 512KB data into 32 upgrade data fragments, numbered 0-31. A CRC32 checksum is calculated for each upgrade data fragment, and the host computer sequentially sends fragments 0, 1, 2... The feeder device successfully receives upgrade data fragments 0, 1, 2...5, all passing the checksum verification. These fragments are written to a temporary storage area, and positions 0-5 are marked as 1 in the bitmap to indicate receipt. During the transmission of the 6th upgrade data fragment, the 4G wireless network momentarily drops. After 30 seconds, the communication link is re-established, and the feeder device immediately sends a summary of received upgrade data fragments 0-5 to the host computer. The host computer calculates the difference set and finds that 26 fragments ({6, 7, ..., 31}) are missing. Therefore, it continues sending only from fragment 6 onwards, without retransmitting fragments 0-5. Finally, after the feeder device receives all the fragments, the bitmap is all set to 1, the transmission phase is completed, ensuring that the overall upgrade process is efficient and reliable.

[0031] Furthermore, an upgrade parsing mechanism is introduced to parse the upgrade package to obtain the sequence of modules to be upgraded. This includes performing multi-layer security verification on the upgrade package, wherein the multi-layer security verification includes transport layer segment-by-segment verification, content layer overall hash verification, source layer digital signature verification, timeliness layer anti-replay verification, and module-by-module verification.

[0032] Specifically, before the upgrade parsing mechanism is introduced to parse the upgrade package, the upgrade package needs to undergo multi-layer security verification, including transport layer fragment-by-fragment verification, content layer overall hash verification, source layer digital signature verification, timeliness layer anti-replay verification, and module layer module-by-module verification. Upgrade is rejected if any layer fails verification. Among these, the transport layer fragment-by-fragment verification is the transport layer CRC checksum. When the upgrade package is transmitted in fragments through the communication link, each transmission fragment is appended with a CRC32 checksum. The feeder device uses the same CRC32 algorithm to verify each fragment. If verification fails, a retransmission is immediately requested. This is used to prevent random bit flipping during transmission. For example, if a fragment has a one-bit error during transmission, its calculated CRC32 value will not match the original value. The feeder device immediately discards the fragment and requests a retransmission from the host computer.

[0033] Content-layer overall hash verification is used to prevent any form of content tampering, whether unintentional damage or intentional attack. When generating the original upgrade package, the host computer uses the secure hash algorithm SHA-256 to calculate an overall hash value for the entire upgrade package. After receiving the complete upgrade package, the feeder device uses the same SHA-256 algorithm to calculate the SHA-256 hash value for the entire content of the upgrade package and compares it with the hash value stored in the packet header. If the hashes match, it indicates that the upgrade package content is complete and has not been damaged. Source-layer digital signature verification verifies the digital signature stored in the packet tail signature block using a fixed host computer public key. The host computer public key is a secure storage area pre-installed within the feeder device through a secure means during the manufacturing or network access of the feeder device. The signature covers the SHA-256 hash value in the packet header, essentially authenticating the source of the upgrade package content. Successful signature verification indicates that the upgrade package comes from a legitimate host computer and has not been replaced or forged. The digital signature supports both RSA-2048 and SM2 signature algorithms, which can be selected according to the application scenario.

[0034] The time-layer replay protection check refers to the use of a packet generation timestamp and a unique packet identifier (UUID) in the packet header when the host computer generates the upgrade package to prevent replay attacks. The feeder device maintains a record table of the most recent upgrade package UUIDs. When a new upgrade package is received, its UUID is compared to the table. If it is, it's considered a replay and rejected. Simultaneously, the deviation between its generation timestamp and the device's current UTC time is compared. If the deviation exceeds a preset window (e.g., 72 hours), the upgrade package is rejected, preventing attackers from reusing expired legitimate upgrade packages and effectively preventing attackers from using historical legitimate upgrade packages for system downgrades or denial-of-service attacks. The module-level module-by-module verification involves module-by-module SHA-256 hash verification and signature verification. After the overall upgrade package verification passes, each parsed module's LMF file undergoes a module-level SHA-256 hash verification, compared with the hash stored in the module descriptor, and a module-level digital signature verification. This verifies the signature stored in the module descriptor, ensuring that even if the upgrade package is legitimately distributed, the content of individual modules has not been tampered with during transit.

[0035] By performing layer-by-layer verification, corrupted upgrade packages caused by transmission errors, storage aging, or human error are eliminated, preventing erroneous data from being sent to subsequent dependency resolution and upgrade execution stages, thereby improving the success rate and overall reliability of the upgrade task.

[0036] Furthermore, such as Figure 2 As shown, an upgrade parsing mechanism is introduced to parse the upgrade package to obtain a sequence of modules to be upgraded, including: obtaining multiple modules to be upgraded that have passed verification in the upgrade package; according to the upgrade parsing mechanism, parsing the dependency description information of each module to be upgraded and performing dependency compatibility checks; determining the upgrade execution order of the multiple modules to be upgraded based on the verified inter-module dependencies, thus forming the sequence of modules to be upgraded.

[0037] Furthermore, according to the upgrade parsing mechanism, the dependency description information of each of the multiple modules to be upgraded is parsed and dependency compatibility checks are performed, including: merging the currently installed module list with the upgrade module list corresponding to the multiple modules to be upgraded to construct the expected module list after the upgrade; determining any dependent module based on any dependency description table of any module in the expected module list; determining whether the any dependent module meets the predetermined upgrade constraints, wherein the predetermined upgrade constraints refer to the fact that all dependent modules recorded in the arbitrary dependency description table exist in the expected module list and their versions meet the first predetermined version requirements and the application binary interface version match; if the any dependent module does not meet the predetermined upgrade constraints, the overall upgrade fails and diagnostic information is returned.

[0038] Specifically, after the upgrade package passes multi-layer security verification, the feeder device obtains a complete and legitimate list of modules to be upgraded. The feeder device's storage medium, such as a Flash file system, persistently maintains a list of currently installed modules. This list records complete metadata for each loaded module in the feeder device, including: module ID, current version number (semantic version, such as major version, minor version, patch version), module type (such as kernel / driver / communication / application), module installation path, and a dependency description table. Each dependency record in the dependency description table contains the following fields: dependent module ID (4 bytes), minimum version requirement (4 bytes, following SemVer format), maximum version requirement (4 bytes, optional, blank indicates no upper limit), dependency type (1 byte, 0x01 = strong dependency, 0x02 = weak dependency, optional), dependent ABI version number (2 bytes, the ABI version expected by this module), and a list of dependent interfaces (listing the set of interface numbers of the dependent modules actually called by this module). The dependency description table follows semantic versioning specifications: major version number differences of dependent modules indicate breaking ABI changes and must be strictly matched; minor version number differences indicate new features but ABI compatibility, and module version numbers must be higher than or equal to the dependency requirements; patch number differences are only for bug fixes, and any patch number is compatible. Furthermore, this list of currently installed modules is updated synchronously after each successful upgrade.

[0039] The upgrade resolution mechanism first merges the currently installed module list with the upgrade module lists corresponding to multiple modules to be upgraded, constructing a new expected module list. The merging rule is as follows: for each module listed in the upgrade module list, the corresponding entry in the currently installed module list is replaced with its upgraded version information. For other installed modules not covered by the upgrade list, their original entries are retained. Then, it iterates through each module in the expected module list, reading each dependency record in its dependency description table. For each record, it searches the expected module list based on the dependent module ID to determine the corresponding dependent module. It then checks whether all dependent modules in the expected list meet the predetermined upgrade constraints. These constraints include the presence of all dependent modules recorded in any dependency description table in the expected module list. If a dependent module does not exist in the expected module list, it means that the module is not installed and is not included in this upgrade; therefore, the dependency cannot be satisfied. Furthermore, the current version number of the dependent module must meet the lower version limit specified by the dependent party, i.e., the first predetermined version requirement. Version comparison follows semantic versioning rules (major version number, minor version number, patch version number). For example, if the dependent party requires a version no lower than v2.1.0, and the actual version of the dependent module is v2.1.3, then it meets the requirement; if it is v2.0.9, then it does not meet the requirement. Additionally, the actual binary interface (ABI) version of the dependent module must match the ABI version required by the dependent party.

[0040] If any dependency record of any module in the expected module list does not meet any of the above sub-conditions, the overall upgrade is determined to have failed. The parsing mechanism will immediately terminate and return structured diagnostic information to the host computer. The diagnostic information includes the type of failure reason, such as missing dependent modules, low version, ABI version mismatch, etc., as well as the module ID and specific value involved, so that the operation and maintenance personnel can accurately locate the problem.

[0041] In addition to positively checking whether the modules that this module depends on meet the requirements, the parsing mechanism also determines the upgrade execution order of the multiple modules to be upgraded based on the verified inter-module dependencies, forming a sequence of modules to be upgraded. For example, if B is dependent on A, the sorting result is [B,A]. The feeder device upgrades B first and then A, thereby ensuring that when A is upgraded and loaded, the B module it depends on is already the new version.

[0042] By performing dependency compatibility checks, potential anomalies caused by version mismatch, ABI conflict, or missing dependencies are predicted and intercepted before the upgrade is executed, thereby enabling refined and reliable upgrades of feeder devices at the module level and improving the efficiency and reliability of power distribution terminal operation and maintenance.

[0043] Furthermore, based on the verified inter-module dependencies, the upgrade execution order of the multiple modules to be upgraded is determined to form the sequence of modules to be upgraded, including: for any module, traversing in reverse the order of all other modules that depend on it, verifying that the version constraints of each dependent module are still satisfied under the second predetermined version; after the dependency check is passed, constructing a directed acyclic graph with the module dependencies as directed edges and the modules as nodes, and determining the sequence of modules to be upgraded according to the reverse topological order of advancing from the leaf nodes to the root nodes.

[0044] Specifically, starting with each module in the expected module list, a reverse traversal is performed to find all other modules that depend on that module, which are then considered dependent modules. For each dependent module, it is checked whether it can still function correctly in the new version; that is, whether the version constraints of the dependent module are still satisfied in the second planned version. If the constraints are not satisfied, the overall upgrade terminates. After all reverse dependency verifications pass, a fully verified set of inter-module dependencies is obtained. A directed acyclic graph is constructed using modules as nodes and module dependencies as directed edges. The direction of the directed edges follows the principle of dependent → dependent: if module B is dependent on module A (i.e., A requires B to run), then there exists a directed edge B→A from B, indicating that B is a prerequisite or predecessor node of A. The graph's data structure uses an adjacency list for storage, with each node containing a module ID and a list of pointers to all its successor nodes. Then, based on the directed acyclic graph, the modules to be upgraded are topologically sorted to determine the upgrade order as follows: the dependent party is upgraded first, and the dependent party is upgraded later. That is, the process proceeds from the leaf node to the root node of the graph to determine the sequence of modules to be upgraded. The sequence of modules to be upgraded ensures that, throughout the entire upgrade process, the underlying modules that the modules loaded and running at any time depend on are always in the state of having been upgraded.

[0045] By using reverse dependency verification and reverse topology sorting, the correctness and stability of the upgrade process are ensured, while also enabling module-level refinement and reliability upgrades of the feeder device, and improving upgrade efficiency.

[0046] The embedded software of the feeder device is partitioned to obtain a software partitioning result, and the target logic layer in the software partitioning result is extracted, wherein the target logic layer corresponds to the target loadable module set.

[0047] Specifically, the embedded software of the feeder device is divided into four target logical layers according to functional responsibilities and hardware dependencies: the kernel layer, driver layer, communication layer, and application layer. Each target logical layer corresponds to a set of target loadable modules. The kernel layer is the lowest software layer, running the kernel of a real-time operating system (RTOS), such as UniProton, FreeRTOS, or the lowest-level code of Elec-Tech PEE, and includes core modules such as task scheduling, memory management, interrupt management, and timer service modules. The driver layer is a collection of hardware abstractions and feeder device driver modules, including GPIO drivers, UART drivers, SPI drivers, I2C drivers, A / D conversion drivers, network MAC drivers, Flash drivers, watchdog drivers, etc. Each peripheral in the driver layer corresponds to an independent module. Modules are independent of each other through a unified Device Abstraction Interface (DAI). Upgrading a single peripheral driver does not affect other peripheral drivers. The driver layer provides standardized device operation interfaces for the communication protocol layer and application function layer to call.

[0048] Communication Protocol Layer: This layer implements protocol stacks for various power communication protocols, including IEC 60870-5-101, IEC 60870-5-104, IEC 61850 MMS, IEC 61850 GOOSE, IEC 61850 SV, Modbus-RTU / TCP, DNP3, and power industry-customized protocols. Each communication protocol corresponds to an independent module. These modules provide a unified application layer access interface (AAI) upwards and call network or serial port driver interfaces at the driver layer downwards. Adding or revising communication protocols can be achieved by upgrading a single protocol stack module without affecting other protocol stacks or upper-layer applications. Application Functional Layer: A collection of functional modules oriented towards specific business logic, including telemetry processing module (sampling, filtering, RMS / phasor calculation), remote signaling processing module (switching quantity debouncing, position change event generation), remote control execution module (command parsing, safety interlocking, switching operation), protection algorithm module (overcurrent, zero sequence, distance, differential and other protection elements), fault recording module, energy metering module, harmonic analysis module, self-diagnosis module, human-machine interaction module, parameter management module, log management module, Web service module, etc.

[0049] For example, the software architecture of a certain feeder device (model FTU-2000) is shown in the table below:

[0050] By dividing the software into layers, each functional unit is split into independently compiled modules, so that the binary files of individual modules can be replaced and upgraded independently of the whole machine firmware, thereby achieving module-level fine-grained upgrades.

[0051] The target loadable module set is upgraded based on the sequence of modules to be upgraded, and preliminary upgrade results are obtained during a preset observation period.

[0052] Furthermore, the upgrade execution of the target loadable module set based on the sequence of modules to be upgraded includes: extracting the target modules from the sequence of modules to be upgraded, backing up the first target version currently running the target module to the backup storage area, and writing the binary target file of the second target version to the shadow storage area; and updating the function pointers of all external interfaces of the target module in the preset interface routing table at once using atomic operations, so that they switch from pointing to the first target version to pointing to the second target version; wherein, the preset interface routing table refers to a two-dimensional table structure stored in the memory of the feeder device for recording the current implementation function pointers and interface version numbers of the external interfaces of each module, and the atomic operation is to update the function pointers of all external interfaces of the target module in the preset interface routing table at once by disabling interrupts or using hardware atomic instructions.

[0053] Specifically, the target modules in the sequence of modules to be upgraded are extracted. The first target version currently running, i.e., the old version, is backed up to the backup storage area. The backup storage area is an independent reserved area in Flash memory, completely isolated from the active storage area and the shadow storage area in terms of physical address, ensuring that it can be restored to the stable state before the upgrade under any circumstances. The second target version, i.e., the binary target file of the new version, is written to the shadow storage area. The shadow storage area is an independent Flash partition of the same size as the active storage area, specifically used to store the new module file to be switched.

[0054] The feeder unit's memory stores a unified preset interface routing table. This table is a two-dimensional structure that records the current implementation function pointers and interface version numbers of each module's external interfaces. The row index is the interface number, and each external interface is assigned a unique interface number. Each row stores the current implementation function pointer, the module ID, the interface version number, and call statistics for that interface. The current implementation function pointer points to the memory address of the module function currently providing the interface implementation. When modules call each other, the caller does not directly jump to the fixed address of the target function but indirectly calls it through this function pointer, thus decoupling the interface from its implementation.

[0055] After the second target version is ready and the first target version has been backed up, the upgrade execution engine initiates a switchover operation. This operation atomically switches the function pointers of all external interfaces of the target module in the preset interface routing table from pointing to function addresses in the first target version to pointing to the addresses of the corresponding functions in the second target version. The atomic operation involves updating all function pointers of the target module's external interfaces in the preset interface routing table in one go, either by disabling interrupts or using hardware atomic instructions. This switchover operation cannot be interrupted or divided during execution; it either completes entirely or not at all, with no intermediate states. Disabling interrupts means that the execution engine calls processor-level interrupt-disabling instructions before the switchover, such as ARM's CPSID I or RISC-V's csrrci instruction, to mask all external interrupts and kernel scheduling interrupts. Then, in an interrupt-free environment, it updates all interface pointers of the target module in the preset interface routing table one by one, and immediately restores interrupts after the update is complete. Hardware atomic instructions refer to lock-free atomic updates of the preset interface routing table entries if the processor supports hardware-level atomic compare-and-swap instructions, such as ARM's LDREX / STREX or x86's CMPXCHG.

[0056] After the upgrade operation of a single target module is completed, the feeder device continues to process the next module in the sequence of modules to be upgraded until all target modules are upgraded and the preliminary upgrade results are obtained after a preset observation period. The preset observation period is configured to be 5 to 30 minutes, and the specific duration is set by the operation and maintenance strategy according to the importance and risk level of the module.

[0057] By first backing up the old version and pre-storing the new version image, and then using atomic operations to batch switch interface function pointers, the module can be switched without downtime during operation. This avoids interface call errors during the upgrade process, ensures data and business continuity during the upgrade process, eliminates the risk of abnormal operation during the switching interval, and realizes a module-level refined and reliable upgrade of the feeder device with zero downtime, thereby improving the operation and maintenance efficiency and reliability of the power distribution terminal.

[0058] The system determines whether the trial operation health status obtained from the analysis of the preliminary upgrade results has reached the preset health status threshold, obtains the determination result, and performs the upgrade confirmation of the embedded software based on the determination result.

[0059] Furthermore, determining whether the trial operation health status obtained from the preliminary upgrade results reaches the preset health status threshold includes: obtaining module self-check indicators by returning self-check results through the module initialization entry function; obtaining key function heartbeat indicators by periodically reporting heartbeat messages and receiving statistics; obtaining resource usage indicators by monitoring the central processing unit utilization and memory usage; for modules related to protection functions, obtaining consistency verification indicators by comparing the upgraded module processing results with the real-time nuclear protection logic output; and comprehensively scoring the module self-check indicators, the key function heartbeat indicators, the resource usage indicators, and the consistency verification indicators to obtain the trial operation health status.

[0060] Specifically, within a pre-defined observation period, the health of modules is evaluated in real time using multi-dimensional indicators such as self-checks, heartbeats, resource usage, and logical consistency. Each module, upon loading, returns a self-check result through the `module_init` initialization entry function. This includes the integrity of internal data structures (e.g., whether linked lists are circular, whether buffer pointers are valid), the validity of key parameters (e.g., whether the communication baud rate is within the hardware's supported range, whether protection settings exceed limits), and the normality of interaction with dependent modules (e.g., whether the communication controller responds normally, whether the ADC has completed calibration). For example, the initialization entry function returns a 32-bit self-check result code, with each bit representing a self-check item: 1 for pass, 0 for fail. The percentage of pass items is directly mapped to a score from 0 to 100. For instance, a return result code of 0xFFFF0000 indicates that the first 16 items passed and the last 16 failed, resulting in a module self-check score of 16 / 32 × 100 = 50 points. Each upgrade module implements periodic heartbeat reporting in its code, with intervals of 100ms to 1 second. The ratio of the actual number of heartbeats received during the observation period to the theoretically required number of reports is multiplied by 100 to obtain a survival rate score. Simultaneously, the ratio of successful operations carried in the heartbeat messages to the total number of operations is multiplied by 100 to obtain a function score. The average of these two scores yields the critical function heartbeat index. For example, if the theoretical number of heartbeats is 1200 and the actual number received is 1150 within 10 minutes, with a survival rate of 95.8 points and an operation success rate of 98 points, then the critical function heartbeat index = (95.8 + 98) / 2 = 96.9 points. Additionally, resource usage metrics are obtained by monitoring CPU utilization, memory usage, and other resource indicators during operation. CPU utilization is penalized based on peak and average values: 10 points are deducted for every 5% exceedance of the peak value threshold, and 5 points are deducted for every 5% exceedance of the average value threshold. Memory usage is penalized by 15 points for every 10% exceedance of the quota. All deductions are applied incrementally from a base of 100 points. For example, if the CPU peak value is 22% and less than the CPU threshold of 30%, no points are deducted; if the average value is 8% and less than the CPU average threshold of 15%, no points are deducted; if the memory usage rate is 56% and the quota is 32KB, no points are deducted; then the resource usage index = 100 points. For modules related to protection functions, such as the communication protocol layer and application function layer, during the trial operation, the same sampled data is simultaneously input into the second target version and the real-time nuclear baseline protection logic, and the fault judgment, action delay, and exit command are compared one by one. Based on the percentage of consistent times to the total number of comparisons, 5 points are deducted for each deviation, with a minimum score of 0. The final consistency verification index = max(consistency rate × 100 - number of deviations × 5, 0). Then, a weighted comprehensive score is calculated for the module self-test index, key function heartbeat index, resource usage index, and consistency verification index. The weight coefficients of each dimension are preset in the system configuration file of the feeder device and satisfy W self-test + W heartbeat + W resource usage + W consistency = 1.0. The weight allocation principle is dynamically adjusted according to the module type.For example, protection modules have the highest consistency check weights: Wconsistency = 0.4, Wheartbeat = 0.25, WSelf-Check = 0.25, and WResources = 0.10. For communication modules, the weights of heartbeat and resources are increased. For driver modules, the weights of self-check and resources are increased. The health score for this upgrade trial operation is calculated to be within the range of 0 to 100.

[0061] Through multi-dimensional evaluation, a comprehensive coverage of potential failure modes of the upgraded module is achieved, minimizing the risk of missed detections. Furthermore, by employing a scoring mechanism, the upgrade results are standardized and objectively judged, effectively avoiding the hidden dangers of modules appearing to function normally on the surface but with core functions failing or resources malfunctioning after the upgrade, thus ensuring the business stability and operational security after the module upgrade.

[0062] Furthermore, the upgrade confirmation of the embedded software is performed based on the judgment result, including: if the trial operation health reaches the preset health threshold, the upgrade is submitted and the first target version in the backup storage area is destroyed; if the trial operation health does not reach the preset health threshold, an automatic rollback is triggered, and the function pointers of all external interfaces of the target module in the preset interface routing table are switched from the second target version to point to the first target version using atomic operations, and the second target version in the shadow storage area is cleared; wherein, the automatic rollback supports a three-level strategy: a single module rollback is performed when the health of only a single module fails to meet the standard; a batch rollback is performed in reverse topology order when multiple modules with dependencies are upgraded at the same time and any module fails to meet the standard; and a full rollback is performed by the bootloader when the feeder device experiences a serious crash and fails to restart during the trial operation.

[0063] Specifically, the trial operation health of the target module is compared with a preset health threshold. The preset health threshold can be adjusted according to the module type and operation and maintenance strategy, such as setting it to 80 points. When the trial operation health is greater than or equal to the preset health threshold, the upgrade is submitted. By calling the sector erase interface provided by the Flash driver, the binary file of the first target version stored in the backup storage area is completely erased or marked as invalid. At the same time, the storage area of ​​the second target version in the shadow storage area is marked as the new version, and the current version number, installation timestamp, and upgrade log of the module in the module metadata database are updated. After submission, the trial operation of the updated module ends and it enters the normal operation state.

[0064] If the trial operation health level falls below the preset health level threshold, the upgrade is deemed a failure, and a rollback operation is automatically triggered. The rollback operation is the reverse of the atomic switch: the execution engine, using atomic operations and employing either interrupt-disabling or hardware atomic instructions, switches all function pointers of the target module's external interfaces in the preset interface routing table from pointing to the function addresses of the second target version in the shadow storage area back to pointing to the function addresses of the first target version in the backup storage area. After the switch is complete, the execution engine calls the initialization entry function of the first target version module to restore its runtime context, erases or marks the second target version binary file in the shadow storage area as invalid, releases the shadow storage space, and completely restores the feeder device to its pre-upgrade software state, achieving lossless self-healing.

[0065] Furthermore, automatic rollback supports three-level strategies: single-module rollback, batch rollback, and full rollback, automatically selected according to the scenario: When only one module's new version health is substandard in this upgrade, only that module is rolled back, while other successfully upgraded modules continue running the new version, minimizing the impact of upgrade failure. When multiple modules are upgraded simultaneously and there are dependencies between these modules, single-module rollback may break the dependencies. In this case, the rollback control module rolls back the modules in the batch in reverse order of the upgrade topology. When the feeder unit experiences a severe crash and fails to restart during trial operation, such as triggering a hardware watchdog reset, bus failure, or the feeder unit failing to enter normal operation after multiple consecutive restarts, a full rollback is performed. The entire state before this upgrade is completely restored from the backup area. After the rollback, the feeder unit returns to the state of all module versions before this upgrade, ensuring that the feeder unit has recovery capabilities under any extreme circumstances. The trigger priority of the three-level strategy is as follows: first, check whether it belongs to the third level, that is, whether it is a severe crash; if not, determine whether it belongs to the second level multi-module batch rollback; if not, execute the first level single-module rollback. This hierarchical mechanism is implemented through a conditional branch chain to ensure that the most severe faults receive the most thorough recovery measures first.

[0066] By performing upgrade confirmation on the embedded software based on the judgment results, the module-level refined, zero-downtime, and self-healing remote intelligent upgrade of the feeder device is realized, thereby improving the operation and maintenance efficiency and reliability of the power distribution terminal, reducing the cost of on-site manual intervention, and ensuring the continuous and stable operation of the power distribution network.

[0067] Example 2, based on the same inventive concept as the modular upgrade method for health-aware embedded software of the feeder device in the foregoing examples, such as... Figure 3 As shown, this application provides a modular upgrade system for health awareness of embedded software in a feeder device, wherein the modular upgrade system for health awareness of embedded software in the feeder device includes: The module sequence acquisition component 11 is used to generate an upgrade package through the host computer of the feeder device and to parse the upgrade package using an upgrade parsing mechanism to obtain a sequence of modules to be upgraded. The logic level extraction component 12 is used to divide the embedded software of the feeder device to obtain a software partitioning result and to extract the target logic level from the software partitioning result, wherein the target logic level corresponds to a target loadable module set. The upgrade execution component 13 is used to perform upgrade execution on the target loadable module set based on the sequence of modules to be upgraded to obtain a preliminary upgrade result for a preset observation period. The upgrade result judgment component 14 is used to judge whether the trial operation health obtained from the analysis of the preliminary upgrade result has reached a preset health threshold, obtain a judgment result, and perform upgrade confirmation of the embedded software based on the judgment result.

[0068] Furthermore, the module sequence acquisition component 11 is also used to: acquire the original upgrade package generated by the host computer; perform fragmented transmission processing on the original upgrade package to obtain multiple upgrade data fragments; send the multiple upgrade data fragments to the feeder device, and after receiving each of the multiple upgrade data fragments through the feeder device, write them into a temporary storage area and record the set of received fragments; when the communication interruption is restored, only the missing fragments are transmitted; wherein, each of the multiple upgrade data fragments carries a fragment number and a fragment check code.

[0069] Furthermore, the module sequence acquisition component 11 is also used to perform multi-layer security verification on the upgrade package, wherein the multi-layer security verification includes transport layer piece-by-piece verification, content layer overall hash verification, source layer digital signature verification, timeliness layer anti-replay verification, and module layer module-by-module verification.

[0070] Furthermore, the module sequence acquisition component 11 is also used to: acquire multiple modules to be upgraded after verification in the upgrade package; parse the dependency description information of each module to be upgraded in the multiple modules to be upgraded according to the upgrade parsing mechanism and perform dependency compatibility checks; determine the upgrade execution order of the multiple modules to be upgraded based on the verified inter-module dependency relationships, and form the module sequence to be upgraded.

[0071] Furthermore, the module sequence acquisition component 11 is also used to: merge the currently installed module list with the upgrade module list corresponding to the multiple modules to be upgraded to construct the expected module list after the upgrade; determine any dependent module based on any dependency description table of any module in the expected module list; determine whether the any dependent module meets the predetermined upgrade constraints, wherein the predetermined upgrade constraints refer to the fact that all dependent modules recorded in the arbitrary dependency description table exist in the expected module list and their versions meet the first predetermined version requirements and the application binary interface version match; if the any dependent module does not meet the predetermined upgrade constraints, the overall upgrade fails and diagnostic information is returned.

[0072] Furthermore, the module sequence acquisition component 11 is also used to: traverse all other modules that depend on the arbitrary module in reverse order, verify that the version constraints of each dependent module are still satisfied under the second predetermined version; after the dependency check is passed, construct a directed acyclic graph with the module dependency relationship as directed edges and the module as nodes, and determine the sequence of modules to be upgraded according to the reverse topological order of advancing from the leaf node to the root node.

[0073] Furthermore, the upgrade execution component 13 is also used to: extract the target module from the sequence of modules to be upgraded, back up the first target version currently running the target module to the backup storage area, and write the binary target file of the second target version to the shadow storage area; and update the function pointers of all external interfaces of the target module in the preset interface routing table at once using atomic operations, so that they switch from pointing to the first target version to pointing to the second target version; wherein, the preset interface routing table refers to a two-dimensional table structure stored in the memory of the feeder device for recording the current implementation function pointers and interface version numbers of the external interfaces of each module, and the atomic operation is to update the function pointers of all external interfaces of the target module in the preset interface routing table at once by disabling interrupts or using hardware atomic instructions.

[0074] Furthermore, the upgrade result judgment component 14 is also used to: obtain module self-test indicators by returning self-test results through the module initialization entry function; obtain key function heartbeat indicators by periodically reporting heartbeat messages and receiving statistics; obtain resource usage indicators by monitoring the central processing unit occupancy and memory usage; for modules associated with protection functions, obtain consistency verification indicators by comparing the upgraded module processing results with the real-time nuclear protection logic output; and comprehensively score the module self-test indicators, the key function heartbeat indicators, the resource usage indicators, and the consistency verification indicators to obtain the trial operation health status.

[0075] Furthermore, the upgrade result judgment component 14 is also used to: if the trial operation health reaches the preset health threshold, submit this upgrade and destroy the first target version in the backup storage area; if the trial operation health does not reach the preset health threshold, trigger automatic rollback, use atomic operations to switch the function pointers of all external interfaces of the target module in the preset interface routing table from the second target version to point to the first target version, and clear the second target version in the shadow storage area; wherein, the automatic rollback supports a three-level strategy: single module rollback is performed when the health of a single module is not up to standard, batch rollback is performed in reverse topology order when multiple modules with dependencies are upgraded at the same time and any module is not up to standard, and full rollback is performed by the bootloader when the feeder device experiences a serious crash and fails to restart during the trial operation.

[0076] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The health-aware modular upgrade method and specific examples of the embedded software of the feeder device in the foregoing embodiment one are also applicable to the health-aware modular upgrade system of the embedded software of the feeder device in this embodiment. Through the foregoing detailed description of the health-aware modular upgrade method of the embedded software of the feeder device, those skilled in the art can clearly understand the health-aware modular upgrade system of the embedded software of the feeder device in this embodiment. Therefore, for the sake of brevity, it will not be described in detail here.

[0077] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0078] Obviously, those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A method of health-aware modular upgrade of feeder device embedded software, characterized in that, include: The host computer of the feeder device generates an upgrade package, and an upgrade parsing mechanism is introduced to parse the upgrade package to obtain the sequence of modules to be upgraded; The embedded software of the feeder device is partitioned to obtain a software partitioning result, and the target logic layer in the software partitioning result is extracted, wherein the target logic layer corresponds to the target loadable module set; The target loadable module set is upgraded based on the sequence of modules to be upgraded, and preliminary upgrade results are obtained during a preset observation period. Determine whether the trial operation health status obtained from the analysis of the preliminary upgrade results has reached the preset health status threshold, obtain the determination result, and perform the upgrade confirmation of the embedded software based on the determination result; The upgrade package generated by the host computer of the feeder device includes: Obtain the original upgrade package generated by the host computer; The original upgrade package is fragmented for transmission to obtain multiple upgrade data fragments; The multiple upgrade data fragments are sent to the feeder device, and the feeder device receives each of the multiple upgrade data fragments, writes them into the temporary storage area, and records the set of received fragments. When communication is restored, only the missing fragments are transmitted; Each of the multiple upgrade data shards carries a shard number and a shard verification code.

2. The health-aware modular upgrade method for feeder device embedded software as claimed in claim 1, wherein, An upgrade parsing mechanism is introduced to parse the upgrade package to obtain the sequence of modules to be upgraded. This includes performing multi-layer security verification on the upgrade package, wherein the multi-layer security verification includes transport layer segment-by-segment verification, content layer overall hash verification, source layer digital signature verification, timeliness layer anti-replay verification, and module-by-module verification.

3. The health-aware modular upgrade method for feeder device-embedded software of claim 2, wherein, An upgrade parsing mechanism is introduced to parse the upgrade package, resulting in a sequence of modules to be upgraded, including: Obtain the multiple modules to be upgraded from the upgrade package that have passed verification; According to the upgrade parsing mechanism, the dependency description information of each module to be upgraded is parsed and dependency compatibility checks are performed. Based on the verified inter-module dependencies, the upgrade execution order of the multiple modules to be upgraded is determined, forming the module to be upgraded sequence.

4. The health-aware modular upgrade method of the feeder device-embedded software of claim 3, wherein, According to the upgrade parsing mechanism, the dependency description information of each module to be upgraded in the plurality of modules to be upgraded is parsed and dependency compatibility checks are performed, including: The list of currently installed modules is merged with the list of upgrade modules corresponding to the multiple modules to be upgraded, to construct the expected list of modules after the upgrade. Based on any dependency description table of any module in the expected module list, determine any dependent module; Determine whether any dependent module satisfies the predetermined upgrade constraint, wherein the predetermined upgrade constraint means that all dependent modules recorded in the arbitrary dependency description table exist in the expected module list and their versions meet the first predetermined version requirement and match the application binary interface version; If any of the dependent modules does not meet the predetermined upgrade constraints, the overall upgrade will fail and diagnostic information will be returned.

5. The method of claim 4, wherein the health-aware modular upgrade of the feeder device embedded software is characterized by, Based on the verified inter-module dependencies, the upgrade execution order of the multiple modules to be upgraded is determined, forming the sequence of modules to be upgraded, including: For any given module, iterate backwards through all other modules that depend on it, and verify that the version constraints of each dependent module are still satisfied under the second predetermined version. After the dependency check passes, a directed acyclic graph is constructed with module dependencies as directed edges and modules as nodes, and the sequence of modules to be upgraded is determined according to the reverse topological order of advancing from leaf nodes to root nodes.

6. The method of claim 1, wherein the health-aware modular upgrade of the feeder device embedded software is characterized by, Upgrading the target loadable module set based on the sequence of modules to be upgraded includes: Extract the target module from the sequence of modules to be upgraded, back up the first target version currently running the target module to the backup storage area, and write the binary target file of the second target version to the shadow storage area; The function pointers of all external interfaces of the target module in the preset interface routing table are updated in one atomic operation, so that they switch from pointing to the first target version to pointing to the second target version. The preset interface routing table refers to a two-dimensional table structure stored in the memory of the feeder device, which records the current implementation function pointers and interface version numbers of the external interfaces of each module. The atomic operation is to update the function pointers of all external interfaces of the target module in the preset interface routing table in one go by disabling interrupts or using hardware atomic instructions.

7. The method of claim 6, wherein the health-aware modular upgrade of the feeder device embedded software is characterized by, Determining whether the trial operation health level obtained from the analysis of the preliminary upgrade results has reached the preset health level threshold includes the following: The module self-test indicators are obtained by returning the self-test results through the module initialization entry function; By periodically reporting heartbeat messages and receiving statistics, key functional heartbeat indicators can be obtained. Resource usage metrics are obtained by monitoring CPU utilization and memory usage; For modules associated with protection functions, consistency verification indicators are obtained by comparing the processing results of the upgraded modules with the real-time nuclear protection logic output. The health status of the trial operation is obtained by comprehensively scoring the module self-inspection indicators, the key function heartbeat indicators, the resource usage indicators, and the consistency verification indicators.

8. The modular upgrade method for health awareness of embedded software in the feeder device as described in claim 7, characterized in that, Based on the judgment result, the embedded software upgrade confirmation is performed, including: If the health status of the trial run reaches the preset health status threshold, then submit this upgrade and destroy the first target version in the backup storage area; If the health status of the trial operation does not reach the preset health status threshold, an automatic rollback is triggered. An atomic operation is used to switch the function pointers of all external interfaces of the target module in the preset interface routing table from the second target version to the first target version, and the second target version in the shadow storage area is cleared. The automatic rollback supports a three-level strategy: single-module rollback is performed when the health of a single module fails to meet the standard; batch rollback is performed in reverse topology order when multiple dependent modules are upgraded simultaneously and any module fails to meet the standard; and full rollback is performed by the bootloader when the feeder device experiences a serious crash and fails to restart during trial operation.

9. A modular upgrade system for health-sensing embedded software in a feeder device, characterized in that, The steps for implementing the health-aware modular upgrade method for embedded software of a feeder device according to any one of claims 1 to 8, wherein the health-aware modular upgrade system for embedded software of the feeder device comprises: The module sequence acquisition component is used to generate an upgrade package through the host computer of the feeder device, and introduce an upgrade parsing mechanism to parse the upgrade package to obtain the sequence of modules to be upgraded; A logic hierarchy extraction component is used to divide the embedded software of the feeder device to obtain a software partitioning result, and extract the target logic hierarchy from the software partitioning result, wherein the target logic hierarchy corresponds to the target loadable module set; An upgrade execution component is used to perform upgrade execution on the target loadable module set based on the sequence of modules to be upgraded, and obtain preliminary upgrade results for a preset observation period; The upgrade result judgment component is used to determine whether the trial operation health level obtained by analyzing the preliminary upgrade result has reached the preset health level threshold, obtain the judgment result, and perform the upgrade confirmation of the embedded software based on the judgment result.

Images