Software hardening method for a satellite software system

Abstract

The application relates to the technical field of software reinforcement, and provides a software reinforcement method for a satellite software system, which comprises the following steps: a number of cores of a multi-core CPU is recognized 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 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, input parameters of the checkpoint function are parameters that need to be compared; and whether the plurality of to-be-reinforced applications are all normally operated is determined by using the input parameters, and if not, a corresponding repair method is used according to the number of to-be-reinforced applications. According to different situations, the corresponding repair method is used to ensure that the to-be-reinforced applications are normally operated, so that when single event upsets occur in stack data and global data in the process, the to-be-reinforced applications can be quickly recovered to normal.

Description

TECHNICAL FIELD

[0001] The application relates to the field of software reinforcement technology, 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, FLASH, DDR and the like 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:

[0005] 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.

[0006] 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.

[0007] 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.

[0008] 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 corresponding 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.

[0009] Further, the abnormal running of the to-be-strengthened application includes single event upset; and

[0010] The plurality of business processes call a checkpoint function every program interval, put the parameters that need 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 whether each parameter is consistent through atomic lock and shared memory mode.

[0011] 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.

[0012] 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;

[0013] 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.

[0014] 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;

[0015] 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

[0016] If the rollback is triggered continuously for multiple times, notify the application boot program, all business processes actively exit execution, and the application boot program restarts 2 to-be-strengthened applications.

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

[0018] Further, when the number of CPU cores is greater than or equal to 3, three to-be-hardened applications are started, corresponding to one master process and two slave processes, and when the input parameters corresponding to the three business processes are consistent, the respective business processes continue to execute.

[0019] When the input parameters corresponding to two business processes are consistent and the input parameters corresponding to the other business process are inconsistent, it indicates that one to-be-hardened application is not running normally, and the input parameters of the business process corresponding to the to-be-hardened application that is not running normally are repaired using the input parameters of the business processes corresponding to the other two to-be-hardened applications that are running normally, and after the repair, the three business processes continue to execute.

[0020] When the input parameters corresponding to the three business processes are all inconsistent, it indicates that the number of to-be-hardened applications that are not running normally is greater than 1, and all business processes are rolled back to the context position and stack data of the last save point and then continue to execute.

[0021] If the rollback is triggered continuously for multiple times, the application boot program is informed, and all business processes are actively exited from execution, and the application boot program restarts the three to-be-hardened applications.

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

[0023] 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 during the execution of the master process, the slave process waits for the execution result of the master process.

[0024] Further, the application boot program starts the to-be-hardened applications, and respectively keeps alive the multiple to-be-hardened applications, including:

[0025] Each to-be-hardened application periodically reports the state of the business process to the application boot program, the application boot program keeps alive 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.

[0026] The application has at least the following beneficial effects:

[0027] According to the number of cores of the multi-core CPU, 2 or 3 to-be-hardened applications are run, corresponding to 2 or 3 identical business processes, the business processes call a checkpoint function every interval, when each process enters the same checkpoint, whether each to-be-hardened application is normally run is judged by comparing each parameter through shared memory, when 2 or 3 to-be-hardened applications are not normally run, according to different situations, process rollback or 3-to-2 fast recovery or restarting the to-be-hardened application is adopted to ensure that the to-be-hardened application is normally run, so that when the stack data and global data in the process appear single event upset, the to-be-hardened application can be quickly recovered to normal.

[0028] The application binds multiple to-be-hardened applications to multiple different CPU cores, when single event upset is triggered in a CPU, the abnormality can be found at any time, and abnormal data is prevented from affecting subsequent processes. BRIEF DESCRIPTION OF DRAWINGS

[0029] To further clarify the above and other advantages and features of the embodiments of the present application, a more particular description of embodiments of the application will be rendered by reference to specific 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 drawings will be described with additional specificity and detail in the following description.

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

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

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

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

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

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

[0036] In the present application, the embodiments are only intended to illustrate the scheme of the present application and should not be understood as limiting.

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

[0038] It should also be noted here that in the embodiments of the present application, only a part of the components or assemblies may be shown for the sake of 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.

[0039] It should also be noted here that within the scope of the present application, the words "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 words also cover "substantially the same", "substantially equal", "substantially equal".

[0040] It should also be noted here that in the description of the present application, the orientation or positional relationship indicated by the terms "center", "longitudinal", "transverse", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer" and the like is based on the orientation or positional relationship shown in the drawings, and is only for the convenience of describing the present application and simplifying the description, and does not mean that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation, therefore it cannot be understood as a limitation on the present application. In addition, the terms "first", "second" are only for descriptive purposes and cannot be understood as indicating relative importance.

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

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

[0043] 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, 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.

[0044] 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 showing an application loader APP LOADER booting service processes of a dual-core system according to an embodiment of the present application is shown. Figure 3 A schematic diagram showing an application loader APP LOADER booting service processes of a triple-core system according to an embodiment of the present application is shown. Figure 4 A schematic diagram showing a synchronization manner among multiple service processes according to an embodiment of the present application is shown. Figure 5 A schematic diagram showing an access IO operation according to an embodiment of the present application is shown.

[0045] The present application is directed to a multi-core CPU system, including 2-core, 3-core and more processor cores, running a Linux operating system in an SMP (Symmetric Multi-Processing) manner. In an SMP system, multiple processor cores share the same operating system instance, and all cores are regarded as equivalent entities, equally accessing system resources such as memory, I / O devices, etc. After the Linux system is started, an application loader (APP LOADER) is started. The application loader identifies the number of cores of the CPU, and starts multiple applications to be hardened for a CPU with a core number not less than 2.

[0046] As shown in Figure 1 A software hardening method of a satellite software system includes the following steps:

[0047] Step 1. The application loader identifies the number of cores of the multi-core CPU, and starts multiple applications to be hardened according to the number of cores of the CPU. When the number of cores of the CPU is 2, 2 identical applications to be hardened are simultaneously started, corresponding to 2 identical service processes; when the number of cores of the CPU is greater than or equal to 3, 3 identical applications to be hardened are simultaneously started, corresponding to 3 identical service processes. The multiple applications to be hardened execute the same version file.

[0048] Step 2. When the multiple applications to be hardened 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 hardened, and binds the multiple applications to be hardened to multiple different CPU cores (CPU core). One application to be hardened corresponds to one service process. The application to be hardened corresponding to the master process is a master application to be hardened, and the application to be hardened corresponding to the slave process is a slave application to be hardened. One application to be hardened is bound to one CPU core.

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

[0050] Step 3. After the application to be hardened is started by the application loader, the keep-alive of the multiple applications to be hardened is performed respectively.

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

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

[0053] In one embodiment, the abnormal operation of the application to be hardened includes single event upset.

[0054] Add a checkpoint function 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 application to be hardened 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.

[0055] The multiple business processes call the checkpoint function: SEU_Check(int CheckID, int Count,...) every certain period of time: the parameters that need to be compared are placed in 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 are compared with each other through atomic locks and shared memory.

[0056] As shown in 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.

[0057] In one embodiment, the master process corresponding to the master to-be-strengthened application 102 obtains the input parameter data information of each slave process corresponding to the slave to-be-strengthened application 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.

[0058] 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 saved 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.

[0059] 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.

[0060] When the input parameters for the three business processes are different, all business processes roll back to the context and stack data of the previous save point and then continue execution. If rollback is triggered multiple times consecutively, the application bootstrap program is notified, and all business processes voluntarily exit execution. The application bootstrap program then restarts the three applications to be hardened. In other words, if all business processes return to the previous context and then trigger a parameter inconsistency exception at the same location, the application bootstrap program is notified to restart the three applications to be hardened.

[0061] like Figure 5 As shown, all functions that access I / O operations are executed only in the main process. When I / O operations such as hardware access occur in the main process, the main process performs the access normally and synchronizes the access results to the slave process through shared memory. The slave process is in a waiting state while the main process is accessing I / O.

[0062] Two applications to be hardened are launched, each corresponding to a business process, designated as master and slave processes. Three applications to be hardened are also launched, each corresponding to a business process, designated as master, slave, and slave processes. The business process corresponding to the master application 102 is the master process, and the business process corresponding to the slave application 103 is the slave process. Since all processes execute the same version file, when the I / O operation interface function is executed, the master process executes the I / O operation interface function normally and synchronizes the execution result to the slave process through shared memory or other means. During the execution of the master process, the slave process waits for the execution result from the master process to prevent I / O operations from being executed multiple times.

[0063] The software hardening method of this invention strengthens the program code flow of an SMP system and quickly repairs anomalies. Business processes run bound to CPU cores; when a single-event flip occurs within a CPU, the anomaly can be detected and quickly repaired, preventing abnormal data from affecting subsequent processes. When a single-event flip occurs in the stack data and global data of a process, it can be repaired by selecting 2 out of 3 from the results of other processes, achieving rapid anomaly repair.

[0064] The same business application version launches different applications to be hardened (MASTER_APP and one or more SLAVE_APPs). Data consistency is ensured through checkpoint verification among multiple applications to be hardened, and corresponding technologies are used to keep the master and slave processes running synchronously. The master and slave processes are bound to different CPU cores, and the operating system (application bootloader) schedules the master and slave processes to run on different cores without affecting each other.

[0065] 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.

[0066] 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 software hardening method of a satellite software system, characterized by, The method comprises the following steps: The number of cores of the multi-core CPU is identified by the application boot program, and a plurality of to-be-hardened applications are started according to the number of cores of the CPU, wherein: when the number of cores of the CPU is 2, 2 identical to-be-hardened applications are simultaneously started; when the number of cores of the CPU is greater than or equal to 3, 3 identical to-be-hardened applications are simultaneously started; When the plurality of to-be-hardened applications are started, a master process and one or more slave processes are determined from a plurality of service processes corresponding to the plurality of to-be-hardened applications by the application boot program, and the plurality of to-be-hardened applications are bound to a plurality of different CPU cores; A checkpoint function is added in the plurality of service processes, and the input parameters of the checkpoint function are parameters that need to be compared; and Whether the plurality of to-be-hardened applications are all normally running is determined by using the input parameters, and if not, a corresponding repair method is used according to the number of to-be-hardened applications, wherein: for 2 to-be-hardened applications, a method of rolling back or restarting the to-be-hardened applications of all service processes is used for repair; for 3 to-be-hardened applications, if one of the to-be-hardened applications is not normally running, the input parameters of the service process corresponding to the to-be-hardened application that is not normally running are repaired by using the input parameters of the service processes 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 of all service processes is used for repair.

2. The software hardening method of the satellite software system according to claim 1, wherein: The abnormal running of the to-be-hardened applications includes single event upset; and The plurality of service processes call the checkpoint function every certain program, put the parameters that need to be compared into indefinite parameters, and the checkpoint function has process synchronization function inside, each process waits at the same checkpoint, and when each service process enters the same checkpoint, whether the parameters are consistent is compared by using the atomic lock and shared memory mode.

3. The software hardening method of a satellite software system according to claim 2, characterized by, The master process obtains the data information of the input parameters of each slave process by using the atomic lock and shared memory mode, compares the input parameters at corresponding positions, and confirms whether the input parameters are consistent, if the input parameters corresponding to all service processes are equal, it indicates that each to-be-hardened application is normally running.

4. The software hardening method of a satellite software system according to claim 2, characterized by, When the number of CPU cores is 2, 2 identical to-be-hardened applications are simultaneously started, which correspond to 2 completely identical service processes; When the number of CPU cores is greater than or equal to 3, 3 identical to-be-hardened applications are simultaneously started, which correspond to 3 completely identical service processes.

5. The software hardening method of a satellite software system according to claim 3, characterized by, When the number of CPU cores is 2, 2 to-be-hardened applications are started, which correspond to a master process and a slave process, when the input parameters corresponding to the two service processes are consistent, the current code running context and stack data are saved, and each service process continues to execute; If part of the input parameters corresponding to the two service processes are inconsistent, all service processes are rolled back to the context position and stack data of the last saved point, and continue to execute; If the rollback is triggered continuously for multiple times, the application boot program is notified, all service processes actively exit execution, and the application boot program restarts 2 to-be-hardened applications. ​ 6. The software hardening method of a satellite software system according to claim 5, characterized by, When all business processes are restored to the last context position and execute to the same position again, the parameter inconsistency exception is triggered again, the application boot program is notified to restart the two to-be-hardened applications.

7. The software hardening method of a satellite software system according to claim 3, characterized by, When the number of CPU cores 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 of the three business processes are consistent, the respective 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 to-be-hardened application is not normally running, the input parameters of the business process of the to-be-hardened application that is not normally running are repaired using the input parameters of the business processes of the other two to-be-hardened applications that are normally running, after the repair, the three business processes continue to execute; When the input parameters of the three business processes are inconsistent, it indicates that the number of to-be-hardened applications that are not normally running is greater than 1, 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 are actively exited from execution, and the application boot program restarts the three to-be-hardened applications.

8. The software hardening method of a satellite software system according to claim 7, characterized by, When all business processes are restored to the last context position and execute to the same position again, the parameter inconsistency exception is triggered again, the application boot program is notified to restart the three to-be-hardened applications.

9. The software hardening method of a satellite software system according to claim 1, characterized by, Further comprising: 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 execution of the master process.

10. The software hardening method of a satellite software system according to claim 1, characterized by, Further comprising: After the application boot program starts the to-be-hardened applications, the keep-alive of the multiple to-be-hardened applications is performed, including: The respective to-be-hardened applications periodically report the state of the business process to the application boot program, the application boot program performs keep-alive on the to-be-hardened applications through the state message, when the state message of one to-be-hardened application is abnormal, the application boot program actively closes all to-be-hardened applications, and restarts the to-be-hardened applications.

Images