Spacecraft software dynamic refreshing reliability protection method

Abstract

This invention provides a dynamic refresh reliability protection method for spacecraft software. Based on a multi-core processor, a dedicated monitoring and refresh processor is designed to dynamically monitor and refresh the software's runtime program area. This reduces the probability of the program area being overwritten by single-event events and erroneous data, without affecting the execution of original functions, while also reducing the possibility of software failure. This invention expands the reliability protection schemes related to aerospace multi-core processors and has significant value for the development of integrated control and health management software in the spacecraft field. This invention improves the problems of low reliability, susceptibility to single-event events, and difficulty in fault location of traditional spacecraft CPU software. It realizes health management functions, significantly improving the reliability of software products. By designing a dedicated dynamic monitoring and refresh processor in a multi-core processor architecture, this invention achieves parallel computing through multiple cores without interrupting the original software's running state, saving additional time consumption and improving software performance.

Description

Technical Field

[0001] This invention relates to the field of control and regulation technology, and specifically to a method for protecting the reliability of spacecraft software dynamic refresh. Background Technology

[0002] With the diversification and increasing sophistication of spacecraft, spacecraft systems are increasingly divided into multiple subsystems and individual units working collaboratively. Each individual unit includes multiple hardware modules, software processor chips, and FPGA programmable logic chips. To achieve flexible loading, configurable parameters, and reconfigurable functions, most data processing, communication, mission management, interface processing, and collaborative control functions are implemented by software or FPGAs. Software and FPGAs can be considered the soul of electronic equipment in spacecraft. The reliable operation of software and FPGAs is crucial for the stable operation of the system, and their protective measures and safety design are key aspects of the spacecraft development process.

[0003] After a spacecraft is launched into orbit, the high-radiation environment of space exposes numerous CPUs, FPGAs, and other chips used on the satellite to high-energy particle radiation, potentially leading to single-event upsets (SEAs). This can cause data errors or even system failure, severely impacting the normal operation of the spacecraft. Traditional radiation hardening methods involve ruggedizing the chip structure, increasing its casing thickness, and altering its manufacturing process. However, this SEA protection technology suffers from high development costs, poor flexibility, and reduced electrical performance. Besides chip hardening, current spacecraft software logic design also incorporates SEA protection measures. For example, designing an antifuse FPGA chip like the AX2000 can address this. Most FPGA chips support dynamic refresh functionality; without interrupting FPGA operation, the antifuse chip can periodically read chip configuration information from external storage media such as Flash memory, dynamically refreshing the FPGA's internal configuration information, reducing the probability of SEAs, and improving product reliability. Additionally, during FPGA chip design, triple-modulus redundancy can be implemented for specific modules, providing reliability protection for the FPGA module during the compilation and placement / routing stages.

[0004] CPUs lack passive refresh capabilities and can only enhance software reliability through methods such as triple-modulus redundancy and EDAC. Additionally, software can utilize a watchdog timer to reset the processor and initialize the software state in abnormal situations. These methods consume CPU serial processing time, impacting real-time performance. Currently, there is no method to continuously monitor and refresh the software program area space to ensure the correctness of its values, thereby guaranteeing software stability.

[0005] Therefore, a method is needed to solve the problem of dynamic monitoring and refreshing of spacecraft software program areas and improve single-event protection capabilities. Summary of the Invention

[0006] This invention addresses the problems of insufficient dynamic monitoring and refreshing of spacecraft software program areas and weak single-event immunity. It provides a dynamic refresh reliability protection method for spacecraft software, based on a multi-core processor. This method utilizes a dedicated processor for monitoring and refreshing, enabling dynamic monitoring and refreshing of the software program area. This reduces the likelihood of program area being overturned by single-event events and erroneous data overwriting, without affecting the execution of original functions, and also reduces the possibility of software failure. Furthermore, this invention expands reliability protection schemes related to aerospace multi-core processors, and has significant value for the development of integrated control and health management software in the spacecraft field. This invention improves upon the problems of low reliability, susceptibility to single-event events, and difficulty in fault location of traditional spacecraft CPU software. It implements health management functions, significantly improving the reliability of software products. By designing a dedicated dynamic monitoring and refreshing processor within a multi-core processor architecture, this invention achieves parallel computing across multiple cores without interrupting the original software operation, saving additional time and improving software performance.

[0007] This invention provides a method for dynamic software refresh reliability protection in spacecraft, comprising the following steps:

[0008] S1. Configure a multi-core processor chip and a FLASH storage chip in the spacecraft's processor. The multi-core processor chip includes a CPU0 processor chip and a CPU1 processor chip. CPU0 runs an application OSApp based on an embedded real-time operating system OS. CPU1 runs an application CPU1App that dynamically monitors and refreshes. The CPU0 processor chip and the CPU1 processor chip can interact.

[0009] S2. Burn the OSApp program, CPU1App program and BOOT program into the FLASH memory chip;

[0010] S3. After power-on, the multi-core processor chip completes initialization, moves the BOOT program from the Flash memory chip to the specified address space of the DDR controller, and configures the multi-core register to start the multi-core processor chip. The CPU0 processor chip and the CPU1 processor chip begin to run in parallel.

[0011] When the S4 CPU0 processor chip is running, the BOOT program reads the OSApp program and CPU1App program from the FLASH memory chip into the DDR controller, then runs the OSApp program in the CPU0 processor chip, and at the same time runs the CPU1App program used for comparison and verification in the CPU1 processor chip.

[0012] S5, CPU1App program compares the OSApp program area in the DDR controller's running space with the OSApp program area stored in the FLASH memory chip and determines whether they are consistent in order to monitor the operating status of the CPU0 processor chip.

[0013] S6. When the CPU1App program finds that the running space and the stored data are inconsistent, it overwrites the OSApp program stored in the FLASH storage chip into the CPU0 processor chip and returns to step S5 to continue monitoring.

[0014] When the CPU1App program finds that the running space and the stored data are consistent, it returns to step S5 to continue monitoring.

[0015] In the preferred embodiment of the spacecraft software dynamic refresh reliability protection method described in this invention, in step S1, the multi-core processor chip integrates four identical LEON4 processing cores, a timer, an interrupt controller, a DDR controller, and a FLASH controller, and both the CPU0 processor chip and the CPU1 processor chip are LEON4 processing cores.

[0016] In a preferred embodiment of the spacecraft software dynamic refresh reliability protection method described in this invention, the DDR controller is mounted in a 256MB storage area following the processor address 0x60000000, and the FLASH storage chip is mounted in an 8MB storage area following the processor address 0.

[0017] In a preferred embodiment of the spacecraft software dynamic refresh reliability protection method described in this invention, after the BOOT program starts first in step S3, the OSApp program is moved from the FLASH storage chip to the 0x60040000 address area of ​​the DDR controller, and the CPU1App program is moved from the FLASH storage chip to the 0x61080000 address area of ​​the DDR controller. A shared memory area shared by the CPU0 processor chip and the CPU1 processor chip is planned for data interaction.

[0018] The spacecraft software dynamic refresh reliability protection method described in this invention, as a preferred embodiment, involves the CPU1 comparing the OSApp program area data at 0x40000 in the FLASH storage chip with the OSApp runtime space data at 0x60040000 in the DDR controller in real time.

[0019] The spacecraft software dynamic refresh reliability protection method of the present invention, as a preferred embodiment, in step S1, the OSApp executable file running on CPU0 includes an interrupt table area, a program area, and a data area; in step S5, CPU1App detection and in step S6, overwriting target the program area and skip the interrupt table area.

[0020] In the preferred embodiment of the spacecraft software dynamic refresh reliability protection method described in this invention, in step S5, CPU1App performs data comparison according to a set time interval.

[0021] The spacecraft software dynamic refresh reliability protection method described in this invention, as a preferred method, has a time interval of 10 seconds.

[0022] The spacecraft software dynamic refresh reliability protection method described in this invention, as a preferred method, has a CPU1App data comparison time of less than 1 second.

[0023] In the spacecraft software dynamic refresh reliability protection method described in this invention, as a preferred embodiment, the CPU0 processor chip and the CPU1 processor chip independently use their own timer resources and interrupt resources.

[0024] The technical solution of this invention is:

[0025] A method for protecting the reliability of spacecraft software dynamic refresh.

[0026] The specific design is based on a multi-core processor architecture, with one dedicated processor serving as a monitoring and refresh processor, and the remaining processors acting as general application processors. These processors operate independently without interfering with each other. The monitoring and refresh processor periodically reads and writes values ​​in the program area of ​​the CPU's runtime space and compares them in real-time with the program data in external memory such as Flash or DRAM. If the values ​​are inconsistent, the CPU program area is considered faulty, possibly due to a single-event event. Measures are then taken to rewrite the erroneous area, ensuring the correctness of the program area data and completing the dynamic monitoring and refresh of the software program area.

[0027] This invention is used for dynamic refresh, health monitoring, single-event recovery, reliability design and development of multi-core processor software in the field of spacecraft. It solves the problems of the inability to dynamically monitor and refresh the software program area of ​​spacecraft and the weak single-event protection capability. It has the advantages of low cost, high real-time monitoring and flexible control.

[0028] The present invention has the following advantages:

[0029] (1) This invention designs a dedicated monitoring and refresh processor based on a multi-core processor, realizing dynamic monitoring and refreshing of the software running program area. This reduces the probability of the program area being overturned by a single particle and erroneous data being overwritten, without affecting the execution of the original functions, and at the same time reducing the possibility of software failure. At the same time, this invention expands the reliability protection schemes related to aerospace multi-core processors, which has great value for the development of integrated control and health management software in the field of spacecraft.

[0030] (2) This invention improves upon the problems of low reliability, susceptibility to single-event knockout, and difficulty in fault location of CPU software in traditional spacecraft. It achieves health management functions, significantly improving the reliability of the software product.

[0031] (3) By designing a dedicated processor for dynamic monitoring and refresh in a multi-core processor architecture, this invention achieves the ability to save extra time and improve software performance through multi-core parallel computing without interrupting the original software running state. Attached Figure Description

[0032] Figure 1 A flowchart of a spacecraft software dynamic refresh reliability protection method;

[0033] Figure 2 A schematic diagram of the dual-core software storage and running space for a spacecraft software dynamic refresh reliability protection method;

[0034] Figure 3 Spatial allocation design diagram for a spacecraft software dynamic refresh reliability protection method;

[0035] Figure 4 A schematic diagram of online loading instructions for a dynamic software refresh reliability protection method for spacecraft;

[0036] Figure 5 A schematic diagram of a software dynamic refresh reliability protection method for spacecraft, showing the burning and solidification mode instructions.

[0037] Figure 6 A schematic diagram illustrating the successful burning and solidification of a dynamic software refresh reliability protection method for spacecraft.

[0038] Figure 7 A diagram showing the segmentation of the OSApp executable file, which is a method for dynamic software refresh reliability protection in spacecraft.

[0039] Figure 8 A schematic diagram of the simulation mode debugging for a spacecraft software dynamic refresh reliability protection method;

[0040] Figure 9 This is a schematic diagram of the multi-core dynamic monitoring software operation log, which is a method for dynamically refreshing reliability protection of spacecraft software. Detailed Implementation

[0041] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0042] Example 1

[0043] like Figure 1 As shown, a method for dynamic software refresh reliability protection in spacecraft is presented. Figure 2 This is a schematic diagram of the dual-core software storage and running space of the present invention, illustrating the distribution and cooperation of the monitoring and refresh dedicated processor, the general application processor, the DDR program area running space, and the external program area storage space.

[0044] The hardware platform for this embodiment is:

[0045] The chip uses the SPARC architecture S698PM processor chip, which integrates four identical LEON4 processing cores, timers, interrupt controllers, DDR controllers, FLASH controllers and other peripheral controllers. At the same time, a FLASH memory chip is deployed on the platform board as the boot storage medium.

[0046] The dynamic monitoring plan is as follows:

[0047] Utilizing the dual cores of the S698 multi-core processor chip, CPU0 runs an application called OSApp, which is based on an embedded real-time operating system (OS). CPU1 runs an application that dynamically monitors refresh rates. Based on the dual-core CPU mode, the BOOT program reads OSApp and CPU1App from FLASH into DDR. The OSApp, which performs the product's business functions, runs on CPU0, while the CPU1App, which monitors refresh rates, runs on CPU1. Its function is to compare and verify the OSApp program area in the DDR runtime space with the OSApp program area stored in FLASH, and monitor the running status of CPU0.

[0048] Unified planning of chip FLASH storage and DDR operating space:

[0049] Space allocation design such as Figure 3 As shown. DDR is mounted in the 256MB memory area following address 0x60000000 of the processor, while FLASH is mounted in the 8MB memory area starting at address 0 of the processor. After the BOOT program starts first, it moves the CPU0 program from FLASH to the 0x60040000 address area of ​​DDR, and moves the CPU1 program from FLASH to the 0x61080000 address area of ​​DDR. A shared memory area for both cores is also planned for data exchange. The function of CPU1 is to compare the OSApp program area data at address 0x40000 in FLASH with the OSApp runtime space data at address 0x60040000 in DDR in real time. If a discrepancy is found, the data in FLASH is immediately overwritten to the corresponding address in DDR.

[0050] Figure 3This is a diagram illustrating the DDR and FLASH space allocation of the dynamic monitoring scheme, showing the running space and storage space information of the three software programs.

[0051] Dual-core debug mode:

[0052] In debug mode, the three applications are downloaded to different regions of the DDR memory, allowing them to run and jump between the three programs on a dual-core processor. In-circuit loading instructions include... Figure 4 As shown.

[0053] Dual-core software burning and hardening:

[0054] After debugging, the three applications were downloaded to different addresses in the FLASH memory to enable the processor to boot. Flash programming instructions were then executed. Figure 5 :

[0055] The serial port log of the FLASH burning process is shown in the figure below. "Download finished" indicates that all three software programs have been successfully burned. Figure 6 .

[0056] Dual-core processor enabled:

[0057] After programming, the processor can bootstrap. Upon power-up, the chip initializes, moves the application program from Flash to the designated address space in DDR, configures the multi-core registers, and starts the multi-core processor to run in parallel. The general application processor performs business functions such as bus control, data parsing, and high-speed calculation.

[0058] Dual-core monitoring program verification address analysis:

[0059] Using the dual-core CPU mode, the BOOT program reads OSApp and CPU1App from FLASH into DDR, runs OSApp in CPU0, and runs the comparison and verification program CPU1App in CPU1. Its function is to compare the program area of ​​OSApp in the DDR running space (skipping the interrupt table area) with the program area of ​​OSApp stored in FLASH (skipping the interrupt table area) and monitor the running status of CPU0.

[0060] The OSApp executable file in this software project is divided into the following sections: Figure 7 As shown.

[0061] Figure 7This is a diagram illustrating the partitioning of the executable file (OSApp) running on the application processor CPU0. It shows that the program consists of an interrupt table area, a program area, and a data area. The interrupt table is modified during program initialization. The program area contains the compiled program code and remains unchanged. The data area stores global variables, which change during program execution. Therefore, dynamic monitoring and refreshing of the software are performed on the .text portion of the program area.

[0062] [1] The programmable binary file size of OSApp (total size of the three regions) is 0x265f0 (approximately 157KB).

[0063] [2] The BOOT transfer size needs to be greater than 0x265f0, and in this example, 0x40000 is used.

[0064] [3] Simulation debugging mode (see Figure 8 You can check that the total size of the OSApp program area and interrupt table is 0x25150 (approximately 152KB).

[0065] [4] CPU1 verification should take the program area size, i.e., the length 0x25150 minus the interrupt table length 0x1000.

[0066] Figure 8 This is a screenshot showing the size of each segment of OSApp in simulation mode. The image shows that the total size of the interrupt table starting at 0x60040000 plus the program area is 0x25150, and the data area size is 0x14b0.

[0067] (9) Analysis of phenomena verified by dual-core monitoring program:

[0068] Designed using the above method, the processor dynamically monitors and refreshes the application area every 10 seconds. The actual software running status is logged via serial port as follows: Figure 9 As shown, both CPU0 and CPU1 are running normally. CPU1 compares and verifies the CPU0 program area with the FLASH every 10 seconds, and the verification passes. Simultaneously, the monitored software program area size is greater than 150KB, and the monitoring and verification time is less than 1 second. This verifies the feasibility and effectiveness of the multi-core dynamic monitoring and refresh scheme.

[0069] Figure 9 This is the runtime log of the multi-core dynamic monitoring software. The log information shows that both CPU0 and CPU1 can independently use their own timer resources, interrupt resources, etc., while CPU1 implements the monitoring and verification functions for the CPU0 program area.

[0070] (10) Based on the above verification results, the following conclusions can be drawn:

[0071] The dedicated monitoring and refresh processor compares the DDR program area with the Flash storage data to complete the functions of anomaly monitoring and erroneous data recovery, enabling dynamic refresh and reliability protection of spacecraft software.

[0072] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for protecting the reliability of spacecraft software dynamic refresh, characterized in that: Includes the following steps: S1. Configure a multi-core processor chip and a FLASH storage chip in the spacecraft's processor. The multi-core processor chip includes a CPU0 processor chip and a CPU1 processor chip. CPU0 runs an application OSApp based on an embedded real-time operating system OS. CPU1 runs an application CPU1App that dynamically monitors and refreshes. The CPU0 processor chip and the CPU1 processor chip can interact. S2. Burn the OSApp program, CPU1App program and BOOT program into the FLASH storage chip; S3. After power-on, the multi-core processor chip completes initialization. After the BOOT program starts first, the OSApp program is moved from the FLASH storage chip to the 0x60040000 address area of ​​the DDR controller, and the CPU1App program is moved from the FLASH storage chip to the 0x61080000 address area of ​​the DDR controller. A shared memory area for CPU0 processor chip and CPU1 processor chip is planned for data interaction, and the multi-core register is configured to start the multi-core processor chip. CPU0 processor chip and CPU1 processor chip start running in parallel. S4. When the CPU0 processor chip is running, the BOOT program reads the OSApp program and the CPU1App program from the FLASH storage chip into the DDR controller, and then runs the OSApp program in the CPU0 processor chip. At the same time, the CPU1App program used for comparison and verification is run in the CPU1 processor chip. S5. CPU1 compares the OSApp program area data at 0x40000 in the FLASH storage chip with the OSApp running space data at 0x60040000 in the DDR controller in real time and determines whether they are consistent in order to monitor the running status of the CPU0 processor chip. S6. When the CPU1App program finds that the running space and the stored data are inconsistent, the OSApp program stored in the FLASH storage chip is overwritten into the CPU0 processor chip, and the process returns to step S5 to continue monitoring. When the CPU1App program finds that the running space and the stored data are consistent, it returns to step S5 to continue monitoring.

2. The spacecraft software dynamic refresh reliability protection method according to claim 1, characterized in that: In step S1, the multi-core processor chip integrates four identical LEON4 processing cores, a timer, an interrupt controller, a DDR controller, and a FLASH controller. Both the CPU0 processor chip and the CPU1 processor chip are LEON4 processing cores.

3. The spacecraft software dynamic refresh reliability protection method according to claim 1, characterized in that: The DDR controller is mounted in the 256MB storage area following the processor address 0x60000000, and the FLASH storage chip is mounted in the 8MB storage area following the processor address 0.

4. The spacecraft software dynamic refresh reliability protection method according to claim 1, characterized in that: In step S1, the OSApp executable file that CPU0 runs includes the interrupt table area, the program area, and the data area; in step S5, CPU1App detection and in step S6, overwriting target the program area and skip the interrupt table area.

5. The spacecraft software dynamic refresh reliability protection method according to claim 1, characterized in that: In step S5, CPU1App performs data comparison according to the set time interval.

6. The spacecraft software dynamic refresh reliability protection method according to claim 5, characterized in that: The time interval is 10 seconds.

7. The spacecraft software dynamic refresh reliability protection method according to claim 5, characterized in that: CPU1App data comparison takes less than 1 second.

8. The spacecraft software dynamic refresh reliability protection method according to claim 1, characterized in that: CPU0 and CPU1 processor chips use their own timer and interrupt resources independently.

Images