Spacecraft-oriented software on-orbit multi-bus fault-tolerant reconstruction system and method

Abstract

The invention discloses a spacecraft-oriented software on-orbit multi-bus fault-tolerant reconstruction system and method, and relates to the technical field of spacecraft electronic information. The system comprises a ground uploading subsystem, an on-satellite reconstruction management subsystem, a CAN and RS485 dual-bus redundant network and a load reconstruction client. The on-satellite reconstruction management subsystem segments software to be reconstructed according to 256KB, data packets in the segments are transmitted out of order, and transmission continuity is guaranteed through dual-bus hot backup and fault switching; and the load reconstruction client executes three-level verification of data packets, segments and files, and selectively retransmits the data packets, the segments and the files according to abnormal degrees. According to the scheme, through multi-bus redundancy, segmented transmission and a multi-stage fault-tolerant mechanism, multi-load collaborative updating is achieved, the space extreme environment is adapted, the reliability and efficiency of software on-orbit updating are greatly improved, algorithm iteration can be completed without changing hardware, and the spacecraft task life cycle is prolonged.

Description

Technical Field

[0001] This invention relates to the field of spacecraft electronic information technology, and in particular to a software-based on-orbit multi-bus fault-tolerant reconfiguration system and method for spacecraft. Background Technology

[0002] With the rapid iteration of Low Earth Orbit (LEO) constellations, High Throughput Satellites (HTS), and Geosynchronous Orbit (GEO) satellite technologies, the remote sensing, communication, and scientific exploration missions undertaken by spacecraft are becoming increasingly complex, and the amount of onboard data is growing explosively. The traditional "onboard acquisition-ground processing" model can no longer meet the demands for real-time performance and efficiency. To address this issue, on-orbit processors have become a core payload of spacecraft, needing to perform critical tasks such as regional positioning, image reconstruction, radiometric correction, geometric correction, image compression, and surface anomaly monitoring. The core algorithms for these tasks need to be continuously optimized based on scientific research progress and practical application scenarios. Therefore, the ability to update software on-orbit has become a core requirement for expanding spacecraft performance.

[0003] However, the unique characteristics of the spacecraft's on-orbit environment and the limitations of existing technologies present multiple challenges to on-orbit software reconfiguration. On the one hand, the space environment presents extreme conditions such as strong radiation, vacuum, and electromagnetic interference, which can easily lead to single-event upsets, bus transmission errors, and equipment failures, imposing stringent requirements on the reliability of the reconfiguration process. On the other hand, existing reconfiguration schemes mostly employ single-bus transmission. While the CAN bus offers strong real-time performance, its bandwidth is limited, making it difficult to adapt to the transmission of large-format software such as FPGA bit files. The RS485 bus lacks redundancy design, and a single link failure can easily lead to reconfiguration interruption. Furthermore, large file transmission is limited by orbital transit time and payload buffer capacity. Traditional full-file transmission modes require retransmission of the entire file when a few data packets are abnormal, resulting in a significant waste of orbital resources. Moreover, the lack of a unified multi-payload reconfiguration framework makes it difficult to adapt to the collaborative update needs of different devices such as the main control module and GPU module.

[0004] Furthermore, spacecraft have extremely high requirements for system autonomy, controllability, and long-term stability. Existing reconfiguration solutions are insufficient in terms of domestic adaptation, multi-level fault tolerance verification, and rapid anomaly recovery. They cannot fully withstand interference from the extreme space environment and cannot meet the needs of algorithm iteration and mission expansion throughout the long lifecycle of spacecraft. Therefore, there is an urgent need to build a software on-orbit reconfiguration system based on multi-bus redundancy, large file segmented transmission, and multi-level fault tolerance verification to address the shortcomings of existing technologies in reliability, efficiency, and adaptability, and provide a solid guarantee for on-orbit software updates for spacecraft. Summary of the Invention

[0005] The purpose of this invention is to provide a software on-orbit multi-bus fault-tolerant reconfiguration system and method for spacecraft, which solves the problems of low reliability, insufficient efficiency and poor adaptability of existing spacecraft software on-orbit reconfiguration. Through dual-bus redundancy, segmented transmission and multi-level fault tolerance mechanism, it achieves highly reliable on-orbit software updates that are compatible with multiple payloads and adaptable to extreme environments.

[0006] To achieve the above objectives, the present invention provides a software-based on-orbit multi-bus fault-tolerant reconfiguration system for spacecraft, comprising: The ground-based injection subsystem is used to generate and inject reconstruction task data packages containing the software files to be reconstructed and control instructions. The on-board reconfiguration management subsystem is communicatively connected to the ground-based injection subsystem and is used to receive and parse the reconfiguration task data packets, serving as the master control node for the reconfiguration task. A redundant communication network, including at least two independent communication buses that support hot backup, is used to establish a communication link between the on-board reconfiguration management subsystem and one or more on-board payload processors. At least one payload reconfiguration client is set up in the corresponding on-board payload processor as a controlled node for the reconfiguration task, and is used to receive reconfiguration data from the on-board reconfiguration management subsystem through the redundant communication network. The on-board reconfiguration management subsystem is configured as follows: The 256KB standard software file to be reconstructed is divided into multiple data segments, and each data segment is further divided into a single data packet containing 128 bytes of valid data. A communication bus is selected from the redundant communication network as the current primary bus, and data packets are sent to the target payload reconstruction client in segment order. Data packets within the same data segment can be sent out of order, and each data packet carries a data segment identifier and a packet sequence identifier. Based on feedback from the payload reconstruction client, selective retransmission is performed on data packets or data segments with transmission errors. The load reconstruction client is configured as follows: The received data packets are verified and cached in real time, with a cache capacity no less than the size of a single data segment; the integrity of the received data segments is verified, and the feedback is generated based on the verification results and the number of abnormal data packets; after all data segments have passed verification, the complete software file is reassembled and on-orbit loading is performed.

[0007] Preferably, the redundant communication network includes a CAN bus network and an RS-485 bus network.

[0008] Preferably, the on-board reconfiguration management subsystem is further configured to: encapsulate the reconfiguration data using a CAN application layer protocol that includes node address, frame type, and composite frame information when transmitting via the CAN bus network; and encapsulate the reconfiguration data using a private function code based on the MODBUS protocol extension when transmitting via the RS-485 bus network.

[0009] Preferably, the feedback generated by the load reconstruction client includes: When the data segment integrity check fails and the number of abnormal data packets does not exceed a preset threshold, the feedback includes the identification information of the abnormal data packets to trigger the on-board reconfiguration management subsystem to perform targeted retransmission. When the data segment integrity check fails and the number of abnormal data packets exceeds the preset threshold, a data segment reception failure status is fed back to trigger the on-board reconfiguration management subsystem to retransmit the entire data segment.

[0010] Preferably, the verification performed by the payload reconstruction client includes three levels of verification: CRC cyclic redundancy check on a single data packet, overall CRC check on a single data segment, and CRC check on the reconstructed complete software file, with the verification scope covering key fields of the data frame to the complete file.

[0011] Preferably, the system further includes a reliability enhancement module, which includes a triple watchdog circuit, a storage module, and a current limiting and reset circuit. A triple watchdog circuit is set in the load reconstruction client, including a FLASH FPGA watchdog, a watchdog between the FPGA and the GPU, and a hardware watchdog inside the GPU, for monitoring the processor's operating status. The storage module adopts a dual SSD backup design, supports ECC error checking and correction mechanism, and has a total ionization dose resistance of not less than 20 krad; The current limiting and reset circuit is used for single-event protection, cutting off the power supply or triggering a reset in the event of a single-event latch-up.

[0012] A software-based on-orbit multi-bus fault-tolerant reconfiguration method for spacecraft includes the following steps: S1. Ground preparation and uploading: On the ground, the software files to be reconstructed are packaged, version management and security review are completed, a task data package containing file verification information, reconstruction instructions and configuration item identifiers is generated, and then uploaded to the spacecraft via the space-to-ground link; S2. On-board initialization and channel selection: The on-board reconfiguration management subsystem receives and confirms the task data packet, and selects a communication bus from the redundant communication network as the primary transmission channel for this reconfiguration task. S3. Segmented data transmission: The on-board reconfiguration management subsystem splits the software file into data segments and data packets, and sends them to the target payload reconfiguration client through the primary transmission channel. Data packets within the same data segment are transmitted out of order. S4. On-orbit verification and fault-tolerant recovery: The payload reconfiguration client performs multi-level verification on the received data and feeds back abnormal information to the on-board reconfiguration management subsystem based on the verification results, triggering selective retransmission of specific data packets or the entire data segment until all data verification passes. S5. File Reassembly and Loading: The payload reconstruction client reassembles all successfully received data segments into a complete software file, performs final consistency verification, executes on-orbit loading and update, and reports the reconstruction results via telemetry.

[0013] Preferably, in step S3, each data packet carries a globally unique data segment identifier, packet sequence identifier, and data length information. The on-board reconstruction management subsystem caches the current segment data so as to retransmit abnormal data packets as needed.

[0014] Preferably, if a failure of the current primary transmission channel is detected during step S2 or step S3, the on-board reconfiguration management subsystem automatically or according to ground instructions switches to another communication bus in the redundant communication network and continues or re-executes the reconfiguration task based on the verification status of the transmitted data.

[0015] Preferably, the on-orbit verification and fault-tolerant recovery in step S4 includes: S41. Data packet level verification: Perform cyclic redundancy check and sequence number consistency check on each received data packet, discard invalid data packets and record the abnormal sequence number; S42. Data Segment Level Verification and Recovery: After all data packets in a data segment have been received, a full CRC check of the data segment is performed. If the check fails, retransmission of the erroneous data packets or retransmission of the entire data segment is triggered based on the number of erroneous data packets in the segment. S43. File-level verification: After all data segments have been transmitted and verified successfully, a CRC check is performed on the reassembled complete file to confirm that it is consistent with the verification information recorded on the ground.

[0016] According to specific embodiments provided by the present invention, the present invention discloses the following technical effects: (1) This system significantly improves the reliability and efficiency of on-orbit software updates for spacecraft through an innovative dual-bus redundancy architecture and segmented transmission mechanism. The CAN and RS485 buses serve as hot backups for each other, supporting autonomous fault switching and avoiding reconstruction interruptions caused by single-link failures. Large files are segmented according to standardized rules, and data packets within segments support out-of-order transmission and precise reassembly, breaking through the limitations of single-bus bandwidth and cache, and reducing the waste of orbital resources. The unified multi-payload reconstruction framework adopts standardized instruction encapsulation and node address allocation rules, realizing collaborative updates of multiple devices such as the main control module and GPU module, and adapting to different types of on-orbit processing task requirements.

[0017] (2) The three-level verification and multi-level fault tolerance mechanism of the system effectively resists the interference of the extreme space environment. The hierarchical verification process of data packets, data segments and complete files accurately locates and repairs abnormal data transmission, and performs targeted retransmission according to the degree of abnormality to ensure the integrity of the reconstructed data; the triple watchdog monitoring, dual backup of storage modules and single-event protection design realizes the autonomous monitoring and recovery of faults such as program crashes, system deadlocks and radiation interference, and strengthens the long-term stable operation capability of the system in vacuum and radiation environments.

[0018] (3) The combination of software on-orbit reconfiguration function and integrated debugging system gives the spacecraft strong mission adaptability and development efficiency. The core algorithm can achieve on-orbit iteration without modifying the hardware, which extends the mission life cycle of the spacecraft and meets the continuous optimization needs of functions such as surface anomaly monitoring and image correction. The matching design of the development system and the verification system can accurately simulate the on-board operating environment on the ground, complete the software and hardware compatibility test and functional verification in advance, simplify the development process, reduce the risk of on-orbit failure, and at the same time, the adaptation of domestic modules and software ecosystem ensures the system's independent controllability.

[0019] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

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

[0021] Figure 1 This is a system architecture block diagram of a software-based on-orbit multi-bus fault-tolerant reconfiguration system for spacecraft, according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the CAN bus standard frame structure according to an embodiment of the present invention; Figure 3This is a schematic diagram illustrating data segmentation and unpacking in an embodiment of the present invention; Figure 4 This is a schematic diagram of a software-based on-orbit multi-bus fault-tolerant reconfiguration method for spacecraft according to an embodiment of the present invention; Figure 5 This is a diagram illustrating the extended MODBUS protocol interaction sequence according to an embodiment of the present invention. Figure 6 This is a flowchart of the on-board reconfiguration management subsystem (Master) according to an embodiment of the present invention; Figure 7 This is a flowchart of the load reconstruction client (Slave) side of an embodiment of the present invention. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0023] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0024] Example: On-orbit reconstruction using intelligent processing algorithms for remote sensing satellites

[0025] This embodiment applies to the integrated processing unit of a low Earth orbit (LEO) remote sensing satellite, with the goal of completing the on-orbit update of the surface anomaly monitoring algorithm. The architecture of this satellite integrated processing unit is as follows: Figure 1 As shown, it includes an on-board reconfiguration management subsystem, a redundant communication network, and a payload reconfiguration client. It supports dual-bus communication of CAN and RS485 and must withstand extreme environments such as space radiation and vacuum to meet high-reliability reconfiguration requirements.

[0026] I. System Architecture and Components 1. Ground-based Upload Subsystem: This subsystem, located at the ground tracking and control station, is responsible for initiating and managing software reconfiguration tasks. Its main functions include: version management, security review, and testing of the algorithm software to be uploaded; encapsulating software files and related control commands according to the format agreed upon by the onboard system to generate a reconfiguration task data packet; and finally uploading the data packet to the spacecraft in orbit via the space-to-ground tracking and control link. In this example, the space-to-ground tracking and control link includes the tracking and control units TTCA and TTCB, which communicate with the StarStyle Reconfiguration Management Subsystem via uplink TC-PCM and downlink TM-PCM.

[0027] 2. Onboard Reconfiguration Management Subsystem: This subsystem is integrated into the spacecraft's onboard computer and serves as the master control node for the entire reconfiguration process. It is responsible for receiving and parsing commands and data from the ground; managing and scheduling the onboard redundant communication network; selecting the optimal communication path to send reconfiguration data to the target payload according to preset strategies or ground commands; and simultaneously receiving feedback information from the payload and executing corresponding fault-tolerant control logic, such as organizing data retransmission.

[0028] 3. Redundant communication network: To ensure the absolute reliability of reconfiguration commands and data transmission, this system deploys a dual-redundant communication bus network on the satellite.

[0029] CAN Bus Network: Employs a high-reliability CAN bus conforming to international standards, designed with A / B dual-channel hot backup. The bus baud rate is set to 500kbps, and the physical layer uses twisted-pair cabling. Its application layer protocol is customized and implemented according to the CAN Specification V2.0 B. The standard frame structure of the CAN bus is as follows... Figure 2 As shown: (1) Start of frame: 1 bit, marking the start of data frames and remote frames, consisting of a single "dominant" bit; (2) Arbitration segment: 12 bits, consisting of an identifier (ID) and a remote transmission request (RTR): Identifier: 11 bits (ID10~ID0), of which the high 7 bits (ID10~ID4) are not all "recessive", that is, "1111111" is prohibited; RTR: 1 bit, this scheme uses data frames, and is fixed as "dominant"; The arbitration segment determines the priority of data frame transmission; higher priority identifiers have lower binary values.

[0030] (3) Control segment: 6 bits, of which the first 2 bits are reserved bits and are sent at the "dominant" level; the last 4 bits are the data length code (DLC) of "0000" to "1000", indicating that the number of bytes of data is 0 to 8 bytes; (4) Data segment: 0~64 bits, i.e., a maximum of 8 bytes, indicated by DLC; (5) CRC segment: 16 bits, the calculation range includes frame start, arbitration segment, control segment, data segment (if any), and cyclic redundancy check code.

[0031] (6) ACK segment (acknowledgment segment): 2 bits. The sending node sends out two "recessive" bits in the acknowledgment segment, namely the acknowledgment gap and the acknowledgment delimiter. All nodes that receive a CRC match rewrite the "recessive" bits of the transmitter's acknowledgment gap with "dominant" bits and send out the acknowledgment. (7) End of frame: 7 bits. Each data frame and remote frame is defined by a sequence of 7 “recessive” bits to indicate the end of the frame.

[0032] The identifier of a data frame is defined as a composite field containing the target node address, frame type (such as telemetry, remote control), and frame continuity information (single frame, start frame, middle frame, end frame) to support the split transmission of large blocks of data.

[0033] RS-485 bus network: As another independent communication channel, it adopts the RS-485 electrical standard and sets the baud rate to 921600bps to obtain higher bandwidth. Its communication protocol is based on the mature MODBUS-RTU mode and extends it, defining a series of proprietary function codes specifically for file transfer control, data block transfer, transfer status query and other reconstruction-related operations.

[0034] 4. Payload Reconfiguration Client: This client software runs within the onboard payload processor that requires software updates, such as the master control module and intelligent processing module in this embodiment. As a slave node, it is responsible for receiving reconfiguration data packets through a designated bus and performing real-time verification and caching. Its buffer capacity is designed to temporarily store at least one complete data segment (e.g., 256KB). The client has the ability to perform autonomous data verification, error reporting, and software loading and activation according to the master node's instructions.

[0035] II. Reconstruction Method and Process This restructuring process followed Figure 4 The overall process is shown below, where Master represents the master control node, i.e., the on-board reconfiguration management subsystem in this application; Slave represents the slave node, i.e., the payload reconfiguration client in this application. The specific steps are as follows: Step S1: Ground preparation and infusion.

[0036] After ground personnel completed the development and testing of the new algorithm, they initiated the reconstruction process. First, the 30MB binary file was preprocessed, and its global CRC checksum was calculated. Then, according to the protocol, file information (such as filename, size, version number, and total checksum) was encapsulated into a "reconstruction start command packet." This command packet was sent to the satellite's onboard computer via the uplink telemetry and control channel.

[0037] Step S2: On-board initialization and channel selection.

[0038] After receiving the mission data packet, the onboard reconfiguration management subsystem (Master) performs a validity check and initializes the bus receive buffer and verification parameters. Then, based on the current bus status, historical success rate, or direct ground commands, it selects a communication bus as the primary channel for this mission. The CAN bus is preferentially selected as the primary transmission channel, and the completion status (0x11 idle) is initialized via telemetry feedback. The initialization interaction process between the Master and Slave is as follows: Figure 4 , Figure 5 As shown: The Master triggers the Slave to enter refactoring mode by sending the req_pdu 0x64 instruction, and the Slave returns rsp_pdu 0x64 to indicate that it is ready.

[0039] Step S3: Segmented data transmission.

[0040] The onboard management subsystem begins transmitting the file itself, adopting a "segmentation first, then packetization" strategy to improve transmission efficiency and reliability.

[0041] The onboard reconstruction management subsystem splits the 30MB file into 118 data segments (the first 117 segments are 256KB each, and the last segment is 192KB) according to the 256KB standard. Each segment is further divided into 2048 data packets (each packet contains 128 bytes of valid data). The splitting logic is as follows: Figure 2 As shown. Each data packet carries a globally unique data segment identifier, packet sequence identifier, and data length information. The satellite buffers the data for the current segment. Data is sent sequentially via the CAN bus, with data packets within the same segment transmitted out of order. The transmission process is as follows: Figure 6 As shown.

[0042] Step S4: On-orbit Level 3 Verification and Fault Tolerance Recovery.

[0043] The data reception process of the load reconfiguration client is as follows Figure 7 As shown, the process involves a three-level verification and autonomous recovery procedure, which is the core of achieving high reliability.

[0044] Level 1: Real-time packet verification. Each received packet (128 bytes) is immediately subjected to CRC check and sequence number check. Packets that fail the check are discarded, and their sequence numbers are recorded in a local exception list.

[0045] Level 2: Data Segment Integrity Verification and Intelligent Retransmission. After all data packets belonging to the same data segment have been received, the client calculates the overall CRC value of the segment using all the cached data and compares it with the expected value received in step S103.

[0046] If the verification passes, the data segment has been successfully received.

[0047] If the verification fails, the client will check the list of abnormal packets recorded during the reception of this segment. The system presets a threshold (3 in this embodiment). If the number of abnormal packets does not exceed 3, the client will accurately report the sequence numbers of these abnormal packets when responding to the master node's query. The master node will then only retransmit these specific data packets. If the number of abnormal packets exceeds 3, the client will report a segment reception failure, and the master node will retransmit the entire 256KB data segment. This "precise retransmission" mechanism greatly avoids unnecessary data duplication.

[0048] Level 3: Overall File Verification. After all data segments pass Level 2 verification, the client will reassemble the complete 30MB file sequentially, calculate its CRC, and perform a final comparison with the global checksum sent from the ground in step S1. Only if the comparison matches is the file transfer considered completely successful.

[0049] Step S5: File reorganization and loading activation.

[0050] After file-level verification passes, the ground control center sends a software activation command. The payload reconfiguration client writes the correctly reconfigured new algorithm software to a designated location in its non-volatile memory (such as a solid-state drive) and updates the boot information. Subsequently, the new software starts running through module restart or hot-swap. All critical states throughout the reconfiguration process, including reception results, verification status, and abnormal events, are continuously transmitted to the ground via telemetry channels, forming a complete closed loop of "uplink injection - on-orbit processing - status downlink." The complete interaction process is as follows: Figure 4 As shown.

[0051] Figure 5 , Figure 6 and Figure 7 The document demonstrates a private function code sequence interface based on the MODBUS protocol extension, used for command interaction between the onboard reconfiguration management subsystem (Master, master control node) and the payload reconfiguration client (Slave, controlled node). The specific function of each interface is as follows: 1. req_pdu 0x64: Reconstruction file initialization request Function: The Master initiates a "handshake instruction" to the Slave to confirm whether the Slave is idle and whether it is ready to receive the refactoring files.

[0052] Interaction logic: The Slave returns rsp_pdu 0x64 in response "ready" to indicate that it is ready; if the response fails, the Master will retry a maximum of 3 times, and if the retry fails, the current reconstruction will be terminated.

[0053] 2. req_pdu 0x65: Segment transfer preparation request Function: Once the Slave confirms that it is ready, the Master sends this instruction to notify the Slave that it is about to start transmitting a single data segment (256KB), allowing the Slave to initialize the receive buffer and check parameters for that segment.

[0054] Interaction logic: The Slave returns rsp_pdu 0x65 in response "ready", indicating that preparation for receiving this segment is complete.

[0055] 3. req_pdu 0x66: Data packet transfer command Function: This is the core data transmission interface. The Master sends the split data packets (each packet contains 128 bytes of valid data) to the Slave via this command. Data packets within the same data segment can be transmitted out of order.

[0056] Interaction logic: After receiving data packets, the Slave will cache them in real time and perform CRC checks to prepare for subsequent segment-level checks.

[0057] 4. req_pdu 0x67: Data segment receive status query Function: After all data packets of a data segment have been sent, the Master uses this command to query the Slave's segment reception status, including whether there are any abnormal data packets and whether the segment-level CRC check has passed.

[0058] Interaction logic: The Slave's rsp_pdu 0x67 will return the number of abnormal packets or the verification result. The Master decides whether to retransmit the abnormal data packets (≤3 abnormal packets) or retransmit the entire data segment (>3 abnormal packets) based on the feedback.

[0059] 5. req_pdu 0x68: Complete file reception status query Function: After all data segments have been transmitted, the Master uses this command to query the Slave for the final verification result of the entire reconstructed file, confirming whether the file is complete and whether the checksum is consistent with the one recorded on the ground.

[0060] Interaction logic: The Slave returns rsp_pdu 0x68 to indicate the file reception status. After successful verification, the Master reports the telemetry status, and the refactoring process loop ends.

[0061] III. System Reliability Enhancement Design To cope with the harsh challenges of the space environment (such as single-event effects and total dose radiation), the system in this embodiment incorporates several hardening designs at both the hardware and software levels: 1. Multiple Monitoring and Reset Functions: A triple watchdog monitoring circuit is designed inside the payload processor. This includes an internal FPGA watchdog based on Flash, a watchdog responsible for heartbeat monitoring between the FPGA and GPU, and a hardware watchdog on the GPU chip itself. If any level of monitoring detects a task anomaly (such as an infinite loop), it will trigger a reset within the corresponding range, ensuring that the system recovers quickly from a fault.

[0062] 2. Radiation-resistant storage design: The solid-state storage module for storing programs and data adopts a dual-module architecture with mutual backup. The storage controller supports error checking and correction technology, capable of detecting and correcting unit errors caused by radiation. The selected storage chips meet aerospace-grade requirements for total radiation dose resistance of not less than 20 krad.

[0063] 3. Single-event latch-up protection: Independent current-limiting protection circuits and power switches are set up for critical processing modules in the power distribution network. When a single-event latch-up event causes an abnormally large current, the protection circuit can act quickly to cut off the local power supply, prevent the fault from spreading, and achieve a safe system reset in conjunction with a watchdog timer.

[0064] The remaining technical features in the above embodiments can be flexibly selected by those skilled in the art to meet different specific practical needs according to actual circumstances. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims. In the above description, numerous specific details have been set forth to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that these specific details are not necessary to implement the present invention. In other instances, to avoid obscuring the present invention, well-known techniques, such as specific construction details, operating conditions, and other technical conditions, have not been specifically described.

[0065] This document uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A software-based on-orbit multi-bus fault-tolerant reconfiguration system for spacecraft, characterized in that, include: The ground-based injection subsystem is used to generate and inject reconstruction task data packages containing the software files to be reconstructed and control instructions. The on-board reconfiguration management subsystem is communicatively connected to the ground-based injection subsystem and is used to receive and parse the reconfiguration task data packets, serving as the master control node for the reconfiguration task. A redundant communication network, including at least two independent communication buses that support hot backup, is used to establish a communication link between the on-board reconfiguration management subsystem and one or more on-board payload processors. At least one payload reconfiguration client is set up in the corresponding on-board payload processor as a controlled node for the reconfiguration task, and is used to receive reconfiguration data from the on-board reconfiguration management subsystem through the redundant communication network. The on-board reconfiguration management subsystem is configured as follows: The 256KB standard software file to be reconstructed is divided into multiple data segments, and each data segment is further divided into a single data packet containing 128 bytes of valid data. A communication bus is selected from the redundant communication network as the current primary bus, and data packets are sent to the target payload reconstruction client in segment order. Data packets within the same data segment can be sent out of order, and each data packet carries a data segment identifier and a packet sequence identifier. Based on feedback from the payload reconstruction client, selective retransmission is performed on data packets or data segments with transmission errors. The load reconstruction client is configured as follows: The received data packets are verified and cached in real time, with a cache capacity no less than the size of a single data segment; Integrity verification is performed on the received data segments, and feedback is generated based on the verification results and the number of abnormal data packets. After all data segments pass verification, the complete software files are reassembled and on-orbit loading is performed.

2. The software-based on-orbit multi-bus fault-tolerant reconfiguration system for spacecraft according to claim 1, characterized in that: The redundant communication network includes a CAN bus network and an RS-485 bus network.

3. The software-based on-orbit multi-bus fault-tolerant reconfiguration system for spacecraft according to claim 2, characterized in that: The on-board reconfiguration management subsystem is further configured to: encapsulate reconfiguration data using a CAN application layer protocol containing node address, frame type, and composite frame information when transmitting via the CAN bus network; and encapsulate reconfiguration data using a private function code based on the MODBUS protocol extension when transmitting via the RS-485 bus network.

4. The software-based on-orbit multi-bus fault-tolerant reconfiguration system for spacecraft according to claim 1, characterized in that: The feedback generated by the load reconstruction client includes: When the data segment integrity check fails and the number of abnormal data packets does not exceed a preset threshold, the feedback includes the identification information of the abnormal data packets to trigger the on-board reconfiguration management subsystem to perform targeted retransmission. When the data segment integrity check fails and the number of abnormal data packets exceeds the preset threshold, a data segment reception failure status is fed back to trigger the on-board reconfiguration management subsystem to retransmit the entire data segment.

5. A software-based on-orbit multi-bus fault-tolerant reconfiguration system for spacecraft according to claim 1, characterized in that: The verification performed by the payload reconstruction client includes three levels of verification: CRC cyclic redundancy check on a single data packet, overall CRC check on a single data segment, and CRC check on the reconstructed complete software file. The verification scope covers key fields of the data frame to the complete file.

6. The software-based on-orbit multi-bus fault-tolerant reconfiguration system for spacecraft according to claim 1, characterized in that: The system also includes a reliability enhancement module, which includes a triple watchdog circuit, a storage module, and a current limiting and reset circuit. A triple watchdog circuit is set in the load reconstruction client, including a FLASH FPGA watchdog, a watchdog between the FPGA and the GPU, and a hardware watchdog inside the GPU, for monitoring the processor's operating status. The storage module adopts a dual SSD backup design, supports ECC error checking and correction mechanism, and has a total ionization dose resistance of not less than 20 krad; The current limiting and reset circuit is used for single-event protection, cutting off the power supply or triggering a reset in the event of a single-event latch-up.

7. A software-based on-orbit multi-bus fault-tolerant reconfiguration method for spacecraft based on the system described in any one of claims 1-6, characterized in that, Includes the following steps: S1. Ground preparation and uploading: On the ground, the software files to be reconstructed are packaged, version management and security review are completed, a task data package containing file verification information, reconstruction instructions and configuration item identifiers is generated, and then uploaded to the spacecraft via the space-to-ground link; S2. On-board initialization and channel selection: The on-board reconfiguration management subsystem receives and confirms the task data packet, and selects a communication bus from the redundant communication network as the primary transmission channel for this reconfiguration task. S3. Segmented data transmission: The on-board reconfiguration management subsystem splits the software file into data segments and data packets, and sends them to the target payload reconfiguration client through the primary transmission channel. Data packets within the same data segment are transmitted out of order. S4. On-orbit verification and fault-tolerant recovery: The payload reconfiguration client performs multi-level verification on the received data and feeds back abnormal information to the on-board reconfiguration management subsystem based on the verification results, triggering selective retransmission of specific data packets or the entire data segment until all data verification passes. S5. File Reassembly and Loading: The payload reconstruction client reassembles all successfully received data segments into a complete software file, performs final consistency verification, executes on-orbit loading and update, and reports the reconstruction results via telemetry.

8. A software-based on-orbit multi-bus fault-tolerant reconfiguration method for spacecraft according to claim 7, characterized in that: In step S3, each data packet carries a globally unique data segment identifier, packet sequence identifier, and data length information. The on-board reconstruction management subsystem caches the current segment data so that abnormal data packets can be retransmitted as needed.

9. A software-based on-orbit multi-bus fault-tolerant reconfiguration method for spacecraft according to claim 7, characterized in that: If a failure of the current primary transmission channel is detected during step S2 or step S3, the on-board reconfiguration management subsystem automatically or according to ground instructions switches to another communication bus in the redundant communication network and continues or re-executes the reconfiguration task based on the verification status of the transmitted data.

10. A software-based on-orbit multi-bus fault-tolerant reconfiguration method for spacecraft according to claim 7, characterized in that, The on-orbit verification and fault-tolerant recovery in step S4 include: S41. Data packet level verification: Perform cyclic redundancy check and sequence number consistency check on each received data packet, discard invalid data packets and record the abnormal sequence number; S42. Data Segment Level Verification and Recovery: After all data packets in a data segment have been received, a full CRC check of the data segment is performed. If the check fails, retransmission of the erroneous data packets or retransmission of the entire data segment is triggered based on the number of erroneous data packets in the segment. S43. File-level verification: After all data segments have been transmitted and verified successfully, a CRC check is performed on the reassembled complete file to confirm that it is consistent with the verification information recorded on the ground.

Images