Software reinforcement method of satellite software system

Abstract

The invention relates to the technical field of software reinforcement, and provides a software reinforcement method for a satellite software system, which comprises the following steps of: identifying the core number of a multi-core CPU (Central Processing Unit) by an application bootstrap program, and starting a plurality of applications to be reinforced according to the core number of the CPU; when a plurality of to-be-reinforced applications are started, determining a master process and one or more slave processes from a plurality of business processes corresponding to the plurality of to-be-reinforced applications by an application bootstrap program, and binding the plurality of to-be-reinforced applications to a plurality of different CPU cores; adding check point functions in the plurality of business processes, wherein input parameters of the check point functions are parameters needing to be compared; and determining whether all the to-be-reinforced applications run normally or not by using the input parameters, and if not, using a corresponding repair method according to the number of the to-be-reinforced applications. Normal operation of the to-be-reinforced application is ensured by adopting corresponding repairing methods according to different conditions, so that the stack data and the global data in the process can be quickly recovered to be normal when single event upset occurs.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of software reinforcement, in particular to a software reinforcement method for a satellite software system. BACKGROUND

[0002] With the rapid development of space technology, the use of commercial off-the-shelf (COTS) components such as CPUs, SoCs, FLASHs and DDRs can significantly reduce the cost of satellites, shorten the development time of satellites and improve the performance of satellites. In low earth orbit, the residual atmosphere and the earth's magnetic field can provide certain radiation protection, but this absorption effect will rapidly decrease with the increase of altitude. Generally, the commercial off-the-shelf (COTS) components are prone to single event upset effect in orbit, which brings challenges to the reliability and safety of satellite operation in orbit. The conventional anti-single event upset is mainly achieved by selecting anti-radiation devices, redundant design of hardware circuits or adding some anti-radiation shielding materials. The single event upset effect can destroy the logic operation and cause the bit flip in the data storage unit and the connection circuit. In particular, when the single event upset occurs in the internal module of the CPU, it can cause the software to run dead or abnormally, which brings hidden dangers to the safety of the satellite. SUMMARY

[0003] The application aims to provide a software reinforcement method for a satellite software system. According to the number of cores of a multi-core CPU, two or three to-be-reinforced applications are run. Every interval of a program is used to determine whether the to-be-reinforced applications are normally run. When part of the to-be-reinforced applications are not normally run, the process rollback or 3-to-2 fast recovery or the restart of the to-be-reinforced applications is used according to the total number of to-be-reinforced applications and the number of to-be-reinforced applications that are not normally run, so as to ensure that the to-be-reinforced applications are normally run. The application can quickly recover to normal when the single event upset occurs.

[0004] The application provides a software reinforcement method for a satellite software system, which comprises the following steps: The number of cores of a multi-core CPU is identified by an application boot program, and a plurality of to-be-reinforced applications are started according to the number of cores of the CPU. When the number of cores of the CPU is 2, two to-be-reinforced applications that are the same are simultaneously started. When the number of cores of the CPU is greater than or equal to 3, three to-be-reinforced applications that are the same are simultaneously started. When the plurality of to-be-reinforced applications are started, a master process and one or more slave processes are determined from a plurality of business processes corresponding to the plurality of to-be-reinforced applications by the application boot program, and the plurality of to-be-reinforced applications are bound to a plurality of different CPU cores. A checkpoint function is added in the plurality of business processes. The input parameter of the checkpoint function is a parameter that needs to be compared. Determine whether all the to-be-strengthened applications are normally running using the input parameters, and if not, use a corresponding repair method according to the number of to-be-strengthened applications, wherein: for 2 to-be-strengthened applications, use the method of all business processes rollback or restarting the to-be-strengthened applications for repair; for 3 to-be-strengthened applications, if one of the to-be-strengthened applications is not normally running, use the input parameters of the corresponding business processes of the other two to-be-strengthened applications to repair the input parameters of the business processes of the to-be-strengthened application that is not normally running, and if the number of to-be-strengthened applications that are not normally running is greater than 1, use the method of all business processes rollback or restarting the to-be-strengthened applications for repair.

[0005] Further, the abnormal running of the to-be-strengthened application includes single event upset; and The plurality of business processes call a checkpoint function every period, put the parameters to be compared into indefinite parameters, the checkpoint function has process synchronization function inside, each process waits at the same checkpoint, when each business process enters the same checkpoint, compare each parameter through atomic lock and shared memory mode.

[0006] Further, the master process obtains the data information of the input parameters of each slave process through atomic lock and shared memory mode, compares the input parameters at the corresponding positions, and confirms whether the input parameters are consistent, if the input parameters corresponding to all business processes are equal, it indicates that each to-be-strengthened application is normally running.

[0007] Further, when the number of CPU cores is 2, 2 identical to-be-strengthened applications are started at the same time, which corresponds to 2 completely identical business processes; When the number of CPU cores is greater than or equal to 3, 3 identical to-be-strengthened applications are started at the same time, which corresponds to 3 completely identical business processes.

[0008] Further, when the number of CPU cores is 2, 2 to-be-strengthened applications are started, which corresponds to a master process and a slave process, when the input parameters corresponding to the two business processes are consistent, save the current code running context and stack data, and each business process continues to execute; If part of the input parameters corresponding to the two business processes are inconsistent, all business processes rollback to the context position and stack data of the last save point and continue to execute; and If the rollback is triggered continuously for multiple times, notify the application boot program, and all business processes actively exit execution, and the application boot program restarts 2 to-be-strengthened applications.

[0009] Further, when all business processes recover to the last context position and execute to the same position again to trigger the parameter inconsistency exception, notify the application boot program to restart 2 to-be-strengthened applications.

[0010] Further, when the CPU core number is greater than or equal to 3, three to-be-hardened applications are started, corresponding to one master process and two slave processes, when the input parameters corresponding to the three service processes are consistent, the respective service processes continue to execute; When the input parameters corresponding to two service processes are consistent, and the input parameters corresponding to the other service process are inconsistent, it indicates that one to-be-hardened application is not normally running, the input parameters of the service process corresponding to the to-be-hardened application are repaired using the input parameters of the service processes corresponding to the other two normally running to-be-hardened applications, after the repair, the three service processes continue to execute; When the input parameters corresponding to the three service processes are all different, it indicates that the number of to-be-hardened applications not normally running is greater than 1, all service processes rollback to the context position and stack data of the last saved point, and then continue to execute; If the rollback is triggered continuously for multiple times, the application boot program is informed, the service processes are all actively exited from execution, and the application boot program restarts the three to-be-hardened applications.

[0011] Further, when all service processes are restored to the last context position and execute to the same position again, and the parameter inconsistency exception is triggered again, the application boot program is informed to restart the three to-be-hardened applications.

[0012] Further, when an IO operation interface function is executed, the master process normally executes the IO operation interface function, and the execution result is synchronized to the slave process through a shared memory mode, and the slave process waits for the execution result of the master process during the execution of the master process.

[0013] Further, the application boot program further comprises the following steps of: The application boot program periodically reports the state of the service process to the application boot program, and the application boot program performs keep-alive on the to-be-hardened applications through the state message, when the state message of one of the to-be-hardened applications is abnormal, the application boot program actively closes all to-be-hardened applications, and restarts the to-be-hardened applications.

[0014] The application has at least the following beneficial effects: According to the number of cores of the multi-core CPU, two or three to-be-hardened applications are run, corresponding to two or three completely same service processes, the service processes call a checkpoint function every period, when all processes enter the same checkpoint, whether all to-be-hardened applications are normally running is determined by comparing whether the parameters are consistent through a shared memory mode, when two or three to-be-hardened applications are not all normally running, process rollback or 3-to-2 fast recovery or restarting the to-be-hardened applications are adopted according to different situations to ensure that the to-be-hardened applications are normally running, so that when the stack data and global data in the process appear single event upset, the process can be quickly recovered. The application binds multiple applications to be reinforced to multiple different CPU cores, when a single event upset is triggered inside a CPU, an exception can be found at any time, and abnormal data is prevented from affecting subsequent processes. BRIEF DESCRIPTION OF DRAWINGS

[0015] To further clarify the above and other advantages and features of the present embodiments, a more particular description of embodiments of the application will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the application and are therefore not to be considered limiting of its scope. The same or corresponding elements in the drawings are denoted by the same or similar reference signs.

[0016] Figure 1 A flow chart of a software reinforcement method of a satellite software system is shown according to an embodiment of the application.

[0017] Figure 2 A schematic diagram showing an application boot program APP_LOADER booting a service process of a dual-core system is shown according to an embodiment of the application.

[0018] Figure 3 A schematic diagram showing an application boot program APP_LOADER booting a service process of a triple-core system is shown according to an embodiment of the application.

[0019] Figure 4 A schematic diagram showing a synchronization mode between multiple service processes is shown according to an embodiment of the application.

[0020] Figure 5 A schematic diagram showing an access IO operation is shown according to an embodiment of the application. DETAILED DESCRIPTION

[0021] It should be noted that the components in the drawings can be exaggerated for illustrative purposes and are not necessarily to scale.

[0022] In the present application, the embodiments are merely intended to illustrate the solutions of the present application and should not be understood as limiting.

[0023] In the present application, the quantifier "one", "a" does not exclude the scenario of multiple elements, unless specifically indicated.

[0024] It should also be noted herein that, in the embodiments of the present application, only a part of components or assemblies can be shown for clarity and simplicity, but those skilled in the art can understand that, under the teaching of the present application, the required components or assemblies can be added according to the specific scene needs.

[0025] It should also be noted that, in the scope of the present application, the expressions "same", "equal", "equal to" and the like do not mean that the two values are absolutely equal, but allow a certain reasonable error, that is, the expressions also cover "substantially same", "substantially equal", "substantially equal to".

[0026] It should also be noted that, in the description of the present application, the terms "center", "longitudinal", "transverse", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer" and the like indicate the orientation or positional relationship shown in the drawings, which are only for the convenience of describing the present application and simplifying the description, and do not mean that the devices or elements referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as limiting the present application. In addition, the terms "first" and "second" are only for descriptive purposes and cannot be understood as indicating relative importance.

[0027] In addition, the embodiments of the present application describe the process steps in a specific order, but this is only for the convenience of distinguishing between steps and is not limited to the order of the steps. In different embodiments of the present application, the order of the steps can be adjusted according to the adjustment of the process.

[0028] If a single event upset event is triggered inside the CPU during the running of a satellite software application based on a Linux system, it may cause various exceptions such as data segment exception and code segment exception during the execution of the application, and the software will fail to run.

[0029] The prior art is to reinforce the FPGA or hardware circuit against single event upset, and some technologies are to compare and verify part of the static data in the form of 3-to-2, and when the CPU executes the application and an exception occurs, it can only be solved by restarting the process or restarting the operating system, which increases the system recovery time. The present application provides a software reinforcement method for a satellite software system against single event upset of a multi-core CPU.

[0030] Figure 1 A flowchart of a software reinforcement method for a satellite software system according to an embodiment of the present application is shown. Figure 2 A schematic diagram of an application boot program APP_LOADER booting a business process according to a dual-core system of an embodiment of the present application is shown. Figure 3 A schematic diagram of an application boot program APP_LOADER booting a business process according to a triple-core system of an embodiment of the present application is shown. Figure 4 A schematic diagram of a synchronization mode between a plurality of business processes according to an embodiment of the present application is shown. Figure 5A schematic diagram of an access IO operation according to one embodiment of the present application is shown.

[0031] The present application is directed to a multi-core CPU system, including 2, 3 and more processor cores, running Linux operating system in SMP (Symmetric Multi-Processing) mode. In SMP system, multiple processor cores share the same operating system instance, all cores are treated as equal entities, equally accessing memory, I / O devices and other system resources. After Linux system is started, an application loader (APP_LOADER) is started. The application loader identifies the number of cores of the CPU, and starts software reinforcement function for CPU with core number no less than 2.

[0032] As shown in Figure 1 , a software reinforcement method of satellite software system includes the following steps: Step 1, the application loader identifies the number of cores of the multi-core CPU, and starts multiple applications to be reinforced according to the number of cores of the CPU. When the number of CPU cores is 2, 2 identical applications to be reinforced are started simultaneously, corresponding to 2 identical service processes; when the number of CPU cores is greater than or equal to 3, 3 identical applications to be reinforced are started simultaneously, corresponding to 3 identical service processes. The multiple applications to be reinforced execute the same version file.

[0033] Step 2, when the multiple applications to be reinforced are started, the application loader determines a master process and one or more slave processes from the multiple service processes corresponding to the multiple applications to be reinforced, and binds the multiple applications to be reinforced to multiple different CPU cores. One application to be reinforced corresponds to one service process. The application to be reinforced corresponding to the master process is the master application to be reinforced, and the application to be reinforced corresponding to the slave process is the slave application to be reinforced. One application to be reinforced is bound to one CPU core.

[0034] Specifically, when the application to be reinforced is started, the application loader informs the current service process whether it is a master process or a slave process through parameters, and informs the application to be reinforced which core it needs to run on.

[0035] Step 3, after the application to be reinforced is started by the application loader, the keep-alive of the multiple applications to be reinforced is performed.

[0036] Specifically, as shown in Figure 2 and 3As shown, after the application boot program (APP LOADER) 101 starts the to-be-hardened applications, the to-be-hardened applications (a master to-be-hardened application (MASTER APP) 102 and one or more slave to-be-hardened applications (SLAVE APP) 103) are kept alive, and the application boot program can discover the abnormality at any time. Each to-be-hardened application periodically reports the state (that is, the keep-alive information) of the business process to the application boot program, and the application boot program keeps the to-be-hardened application alive through the state message. When the state message of one of the to-be-hardened applications is abnormal, the application boot program actively closes all to-be-hardened applications and reboots the to-be-hardened applications.

[0037] Step 4: A checkpoint function is added in the multiple business processes, the input parameters of the checkpoint function are the parameters that need to be compared, and whether all the to-be-hardened applications are normally running is determined by using the input parameters. If not, a corresponding repair method is used according to the number of to-be-hardened applications, wherein: for two to-be-hardened applications, the method of rolling back or restarting the to-be-hardened applications is used for repair; for three to-be-hardened applications, if one of the to-be-hardened applications is not normally running, the input parameters of the business process corresponding to the to-be-hardened application that is not normally running are repaired using the input parameters of the business process corresponding to the other two to-be-hardened applications, and if the number of to-be-hardened applications that are not normally running is greater than 1, the method of rolling back or restarting the to-be-hardened applications is used for repair.

[0038] In one embodiment, the abnormal running of the to-be-hardened application includes single event upset.

[0039] A checkpoint function is added in the multiple business processes, the input parameters of the checkpoint function are the parameters that need to be compared, and the checkpoint function is used as a basis for judging whether the business process of each to-be-hardened application is executed abnormally. In programming, the input parameters of the checkpoint function refer to the data or conditions passed to it when the checkpoint function is called. These parameters are used to check at key nodes of program execution to ensure that the business process meets expectations.

[0040] The multiple business processes call the checkpoint function: SEU_Check(int CheckID, int Count,...) every certain period of time, put the parameters that need to be compared into the indefinite parameters, and the checkpoint function has a process synchronization function inside. Each process waits at the same checkpoint (CheckID). When each business process enters the same checkpoint, the parameters of each process are compared for consistency through atomic locks and shared memory.

[0041] As Figure 4As shown, each to-be-strengthened application corresponds to a business process, and the business processes of the to-be-strengthened applications are synchronized through atomic operations and shared memory, and the data is exchanged through shared memory. Shared memory is a technology that allows multiple processes (such as a master process and a slave process) to directly access the same memory region, and is a way of efficiently transferring data between processes. An atomic lock is a synchronization mechanism used to ensure that an operation cannot be divided, and the purpose is to prevent chaos when multiple processes operate on the same resource (such as data in shared memory) at the same time.

[0042] In one embodiment, the master process corresponding to the master to-be-strengthened application 102 obtains the input parameter data information of the slave processes corresponding to the slave to-be-strengthened applications 103 through atomic locks and shared memory, compares the input parameters at the corresponding positions, and confirms whether the input parameters are consistent. If the input parameters of all business processes are equal, it indicates that the to-be-strengthened applications are running normally. If the input parameters are inconsistent, the processing methods are different for different numbers of cores, or in other words, the processing methods are different for different numbers of to-be-strengthened applications.

[0043] For a 2-core CPU system, two to-be-strengthened applications are started, one of which is the master to-be-strengthened application 102 and the other is the slave to-be-strengthened application 103, corresponding to a master process and a slave process. When the input parameters of the two business processes are consistent, it indicates that the two to-be-strengthened applications are running normally, the current code running context and stack data are saved, and the business processes continue to execute. If it is found that part of the input parameters are inconsistent, it indicates that the two to-be-strengthened applications are not running normally, and all business processes are rolled back to the context position and stack data of the last save point, and then continue to execute. If the rollback is triggered continuously for multiple times, the application boot program is notified, and all business processes actively exit execution, and the application boot program restarts the two to-be-strengthened applications. That is, when all business processes recover to the last context position and execute to the same position again, triggering the parameter inconsistency exception, the application boot program is notified to restart the two to-be-strengthened applications.

[0044] As shown, Figure 4 For a 3-core or more CPU system, three to-be-strengthened applications are started, one of which is the master to-be-strengthened application 102 and the other two are the slave to-be-strengthened applications 103, corresponding to a master process and two slave processes. When the input parameters of the three business processes are consistent, it indicates that the three to-be-strengthened applications are running normally, and the business processes continue to execute. When the input parameters of two business processes are consistent and the input parameters of the other business process are inconsistent, it indicates that one of the to-be-strengthened applications is not running normally. At this time, the 3-of-2 method is used to recover, that is, the input parameters of the business process of the to-be-strengthened application that is not running normally are repaired using the input parameters of the business processes of the two to-be-strengthened applications that are running normally. After the repair, the three business processes continue to execute.

[0045] When the partial input parameters corresponding to the three service processes are all different, all the service processes fall back to the context position and stack data of the last save point, and then continue to execute. If the fallback is triggered continuously for multiple times, the application director is notified, and the service processes actively exit the execution, and the application director restarts the three to-be-hardened applications. That is, when all the service processes recover to the last context position and execute to the same position again, and the parameter inconsistency exception is triggered, the application director is notified to restart the three to-be-hardened applications.

[0046] As shown in Figure 5 All functions of accessing IO operations are only executed in the master process. When the IO operation such as accessing hardware occurs in the process, the master process normally performs the access, and synchronizes the access result to the slave process through shared memory. The slave process is in a waiting state during the IO access of the master process.

[0047] Two to-be-hardened applications are started, corresponding to two service processes, and the processes are divided into master and slave processes; three to-be-hardened applications are started, corresponding to three service processes, and the processes are divided into master, slave and slave processes. The service process corresponding to the master to-be-hardened application 102 is the master process, and the service process corresponding to the slave to-be-hardened application 103 is the slave process. Since all the processes execute the same version file, when the IO operation interface function is executed, the master process normally executes the IO operation interface function, synchronizes the execution result to the slave process through shared memory and the like, and the slave process waits for the execution result of the master process during the execution of the master process, to prevent the IO operation from being executed multiple times.

[0048] The software hardening method of the application hardens the program code flow of the SMP system and quickly repairs the exception. The service process is bound to the CPU core for running, when single event upset is triggered in a CPU, the exception can be found at any time, and the exception is quickly repaired to prevent the abnormal data from affecting the subsequent flow. When single event upset occurs in the stack data and global data in the process, the running result of the other process can be used for 3-to-2 repair, to achieve quick repair of the exception.

[0049] The same business program version starts different to-be-hardened applications (MASTER_APP and one or more SLAVE_APP), the data consistency is ensured through data verification of the check points between the multiple to-be-hardened applications, and the master and slave processes are kept in synchronous running through corresponding technologies. The master and slave processes are bound to different CPU cores, and the operating system (application director) schedules the master and slave processes to run on different cores without affecting each other.

[0050] Other variant solutions, the system does not limit the number of running business processes, if the system runs multiple different business processes, multiple groups of business processes are started, each process is bound to a specific CPU core, one of the business processes in a group is the master process, and the other business processes are slave processes. A checkpoint can be set in a certain thread of the business process, and the process setting checkpoint processing logic is consistent with the description of the above technical solutions.

[0051] While some embodiments of the application have been described above, it is understood that they have been presented by way of example only. Numerous variations, changes, and substitutions will occur to those skilled in the art without departing from the scope of the application. It is therefore intended that the appended claims cover all such variations as fall within the scope of the application.

Claims

1. A method for hardening a satellite software system, characterized in that, Includes the following steps: The application bootloader identifies the number of cores in a multi-core CPU and launches multiple applications to be hardened based on the number of CPU cores. Specifically: when the number of CPU cores is 2, two identical applications to be hardened are launched simultaneously; when the number of CPU cores is greater than or equal to 3, three identical applications to be hardened are launched simultaneously. When multiple applications to be hardened are started, the application bootloader determines a master process and one or more slave processes from the multiple business processes corresponding to the multiple applications to be hardened, and binds the multiple applications to be hardened to multiple different CPU cores; Add checkpoint functions to multiple business processes, with the input parameters of the checkpoint functions being the parameters to be compared; and The input parameters are used to determine whether all applications to be reinforced are running normally. If not, the corresponding repair method is used according to the number of applications to be reinforced. Specifically: for two applications to be reinforced, the method of rolling back or restarting all business processes of the applications to be reinforced is used for repair; for three applications to be reinforced, if one of the applications to be reinforced is not running normally, the input parameters of the business processes corresponding to the other two applications to be reinforced are used to repair the input parameters of the business processes corresponding to the non-running applications to be reinforced. If the number of non-running applications to be reinforced is greater than one, the method of rolling back or restarting all business processes of the applications to be reinforced is used for repair.

2. The software hardening method for a satellite software system according to claim 1, characterized in that: The abnormal operation of the application to be hardened includes single-particle flips; and Multiple business processes call the checkpoint function at regular intervals, putting the parameters to be compared into variable parameters. The checkpoint function has process synchronization functionality, with each process waiting at the same checkpoint. When all business processes enter the same checkpoint, they compare whether the parameters are consistent with each other through atomic locks and shared memory.

3. The software hardening method for a satellite software system according to claim 2, characterized in that, The main process obtains the input parameter data information of each slave process through atomic locks and shared memory, compares the input parameters at corresponding positions, and confirms whether the input parameters are consistent. If the input parameters corresponding to all business processes are equal, it means that each application to be hardened is running normally.

4. The software hardening method for a satellite software system according to claim 2, characterized in that, When the number of CPU cores is 2, two identical applications to be hardened are launched at the same time, which corresponds to two completely identical business processes; When the number of CPU cores is greater than or equal to 3, three identical applications to be hardened will be launched simultaneously, which corresponds to three completely identical business processes.

5. The software hardening method for a satellite software system according to claim 3, characterized in that, When the number of CPU cores is 2, two applications to be hardened are started, corresponding to one main process and one slave process. When the input parameters corresponding to the two business processes are consistent, the current code execution context and stack data are saved, and each business process continues to execute. If the input parameters of two business processes are inconsistent, all business processes will roll back to the context and stack data of the previous save point and continue execution. as well as If the rollback is triggered multiple times in a row, the application bootstrap program will be notified, all business processes will automatically exit execution, and the application bootstrap program will restart the two applications to be hardened.

6. The software hardening method for a satellite software system according to claim 5, characterized in that, When all business processes return to the previous context and execute to the same location again, triggering a parameter inconsistency exception, the application bootstrap program is notified to restart the two applications to be hardened.

7. The software hardening method for a satellite software system according to claim 3, characterized in that, When the number of CPU cores is greater than or equal to 3, 3 applications to be hardened are started, corresponding to one main process and two slave processes. When the input parameters corresponding to the 3 business processes are consistent, each business process continues to execute. When the input parameters of two business processes are the same, and the input parameters of another business process are different, it indicates that one application to be reinforced is not running normally. The input parameters of the business processes corresponding to the other two normally running applications to be reinforced are used to repair the input parameters of the business process corresponding to the abnormal application to be reinforced. After repair, the three business processes continue to execute. When the input parameters corresponding to the three business processes are different, it indicates that the number of abnormal applications to be hardened is greater than 1. All business processes will roll back to the context position and stack data of the previous save point and then continue to execute. If the rollback is triggered multiple times in a row, the application bootstrap program will be notified, all business processes will automatically exit execution, and the application bootstrap program will restart the three applications to be hardened.

8. The software hardening method for a satellite software system according to claim 7, characterized in that, When all business processes return to the previous context and execute to the same location again, triggering a parameter inconsistency exception, the application bootstrap program is notified to restart the three applications to be hardened.

9. The software hardening method for a satellite software system according to claim 1, characterized in that, Also includes: When the I / O operation interface function is executed, the main process executes the I / O operation interface function normally and synchronizes the execution result to the slave process through shared memory. During the execution of the main process, the slave process waits for the execution result of the main process.

10. The software hardening method for a satellite software system according to claim 1, characterized in that, Also includes: After the application bootloader starts the application to be hardened, it keeps multiple applications alive, including: Each application to be hardened periodically reports the status of its business process to the application bootstrap program. The application bootstrap program keeps the applications to be hardened alive through status messages. When the status message of one of the applications to be hardened is abnormal, the application bootstrap program actively closes all the applications to be hardened and restarts them.

Images