A flexible spaceborne minimum safety system and a rapid reconfiguration method

Abstract

A flexible onboard minimum safety system and rapid reconfiguration method are presented. The minimum safety system includes a CPU circuit with an operating system, a control FPGA circuit, an ACTEL / ASIC refresh and reconfiguration circuit, a PROM, and a NOR FLASH. The CPU circuit with the operating system is used to read the boot program from the PROM to complete the initialization configuration, for data reception and parsing, and for external bus control. The NOR FLASH is used to store on-orbit updated software. The control FPGA circuit acts as the actuator, used to distribute remote control commands, collect telemetry data, and control the updating and storage of the uploaded software. The ACTEL / ASIC refresh and reconfiguration circuit manages the configuration file of the control FPGA circuit, and by default reads the software from the NOR FLASH to load the control FPGA circuit. A rapid reconfiguration method is implemented based on the above minimum safety system.

Description

Technical Field

[0001] This invention relates to a flexible onboard minimum safety system and a rapid reconfiguration method, belonging to the field of software-defined satellite technology. Background Technology

[0002] Traditional satellites typically employ a single payload configuration with fixed functions. In-orbit deployment requires launching multiple satellites to achieve different functions, resulting in low utilization. As remote sensing satellites achieve increasingly higher resolutions and their on-orbit intelligent processing applications become more widespread, data transmission pressures are reduced, and satellite application efficiency is improved. Different application scenarios require satellites to possess different processing functions, such as target detection and recognition from multi-source data, cloud analysis, and key area extraction. Since the working principles of intelligent processing in remote sensing satellites are relatively similar, the required hardware is similar, thus allowing for hardware platform reuse. Software-defined satellites, through hardware reuse, offer programmable platforms. By configuring different application software, satellite functions can be reconfigured. This allows a single payload hardware platform to perform multiple payload functions, thereby enhancing the satellite's intelligence level and application efficiency.

[0003] With the rapid development of satellite remote sensing technology and the gradual application of intelligent on-board processing tasks, software-defined payloads and software-defined satellites have become new trends in technological development. Satellite hardware platforms adopt a universal and standardized system architecture, allowing satellites to perform different functions by loading different apps, much like smartphones. To enable satellites to adapt to diverse application needs, these apps need to be updated in orbit to replace older versions. Unlike the ground environment, satellite app uploading relies on valuable satellite-to-ground links, resulting in limited transmission time and the possibility of errors or interruptions. Furthermore, satellites are susceptible to single-event events (SEE), and the app software embedded in NOR flash memory is subject to SEE probability in orbit. If the app software in the NOR flash memory encounters an error, it can cause hardware loading failure, leading to satellite malfunction. Summary of the Invention

[0004] The technical problem to be solved by this invention is to overcome the shortcomings of the prior art and solve the problems of high efficiency and high reliability of software-defined satellites.

[0005] The objective of this invention is achieved through the following technical solutions:

[0006] A flexible spaceborne minimum safety system includes a CPU circuit with an operating system, a control FPGA circuit, an ACTEL / ASIC refresh and reconfiguration circuit, a PROM, and a NOR FLASH.

[0007] The CPU circuit with the operating system is used to read the boot program from the PROM to complete the initialization configuration, to receive and parse data, and to control the external bus.

[0008] NOR FLASH is used to store software that is updated in orbit;

[0009] The FPGA circuit is used as an actuator to distribute remote control commands, collect telemetry data, and control the updating and storage of the uploading software.

[0010] The ACTEL / ASIC refresh and reconfiguration circuit is used to manage the configuration files for controlling the FPGA circuit. By default, it reads the software from the NOR FLASH to complete the loading of the FPGA circuit.

[0011] In one embodiment of the present invention, the PROM is an antifuse type device, which is immune to single particles.

[0012] In one embodiment of the present invention, NOR FLASH uses Hamming code and multimodal redundancy for data storage.

[0013] In one embodiment of the present invention, the PROM includes two PROMs, one of which is used to store the boot program of the CPU circuit with the operating system, namely PROM1, and the other is used to store the configuration program for the minimum startup of the control FPGA, namely PROM2; when the control FPGA circuit fails to load, the ACTEL / ASIC refresh and reconfiguration circuit reads the minimum startup configuration program for the control FPGA from PROM2.

[0014] In one embodiment of the present invention, the onboard minimum safety system further includes an interface circuit, which controls the FPGA circuit to transmit data with external units through the interface circuit.

[0015] A rapid reconfiguration method based on the aforementioned onboard minimum safety system includes:

[0016] S1. When the control FPGA circuit receives the uploading data from the interface, it first writes it into the DRAM buffer in packets, and then performs CRC verification. If the CRC verification is correct, proceed to step S2; if the CRC verification is incorrect, clear the buffer, continue to receive uploading data, and report the error frame counter through telemetry.

[0017] S2. After receiving 56 bytes of data, RS(64,56) encoding is performed. The encoded data is then extended to 64 bytes, and the process proceeds to step S3.

[0018] S3. The encoded data is first stored in buffer FIFO1. When 64 bytes are full, the operation switches to buffer FIFO2 to continue writing. At the same time, 64 bytes of data are read from buffer FIFO1 and written to one of the NOR FLASH chips (NOR FLASH3 / 4) according to the most efficient NOR FLASH write buffer mode. When buffer FIFO2 is full, 64 bytes of data are read at a time and written to the other NOR FLASH chip (NOR FLASH3 / 4) according to the most efficient NOR FLASH write buffer mode. At the same time, the encoded data is written to buffer FIFO1. This ping-pong operation continues until the software is finished and the process exits. After each 64 bytes of data are sent, the busy / idle flag returned by NORFLASH is queried.

[0019] S4. After the satellite is powered on, the satellite's functional units complete the loading from their respective units or are loaded through the control FPGA; when the control FPGA receives the switching control FPGA loading command sent by the satellite staff, it proceeds to step S5.

[0020] S5. Control the FPGA circuit to read the software data stored in NOR FLASH (NOR FLASH3 / 4) page by page, and then proceed to step S6;

[0021] S6. Control the FPGA to send configuration programs to the functional units of the satellite to complete the loading of each functional unit. First, control the FPGA to read the configuration program from NOR FLASH3 and NOR FLASH4 and write it into the DRAM cache. After storing 64 bytes, read it out all at once for RS(64,56) decoding. The decoding module needs to judge the correctness of the data. If it detects that the decoding capability is exceeded, stop sending to the functional unit, that is, end the sending of configuration data to the current functional unit, and jump to the next functional unit in S5. If no error is detected or there is an error but it is within the decoding capability, send the decoded data to the functional unit. After completing the sending action of the current function, jump to the next functional unit until all functional units have completed the sending action, and then go to step S7.

[0022] S7. Control the FPGA circuit to upload the decoded data to each functional unit for independent storage, or directly load the data to each functional unit through the interface.

[0023] Compared with the prior art, the present invention has the following advantages:

[0024] (1) The present invention designs a minimum safety system with CPU+FPGA+ACTEL / ASIC+PROM+NOR FLASH architecture. The FPGA is controlled by default to load through NOR FLASH2, which has on-orbit injection capability, ensuring the flexibility of the control center. At the same time, when software data in NOR FLASH2 is corrupted on-orbit, the system can automatically switch to PROM2 to load the minimum startup configuration function, and then re-inject NOR FLASH2, ensuring the high reliability and security of the software-defined satellite.

[0025] (2) The present invention designs a high code rate Hamming code (72,64) + three-mode redundancy to ensure that the APP software controlling the FPGA in the software-defined satellite has strong anti-single-event upset performance in orbit.

[0026] (3) Combining the characteristics of NOR FLASH, this invention designs a fast write cache mode + ping-pong pipeline method, which greatly shortens the uploading time of the functional unit APP software and improves the satellite's rapid reconfiguration function. At the same time, the functional unit APP software stored in NOR FLASH3 / 4 is RS(64,56) encoded and decoded to ensure the high reliability of the APP software in orbit. Attached Figure Description

[0027] Figure 1 A system solution for software-defined satellites.

[0028] Figure 2 This is the execution flowchart for the minimum safety system.

[0029] Figure 3 This is a flowchart of a method for rapid refactoring of functional units.

[0030] Figure 4 This is a diagram showing the distribution of the functional unit APP software in the NOR FLASH storage area.

[0031] Figure 5 This is a diagram of the test environment architecture. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the present invention clearer, the embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.

[0033] This invention proposes a minimum safety system and rapid reconfiguration method for software-defined satellites. This method enables rapid uploading of application software to satellite products and ensures system safety and reliability even in the event of uploading anomalies or single-event upsets (SEORs). Traditional satellites are essentially customized, with application software pre-programmed into antifuse PROM memory before launch. Once programmed, it cannot be updated in orbit, resulting in limited satellite functionality. Software-defined satellites, however, require uploading different application software for different application scenarios and at different times, enabling multi-purpose use. Therefore, the application software needs to be stored in rewritable NOR flash memory. While software-defined satellites offer significantly improved flexibility and utilization, NOR flash memory is susceptible to SEORs due to the influence of space radiation particles, inevitably impacting satellite safety and reliability. Given the extremely valuable uplink resources and limited visible arc between the satellite and ground station, the uploading time must be minimized. For large-scale logic devices, a single application software can reach hundreds of megabytes (Mb), while existing satellite uploading rates are only in the hundreds of kbps range. Continuous uploading of a single application software takes nearly an hour; uploading multiple application files would take even longer, inevitably affecting the normal operation of the satellite. Furthermore, due to single-event events in space or failures in the uploading link, the application software stored in the NOR FLASH memory may generate errors, leading to product loading failure and system malfunction. This invention designs a minimal safety system and rapid reconfiguration method for software-defined satellites, enabling the system to self-recover when application software errors occur. It also solves the problem of excessively long uploading times for satellite application software, minimizing uploading time and meeting the increasingly urgent need for on-orbit application software updates.

[0034] The hardware platform of a software-defined satellite is fully reconfigurable, consisting of two main parts: a control unit and functional units. The control unit is responsible for receiving commands from the payload platform, transmitting telemetry data, uploading its own application software (APP), and centrally managing the APP software of the functional units. The functional units can be flexibly configured according to user needs, integrating routing, switching, high-performance computing, and storage functions. They encompass high-performance programmable devices such as FPGAs, DSPs, and GPUs, loading different APP software to achieve different functions. A software-defined satellite system solution is shown below. Figure 1 As shown.

[0035] The control unit consists of three circuits: a CPU circuit with an operating system, a control FPGA circuit, and an ACTEL / ASIC refresh and reconfiguration circuit. The CPU serves as the central control unit, handling functions such as CAN bus, 1553B bus, or SpaceWire bus control. After the satellite is powered on, the CPU reads the boot program from PROM1 to complete initialization and configuration, possessing basic functions such as data reception and parsing. Because PROM1 is an antifuse type device, it is immune to single-event events and has high reliability. Different control functions are implemented in orbit through the APP software stored in NOR FLASH1. The control FPGA is the actuator of the control unit, with complex functions. In orbit, it needs to implement different functions according to different application scenarios. It has reconfigurable capabilities in orbit, implementing different control functions through the APP software stored in NOR FLASH2. Its main functions include: distributing remote control commands to each processing unit, collecting corresponding telemetry data, and updating and centrally storing the APP software uploaded to functional units (routing and switching units, computing units, etc.). The ACTEL / ASIC refresh and reconfiguration circuit's main function is to manage the configuration files of the control FPGA. Since the FPGA and CPU are the control core of the entire payload platform, the configuration file management of the FPGA requires high reliability. It should also be flexibly configurable to suit different application scenarios.

[0036] This invention designs a minimum safe system architecture of CPU+FPGA+ACTEL / ASIC+PROM+NOR FLASH. The refresh and reconfiguration circuit can be implemented using an antifuse-type ACTEL or an ASIC; both are immune to single-event upsets and possess high reliability. After system power-on, the ACTEL / ASIC refresh and reconfiguration circuit reads the APP software from NOR FLASH2 by default to complete the FPGA loading. NOR FLASH is an erasable memory chip, and there is a risk of single-event upsets in orbit. If a single-event upset occurs, FPGA loading will fail. Therefore, to reduce the risk of FPGA loading failure caused by a single-event upset of the APP software stored in NOR FLASH2, this invention adopts Hamming code (72,64) + triple modular redundancy to ensure that the APP software storing the FPGA in NOR FLASH2 has strong anti-single-event performance. Hamming code (72,64) has the ability to correct 1 / 2 errors, and the selected (72,64) code pattern has a high code rate, the information bits are an integer multiple of the bytes, and it has strong anti-interference ability. At the same time, triple redundancy is added, which takes advantage of the principle that the probability of errors occurring simultaneously on the same set of hardware units is smaller than the probability of errors occurring on a single hardware unit, and uses the majority decision of two out of three to be the correct output of the system.

[0037] Although this invention employs Hamming code (72,64) + triple modal redundancy for high reliability, single-event risk cannot be completely eliminated, and the possibility of rollover still exists. Since the control unit is the control flow hub of the payload platform, it is crucial for both the payload platform and the satellite. If the control FPGA loading fails, control information cannot be transmitted to the functional units, and the software-defined satellite will also fail. To completely prevent this from happening, this invention designs a separate PROM2 circuit, externally connected to ACTEL / ASIC. If, after system power-on, the APP software read from NOR FLASH2 rolls over, and errors still exist after Hamming code (72,64) + triple modal redundancy, then ACTEL / ASIC automatically switches to PROM2 for reading based on the FPGA loading failure signal. Unlike the APP software stored in NOR FLASH2, PROM2 only needs to store the minimum startup configuration program for its own uploading channels and remote / telemetry functions. The execution flow of the minimum safety system is as follows: Figure 2 As shown.

[0038] The CPU+FPGA+ACTEL / ASIC+PROM+NOR FLASH bottom-line security system architecture designed in this invention satisfies both the flexibility of software-defined satellites and ensures the reliability of the system.

[0039] With the rapid development of technologies such as artificial intelligence and image algorithms, especially artificial intelligence, the application software installed on satellites at the time of manufacture is often not optimal in performance. It requires continuous training and iteration in orbit to reach its optimal state. Therefore, the application software needs to undergo multiple rounds of iteration. The hardware platform configuration of software-defined satellites is mostly high-performance processors, while the required application software is generally large; for example, the application software for a 7-series FPGA reaches 230 Mbit.

[0040] From application software uploading to final execution, the process typically involves the satellite-to-ground uplink → satellite service subsystem → control unit → functional unit. Traditionally, the uplink uses the S-channel telemetry and control (TT&C) with a speed of only a few kbps. Currently, the Ka-channel is used, reaching speeds of hundreds of Mbps, a significant improvement. The satellite service subsystem and payload platform utilize a high-speed SpaceWire bus, achieving speeds of hundreds of Mbps, allowing the application software to reach the payload platform from the ground more quickly. Because NOR FLASH write operations require command execution, their efficiency is low, resulting in slow write speeds, mostly in the hundreds of kbps range. This has become a bottleneck in the application software uploading path. This invention proposes a software-defined satellite rapid reconfiguration method, using a control FPGA as the core, and configuring two large-capacity NOR FLASH (NOR FLASH3 / 4) chips to centrally store the application software of the functional units. The control FPGA transmits the remote control and telemetry signals required by the functional units via a low-speed RS485 dual-bus, and sends the uploaded application software required by the functional units via a high-speed LVDS interface. To improve system reliability and flexibility, an RS485 dual-bus design is implemented, employing the invention: An Adaptive Control Method Based on a Spaceborne RS485 Dual-Bus (Publication No.: CN113726402B). This invention designs a fast write cache + ping-pong pipeline technology to achieve rapid uploading of the APP software. Simultaneously, the APP software stored in NOR FLASH (NOR FLASH3 / 4) utilizes RS(64,56) encoding and decoding technology, possessing a powerful 4-byte error correction capability to ensure high reliability of the functional unit's APP software. The rapid reconfiguration method for the functional unit is as follows... Figure 3 As shown.

[0041] A rapid reconfiguration method based on software-defined satellites includes the following steps:

[0042] S1. When the control FPGA receives the uploading data from the interface, it first writes it to the DRAM buffer in packets, then performs a CRC check. If the CRC check is correct, the data is sent to the back-end encoding module, and the process proceeds to step S2. If the CRC check is incorrect, the buffer is cleared, while the FPGA continues to receive uploading data and reports errors via a telemetry frame counter.

[0043] S2. After receiving 56 bytes of data, RS(64,56) encoding is performed. The encoded data is then extended to 64 bytes, and the process proceeds to step S3.

[0044] S3: After encoding, the data is first stored in buffer FIFO1. When 64 bytes are full, the process switches to buffer FIFO2 to continue writing. Simultaneously, 64 bytes of data are read from buffer 1 and written to one of the NOR FLASH chips using the most efficient write buffer mode for NOR FLASH. A single command can write 64 bytes, which is faster than the conventional 1-byte write operation. After sending 64 bytes of data, the busy / idle flag returned by the chip is checked, and the process proceeds to S4. Each write operation to the NOR FLASH must be performed according to the block address, and the block address and frame counter must match. Steps S3 and S4 are a ping-pong operation until the APP software is fully written, at which point the process exits.

[0045] Steps S4 and S4 are the same as S3. When FIFO2 is full, 64 bytes of data are read at a time, and data is written to another NOR FLASH chip according to the write buffer mode. At the same time, the data encoded by the front-end RS is written to FIFO1. After sending 64 bytes of data to the NOR FLASH, the busy / idle flag returned by the chip is queried, and then S3 is entered. Steps S4 and S3 are ping-pong operations until the APP software is written and then exit.

[0046] S5. After the satellite is powered on, each functional unit loads from its own configuration circuit by default. Each functional unit can be loaded through its own configuration circuit or by controlling the FPGA. Upon receiving the FPGA loading control switching command from the interface circuit, proceed to step S6.

[0047] S6. Control the FPGA to read the APP software data stored in NOR FLASH3 and NOR FLASH4 page by page, then proceed to step S7. Since the APP data is written to the NOR FLASH using a ping-pong operation, the data is read first from NOR FLASH3, then from NOR FLASH4, reading 64 bytes at a time, repeating this process until the APP software for the corresponding functional unit is read. Because the power-on status of each functional unit differs in each operating mode, this step requires selecting the appropriate area from the NOR FLASH to read based on the different operating condition instructions.

[0048] S7. After the APP data is read from the NOR FLASH, it is written to the DRAM cache. Once 64 bytes are filled, the data is read out all at once for RS(64,56) decoding. The decoding module needs to determine the correctness of the data. If the data exceeds the decoding capability, the transmission to the functional unit is stopped, and the process jumps to the next functional unit area in S6. If no error is detected, or if there is an error but it is within the decoding capability, the decoded data is sent to the functional unit, subsequent read operations are performed, and the process proceeds to step S8. Regardless of whether the decoding is correct or not, the system inserts the result into the telemetry data and transmits it back to the ground.

[0049] S8. The FPGA can control the decoded data to be distributed and stored in each functional module via RS485 bus, or it can be directly loaded into each functional module via high-speed LVDS interface.

[0050] The distribution diagram of APP software stored in NOR FLASH3 and NOR FLASH4 is as follows: Figure 4 As shown.

[0051] The software-defined satellite minimum safety system and rapid reconfiguration method proposed in this invention were comprehensively verified in the integrated data processor of the Chang'e-7 relay satellite. First, a test environment was established, using one computer to simulate the satellite service demodulation equipment, a dedicated ground inspection system to simulate the satellite service subsystem, and the integrated data processor as the payload platform. Communication between the computer and the dedicated ground inspection system was via a gigabit Ethernet port, while communication between the dedicated ground inspection system and the payload platform was simulated via CAN bus and SpaceWire bus. The test environment is as follows. Figure 5 As shown.

[0052] The present invention is verified according to two main functions: the first function is to verify the minimum security system, and the second function is to verify the system's rapid reconfiguration function.

[0053] Minimum Safety System Verification: After receiving the FPGA's own APP software from the CPU, the control FPGA writes it into NOR FLASH2 using Hamming code (72,64) + triple modulo redundancy. Upon system power-up, the ACTEL / ASIC refresh and reconfiguration circuit reads the APP software from NOR FLASH2 by default, completing the loading of the control FPGA. Testing showed that the control FPGA operates normally after power-up. When erroneous data is added to NOR FLASH2, and the number of errors is within the Hamming code and triple modulo redundancy error correction range, the control FPGA still loads successfully. When the added erroneous data exceeds the error correction range, the control FPGA loading fails. After approximately 3 seconds, the control FPGA loads successfully. This test shows that the ACTEL / ASIC refresh and reconfiguration circuit automatically switches from NOR FLASH2 to PORM2 to complete the loading of the control FPGA. At this point, the control FPGA runs the minimum system software and can normally receive the uploaded data and perform basic remote control and telemetry functions. Finally, the minimum system completes the APP software update in NOR FLASH2.

[0054] The system's rapid reconfiguration function: The control unit receives the framed functional unit APP software from a dedicated ground-based detection and relay computer via the CAN bus and stores it in NOR FLASH3 / 4 according to RS encoding. Testing showed that, using the CAN bus at full speed of 500kbps with the frame interval minimized (effective rate close to 500kbps), uploading one set of APP software to the V7 FPGA took approximately 10 minutes, three times faster than the current uploading time. Using the SpaceWire bus at 100Mbps with the frame interval increased (effective rate 1Mbps), uploading one set of APP software to the V7 FPGA took approximately 5 minutes, six times faster than the current uploading time. This significantly shortens the on-orbit update time of the APP software, improving satellite utilization efficiency and flexibility. After the APP software update, a system reload command is sent, and the functional units operate normally. Simultaneously, manual modification of the APP data in NOR FLASH3 / 4 according to orbital irradiance measurements resulted in normal functional unit loading, and telemetry displays reported successful RS error correction.

[0055] The designed CPU+FPGA+ACTEL / ASIC+PROM+NOR FLASH minimum safety system architecture features FPGA loading via NOR FLASH2 by default, with on-orbit injection capability to ensure the flexibility of the control center. In the event of a NOR FLASH2 loading failure, the system can automatically switch to PROM2 to complete the loading of basic functions, ensuring the high reliability and security of the software-defined satellite. A high-rate Hamming code (72,64) + triple-modulus redundancy design ensures strong single-event upset resistance for the control center APP software of the software-defined satellite in orbit. A centralized storage management system for functional unit APPs is designed, allowing the control unit to centrally store the APP software of functional units and enabling injection and fast loading of each functional unit. Leveraging the fast write mode characteristics of NOR FLASH, the APP software stored in NOR FLASH3 / 4 is encoded and decoded using RS(64,56) encoding, ensuring high on-orbit reliability of the APP software. Furthermore, the injection process employs a fast write caching mode + ping-pong pipeline technology, significantly shortening the APP software injection time and improving the satellite's rapid reconfiguration capability.

[0056] This invention proposes a software-defined satellite minimum safety system and rapid reconfiguration method, which ensures high reliability and flexibility of satellite on-orbit reconfiguration, while shortening APP uploading time and improving satellite application efficiency. The system has been verified to be stable and reliable and is currently being used on a satellite data processor, and will be promoted and applied in many remote sensing and communication satellite models.

[0057] The contents not described in detail in this specification are common knowledge to those skilled in the art.

[0058] Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make possible changes and modifications to the technical solutions of the present invention by utilizing the methods and techniques disclosed above without departing from the spirit and scope of the present invention. Therefore, any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solutions of the present invention shall fall within the protection scope of the technical solutions of the present invention.

Claims

1. A flexible spaceborne minimum safety system, characterized in that, This includes CPU circuits with operating systems, control FPGA circuits, ACTEL / ASIC refresh and reconfiguration circuits, PROM, and NOR FLASH. The CPU circuit with an operating system is used to read the boot program from the PROM to complete the initialization configuration, for data reception and parsing, and for external bus control. There are two PROMs: one is used to store the boot program of the CPU circuit with the operating system, namely PROM1, and the other is used to store the configuration program for the minimum startup of the FPGA, namely PROM2. When the FPGA control circuit fails to load, the ACTEL / ASIC refresh and reconfiguration circuit reads the minimum startup configuration program for the FPGA control from PROM2. A separate PROM2 circuit is used and externally connected to the ACTEL / ASIC. If the software read from the NOR FLASH flips after the system is powered on, and there is still an error after Hamming code (72,64) + triple modulo redundancy, then the ACTEL / ASIC automatically switches to PROM2 to read based on the FPGA loading failure signal. NOR FLASH is used to store software that is updated in orbit; the software stored in NOR FLASH uses the RS(64,56) encoding and decoding method and has 4 bytes of error correction capability. The FPGA circuit is used as an actuator to distribute remote control commands, collect telemetry data, and control the updating and storage of the uploading software. The ACTEL / ASIC refresh and reconfiguration circuit is used to manage the configuration files for controlling the FPGA circuit. By default, it reads the software from the NOR FLASH to complete the loading of the FPGA circuit.

2. The spaceborne minimum safety system according to claim 1, characterized in that, PROM is an antifuse type device that is immune to single particles.

3. The spaceborne minimum safety system according to claim 1, characterized in that, NOR FLASH uses Hamming code and multimodal redundancy for data storage.

4. The spaceborne minimum safety system according to claim 1, characterized in that, The onboard minimum safety system also includes an interface circuit, through which the control FPGA circuit transmits data with external units.

5. The spaceborne minimum safety system according to claim 1, characterized in that, The FPGA acts as the actuator of the control unit. It needs to perform different functions in orbit according to different application scenarios. It has reconfigurability in orbit and implements different control functions through software stored in NOR FLASH.

6. The spaceborne minimum safety system according to claim 1, characterized in that, NOR FLASH employs triple redundancy, taking advantage of the principle that the probability of errors occurring simultaneously on the same set of hardware units is lower than the probability of errors occurring on a single hardware unit, and using a majority decision of two out of three to determine the correct output.

7. A rapid reconfiguration method based on the spaceborne minimum safety system according to any one of claims 1 to 6, characterized in that, include: S1. When the control FPGA circuit receives the uploading data from the interface, it first writes it into the DRAM buffer in packets, and then performs CRC verification. If the CRC verification is correct, proceed to step S2; if the CRC verification is incorrect, clear the buffer, continue to receive uploading data, and report the error frame counter through telemetry. S2. After receiving 56 bytes of data, RS(64,56) encoding is performed. The encoded data is then extended to 64 bytes, and the process proceeds to step S3. S3. The encoded data is first stored in buffer FIFO1. When 64 bytes are written, the operation switches to buffer FIFO2 to continue writing. At the same time, 64 bytes of data are read from buffer FIFO1 and written to one of the NOR FLASH chips according to the most efficient write buffer mode of NOR FLASH. When buffer FIFO2 is full, 64 bytes of data are read at a time and written to the other NOR FLASH chip according to the most efficient write buffer mode of NOR FLASH. At the same time, the encoded data is written to buffer FIFO1. This ping-pong operation continues until the software is written and the process exits. Each time 64 bytes of data are sent, the busy / idle flag returned by the NOR FLASH is queried. S4. After the satellite is powered on, the satellite's functional units complete the loading from their respective units or are loaded through the control FPGA; when the control FPGA receives the switching control FPGA loading instruction sent by the satellite staff, it proceeds to step S6. S6. Control the FPGA circuit to read the software data stored in the NOR FLASH page by page, and then proceed to step S7; S7. Control the FPGA to send configuration programs to the functional units of the satellite to complete the loading of each functional unit. First, control the FPGA to read the configuration program from NOR FLASH3 and NOR FLASH4 and write it into the DRAM cache. After storing 64 bytes, read it out all at once for RS(64,56) decoding. The decoding module needs to judge the correctness of the data. If it detects that the decoding capability is exceeded, stop sending to the functional unit, that is, end the sending of configuration data to the current functional unit, and jump to the next functional unit in S6. If no error is detected or there is an error but it is within the decoding capability, send the decoded data to the functional unit. After the current functional unit's sending action is completed, jump to the next functional unit's sending action until all functional units have completed sending action, and then go to step S8. S8 controls the FPGA circuit to upload the decoded data to each functional unit for independent storage, or to directly load the data to each functional unit via an interface.

Images